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


Overview


Readers will learn how to configure a site-to-site VPN between two EdgeRouters that use DHCP assigned (dynamic) Public IP addresses. Instead of peering with IP addresses, the VPN will be established between two hostnames (Fully Qualified Domain Names) provided by Dynamic DNS.

IMPORTANT: There is a bug currently affecting multiple FQDN site-to-site VPNs when using pre-shared-key authentication. To get around this issue please use the same pre-shared-key for all peers, or switch to RSA authentication.

 

NOTES & REQUIREMENTS:
Applicable to the latest EdgeOS firmware on 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 configuration used in this article.
 
Devices used in this article:

Table of Contents


  1. Frequently Asked Questions (FAQ)
  2. Network Diagram
  3. Steps: Policy-Based VPN using FQDNs
  4. Steps: Solutions for Connection Failures
  5. Steps: Testing & Verification
  6. Related Articles

FAQ


Back to Top

1. What site-to-site VPN types can be configured on EdgeOS when peering using hostnames/FQDNs?

You can configure Policy-Based and GRE over IPsec site-to-site VPNs when peering using hostnames.

2. What is the function of traffic offloading and how does it affect IPsec tunnels?

Offloading is used to execute functions of the router using the hardware directly which greatly increases performance. If traffic is not offloading, it is routed using the CPU with limited performance. Please see the Hardware Offloading article for more information.

 

Packets passed through an IPsec tunnel are eligible for offloading and thus routed via hardware when IPsec offloading is enabled. You can enable IPsec offloading via the Command Line Interface (CLI) with:

configure
set system offload ipsec enable
commit ; save
3. Do I need to create firewall rules for IPsec and exclude the traffic from NAT?

You do not need to create any firewall or NAT policies for IPsec if you check the Automatically open firewall and exclude from NAT box in the Graphical User Interface (GUI).

 

If you wish to create your own firewall/NAT policies, please follow the steps in the EdgeRouter - IPsec Site-to-Site VPN Additions and Changes (CLI) article.

4. What are the available encryption and hashing options (Security Associations / SAs) for Phase 1 (IKE) and Phase 2 (ESP)?

Encryption

  • AES128
  • AES256
  • AES128GCM128
  • AES256GCM128 
  • 3DES

Hashing

  • MD5
  • SHA1
  • SHA2-256
  • SHA2-384
  • SHA2-512

 

Please see the EdgeRouter - IPsec Site-to-Site VPN Additions and Changes (CLI) article for more information.

5. Can I configure these tunnels to use IKEv2 instead of IKEv1?

Yes, please see the EdgeRouter - IPsec Site-to-Site VPN Additions and Changes (CLI) article for more information.

6. How do I start troubleshooting if my VPN does not establish?
  • Send relevant traffic (ping) over the tunnel between two hosts located behind the EdgeRouters.
  • Verify the state of the VPN tunnel using the CLI.
  • Capture the IPsec traffic on the WAN interface using the CLI.
  • Analyze the VPN log messages.
  • Verify if any host-based firewalls are blocking the (ping) traffic.

 

All of these verification steps are shown in the Testing & Verification section.


Network Diagram


Back to Top

The network topology is shown below.

ER-R

  • eth0 (WAN) - 203.0.113.1 (dhcp) er-r.ubnt.com
  • eth1 (LAN) - 192.168.1.1/24

ER-L

  • eth0 (WAN) - 192.0.2.1 (dhcp) er-l.ubnt.com
  • eth1 (LAN) - 172.16.1.1/24


Steps: Policy-Based VPN using FQDNs


Back to Top

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

The ports and protocols relevant to IPsec are:

  1. UDP 500 (IKE)
  2. Protocol 50 (ESP)
  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 mirror images of each other. Only the prefixes defined in the proxy IDs will be carried over the tunnel. In the example, ER-L has the 192.168.1.0/24 present on the LAN side, whereas the ER-R side uses 172.16.1.0/24. The configuration below will primarily focus on ER-R.

GUI: Access the Graphical User Interface (GUI).

