EdgeRouter - IPsec Policy-Based Site-to-Site VPN to RRAS

 Overview


Readers will learn how to configure a Policy-Based Site-to-Site IPsec VPN between an EdgeRouter and an Windows Server running the Routing and Remote Access (RRAS) role. The actual VPN settings will be configured on the Windows Server by the 'Connection Security Rules' using the Windows Firewall (not the RRAS VPN wizard). 

A Policy-Based VPN is characterized by the definition of local and remote subnets (proxy IDs). This type of VPN differs from a Route-Based VPN which is characterized by the usage of Virtual Tunnel Interfaces (VTIs) and routing entries.

book_25x25.png    NOTES & REQUIREMENTS:

Applicable to EdgeOS 1.9.7 + firmware in all EdgeRouter models. Knowledge of the Command Line Interface (CLI), UniFi Controller, and basic networking knowledge is required. Please see the Related Articles below for more information and see the attachments for the configurations used in this article.

 

Equipment used in this article:

- EdgeRouter-X (ER-X)

- Windows Server 2016 with RRAS role

- Test clients behind the peers (Host1 and Host2)

Table of Contents


  1. Network Diagram
  2. Steps: Policy-Based VPN
  3. Steps: RRAS VPN
  4. Steps: Testing & Verification
  5. Related Articles

Network Diagram


Back to Top

The network topology is shown below. The following interfaces are in use on the EdgeRouter and the Windows Server:

ER-X

  1. eth0 (WAN) - 203.0.113.1
  2. eth1 (LAN) - 192.168.1.1/24

Windows Server

  1. eth0 (WAN) - 192.0.2.1
  2. eth1 (LAN) - 172.16.1.1/24


Steps: Policy-Based VPN


Back to Top

For the purpose of this article it is assumed that the routing and interface configuration is already in place and that reachability has been tested.

The UDP ports and protocols relevant to IPsec are:

  1. UDP 500 (IKE)
  2. ESP (Protocol 50)
  3. UDP 4500 (NAT-T)

The type of VPN that will be created is called a Policy-Based VPN which uses remote and local subnets, otherwise known as proxy IDs. These values need to match exactly between the two peers and need to be mirrored images of each other. Only the prefixes defined in the proxy IDs will be carried over the tunnel. In the example ER has the 192.168.1.0/24 present on the LAN side, whereas the UniFi side uses 172.16.1.0/24.

The first part of the configuration focuses on the ER, afterwards the VPN will be set up on the Windows Server.

www.png  GUI STEPS: Access the router's Web-Management Portal (GUI).

1. Define the IPsec peer and Security Associations (SAs) on the ER (replace <secret> with your desired passphrase).

VPN > IPsec Site-to-Site > +Add Peer

  • Show advanced options
  • Automatically open firewall and exclude from NAT
Peer: 192.0.2.1
Description: IPsec
Local IP: 203.0.113.1
Encryption: AES-128
Hash: SHA1
DH Group: 2
Pre-shared Secret: <secret>
Local subnet: 192.168.1.0/24
Remote subnet: 172.16.1.0/24 
info_i_25x25.png Note: It is also possible to use a non-static IP address for the WAN connection. For PPPoE interfaces or load-balancing scenarios it is currently recommend to use 0.0.0.0 over Local IP ‘any’.

 

 

CLI_circle.png  CLI STEPS: Access the command line interface (CLI). You can do this using the CLI button in the GUI or by using a program such as PuTTY.

1. Enter configuration mode.

configure

2. Display the current IPsec VPN peer configuration (only relevant output is shown).

