EdgeRouter - IPsec Dynamic Site-to-Site VPN using FQDNs

 Overview


Readers will learn how to configure a Policy-Based Site-to-Site IPsec VPN between two EdgeRouters that acquire a Public IP address using DHCP. In order to establish a tunnel using dynamic peer addresses, a service such as DynDNS (Dynamic DNS) can be used to peer with a Fully Qualified Domain Name (FQDN).

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). The latter type does NOT support dynamic peer addresses or FQDNs.

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. 

 

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 using FQDNs
  3. Steps: Solutions for Connection Failures
  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 EdgeRouters:

ER-Left

  1. eth0 (WAN) - 203.0.113.1 (dhcp) er-left.ubnt.com
  2. eth1 (LAN) - 192.168.1.1/24

ER-Right

  1. eth0 (WAN) - 192.0.2.1 (dhcp) er-right.ubnt.com
  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 routing and Dynamic DNS is already in place and that both peers are reachable using their respective FQDNs.

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 and peering address. 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 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: er-right.ubnt.com
Description: IPsec
Local IP: 0.0.0.0
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: We currently recommend using Local IP 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
  • Uncheck: Automatically open firewall and exclude from NAT
Peer: er-left.ubnt.com
Description: IPsec
Local IP: 0.0.0.0
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

Steps: Solutions for Connection Failures


Back to Top

If the VPN fails to establish for any number of peers there are three possible solutions:

  • Use the dhcp-interface command over local-address 0.0.0.0
  • Define Authentication IDs for each peer and the local device
  • Change from pre-shared keys to certificate-based authentication

 

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 configuration (only relevant output is shown).

show vpn
ipsec {
   site-to-site {
       peer er-right.ubnt.com {
           local-address 0.0.0.0
           }
       }
   }
...

sudo cat /etc/ipsec.secrets
%any %any : PSK "<secret>"


sudo cat /etc/ipsec.conf   
conn peer-er-right.ubnt.com-tunnel-1

       left=0.0.0.0
       right=er-right.ubnt.com

3. Change the local IPsec interface address.

delete vpn ipsec site-to-site peer er-right.ubnt.com local-address
set vpn ipsec site-to-site peer er-right.ubnt.com dhcp-interface eth0
info_i_25x25.png Note: The dhcp-interface and local-address statements cannot be used simultaneously, which is why the 0.0.0.0 address is removed from the configuration first.

4. Commit the changes and save the configuration.

commit ; save ; exit

5. Verify the IPsec Security Associations (SAs) and configuration changes (only relevant output is shown).

sudo cat /etc/ipsec.secrets
203.0.113.1 er-right.ubnt.com %any : PSK "<secret>" #RIGHT# #dhcp-interface=eth0#


sudo cat /etc/ipsec.conf   
conn peer-er-right.ubnt.com-tunnel-1
       #dhcp-interface=eth0
       left=203.0.113.1
info_i_25x25.png Note: The ipsec.secrets file now displays the FQDN of the peer as well as a link to the DHCP interface. The ipsec.conf file is also now linked to whatever IP is present on the DHCP interface, instead of 0.0.0.0.
show vpn ipsec sa
peer-er-right.ubnt.com-tunnel-1: #1, ESTABLISHED, IKEv1, 7d2d58dc63e145f6:99d93b7b64c51350

 local  '203.0.113.1' @ 203.0.113.1
 remote '192.0.2.1' @ 192.0.2.1

6. Define Authentication IDs for the peer and the local device.

configure
set vpn ipsec site-to-site peer er-right.ubnt.com authentication id @er-left.ubnt.com
set vpn ipsec site-to-site peer er-right.ubnt.com authentication remote-id @er-right.ubnt.com

7. Commit the changes and save the configuration.

commit ; save ; exit

8. Verify the IPsec Security Associations (SAs) and configuration changes (only relevant output is shown).

sudo cat /etc/ipsec.secrets
203.0.113.1 er-right.ubnt.com @er-left.ubnt.com @er-right.ubnt.com : PSK "<secret>" #dhcp-interface=eth0#


