EdgeRouter - IPsec Route-Based (VTI) Site-to-Site VPN to USG

 Overview


Readers will learn how to configure a Route-Based Site-to-Site IPsec VPN between an EdgeRouter and a UniFi Security Gateway (USG) using static routing.

A Route-Based VPN is characterized by the usage of Virtual Tunnel Interfaces (VTIs) and routing entries. This type of VPN differs from a Policy-Based VPN which relies on a definition of local and remote subnets (proxy IDs). This example focuses on using static routing, however it is also possible to run a dynamic routing protocol such as OSPF over the tunnel.

book_25x25.png    NOTES & REQUIREMENTS:

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

- UniFi Security Gateway (USG)

- Test clients behind the peers (Host1 and Server1)

Table of Contents


  1. Network Diagram
  2. Steps: Route-Based VPN
  3. Steps: USG VPN
  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 EdgeRouter and the USG:

ER-X

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

 USG

  1. gi0/0 (WAN) - 192.0.2.1
  2. gi0/1 (LAN) - 172.16.1.1/24
  3. vti64 -

image1.png


Steps: Route-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 Static VTI over IPsec tunnel (IPIP encapsulation). This means that packets will be routed over a VTI interface (vti0) and encrypted using IPsec afterwards. Static routes will be used to facilitate routing between the sites.

The first part of the configuration focuses on the ER, afterwards the VPN will be setup on the USG.

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: 192.0.2.1
Description: IPsec
Local IP: 203.0.113.1 (needs to be the local public IP address, not any)
Encryption: AES-256
Hash: SHA1
DH Group: 14
Pre-shared Secret: <secret>
Local subnet: 192.168.1.0/24 (does not matter because it will be removed later)
Remote subnet: 172.16.1.0/24 (does not matter because it will be removed later)
info_i_25x25.png Note: Currently the Route-Based VTI configuration does NOT support dynamic peer addresses or Fully Qualified Domain Names (FQDN) used by Dynamic DNS (DynDNS). The VTI endpoints need to connect to known IP addresses and do NOT work with local-address any or peer 0.0.0.0.

 

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