1. Define the IPsec peer and Security Associations (SAs) on ER-R (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-l.ubnt.com
Description: ipsec
Local IP: 0.0.0.0
Encryption: AES-128
Hash: SHA1
DH Group: 14
Pre-shared Secret: <secret>
Local subnet: 192.168.1.0/24
Remote subnet: 172.16.1.0/24

2. Define the IPsec peer and Security Associations (SAs) on ER-L (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-r.ubnt.com
Description: ipsec
Local IP: 0.0.0.0
Encryption: AES-128
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 key authentication to certificate-based (RSA) authentication
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-l.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-l.ubnt.com-tunnel-1
       left=0.0.0.0
       right=er-l.ubnt.com

3. Change the local IPsec interface address.

delete vpn ipsec site-to-site peer er-l.ubnt.com local-address
set vpn ipsec site-to-site peer er-l.ubnt.com dhcp-interface eth0
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-l.ubnt.com %any : PSK "<secret>" #RIGHT# #dhcp-interface=eth0#

sudo cat /etc/ipsec.conf   
conn peer-er-l.ubnt.com-tunnel-1
       #dhcp-interface=eth0
       left=203.0.113.1
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 the DHCP assigned IP address on the WAN interface, instead of 0.0.0.0.
show vpn ipsec sa
peer-er-l.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-l.ubnt.com authentication id @er-r.ubnt.com
set vpn ipsec site-to-site peer er-l.ubnt.com authentication remote-id @er-l.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-l.ubnt.com @er-r.ubnt.com @er-l.ubnt.com : PSK "<secret>" #dhcp-interface=eth0#

sudo cat /etc/ipsec.conf  
conn peer-er-l.ubnt.com-tunnel-1
       #dhcp-interface=eth0
       left=203.0.113.1
       leftid="@er-r.ubnt.com"
       right=er-l.ubnt.com
       rightid="@er-l.ubnt.com"

show vpn ipsec sa
peer-er-l.ubnt.com-tunnel-1: #1, ESTABLISHED, IKEv1, 10eb80b9f7d2b991:bf8b673e5eb44fc6
 local  'er-r.ubnt.com' @ 203.0.113.1
 remote 'er-l.ubnt.com' @ 192.0.2.1
NOTE: The ipsec.secrets file now contains no reference to %any. The ipsec.conf file now displays the leftid and rightid of the peers.
 
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 certificate that will be used for the RSA authentication.

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)
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-R is aBcDaBcD, whereas ER-L generated eFgHeFgH (shorted for visibility).

10. Copy the public portion of ER-L’s RSA key to ER-R 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 er-l rsa-key eFgHeFgH (ER-L public key)

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

delete vpn ipsec site-to-site peer er-l.ubnt.com authentication mode
delete vpn ipsec site-to-site peer er-l.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-l.ubnt.com authentication mode rsa
set vpn ipsec site-to-site peer er-l.ubnt.com authentication rsa-key-name er-l

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-l.ubnt.com-tunnel-1
       #dhcp-interface=eth0
       left=203.0.113.1
       leftid="@er-r.ubnt.com"
       right=er-l.ubnt.com
       rightid="@er-l.ubnt.com"
       authby=rsasig
       leftsigkey=localhost.pub
       rightsigkey=er-l.pub
NOTE: The ipsec.secrets file now contains no reference to any peers.

Steps: Testing & Verification


Back to Top

1. Verify the IPsec Security Associations (SAs) and tunnel status.

show vpn ipsec sa
peer-er-l.ubnt.com-tunnel-1: #1, ESTABLISHED, IKEv1, 10eb80b9f7d2b991:bf8b673e5eb44fc6
 local  'er-r.ubnt.com' @ 203.0.113.1
 remote 'er-l.ubnt.com' @ 192.0.2.1
 AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
 established 10s ago, reauth in 28176s
 peer-er-l.ubnt.com-tunnel-1: #1, INSTALLED, TUNNEL, ESP:AES_CBC-128/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
NOTE: If there is no (or only partial) output, the tunnel is not established. These types of tunnels will only establish if relevant traffic is sent over the link (sourced from a host behind the EdgeRouter). 

 

Verify that the in and out traffic counters are increasing at the same time and that the remote and local subnets are listed in the output.

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-l.ubnt.com-tunnel-1
       #dhcp-interface=eth0
       left=203.0.113.1
       leftid="@er-r.ubnt.com"
       right=er-l.ubnt.com
       rightid="@er-l.ubnt.com"
       leftsubnet=192.168.1.0/24
       rightsubnet=172.16.1.0/24
       ike=aes128-sha1-modp2048!
       keyexchange=ikev1
       ikelifetime=28800s
       esp=aes128-sha1-modp2048!
       keylife=3600s
       rekeymargin=540s
       type=tunnel
       compress=no
       authby=rsasig
       leftsigkey=localhost.pub
       rightsigkey=er-l.pub
       auto=route
       keyingtries=%forever
#conn peer-er-right.ubnt.com-tunnel-1

3. Capture the arrival of IKE/ESP traffic on the WAN interface.

sudo tcpdump -i eth0 -n udp dst port 500 or port 4500 or esp
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 I ident
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 R ident
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 I ident
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 R ident
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 I ident[E]
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 R ident[E]
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 2/others I oakley-quick[E]
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 2/others R oakley-quick[E]
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 2/others I oakley-quick[E]
IP 192.0.2.1 > 203.0.113.1: ESP(spi=0xc25e3a53,seq=0x1), length 164
IP 192.0.2.1 > 203.0.113.1: ESP(spi=0xc25e3a53,seq=0x2), length 164
IP 203.0.113.1 > 192.0.2.1: ESP(spi=0x216ec4ce,seq=0x1), length 148
IP 192.0.2.1 > 203.0.113.1: ESP(spi=0xc25e3a53,seq=0x3), length 68
NOTE: This is a live capture. If there is no output then the traffic is either not being generated or there is something blocking the traffic upstream.

4. Capture and analyze the IPsec VPN log messages.

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-l.ubnt.com-tunnel-1[1] to 192.0.2.1
[ENC] generating ID_PROT request 0 [ SA V V V V ]
[ENC] parsed ID_PROT response 0 [ SA V V V ]
[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
[IKE] authentication of 'er-l.ubnt.com' (myself) successful
[ENC] generating ID_PROT request 0 [ ID SIG N(INITIAL_CONTACT) ]
[ENC] parsed ID_PROT response 0 [ ID SIG ]
[CFG]   using trusted certificate "er-l.ubnt.com"
[IKE] authentication of 'er-l.ubnt.com' with RSA successful
[IKE] IKE_SA peer-er-l.ubnt.com-tunnel-1 established between 203.0.113.1[er-r.ubnt.com]..192.0.2.1[er-l.ubnt.com]
[ENC] generating QUICK_MODE request 3062958650 [ HASH SA No KE ID ID ]
[ENC] parsed QUICK_MODE response 3062958650 [ HASH SA No KE ID ID ]
[IKE] CHILD_SA peer-er-l.ubnt.com-tunnel-1{1} established with SPIs ca03_i cb9_o and TS 192.168.1.0/24 === 172.16.1.0/24
NOTE: This is also a live capture. Alternatively, you can use the show vpn log | no-more command to view the entire IPsec log history.

Related Articles


Back to Top