Cisco ASA Route-Based (VTI) VPN Example
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.
Diagram
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 (172.16.10.25) in the branch office needs to access a web server (192.168.10.10) in the headquarter and we need to set up a VPN tunnel to provide connectivity.
Configuration
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 201.85.10.1 255.255.255.248 standby 201.85.10.2
!
interface GigabitEthernet0/1
nameif INSIDE
security-level 100
ip address 192.168.10.1 255.255.255.0 standby 192.168.10.2
route WAN 0.0.0.0 0.0.0.0 201.85.10.6 1Enable IKEv2
We need to of course enable IKEv2 on the WAN interface.
crypto ikev2 enable WANPhase-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.
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 28800Phase-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-LABVirtual 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 10.1.1.2 255.255.255.252
tunnel source interface WAN
tunnel destination 101.85.10.1
tunnel mode ipsec ipv4
tunnel protection ipsec profile VPN-LAB-PROFILEroute VPN-BRANCH 172.16.10.0 255.255.255.0 10.1.1.1 1Group Policy and Tunnel Group
group-policy VPN-LAB-GP internal
group-policy VPN-LAB-GP attributes
vpn-tunnel-protocol ikev2 tunnel-group 101.85.10.1 type ipsec-l2l
tunnel-group 101.85.10.1 general-attributes
default-group-policy VPN-LAB-GP
tunnel-group 101.85.10.1 ipsec-attributes
ikev2 remote-authentication pre-shared-key Cisco123
ikev2 local-authentication pre-shared-key Cisco123That'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.
Verification
To test VPN, let's initiate some traffic from the Client to the server to verify that the tunnel is working.
client-pc> ping 192.168.10.10
84 bytes from 192.168.10.10 icmp_seq=1 ttl=63 time=5.170 ms
84 bytes from 192.168.10.10 icmp_seq=2 ttl=63 time=2.478 ms
84 bytes from 192.168.10.10 icmp_seq=3 ttl=63 time=3.012 ms
84 bytes from 192.168.10.10 icmp_seq=4 ttl=63 time=2.569 ms
84 bytes from 192.168.10.10 icmp_seq=5 ttl=63 time=2.444 msThere 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 201.85.10.1/500 101.85.10.1/500 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 0.0.0.0/0 - 255.255.255.255/65535
remote selector 0.0.0.0/0 - 255.255.255.255/65535
ESP spi in/out: 0xe0a0e93a/0xd0780a7c asa-lab-01# show crypto ipsec sa peer 101.85.10.1
peer address: 101.85.10.1
Crypto map tag: __vti-crypto-map-4-0-1, seq num: 65280, local addr: 201.85.10.1
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: 101.85.10.1
#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.: 201.85.10.1/500, remote crypto endpt.: 101.85.10.1/500
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 0x00000001Closing 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.