show vpn
ipsec {
   site-to-site {
       peer 192.0.2.1 {
           local-address 203.0.113.1
           tunnel 1 {
               esp-group FOO0
               local {
                   prefix 192.168.1.0/24
               }
               remote {
                   prefix 172.16.0.0/22
               }
           }
...

3. Remove the IPsec tunnel(s).

delete vpn ipsec site-to-site peer 192.0.2.1 tunnel 1

4. Create a VTI to be used by the VPN (this interface does not require a defined IP address).

set interfaces vti vti0
info_i_25x25.png Note: Unlike GRE tunnels, VTI interfaces do not add an additional 24 bytes of overhead. The MTU will be automatically lowered to accommodate the IPsec overhead. You may choose to increase or decrease this MTU based on your specific scenario using the set interfaces vti vti0 mtu <mtu-value> statement.

5. Create routing entries for the remote subnets pointing towards the VTI.

set protocols static interface-route 172.16.1.0/24 next-hop-interface vti0

6. Link the IPsec peer configuration to the VTI interface created earlier.

set vpn ipsec site-to-site peer 192.0.2.1 vti bind vti0
set vpn ipsec site-to-site peer 192.0.2.1 vti esp-group FOO0

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

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

8. Commit the changes.

commit

9. Save the configuration.

save

Steps: USG VPN


Back to Top

Please make sure that the latest stable version of UniFi is being used and that the device is capable of reaching the internet.

www.png   GUI STEPS: Access the UniFi Controller Web-Management (GUI).

1. Assign a public IP address to the USG.

Devices > USG > Configuration > WAN
Connection Type: Static IP

IP address: 192.0.2.1
Preferred DNS: 192.0.2.2
Subnet Mask: 255.255.255.252
Router: 192.0.2.2

2. Modify the LAN network or leave it at the default setting (depending on your scenario).

Settings > Networks > LAN > edit
Name: LAN

Purpose: Corporate
Parent Interface: LAN
Gateway/Subnet: 172.16.1.1/24
DHCP Server: Enable
DHCP Range: 172.16.1.10 - 172.16.1.150

3. Create a new network that will be used for IPsec (replace <secret> with your desired passphrase).

  • Show advanced options
  • Check Dynamic Routing
  • Check Perfect Forward Secrecy (PFS)
Settings > Networks > + Create New Network
Name: IPsec

Purpose: Site-to-Site VPN
VPN Type: IPsec VPN
Enabled: Enable this Site-to-Site VPN
Remote Subnets: 192.168.1.0/24
Peer IP: 203.0.113.1
Local WAN IP: 192.0.2.1
Pre-Shared Key: <secret>
IPsec Profile: Customized

Advanced Options
Key Exchange Version: IKEv1

Encryption: AES-256
HASH: SHA1
DH Group: 14
PFS: Enable Perfect Forward Secrecy
Dynamic Routing: Enabled (check)

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-192.0.2.1-tunnel-vti: #4, ESTABLISHED, IKEv1, 24d45792c4976ca4:f4b8de413b632a7c

 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 13s ago, reauth in 85578s
 peer-192.0.2.1-tunnel-vti: #1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_MD5_96
   installed 13 ago, rekeying in 42249s, expires in 43187s
   in  cf09bc59,    500 bytes,     5 packets,     5s ago
   out 769b07da,    500 bytes,     5 packets,     5s ago
   local  0.0.0.0/0
   remote 0.0.0.0/0

sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.2, Linux 3.10.14-UBNT, mips):

 uptime: 22 minutes, since Mar 12 09:34:36 2017
 malloc: sbrk 376832, mmap 0, used 272632, free 104200
 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 8
Listening IP addresses:
 203.0.113.1
 192.168.1.1
 10.255.12.1
Connections:
peer-192.0.2.1-tunnel-vti:  203.0.113.1...192.0.2.1  IKEv1
peer-192.0.2.1-tunnel-vti:   local:  [203.0.113.1] uses pre-shared key authentication
peer-192.0.2.1-tunnel-vti:   remote: [192.0.2.1] uses pre-shared key authentication
peer-192.0.2.1-tunnel-vti:   child:  0.0.0.0/0 === 0.0.0.0/0 TUNNEL
Routed Connections:
peer-192.0.2.1-tunnel-vti{1}:  ROUTED, TUNNEL
peer-192.0.2.1-tunnel-vti{1}:   0.0.0.0/0 === 0.0.0.0/0
Security Associations (1 up, 0 connecting):
peer-192.0.2.1-tunnel-vti[4]: ESTABLISHED 74 seconds ago, 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
peer-192.0.2.1-tunnel-vti[4]: IKEv1 SPIs: 24d45792c4976ca4_i f4b8de413b632a7c_r*, pre-shared key reauthentication in 23 hours
peer-192.0.2.1-tunnel-vti[4]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
peer-192.0.2.1-tunnel-vti{1}:  INSTALLED, TUNNEL, ESP SPIs: cf09bc59_i 769b07da_o
peer-192.0.2.1-tunnel-vti{1}:  AES_CBC_128/HMAC_MD5_96, 500 bytes_i (5 pkts, 66s ago), 500 bytes_o (5 pkts, 66s ago)
peer-192.0.2.1-tunnel-vti{1}:   0.0.0.0/0 === 0.0.0.0/0

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-192.0.2.1-tunnel-vti
       left=203.0.113.1
       right=192.0.2.1
       leftsubnet=0.0.0.0/0
       rightsubnet=0.0.0.0/0
       ike=aes256-sha256-modp2048!
       keyexchange=ikev1
       ikelifetime=86400s
       esp=aes128-md5!
       keylife=43200s
       rekeymargin=540s
       type=tunnel
       compress=no
       authby=secret
       mark=9437185
       auto=route
       keyingtries=%forever
#conn peer-192.0.2.1-tunnel-vti

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
[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-vti{1} established with SPIs cad56e88_i 86968a35_o and TS 0.0.0.0/0 === 0.0.0.0/0
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. Verify the ER state of the tunnel and capture the traffic that is sent over the tunnel:

show interfaces vti vti0
vti0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN group default

   link/ipip 203.0.113.1 peer 192.0.2.1
   inet 10.255.12.1/30 scope global vti0
      valid_lft forever preferred_lft forever

   RX:  bytes    packets     errors    dropped    overrun      mcast
         1600         19          0          0          0          0
   TX:  bytes    packets     errors    dropped    carrier collisions
         1332         14          0          0          0          0

show interfaces vti vti0 capture
IP 172.16.1.10 > 192.168.1.10: ICMP echo request, id 12993, seq 18, length 64

IP 192.168.1.10 > 172.16.1.10: ICMP echo reply, id 12993, seq 18, length 64
IP 172.16.1.10 > 192.168.1.10: ICMP echo request, id 12993, seq 19, length 64
IP 192.168.1.10 > 172.16.1.10: ICMP echo reply, id 12993, seq 19, length 64

6. 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