Cisco IOS VTI

By | December 3, 2020

The use of Internet Protocol Security (IPsec) Virtual Tunnel Interfaces (VTIs) simplifies the configuration process when you must provide protection for site-to-site VPN tunnels. A major benefit of IPsec VTIs is that the configuration does not require a static mapping of IPsec sessions to a physical interface. IPsec VTI’s function like any other real interface so that you can apply many Cisco IOS Software features on them.

The simplest form of Cisco IOS Software tunnel-based site-to-site IPsec VPN configuration:

  • It replaces cryptographic map-based configuration.
  • It is intuitive to configure and integrates better with other Cisco IOS Software features.

VTI features include the following:

  • They behave as regular tunnels, one for each remote site of the VPN.
  • Their encapsulation must be either IPsec Encapsulating Security Payload (ESP) or Authentication Header (AH).
  • Their line protocol depends on the state of the VPN tunnel (IPsec Security Associations (SAs)).

An IPsec VTI has several benefits:

  • Simplifies configuration: Customers can use the virtual tunnel constructs to configure an IPsec peering, thus simplifying the complexity of the VPN configuration as compared to crypto maps or GRE IPsec tunnels.
  • Flexible interface feature support: An IPsec VTI is an encapsulation that uses its own Cisco IOS Software interface. This characteristic offers the flexibility of defining features to run on either the physical interface (that operates on ciphertext traffic) or on the IPsec VTI (that operates on cleartext traffic).
  • Multicast support: Customers can use the IPsec VTIs to securely transfer multicast traffic such as voice and video applications from one site to another.
  • Improved scalability: IPsec VTIs need fewer established SAs to cover different types of traffic, both unicast and multicast, thus enabling improved scaling.
  • Provides a routable interface: Like GRE IPsec, IPsec VTIs can natively support all types of IP routing protocols, which provide scalability and redundancy.

The IPsec VTI has the following limitations:

  • The IPsec VTI is limited to only IP unicast and multicast traffic, as opposed to GRE tunnels, which have a wider, multiprotocol application.
  • Cisco IOS Software IPsec stateful failover is not supported with IPsec VTIs. However, you can use alternative failover methods such as dynamic routing protocols to achieve similar functionality.

Configure Static VTI Point-to-Point Tunnels

We will use this diagram to create static VTI tunnel

Step 1
On the R2 router, create a new IKE policy.

R2(config)# crypto isakmp policy 10
R2(config-isakmp)# authentication pre-share
R2(config-isakmp)# hash sha
R2(config-isakmp)# encryption aes 128
R2(config-isakmp)# group 14
R2(config-isakmp)# lifetime 3600

Step 2
On the R2 router, create a PSK and bind it to the IP address of the R3 router (172.18.4.2).

R2(config)# crypto isakmp key cisco address 172.18.4.2

Step 3
The transform set determines the encryption and data authentication hash for the IPSec SA. The transform set must match an equal policy on the peer. On the R2 router, create an IPsec transform set for user traffic protection. Use ESP with 128-bit AES as the encryption transform and use ESP with SHA-1 (HMAC variant) as the authentication transform.

R2(config)# crypto ipsec transform-set MYSET esp-aes 128 esp-sha-hmac

Step 4
On the R2 router, create an IPsec profile and include transform set in the profile.

R2(config)# crypto ipsec profile MYPROFILE
R2(ipsec-profile)# set transform-set MYSET

Step 5
On the R2 router, create a new tunnel interface. Configure the interface to use the IP address and subnet of the Ethernet 0/0 interface. Specify a tunnel source (Ethernet 0/0) and a tunnel destination of R3’s Ethernet 0/0 interface IP address (172.18.4.2).

R2(config)# interface Tunnel0
R2(config-if)# ip unnumbered Ethernet0/0
R2(config-if)# tunnel source Ethernet0/0
R2(config-if)# tunnel destination 172.18.4.2

Step 6
On the R2 router, specify IPsec as the tunnel encapsulation. Specify the traffic protection policy by referencing the configured IPsec profile.

R2(config)# interface Tunnel0
R2(config-if)# tunnel mode ipsec ipv4
R2(config-if)# tunnel protection ipsec profile MYPROFILE

Step 7
On the R2 router, create a static route to the R3 internal network (10.10.2.0/24) that is reachable over the tunnel.

R2(config)# ip route 10.10.2.0 255.255.255.0 Tunnel0

Step 8
On the R2 router, verify the status of the IPsec SA. Notice that there are no packets encapsulated or de-encapsulated.

R2# show crypto ipsec sa 

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 172.17.1.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 172.18.4.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

Step 9
On the R2 router, verify the status of the tunnel interface. The tunnel interface should be up/up.

R2# show interface tunnel 0
Tunnel0 is up, line protocol is up 
  Hardware is Tunnel
  Interface is unnumbered. Using address of Ethernet0/0 (172.17.1.2)
  MTU 17878 bytes, BW 100 Kbit/sec, DLY 50000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel linestate evaluation up
  Tunnel source 172.17.1.2 (Ethernet0/0), destination 172.18.4.2

Step 10
On the R2 router, verify the routing table. Network 10.10.2.0/24 should be reachable via Tunnel0 interface.

R2# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is 172.17.1.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 172.17.1.1
      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C        10.10.1.0/24 is directly connected, Ethernet0/1
L        10.10.1.1/32 is directly connected, Ethernet0/1
S        10.10.2.0/24 is directly connected, Tunnel0
      172.17.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.17.1.0/24 is directly connected, Ethernet0/0
L        172.17.1.2/32 is directly connected, Ethernet0/0

Step 11
Generate a ping from R2’s internal LAN interface, Eth0/1, to R3’s internal LAN interface address, 10.10.2.1. The ping should be successful.

R2# ping 10.10.2.1 source Ethernet 0/1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.2.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4

Step 12
On the R2 router, verify the status of the IPsec SA again. Observe that the packet count for encapsulated and de-encapsulated increased by five packets. The static VTI point-to-point tunnel interface is operational.

R2# show crypto ipsec sa

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 172.17.1.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 172.18.4.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
    #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

Step 13
On the host PC1, ping the host PC2 at the R3 site (10.10.2.12). The attempt should be successful.

PC1# ping 10.10.2.12
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.2.12, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/202/1007 ms

Step 14
On the R2 router, verify the status of the IPsec SA again. Notice that the packet count for encapsulated and de-encapsulated increases again.

R2# show crypto ipsec sa

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 172.17.1.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 172.18.4.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
    #pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0