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. 

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: 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. The following interfaces are in use on the routers:

ER-L (Left)

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

ER-R (Right)

  • 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 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 biggest challenge that faces this type of setup is that ER-Right 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 the 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-Right should be configured to port-forward both UDP 4500 and UDP 500 to the EdgeRouter. This article does not focus on the configuration of this device and assumes that these forwarding rules are already setup.

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

  1. Configure the non-NAT peer (ER-Left in this example) to peer with a 0.0.0.0 address.
  2. Configure the NAT-peer (ER-Right in this example) 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_25x25.png Note: If the peering address is set to 0.0.0.0 then the router will never try to initiate sessions and will only respond to incoming requests.

 

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: 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-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: 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
info_i_25x25.png Note: We currently recommend using Local IP 0.0.0.0 over Local IP any.

 


Steps: Approach #2 - Peer with Authentication ID


Back to Top

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-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-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: 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
info_i_25x25.png Note: We currently recommend using Local IP 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. 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

After configuring the IPsec VPN, verify the connection/state using the following commands (this output is from approach #2):

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

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

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 on ER-Right:

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_25x25.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 arrival of IKE and NAT-T traffic on the external 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_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 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_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