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


Readers will learn how to configure a Route-Based Site-to-Site IPsec VPN between two EdgeRouters.

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 and exchanging routes using a routing protocol such as OSPF. Please refer to the EdgeRouter - IPsec Policy-Based Site-to-Site VPN article for information on how to set up a Policy-Based VPN. 

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: Route-Based VPN
  3. Steps: Testing & Verification
  4. Related Articles

Network Diagram

Back to Top


  1. eth0 (WAN) -
  2. eth1 (LAN) -
  3. vti0 -


  1. eth0 (WAN) -
  2. eth1 (LAN) -
  3. vti0 -

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. This differs from using GRE (Generic Routing Encapsulation) tunnels (tun0) which utilize GRE over IPsec.

The configuration will mainly focus on ER-R. The configuration of ER-L will be nearly identical with the exception of the defined subnets and peering address. Only the places where the configuration of ER-L 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-R (replace <secret> with your desired passphrase).

VPN > IPsec Site-to-Site > +Add Peer

  • Show advanced options
  • Automatically open firewall and exclude from NAT
Description: IPsec
Local IP: (needs to be the local public IP address, not any)
Encryption: AES-256
Hash: SHA1
DH Group: 14
Pre-shared Secret: <secret>
Local subnet: (does not matter because it will be removed later)
Remote subnet: (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


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.


2. Create a VTI to be used by the VPN and assign it an IP address.

set interfaces vti vti0 address
info_i_25x25.png Note: It is strongly recommended to use a RFC1918 IP address for the tunnel interface. This IP address should not exist anywhere else on the router or in the routing table.

3. Display the current IPsec VPN peer configuration (only relevant output is shown).

show vpn
ipsec {
   site-to-site {
       peer {
           tunnel 1 {
               esp-group FOO0
               local {
               remote {

4. Remove the IPsec tunnel(s).

delete vpn ipsec site-to-site peer tunnel 1

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

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

6. Create a static routing entry for the remote subnet pointing towards the VTI.

set protocols static interface-route next-hop-interface vti0

7. (Optional) Use a dynamic routing protocol such as OSPF instead of creating static routing entries.

set interfaces vti vti0 ip ospf network point-to-point

set protocols ospf passive-interface default
set protocols ospf passive-interface-exclude vti0
set protocols ospf parameters router-id
set protocols ospf area network
set protocols ospf area network

8. (Optional) Lower the MTU settings on the VTI interface.

set interfaces vti vti0 mtu 1400
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. In some cases however, connections (such as HTTPS and SSH) can fail to establish over the tunnel. In these cases you can choose to lower the MTU value of the tunnel. A value of 1400 is a good baseline that prevents fragmentation. You may choose to increase or decrease this MTU based on your specific scenario.

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

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

10. Commit the changes.


11. Save the configuration.


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

 local  '' @
 remote '' @
 established 13s ago, reauth in 85578s
   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

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:
peer-  IKEv1
peer-   local:  [] uses pre-shared key authentication
peer-   remote: [] uses pre-shared key authentication
peer-   child: === TUNNEL
Routed Connections:
peer-{1}:  ROUTED, TUNNEL
peer-{1}: ===
Security Associations (1 up, 0 connecting):
peer-[4]: ESTABLISHED 74 seconds ago,[]...[]
peer-[4]: IKEv1 SPIs: 24d45792c4976ca4_i f4b8de413b632a7c_r*, pre-shared key reauthentication in 23 hours
peer-[4]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
peer-{1}:  INSTALLED, TUNNEL, ESP SPIs: cf09bc59_i 769b07da_o
peer-{1}:  AES_CBC_128/HMAC_MD5_96, 500 bytes_i (5 pkts, 66s ago), 500 bytes_o (5 pkts, 66s ago)
peer-{1}: ===

2. Verify the ER IPsec strongSwan configuration:

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

config setup

conn %default

conn peer-
#conn peer-

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 > isakmp: phase 1 I ident
IP > isakmp: phase 1 R ident
IP > isakmp: phase 1 I ident[E]
IP > isakmp: phase 1 R ident[E]
IP > isakmp: phase 2/others I oakley-quick[E]
IP > 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-[1] to

[ENC] generating ID_PROT request 0 [ SA V V V V ]
[NET] sending packet: from[500] to[500] (160 bytes)
[NET] received packet: from[500] to[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-[1] established between[]...[]
[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-{1} established with SPIs cad56e88_i 86968a35_o and TS ===
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 peer
   inet 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 > ICMP echo request, id 12993, seq 18, length 64

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

6. Send traffic over the tunnel from Server1 to Host1 and vice versa:

sudo traceroute -n
traceroute to (, 30 hops max, 60 byte packets

1 (  1.846 ms  1.824 ms  1.812 ms
2 (  49.158 ms  53.873 ms  55.646 ms
3 (  57.799 ms *  59.623 ms

sudo traceroute -n
traceroute to (, 30 hops max, 60 byte packets

1 (  1.726 ms  1.734 ms  1.712 ms
2 (  46.268 ms  48.562 ms  49.542 ms
3 (  56.236 ms *  55.567 ms

Related Articles

Back to Top