EdgeRouter - IPsec Site-to-Site VPN behind NAT

Overview


Readers will learn how to configure a Policy-Based Site-to-Site IPsec VPN between two EdgeRouters, where one of the routers is located behind a NAT (Network Address Translation) device.

book_25x25white.png

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.

 

Equipment used in this article:

EdgeRouter-4 (ER-4)

- Test clients


Table of Contents


  1. Network Diagram
  2. Steps: Approach #1 - Peer with 0.0.0.0 Address
  3. Steps: Approach #2 - Peer with Authentication ID
  4. Steps: Testing & Verification
  5. Related Articles

Network Diagram


Back to Top

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

ER-L

  • eth0 (WAN) - 203.0.113.1
  • eth1 (LAN) - 192.168.1.1/24

ER-R

  • eth0 (WAN) - 10.255.12.2/30
  • eth1 (LAN) - 172.16.1.1/24

Translating Router

  • WAN - 192.0.2.1
  • LAN - 10.255.12.1/30

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 protocol IPsec uses 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-Right side uses 172.16.1.0/24.

The biggest challenge that faces this type of setup is that ER-R does not have a public IP address and is sitting behind a NAT device. The ESP (Encapsulated Security Payload) traffic that is used by IPsec cannot be port-forwarded or translated in a regular manner. For this reason, NAT-T (NAT-Traversal) is used encapsulate the ESP traffic into UDP using port 4500. The router in front of ER-R needs to be configured to forward both UDP port 4500 and UDP port 500 to the EdgeRouter. This article does not focus on the configuration of this device and assumes that these forwarding rules are already set up.

There are two approaches to successfully setup a Site-to-Site connection between the IPsec peers:

  1. Configure the non-NAT peer (ER-L) to peer with a 0.0.0.0 address.
  2. Configure the NAT-peer (ER-R) to peer using the public IP address of the NAT router (192.0.2.1) as its authentication ID.  

Steps: Approach #1 - Peer with 0.0.0.0 Address


Back to Top

A local IPsec L2TP server must not be configured if the IPsec site-to-site peer address is set to 0.0.0.0. Neither protocol will function properly in this scenario because it is unclear whether the incoming IKE connection requests are from a site-to-site client with a dynamic IP address or an L2TP remote access client.

info_i_25x25white.png

NOTE: If the peering address is set to 0.0.0.0 then the router will never try to initiate IPsec tunnels and will only respond to incoming requests.

 

GUI: Access the Graphical User Interface.

1. 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: 0.0.0.0
Description: IPsec
Local IP: 203.0.113.1
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-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: 203.0.113.1
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: Approach #2 - Peer with Authentication ID


Back to Top

GUI: Access the Graphical User Interface.

1. 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: 192.0.2.1
Description: IPsec
Local IP: 203.0.113.1
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-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: 203.0.113.1
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

 

CLI: Access the Command Line Interface. 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. Set the Authentication ID to the public IP address of the translating router. 

set vpn ipsec site-to-site peer 203.0.113.1 authentication id 192.0.2.1

3. Commit the changes and save the configuration.

commit ; save

Steps: Testing & Verification


Back to Top

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

show vpn ipsec sa
peer-203.0.113.1-tunnel-1: #1, ESTABLISHED, IKEv1, 7c7fa3eb7eb59546:7c057264ab063f76

local '192.0.2.1' @ 10.255.12.2
remote '203.0.113.1' @ 203.0.113.1
AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
established 76s ago, reauth in 28005s
peer-203.0.113.1-tunnel-1: #1, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-128/HMAC_SHA1_96/MODP_2048
installed 76 ago, rekeying in 2562s, expires in 3526s
in c1f5b727, 180 bytes, 3 packets, 70s ago
out cb2e250b, 180 bytes, 3 packets, 70s ago
local 172.16.1.0/24
remote 192.168.1.0/24
info_i_25x25white.png

NOTE: If there is no (or only partial) output, the tunnel is not established. Remember that these types of tunnels will only establish if you sent relevant traffic 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.

sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.2, Linux 3.10.20-UBNT, mips64):
uptime: 2 minutes, since Oct 02 14:19:24 2017
malloc: sbrk 410768, mmap 0, used 276376, free 134392
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
Listening IP addresses:
10.255.12.2
172.16.1.1
172.30.1.1
Connections:
peer-203.0.113.1-tunnel-1: 0.0.0.0...203.0.113.1 IKEv1
peer-203.0.113.1-tunnel-1: local: [192.0.2.1] uses pre-shared key authentication
peer-203.0.113.1-tunnel-1: remote: [203.0.113.1] uses pre-shared key authentication
peer-203.0.113.1-tunnel-1: child: 172.16.1.0/24 === 192.168.1.0/24 TUNNEL
Routed Connections:
peer-203.0.113.1-tunnel-1{1}: ROUTED, TUNNEL
peer-203.0.113.1-tunnel-1{1}: 172.16.1.0/24 === 192.168.1.0/24
Security Associations (1 up, 0 connecting):
peer-203.0.113.1-tunnel-1[1]: ESTABLISHED 88 seconds ago, 10.255.12.2[192.0.2.1]...203.0.113.1[203.0.113.1]
peer-203.0.113.1-tunnel-1[1]: IKEv1 SPIs: 7c7fa3eb7eb546_i* 7c0572663f76_r, pre-shared key reauthentication in 7 hours
peer-203.0.113.1-tunnel-1[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
peer-203.0.113.1-tunnel-1{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: c1f5b727_i cb2e250b_o
peer-203.0.113.1-tunnel-1{1}: AES_CBC_128/HMAC_SHA1_96, 180 bytes_i (3 pkts, 82s ago), 180 bytes_o (3 pkts, 83s ago)
peer-203.0.113.1-tunnel-1{1}: 172.16.1.0/24 === 192.168.1.0/24

2. Verify the IPsec strongSwan configuration file.

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


config setup

conn %default
       keyexchange=ikev1

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

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

0.0.0.0 203.0.113.1 192.0.2.1 : PSK "<secret>" #LEFT#
info_i_25x25white.png

NOTE: the ipsec.secrets file lists the Local IP address first (0.0.0.0) followed by the remote peer address (203.0.113.1), followed by the Authentication ID (192.0.2.1).

3. Capture the IKE traffic on the WAN interface.

sudo tcpdump -i eth0 -n udp dst port 4500 or 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
14:20:48.416654 IP 10.255.12.2.500 > 203.0.113.1.500: isakmp: phase 1 I ident
14:20:48.423597 IP 203.0.113.1.500 > 10.255.12.2.500: isakmp: phase 1 R ident
14:20:48.937831 IP 10.255.12.2.500 > 203.0.113.1.500: isakmp: phase 1 I ident
14:20:49.650892 IP 203.0.113.1.500 > 10.255.12.2.500: isakmp: phase 1 R ident
14:20:50.163656 IP 10.255.12.2.4500 > 203.0.113.1.4500: NONESP-encap: isakmp: phase 1 I ident[E]
14:20:50.170501 IP 203.0.113.1.4500 > 10.255.12.2.4500: NONESP-encap: isakmp: phase 1 R ident[E]
14:20:50.686856 IP 10.255.12.2.4500 > 203.0.113.1.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
14:20:51.398714 IP 203.0.113.1.4500 > 10.255.12.2.4500: NONESP-encap: isakmp: phase 2/others R oakley-quick[E]
14:20:51.912250 IP 10.255.12.2.4500 > 203.0.113.1.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
14:20:53.825375 IP 10.255.12.2.4500 > 203.0.113.1.4500: UDP-encap: ESP(spi=0xcb2e250b,seq=0x1), length 100
14:20:53.827659 IP 203.0.113.1.4500 > 10.255.12.2.4500: UDP-encap: ESP(spi=0xc1f5b727,seq=0x1), length 100
14:20:54.835061 IP 10.255.12.2.4500 > 203.0.113.1.4500: UDP-encap: ESP(spi=0xcb2e250b,seq=0x2), length 100
14:20:54.836919 IP 203.0.113.1.4500 > 10.255.12.2.4500: UDP-encap: ESP(spi=0xc1f5b727,seq=0x2), length 100
info_i_25x25white.png

NOTE: This is a live capture. If there is no output that means that the traffic is either not being generated by the peer(s), 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 172.16.1.10/32[icmp] === 192.168.1.10/32[icmp] with reqid {1}

[IKE] initiating Main Mode IKE_SA peer-203.0.113.1-tunnel-1[1] to 203.0.113.1
[ENC] generating ID_PROT request 0 [ SA V V V V ]
[NET] sending packet: from 10.255.12.2[500] to 203.0.113.1[500] (156 bytes)
[NET] received packet: from 203.0.113.1[500] to 10.255.12.2[500] (136 bytes)
[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] local host is behind NAT, sending keep alives
[ENC] generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
[ENC] parsed ID_PROT response 0 [ ID HASH ]
[IKE] IKE_SA peer-203.0.113.1-tunnel-1[1] established between 10.255.12.2[192.0.2.1]...203.0.113.1[203.0.113.1]
[IKE] scheduling reauthentication in 28081s
[IKE] maximum IKE_SA lifetime 28621s
[ENC] generating QUICK_MODE request 896435043 [ HASH SA No KE ID ID ]
[ENC] parsed QUICK_MODE response 896435043 [ HASH SA No KE ID ID ]
[IKE] CHILD_SA peer-203.0.113.1-tunnel-1{1} established with SPIs c1f27_i cb2e2b_o and TS 172.16.1.0/24 === 192.168.1.0/24
info_i_25x25white.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.


Related Articles


Back to Top

We're sorry to hear that!