info_i_25x25.png See important information about Ubiquiti Devices and KRACK Vulnerability in this article. We will update this document as more information becomes available.

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

 Overview


Readers will learn how to configure a Policy-Based Site-to-Site IPsec VPN between two EdgeRouters.

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. Please refer to the EdgeRouter - IPsec Route-Based (VTI) Site-to-Site VPN article for information on how to set up a Route-Based VPN. If you are using a DynDNS setup with hostnames, then please refer to our EdgeRouter - IPsec Dynamic Site-to-Site VPN using FQDNs article.

book_25x25.png    NOTES & REQUIREMENTS:

Applicable to EdgeOS 1.9.7 + firmware in all EdgeRouter models. Knowledge of the Command Line Interface (CLI), 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)

- Test clients behind the peers (Host1 and Server1)

Table of Contents


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

Network Diagram


Back to Top

The network topology is shown below. The following interfaces are in use on the EdgeRouters:

ER-Left

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

ER-Right

  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-Left has the 192.168.1.0/24 present on the LAN side, whereas the ER-Right side uses 172.16.1.0/24.

The configuration will mainly focus on ER-Left. The configuration of ER-Right will be nearly identical with the exception of the defined subnets. Only the places where the configuration of ER-Right differs will be included in the output below.

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

1. Define the IPsec peer and Security Associations (SAs) on ER-Left (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-256
Hash: SHA1
DH Group: 14
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. In the case of DHCP, please proceed to the CLI steps below to change the local address value (or you can try setting the Local IP to 0.0.0.0). For PPPoE interfaces or load-balancing scenarios it is currently recommend to use 0.0.0.0 over Local IP ‘any’. 

 

 

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

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

  • Show advanced options
  • Automatically open firewall and exclude from NAT
Peer: 203.0.113.1
Description: IPsec
Local IP: 192.0.2.1
Encryption: AES-256
Hash: SHA1
DH Group: 14
Pre-shared Secret: <secret>
Local subnet: 172.16.1.0/24 
Remote subnet: 192.168.1.0/24

info_i_25x25.png Note: TheThe GUI does not show all of the available hashing/encryption options such as SHA256/384/512 and the Galois/Counter Mode (GCM) ciphers. If you leave the 'advanced options' box unchecked then the router will use its default settings, which are:

  • Encryption: AES-128
  • Hash: SHA1
  • DH Group: 14

Whatever SAs you choose, make sure that the values match on both sides and that the remote and local subnets are mirrored on both peers. 

 

 

CLI_circle.png  CLI STEPS (DHCP): 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 {
   site-to-site {
       peer 192.0.2.1 {
           local-address 203.0.113.1
           }
...

3. (Optional) Remove the local IPsec peer address.

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

4. (Optional) 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

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

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

6. Commit the changes.

commit

7. Save the configuration.

save 

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:

show vpn ipsec sa
peer-192.0.2.1-tunnel-1: #1, ESTABLISHED, IKEv1, 184447c009d51f80:14cc0f13aff401c0

 local  '203.0.113.1' @ 203.0.113.1
 remote '192.0.2.1' @ 192.0.2.1
 AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
 established 237s ago, reauth in 85347s
 peer-192.0.2.1-tunnel-1: #1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_MD5_96
   installed 237 ago, rekeying in 41939s, expires in 42964s
   in  cb321982,    180 bytes,     3 packets,   231s ago
   out 5d4174b1,    180 bytes,     3 packets,   231s 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: 10 minutes, since Mar 12 09:05:48 2017
 malloc: sbrk 376832, mmap 0, used 269320, free 107512
 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 5 minutes 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: 184447c009d51f80_i* 14cc0f13aff401c0_r, pre-shared key reauthentication in 23 hours
peer-192.0.2.1-tunnel-1[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
peer-192.0.2.1-tunnel-1{1}:  INSTALLED, TUNNEL, ESP SPIs: cb321982_i 5d4174b1_o
peer-192.0.2.1-tunnel-1{1}:  AES_CBC_128/HMAC_MD5_96, 180 bytes_i (3 pkts, 324s ago), 180 bytes_o (3 pkts, 324s ago)
peer-192.0.2.1-tunnel-1{1}:   192.168.1.0/24 === 172.16.1.0/24

2. Verify the 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=aes256-sha256-modp2048!
       keyexchange=ikev1
       ikelifetime=86400s
       esp=aes128-md5!
       keylife=43200s
       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 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 IPsec VPN logs:

sudo swanctl --log
[KNL] creating acquire job for policy 192.168.1.10/32[icmp/8] === 172.16.1.10/32[icmp/8] with reqid {1}

[IKE] initiating Main Mode IKE_SA peer-192.0.2.1-tunnel-1[1] to 192.0.2.1
[ENC] generating ID_PROT request 0 [ SA V V V V ]
[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (160 bytes)
[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (108 bytes)
[ENC] parsed ID_PROT response 0 [ SA V ]
[IKE] received NAT-T (RFC 3947) vendor ID
[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
[ENC] parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
[ENC] generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
[ENC] parsed ID_PROT response 0 [ ID HASH ]
[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]
[ENC] generating QUICK_MODE request 561157166 [ HASH SA No ID ID ]
[ENC] parsed QUICK_MODE response 561157166 [ HASH SA No ID ID N((24576)) ]
[IKE] CHILD_SA peer-192.0.2.1-tunnel-1{1} established with SPIs cb321982_i 5d4174b1_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. Send traffic over the tunnel from Server1 to Host1 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