show vpn
ipsec {
   esp-group FOO0 {
       lifetime 3600
pfs enable

       proposal 1 {
   encryption aes128
hash sha1  

       }
}

...

3. Disable Perfect Forward Secrecy (PFS)

set vpn ipsec esp-group FOO0 pfs disable

4. (Optional) If your WAN connection uses DHCP, remove the local IPsec peer address.

delete vpn ipsec site-to-site peer 192.0.2.1 local-address

5. (Optional) If your WAN connection uses DHCP,  define the local IPsec DHCP peer address for the WAN interface.

set vpn ipsec site-to-site peer 192.0.2.1 dhcp-interface eth0

6. (Optional) Enable the IPsec offloading feature to increase ESP (not IKE) performance.

set system offload ipsec enable (this requires a reboot to become active)

7. Commit the changes and save the configuration.

commit ; save

Steps: RRAS VPN


Back to Top

Please make sure that the Windows Firewall feature is not disabled and that the device is capable of reaching the internet. The actual VPN will be initiated by 'Connection Security Rules' using the Windows Firewall feature.

www.png  WINDOWS STEPS: Login to the Windows Server

1. Install the Routing and Remote Access (RRAS) role.

Server Manager > Manage > Add Roles and Features > Remote Access > DirectAccess And VPN (RAS) + Routing

2. Enable the RRAS feature for LAN Routing.

Routing and Remote Access Console (RRAS) > Configure and Enable Routing and Remote Access > Custom Configuration > LAN Routing

 

3. Start the RRAS service.

4. Define the Connection Security Rules in the Windows Firewall.

Windows Firewall with Advanced Security Console > Connection Security Rules > New Rule

Rule Type: Tunnel
Tunnel Type: Custom configuration
No, Send all network traffic that matches this connection security rule through the tunnel
Requirements: Require authentication for inbound and outbound connections

Define the tunnel endpoints:

Computers in endpoint 1: 172.16.1.0/24
Local tunnel endpoint 1: 192.0.2.1

Computers in endpoint 2: 192.168.1.0/24
Local tunnel endpoint 2: 203.0.113.1
info_i_25x25.png Note: The terms used in the wizard 'endpoint 1' and 'endpoint 2' refer to the local and remote sites. Endpoint 1 refers to the local site (ie the external IP and internal subnet of the RRAS server) and endpoint 2 refers to the remote site (ie the external IP and internal subnet of the EdgeRouter).

 

 

 

 

Define the authentication methods (replace <secret> with your desired passphrase):

Authentication Methods > Advanced > Customize > First Authentication Methods > Add

Preshared key: <secret>
 

5. Apply the rule to the relevant network locations and give it a name (IPsec in this example).

6. (Optional) Customize the Security Associations (SAs) on the Windows Server.

The tunnel encryption, hashing and lifetime settings can be altered under the properties of the 'Windows Firewall with Advanced Security Console'.

Windows Firewall with Advanced Security on Local Computer > Properties > IPsec Settings > IPsec Defaults > Customize

info_i_25x25.png Note: Phase 1 (IKE) is indicated as 'Key Exchange (Main Mode) and phase 2 (ESP) is indicated as 'Data Protection (Quick Mode)'. Another important distinction is that the IKE/ESP lifetimes are configured as minutes, not seconds.

 


Steps: Testing & Verification


Back to Top

After configuring the IPsec VPN, verify the connection/state using the following commands.

1. Verify the IPsec Security Associations (SAs) and status on the ER:

show vpn ipsec sa
peer-192.0.2.1-tunnel-1: #1, ESTABLISHED, IKEv1, 95360d2823c27bce:7c2fd132ab42aac1
local '203.0.113.1' @ 203.0.113.1
remote '192.0.2.1' @ 192.0.2.1
AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
established 79s ago, reauth in 28017s
peer-192.0.2.1-tunnel-1: #1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_SHA1_96
installed 79 ago, rekeying in 2693s, expires in 3521s
in c2cc1044, 400 bytes, 10 packets, 9s ago
out 05afb9b4, 600 bytes, 10 packets, 9s ago
local 192.168.1.0/24
remote 172.16.1.0/24

sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.2, Linux 3.10.14-UBNT, mips):
uptime: 107 seconds, since Sep 13 17:41:14 2017
malloc: sbrk 376832, mmap 0, used 272336, free 104496
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
Listening IP addresses:
203.0.113.1
192.168.1.1
Connections:
peer-192.0.2.1-tunnel-1: 203.0.113.1...192.0.2.1 IKEv1
peer-192.0.2.1-tunnel-1: local: [203.0.113.1] uses pre-shared key authentication
peer-192.0.2.1-tunnel-1: remote: [192.0.2.1] uses pre-shared key authentication
peer-192.0.2.1-tunnel-1: child: 192.168.1.0/24 === 172.16.1.0/24 TUNNEL
Routed Connections:
peer-192.0.2.1-tunnel-1{1}: ROUTED, TUNNEL
peer-192.0.2.1-tunnel-1{1}: 192.168.1.0/24 === 172.16.1.0/24
Security Associations (1 up, 0 connecting):
peer-192.0.2.1-tunnel-1[1]: ESTABLISHED 99 seconds ago, 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
peer-192.0.2.1-tunnel-1[1]: IKEv1 SPIs: 95360d2823c27bce_i* 7c2fd132ab42aac1_r, pre-shared key reauthentication in 7 hours
peer-192.0.2.1-tunnel-1[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
peer-192.0.2.1-tunnel-1{1}: INSTALLED, TUNNEL, ESP SPIs: c2cc1044_i 05afb9b4_o
peer-192.0.2.1-tunnel-1{1}: AES_CBC_128/HMAC_SHA1_96, 480 bytes_i (12 pkts, 3s ago), 720 bytes_o (12 pkts, 3s ago)
peer-192.0.2.1-tunnel-1{1}: 192.168.1.0/24 === 172.16.1.0/24

2. Verify the ER IPsec strongSwan configuration:

sudo cat /etc/ipsec.conf
# generated by /opt/vyatta/sbin/vpn-config.pl


config setup

conn %default
       keyexchange=ikev1

conn peer-192.0.2.1-tunnel-1
       left=203.0.113.1
       right=192.0.2.1
       leftsubnet=192.168.1.0/24
       rightsubnet=172.16.1.0/24
       ike=aes128-sha1-modp1024!
       keyexchange=ikev1
       ikelifetime=28800s
       esp=aes128-sha1!
       keylife=3600s
       rekeymargin=540s
       type=tunnel
       compress=no
       authby=secret
       auto=route
       keyingtries=%forever
#conn peer-192.0.2.1-tunnel-1

3. Capture the arrival of IKE traffic on the ER external WAN interface:

sudo tcpdump -i eth0 -n udp dst port 500   
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 I ident
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 I ident[E]
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident[E]
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 2/others I oakley-quick[E]
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 2/others R oakley-quick[E]
info_i_25x25.png Note: This is a live capture. If there is no output that means that the traffic is either not being generated on the client, or there is something blocking the traffic upstream.

4. Capture the ER IPsec VPN logs:

sudo swanctl --log
15[KNL] creating acquire job for policy 192.168.1.1/32[tcp/44385] === 172.16.1.10/32[tcp/https] with reqid {1}
15[IKE] initiating Main Mode IKE_SA peer-192.0.2.1-tunnel-1[1] to 192.0.2.1
15[ENC] generating ID_PROT request 0 [ SA V V V V ]
15[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (156 bytes)
13[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (212 bytes)
13[ENC] parsed ID_PROT response 0 [ SA V V V V V V ]
13[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
15[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
15[ENC] generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
11[ENC] parsed ID_PROT response 0 [ ID HASH ]
11[IKE] IKE_SA peer-192.0.2.1-tunnel-1[1] established between 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
11[ENC] generating QUICK_MODE request 3410743081 [ HASH SA No ID ID ]
15[ENC] parsed QUICK_MODE response 3410743081 [ HASH SA No ID ID ]
15[IKE] CHILD_SA peer-192.0.2.1-tunnel-1{1} established with SPIs c2cc144_i 059b4_o and TS 192.168.1.0/24 === 172.16.1.0/24
info_i_25x25.png Note: This is also live capture. If there is no output that means that the traffic is either not being allowed through the firewall. Alternatively you can use the show vpn log | no-more command to view the entire IPsec log history.

5. Verify the Main Mode (IKE) and Quick Mode (ESP) IPsec Security Associations (SAs) on the Windows Server:

Windows Firewall with Advanced Security Console > Monitoring > Security Associations

 

 

info_i_25x25.png Note: You will NOT be able to initiate the VPN from the RRAS server itself or reach the ER subnet. The reason is that the RRAS server will still route to the remote subnet (192.168.1.0/24) using the default route (route print -4). All traffic that arrives from clients behind the RRAS server (Host2 in this example) will be subjected to the firewall rule and forwarded over the VPN. In short you will be able to ping from clients behind the RRAS server to iniate the VPN, not the RRAS server itself.

6. Send traffic over the tunnel from Host1 to Host2 and vice versa:

ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.

64 bytes from 192.168.1.10: icmp_seq=1 ttl=63 time=45.9 ms
64 bytes from 192.168.1.10: icmp_seq=2 ttl=63 time=45.2 ms
64 bytes from 192.168.1.10: icmp_seq=3 ttl=63 time=45.5 ms

ping 172.16.1.10
PING 172.16.1.10 (172.16.1.10) 56(84) bytes of data.

64 bytes from 172.16.1.10: icmp_seq=1 ttl=63 time=43.9 ms
64 bytes from 172.16.1.10: icmp_seq=2 ttl=63 time=44.1 ms
64 bytes from 172.16.1.10: icmp_seq=3 ttl=63 time=44.4 ms

Related Articles


Back to Top