EdgeRouter - VTI Example on EdgeRouter

VTI (Virtual Tunnel Interface) is a way of binding a ipsec tunnel interface.  This feature was added in EdgeOS v1.6.0.

 

In this example we'll have the following network for router R1 and R2:

R1

==

eth0: WAN 20.0.0.2/30, gateway 20.0.01/30

eth1: LAN 192.168.1.1/24

 

R2

==

eth0: WAN 30.0.0.2/30, gateway 30.0.01/30

eth1: LAN 172.16.1.1/24

 

First we'll use the 2nd WAN+2LAN2 setup wizard so that we can change the LAN subnet on R2.  Then on the GUI we'll use the VPN tab to create a standard IPSec site-to-site tunnel.  Lastly we'll use the CLI to convert the IPSec tunnel to use the VTI interface.

The VPN screen for R1 looks like:

 

After doing the same on R2 we can check the status of the tunnel.

 

ubnt@R1:~$ show vpn ike sa
Peer ID / IP                            Local ID / IP               
------------                            -------------
30.0.0.2                                20.0.0.2                               

    State  Encrypt  Hash    D-H Grp  NAT-T  A-Time  L-Time
    -----  -------  ----    -------  -----  ------  ------
    up     aes128   sha1    14       no     14730783 28800  

 
ubnt@R1:~$ show vpn ipsec sa
Peer ID / IP                            Local ID / IP               
------------                            -------------
30.0.0.2                                20.0.0.2                               

    Tunnel  State  Bytes Out/In   Encrypt  Hash  NAT-T  A-Time  L-Time  Proto
    ------  -----  -------------  -------  ----  -----  ------  ------  -----
    1       up     0.0/0.0        aes128   sha1  no     967     3600    all

 

We'll now try to ping the other R2 subnet using the -I to specify the LAN subnet to use for the source address.

 

ubnt@R1:~$ /bin/ping -I eth1 172.16.1.1
PING 172.16.1.1 (172.16.1.1) from 192.168.1.1 eth1: 56(84) bytes of data.
64 bytes from 172.16.1.1: icmp_req=1 ttl=64 time=1.27 ms
64 bytes from 172.16.1.1: icmp_req=2 ttl=64 time=0.791 ms
64 bytes from 172.16.1.1: icmp_req=3 ttl=64 time=0.827 ms
^C
--- 172.16.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.791/0.964/1.276/0.223 ms


ubnt@R1:~$ show vpn ipsec sa
Peer ID / IP                            Local ID / IP               
------------                            -------------
30.0.0.2                                20.0.0.2                               

    Tunnel  State  Bytes Out/In   Encrypt  Hash  NAT-T  A-Time  L-Time  Proto
    ------  -----  -------------  -------  ----  -----  ------  ------  -----
    1       up     252.0/252.0    aes128   sha1  no     1127    3600    all

 

Attached are the working config files for R1 and R2 before we convert to VTI.

 

R1 /config/config.boot

R2 /config/config.boot

 

Now we change over to VTI and see what are the Pro's and Con's.  First we'll create a VTI interfaces on both R1 & R2 and give it an address.

 

ubnt@R1:~$ configure 
[edit]
ubnt@R1# set interfaces vti vti0 address 40.0.0.1/30
[edit]
ubnt@R1# commit
[ interfaces vti vti0 ]
Warning: Interface vti0 is not referenced in vpn configuration.

 

Looking at our site-to-site config for R1 we have:

 

ubnt@R1# show vpn ipsec site-to-site 
 peer 30.0.0.2 {
     authentication {
         mode pre-shared-secret
         pre-shared-secret secret
     }
     connection-type initiate
     ike-group FOO0
     local-address 20.0.0.2
     tunnel 1 {
         allow-nat-networks disable
         allow-public-networks disable
         esp-group FOO0
         local {
             prefix 192.168.1.0/24
         }
         remote {
             prefix 172.16.1.0/24
         }
     }
 }
[edit]

 

 We basically want to replace the tunnel with the vti binding:

 

