Configuring Cisco ASA for Route-Based VPN
Here I'll attempt to give an overview of Cisco ASA's implementation of the static virtual tunnel interface (aka "SVTI", or "VTI" for short), also known more simply as "route-based VPN", and how to configure it on Cisco ASA firewalls.
Some benefits of using VTI is it that does away with the painful requirement of configuring all of those joyless static crypto map access-lists, meaning you no longer have to manually maintain all possible local-to-remote prefix security associations. IPSec VPN deployments ultimately become easier and with BGP you also satisfy HA requirements to public cloud connectors such as AWS and GCP.
GuidelinesBelow are a snapshot of guidelines for using SVTI specific to the ASA platform (keep in mind that SVTI is not ASA or even Cisco-specific technology, each device will have a different implementation):
- You can use dynamic or static routes for traffic over the tunnel interface
- The MTU for VTIs is automatically set, according to the underlying physical interface
- IKE and IPsec security associations will be re-keyed continuously regardless of data traffic in the tunnel - This ensures that VTI tunnels are always up
- VTI and crypto map configurations can co-exist on the same physical interface, provided the peer address configured in the crypto map and the tunnel destination for the VTI are different
- By default, all traffic through VTI is encrypted
- There are no security level configurations for VTI interfaces
- Access-list can be applied on a VTI interface to control traffic through VTI
- For dynamic routing, only BGP is supported over VTI
Creating the TunnelThere are four steps to creating a VTI tunnel:
- Add an ISAKMP Policy
- Add an IPsec Proposal
- Add an IPsec Profile
- Add a VTI Tunnel
Add an ISAKMP PolicyOn the ASA this is no different than a regular L2L policy-based VPN. A phase 1 policy consists of the tunnel-group and ISAKMP policy configuration. For this example we'll assume a fictional peer address of 18.104.22.168:
ciscoasa(config)# crypto ikev1 policy 1 ciscoasa(config-ikev1-policy)# encryption aes ciscoasa(config-ikev1-policy)# hash sha ciscoasa(config-ikev1-policy)# authentication pre-share ciscoasa(config-ikev1-policy)# group 5 ciscoasa(config-ikev1-policy)# lifetime 86400
ciscoasa(config)# crypto ikev1 enable outside ciscoasa(config)# crypto ikev1 am-disable ciscoasa(config)# tunnel-group 22.214.171.124 type ipsec-l2l ciscoasa(config)# tunnel-group 126.96.36.199 ipsec-attributes ciscoasa(config-tunnel-ipsec)# ikev1 pre-shared-key MAS2pxjJosio^kFFaP
Add an IPSec ProposalAdd a regular IKEv1 transform set (or an IKEv2 IPsec proposal - not discussed here) to establish the security association. Here you'll define your desired encryption and integrity algorithms as you would normally do in a transform-set.
IKEv1 transform set example configuration:
ciscoasa(config)# crypto ipsec ikev1 transform-set SET1 esp-aes esp-sha-hmac
Add an IPSec ProfileAn IPsec profile contains the required security protocols and algorithms in the IPsec proposal or transform set that it references. This ensures a secure, logical communication path between two site-to-site VTI VPN peers.
IPSec profile example configuration:
ciscoasa(config)# crypto ipsec profile PROFILE1 ciscoasa(config-ipsec-profile)# set ikev1 transform-set SET1 ciscoasa(config-ipsec-profile)# set security-association lifetime seconds 3600 kilobytes 10000 ciscoasa(config-ipsec-profile)# set pfs group2
Add a VTI Tunnel InterfaceThe tunnel interface enables transport for all encrypted packets destined to and being received by the remote peer.
ciscoasa(config)# interface Tunnel0 ciscoasa(config-if)# nameif vti-188.8.131.52 ciscoasa(config-if)# ip address 169.254.224.1 255.255.255.252 ciscoasa(config-if)# tunnel source interface OUTSIDE ciscoasa(config-if)# tunnel destination 184.108.40.206 ciscoasa(config-if)# tunnel mode ipsec ipv4 ciscoasa(config-if)# tunnel protection ipsec profile PROFILE1
- 169.254/16 is the RFC 3927 reserved link-local IPv4 prefix. You don't have to use it. In this case, we use 169.254.224.0/30 for conflict avoidance since it's unlikely to ever be used anywhere else in the configuration of the two devices on both ends of the tunnel. Using this prefix is simply a workaround practice and isn't required for VTI, as this point-to-point subnet could just as easily be 192.168.10.0/24, for instance.
- In some implementations (for example some CPE devices), SVTI can be configured as 'layer 3' or as 'layer 2', simply meaning that an IP address either is or isn't configured for the tunnel interface itself. The ASA also allows this, however routing policies become more complex as the ASA doesn't allow only the interface be specified for static routes (it mandates a next-hop IP address).
- Keep in mind that the tunnel's assigned IP address and subnet, no matter what you choose, is specific for PTP/point-to-point connectivity between the endpoint devices and nothing else.
- The tunnel destination is the remote peer IP address, I.e. the same IP address that should be configured in the tunnel-group.
- The tunnel interface ID (E.g. "interface Tunnel0") is locally significant only and does not need to match across peers.
Configuring Encrypted RoutesNow that the tunnel is configured, all that is left to do is send traffic across it that we'd like to be encrypted. Instead of haggling with ACLs and encryption domains, you can now do this simply with static or dynamic routing policies.
Static RoutesIf, for example, the customer-side networks are 192.168.2.0/24, 192.168.65.0/24 and 192.168.72.0/24, we would simply need to configure regular static routes to the destination via the tunnel interface and next-hop tunnel IP address (the IP address configured on the remote-end tunnel interface):
ciscoasa(config)# route vti-220.127.116.11 192.168.2.0 255.255.255.0 169.254.224.2 ciscoasa(config)# route vti-18.104.22.168 192.168.65.0 255.255.255.0 169.254.224.2 ciscoasa(config)# route vti-22.214.171.124 192.168.72.0 255.255.255.0 169.254.224.2
Dynamic RoutingSince the topology is a rather simple point-to-point, two router configuration, using BGP to exchange connected interface subnets between peers can be done rather easily.
Using the same tunnel interface IP address schema as above, here is an example policy assuming a customer/far-end ASN of 65001 and our own ASA of 65000 (these two private ASNs are perfectly fine for you to copy):
ciscoasa(config)# router bgp 65000 ciscoasa(config-router)# timers bgp 10 30 0 ciscoasa(config-router)# address-family ipv4 unicast ciscoasa(config-router-af)# neighbor 169.254.224.2 remote-as 65001 ciscoasa(config-router-af)# neighbor 169.254.224.2 activate ciscoasa(config-router-af)# network 192.168.1.0 mask 255.255.255.0
You can optionally add more networks to be advertised to the remote peer by appending more "network" commands. Notice too how we didn't configure any of the remote-side's IP prefixes anywhere while using dynamic routing. That's because those will be learned via BGP and installed in the route table automatically. You would only need to configure these in the configuration if, for example, you were creating a route-map policy filter for your neighbor.
Remember: BGP only originates prefixes which have an existing entry in the RIB. This means you must either advertise already connected subnets (for example the prefix of FW-INSIDE, FW-LB, etc. interfaces) or define static pin-down routes for the 'network' command to work for anything else.
TroubleshootingTroubleshooting VTI is no different than troubleshooting regular IPSec L2L tunnels. Your typical ipsec and isakmp debug, logging, and show commands can be used to verify if the tunnel has been established, has active SPIs, and incrementing encaps & decaps counters. The main difference is that the phase 2 policy will only ever show a single 0.0.0.0/0.0.0.0/0/0 negotiated encryption domain as the phase 2 security association.
BGP troubleshooting is outside the scope of this document, but you can learn more about the basics here: https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/19345-bgp-noad.html
FAQWhen can I use VTI?
The opposite-end device must also support static VTI for this configuration to work. Many modern devices (Palo Alto, Juniper SRX, ASA, Ubiquiti EdgeRouter, Cisco ASR, ISR, etc.) and public clouds (AWS, GCP, Azure) support SVTI VPN termination.
What ASA software version and model supports VTI?
Any device that is able to run 9.8 or higher, meaning any ASA-X or ASAv model.
Can VTI configs be used along-side regular L2L VPN configurations on an ASA?
Does this use GRE?
No. VTI can be thought of as an evolution of GRE since it removes the extra overhead that GRE adds to each packet. VTI is able to use ESP itself as the outer encapsulation method.
Is SVTI limited to Cisco?
Nope. It's an industry standard tunneling technology.
Isn't BGP super complex?
BGP can be complex if discussing things like MPLS design, Internet traffic engineering, etc. But its versatility allows it to also be simple and robust, making it the de-facto dynamic protocol for route-based VPN.