Cisco ASA Route-Based (VTI) VPN Example

Cisco ASA Route-Based (VTI) VPN Example
In: Cisco, Firewall

If I remember correctly, Cisco introduced Virtual Tunnel Based (VTI) VPN back in 2017 with a 9.7.1 code base. It was a long-due release especially if you are working with multi-vendor VPNs. In this blog post, we will go through the steps required to configure IKEv2 tunnel-based VPN on the ASA firewalls.

Route-based VPN is an alternative to policy-based VPN where a VPN tunnel can be created between peers with Virtual Tunnel Interfaces. Route-based VTI VPN allows dynamic or static routes to be used where egressing traffic from the VTI is encrypted and sent to the peer, and the associated peer decrypts the ingress traffic to the VTI.

Using VTI eliminates the need of configuring static crypto maps and access lists. You no longer have to keep track of all remote subnets and include them in the crypto map access list. With VTI, deployments become much easier to manage.  

If you are looking for a Policy-Based VPN, please check out my other blog post below.

Cisco ASA Site-to-Site VPN Example (IKEv1 and IKEv2)
What if I tell you that configuring site to site VPN on the Cisco ASA only requires around 15 lines of configuration.


Our ultimate goal is to set up a site-to-site VPN between the Branch Office and the Headquarters (ASA) and enable connectivity so, the devices in either location can access each other via a secure channel.

Let's assume the client-pc ( in the branch office needs to access a web server ( in the headquarter and we need to set up a VPN tunnel to provide connectivity.


Interface Configuration and Route Table

The interface configuration is self-explanatory, ASA has two interfaces, one for the Server and another one for the Internet. The default route is pointing to the ISP router with a static route.

interface GigabitEthernet0/0
 nameif WAN
 security-level 0
 ip address standby 
interface GigabitEthernet0/1
 nameif INSIDE
 security-level 100
 ip address standby
 route WAN 1

Enable IKEv2

We need to of course enable IKEv2 on the WAN interface.

crypto ikev2 enable WAN

Phase-1 IKEv2 Policy

Create an IKEv2 policy that defines the algorithms/methods to be used for hashing, authentication, DH group, PRF,  lifetime, and encryption. Please note that these policies should match on both sides. If you already have a policy then you don't need to create one. You can check whether there are any policies by running show run crypto ikev2 command.

Ideally, you want to use the strongest authentication and encryption algorithms the peer can support. For authentication, you can use SHA-256 or higher.

SHA-1 or MD5 are considered weak and not recommended to use in a production environment.

For the encryption algorithm, AES-GCM provides the strongest security and has built-in authentication, so you must set integrity to none if you select aes-256-gcm or aes-128-gcm encryption.

When an authenticated encryption algorithm (AES-GCM in our case) is used with IKE, you need to configure a Pseudo-Random Function (PRF) instead of an Integrity.

crypto ikev2 policy 50
 encryption aes-gcm-256
 integrity null
 group 20
 prf sha384
 lifetime seconds 28800

Phase-2 IPSec Proposal

Configure IPSec Proposal and Profile that we will use in the next step. This is a combination of security protocols and algorithms that define the way the VPN peers protect the actual traffic.

crypto ipsec ikev2 ipsec-proposal VPN-LAB
 protocol esp encryption aes-gcm-256 aes-256
 protocol esp integrity sha-512
crypto ipsec profile VPN-LAB-PROFILE
 set ikev2 ipsec-proposal VPN-LAB

Virtual Tunnel Interface (VTI) and Static Route

The next step is to create a tunnel interface and attach the proposal we created in the previous step.

We also need to add a static route that points to the tunnel to reach the remote subnet.

interface Tunnel1
 nameif VPN-BRANCH
 ip address 
 tunnel source interface WAN
 tunnel destination
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VPN-LAB-PROFILE
route VPN-BRANCH 1

Group Policy and Tunnel Group

group-policy VPN-LAB-GP internal
group-policy VPN-LAB-GP attributes
 vpn-tunnel-protocol ikev2 
tunnel-group type ipsec-l2l
tunnel-group general-attributes
 default-group-policy VPN-LAB-GP
tunnel-group ipsec-attributes
 ikev2 remote-authentication pre-shared-key Cisco123
 ikev2 local-authentication pre-shared-key Cisco123

That's all we need to configure, please remember the phase-1 and phase-2 parameters should match on both sides for a successful VPN connection.


To test VPN, let's initiate some traffic from the Client to the server to verify that the tunnel is working.

client-pc> ping

84 bytes from icmp_seq=1 ttl=63 time=5.170 ms
84 bytes from icmp_seq=2 ttl=63 time=2.478 ms
84 bytes from icmp_seq=3 ttl=63 time=3.012 ms
84 bytes from icmp_seq=4 ttl=63 time=2.569 ms
84 bytes from icmp_seq=5 ttl=63 time=2.444 ms

There are a few ASA commands that you can use to verify the tunnel status.

asa-lab-01# show crypto isa sa

There are no IKEv1 SAs

IKEv2 SAs:

Session-id:4, Status:UP-ACTIVE, IKE count:1, CHILD count:1

Tunnel-id Local                                               Remote                                                  Status         Role
 40911855                                                                     READY    INITIATOR
      Encr: AES-GCM, keysize: 256, Hash: N/A, DH Grp:20, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 28800/568 sec
Child sa: local selector -
          remote selector -
          ESP spi in/out: 0xe0a0e93a/0xd0780a7c  
asa-lab-01# show crypto ipsec sa peer
peer address:
    Crypto map tag: __vti-crypto-map-4-0-1, seq num: 65280, local addr:

      local ident (addr/mask/prot/port): (
      remote ident (addr/mask/prot/port): (

      #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 comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #TFC rcvd: 0, #TFC sent: 0
      #Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.:, remote crypto endpt.:
      path mtu 1500, ipsec overhead 55(36), media mtu 1500
      PMTU time remaining (sec): 0, DF policy: copy-df
      ICMP error validation: disabled, TFC packets: disabled
      current outbound spi: D0780A7C
      current inbound spi : E0A0E93A
    inbound esp sas:
      spi: 0xE0A0E93A (3768641850)
         SA State: active
         transform: esp-aes-gcm-256 esp-null-hmac no compression 
         in use settings ={L2L, Tunnel, IKEv2, VTI, }
         slot: 0, conn_id: 64368640, crypto-map: __vti-crypto-map-4-0-1
         sa timing: remaining key lifetime (kB/sec): (4008960/28147)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap: 
          0x00000000 0x00000001
    outbound esp sas:
      spi: 0xD0780A7C (3497527932)
         SA State: active
         transform: esp-aes-gcm-256 esp-null-hmac no compression 
         in use settings ={L2L, Tunnel, IKEv2, VTI, }
         slot: 0, conn_id: 64368640, crypto-map: __vti-crypto-map-4-0-1
         sa timing: remaining key lifetime (kB/sec): (4147200/28147)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap: 
          0x00000000 0x00000001

Closing up

I've used a mixture of both policy-based and route-based VPNs but my preference has always been the latter.  Especially working with public clouds such as AWS or Azure, you definitely want to go with a route-based VPN as it already supports dynamic routing (BGP) inside the tunnel.


Written by
Suresh Vina
Tech enthusiast sharing Networking, Cloud & Automation insights. Join me in a welcoming space to learn & grow with simplicity and practicality.
More from Packetswitch
Table of Contents
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Packetswitch.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.