ubnt@R1# edit vpn ipsec site-to-site peer 30.0.0.2 
[edit vpn ipsec site-to-site peer 30.0.0.2]
ubnt@R1# delete tunnel 1
[edit vpn ipsec site-to-site peer 30.0.0.2]
ubnt@R1# set vti bind vti0 
[edit vpn ipsec site-to-site peer 30.0.0.2]
ubnt@R1# set vti esp-group FOO0 
[edit vpn ipsec site-to-site peer 30.0.0.2]
ubnt@R1# top
[edit]
ubnt@R1# compare
[edit vpn ipsec site-to-site peer 30.0.0.2]
-tunnel 1 {
-    allow-nat-networks disable
-    allow-public-networks disable
-    esp-group FOO0
-    local {
-        prefix 192.168.1.0/24
-    }
-    remote {
-        prefix 172.16.1.0/24
-    }
-}
+vti {
+    bind vti0
+    esp-group FOO0
+}
[edit]
ubnt@R1# commit
[edit]

 

One big difference with VTI is that we're no longer defining what enters the tunnel based on local/remote subnet.  With VTI we have a routable interface, so on R1 well add a route to 172.16.1.1 via the VTI interface.

 

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

And for R2:

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

With that we can ping the remote subnet.  However since it's a routable interface, let's delete the static routes and instead use OSPF to dynamically learn the routes.

 

ubnt@R1:~$ configure 
[edit]
ubnt@R1# delete protocols static interface-route 
[edit]
ubnt@R1# set protocols ospf parameters router-id 20.0.0.2
[edit]
ubnt@R1# set protocols ospf area 0.0.0.0 network 40.0.0.0/30
[edit]
ubnt@R1# set protocols ospf area 0.0.0.0 network 192.168.1.0/24
[edit]
ubnt@R1# set protocols ospf area 0.0.0.0 network 192.168.2.0/24
[edit]
ubnt@R1# set interfaces vti vti0 ip ospf network point-to-point
[edit]
ubnt@R1# commit
[ protocols ospf ]
Starting routing daemon: ospfd.

[edit]
save;exit

 

From the routing table we can see the learned routes.

ubnt@R1:~$ show ip route 
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

S>* 0.0.0.0/0 [1/0] via 20.0.0.1, eth0
C>* 20.0.0.0/30 is directly connected, eth0
O   40.0.0.0/30 [110/10] is directly connected, vti0, 24w2d15h
C>* 40.0.0.0/30 is directly connected, vti0
C>* 127.0.0.0/8 is directly connected, lo
O>* 172.16.1.0/24 [110/20] via 40.0.0.2, vti0, 00:13:53
O   192.168.1.0/24 [110/10] is directly connected, eth1, 24w2d15h
C>* 192.168.1.0/24 is directly connected, eth1
O   192.168.2.0/24 [110/10] is directly connected, eth2, 24w2d15h
C>* 192.168.2.0/24 is directly connected, eth2

Notice that we can know reach both remote LAN subnets, but if we weren't using VTI would have to create 4 tunnels to accomplish the same:

192.168.1.0/24  ---  172.16.1.0/24
192.168.1.0/24  ---  172.16.2.0/24
192.168.2.0/24  ---  172.16.1.0/24
192.168.2.0/24  ---  172.16.2.0/24

Attached are the complete config files for R1 and R2 with VTI and OSPF.

R1 /config/config.boot VTI

R2 /config/config.boot VTI

 

Also note that since VTI is an interface, you can also apply firewall, QoS, etc.

 

ubnt@R1# set interfaces vti vti0 ?
Possible completions:
  address	IP address
  description	Description
  disable	Disable interface
  firewall	Firewall options
  ip		IPv4 routing parameters
  ipv6		IPv6 routing parameters
  mtu		Maximum Transmission Unit (MTU)
  redirect	Incoming packet redirection destination
  traffic-policy
  		Traffic-policy for interface

 

Known limitations:

  1. Since it's a point to point interface, the endpoint must be a known address.  So it doesn't work with "local-address any" or "peer 0.0.0.0".