sudo cat /etc/ipsec.conf  
conn peer-er-right.ubnt.com-tunnel-1

       #dhcp-interface=eth0
       left=203.0.113.1
       leftid="@er-left.ubnt.com"
       right=er-right.ubnt.com
       rightid="@er-right.ubnt.com"

show vpn ipsec sa
peer-er-right.ubnt.com-tunnel-1: #1, ESTABLISHED, IKEv1, 10eb80b9f7d2b991:bf8b673e5eb44fc6

 local  'er-left.ubnt.com' @ 203.0.113.1
 remote 'er-right.ubnt.com' @ 192.0.2.1
info_i_25x25.png Note: The ipsec.secrets file now contains no reference to %any. The ipsec.conf file now displays the leftid and rightid of the peers (These values correspond to the remote-id and id in the configuration). The @ symbol is used to prevent the IDs from being resolved to an IP address. Please see the strongSwan documentation for more information.

9. Generate a RSA key on each of the routers (take note of the public portion).

generate vpn rsa-key
Generating 2048 bit rsa-key to /config/ipsec.d/rsa-keys/localhost.key

..............................................+++
..............................+++

Your new local RSA key has been generated
The public portion of the key is:

aBcDaBcD (output shortened)
info_i_25x25.png Note: The actual public portion of the key is longer than 8 characters. In this example the public portion of the RSA key of ER-Left is aBcDaBcD, whereas ER-Right generated eFgHeFgH.

10. Copy the public portion of ER-Right’s RSA key and define where the local key is stored.

configure
set vpn rsa-keys local-key file /config/ipsec.d/rsa-keys/localhost.key
set vpn rsa-keys rsa-key-name ERRight rsa-key eFgHeFgH (ER-Right public key)

11. Delete the current authentication method and pre-shared-secret.

delete vpn ipsec site-to-site peer er-right.ubnt.com authentication mode
delete vpn ipsec site-to-site peer er-right.ubnt.com authentication pre-shared-secret

12. Configure the RSA authentication method and link it to the rsa-key-name defined earlier.

set vpn ipsec site-to-site peer er-right.ubnt.com authentication mode rsa
set vpn ipsec site-to-site peer er-right.ubnt.com authentication rsa-key-name ERRight

13. Commit the changes and save the configuration.

commit ; save ; exit

14. Verify the IPsec configuration changes (only relevant output is shown).

sudo cat /etc/ipsec.secrets
: RSA /config/ipsec.d/rsa-keys/localhost.key


sudo cat /etc/ipsec.conf   
conn peer-er-right.ubnt.com-tunnel-1

       #dhcp-interface=eth0
       left=203.0.113.1
       leftid="@er-left.ubnt.com"
       right=er-right.ubnt.com
       rightid="@er-right.ubnt.com"
       authby=rsasig
       leftsigkey=localhost.pub
       rightsigkey=ERRight.pub
info_i_25x25.png Note: The ipsec.secrets file now contains no reference to any peers.


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-er-right.ubnt.com-tunnel-1: #1, ESTABLISHED, IKEv1, 10eb80b9f7d2b991:bf8b673e5eb44fc6

 local  'er-left.ubnt.com' @ 203.0.113.1
 remote 'er-right.ubnt.com' @ 192.0.2.1
 AES_CBC-256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
 established 10s ago, reauth in 28176s
 peer-er-right.ubnt.com-tunnel-1: #1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96/MODP_2048
   installed 10 ago, rekeying in 2658s, expires in 3591s
   in  ce5dcffa,    180 bytes,     3 packets,     5s ago
   out c4b4e6c0,    180 bytes,     3 packets,     5s 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: 5 minutes, since Jan 01 06:40:02 2015
 malloc: sbrk 376832, mmap 0, used 280024, free 96808
 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-er-right.ubnt.com-tunnel-1:  203.0.113.1...er-right.ubnt.com  IKEv1
peer-er-right.ubnt.com-tunnel-1:   local:  [er-left.ubnt.com] uses public key authentication
peer-er-right.ubnt.com-tunnel-1:    cert:  "er-left.ubnt.com"
peer-er-right.ubnt.com-tunnel-1:   remote: [er-right.ubnt.com] uses public key authentication
peer-er-right.ubnt.com-tunnel-1:    cert:  "er-right.ubnt.com"
peer-er-right.ubnt.com-tunnel-1:   child:  192.168.1.0/24 === 172.16.1.0/24 TUNNEL
Routed Connections:
peer-er-right.ubnt.com-tunnel-1{1}:  ROUTED, TUNNEL
peer-er-right.ubnt.com-tunnel-1{1}:   192.168.1.0/24 === 172.16.1.0/24
Security Associations (1 up, 0 connecting):
peer-er-right.ubnt.com-tunnel-1[1]: ESTABLISHED 203.0.113.1[er-left.ubnt.com]...192.0.2.1[er-right.ubnt.com]
peer-er-right.ubnt.com-tunnel-1[1]: IKEv1 SPIs: 578c174f70ca41b8_i* 6ac0f86c4f0c7688_r
peer-er-right.ubnt.com-tunnel-1[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
peer-er-right.ubnt.com-tunnel-1{1}:  INSTALLED, TUNNEL, ESP SPIs: ca058e33_i cb8af1b9_o
peer-er-right.ubnt.com-tunnel-1{1}:  AES_CBC_256/HMAC_SHA1_96, 120 bytes_i (2 pkts, 69s ago)
peer-er-right.ubnt.com-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-er-right.ubnt.com-tunnel-1
       #dhcp-interface=eth0
       left=203.0.113.1
       leftid="@er-left.ubnt.com"
       right=er-right.ubnt.com
       rightid="@er-right.ubnt.com"
       leftsubnet=192.168.1.0/24
       rightsubnet=172.16.1.0/24
       ike=aes256-sha1-modp2048!
       keyexchange=ikev1
       ikelifetime=28800s
       esp=aes256-sha1-modp2048!
       keylife=3600s
       rekeymargin=540s
       type=tunnel
       compress=no
       authby=rsasig
       leftsigkey=localhost.pub
       rightsigkey=ERRight.pub
       auto=route
       keyingtries=%forever
#conn peer-er-right.ubnt.com-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
[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-er-right.ubnt.com-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] (156 bytes)
[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (136 bytes)
[ENC] parsed ID_PROT response 0 [ SA V V V ]
[IKE] received XAuth vendor ID
[IKE] received DPD vendor ID
[IKE] received NAT-T (RFC 3947) vendor ID
[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (372 bytes)
[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (372 bytes)
[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
[IKE] authentication of 'er-left.ubnt.com' (myself) successful
[ENC] generating ID_PROT request 0 [ ID SIG N(INITIAL_CONTACT) ]
[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (348 bytes)
[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (316 bytes)
[ENC] parsed ID_PROT response 0 [ ID SIG ]
[CFG]   using trusted certificate "er-right.ubnt.com"
[IKE] authentication of 'er-right.ubnt.com' with RSA successful
[IKE] IKE_SA peer-er-right.ubnt.com-tunnel-1 established between 203.0.113.1[er-left.ubnt.com]..192.0.2.1[er-right.ubnt.com]
[IKE] scheduling reauthentication in 27804s
[IKE] maximum IKE_SA lifetime 28344s
[ENC] generating QUICK_MODE request 3062958650 [ HASH SA No KE ID ID ]
[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (444 bytes)
[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (444 bytes)
[ENC] parsed QUICK_MODE response 3062958650 [ HASH SA No KE ID ID ]
[IKE] CHILD_SA peer-er-right.ubnt.com-tunnel-1{1} established with SPIs ca03_i cb9_o and TS 192.168.1.0/24 === 172.16.1.0/24
[ENC] generating QUICK_MODE request 3062958650 [ HASH ]
[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (60 bytes)
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