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.

Guidelines

Below 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 Tunnel

There are four steps to creating a VTI tunnel:
  1. Add an ISAKMP Policy 
  2. Add an IPsec Proposal
  3. Add an IPsec Profile 
  4. Add a VTI Tunnel 
Beyond these, the remote peer must be configured with identical ISAKMP and IPsec profile parameters (as usual). SA negotiation will start when all tunnel parameters are configured.

Add an ISAKMP Policy

On 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 1.1.1.1:

   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 1.1.1.1 type ipsec-l2l
   ciscoasa(config)# tunnel-group 1.1.1.1 ipsec-attributes
   ciscoasa(config-tunnel-ipsec)# ikev1 pre-shared-key MAS2pxjJosio^kFFaP


Add an IPSec Proposal

Add 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 Profile

An 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 Interface

The tunnel interface enables transport for all encrypted packets destined to and being received by the remote peer.

After packets arrive on the inside interface and are forwarded to the VTI interface, they're encapsulated ("wrapped") with an ESP header then sent back to the forwarding engine and switched via the real "OUTSIDE" hardware interface toward the peer's public IP.

   ciscoasa(config)# interface Tunnel0
   ciscoasa(config-if)# nameif vti-1.1.1.1
   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 1.1.1.1
   ciscoasa(config-if)# tunnel mode ipsec ipv4
   ciscoasa(config-if)# tunnel protection ipsec profile PROFILE1

A few important notes about this configuration example:
  • 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 Routes

Now 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 Routes

If, 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-1.1.1.1 192.168.2.0 255.255.255.0 169.254.224.2
   ciscoasa(config)# route vti-1.1.1.1 192.168.65.0 255.255.255.0 169.254.224.2
   ciscoasa(config)# route vti-1.1.1.1 192.168.72.0 255.255.255.0 169.254.224.2

Dynamic Routing

Since 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.

Troubleshooting

Troubleshooting 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

FAQ

When 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?
Yes.

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.

Popular posts from this blog

Running ASA on Firepower 2100: An End-to-End Guide

Up and Rawring with TRex: Cisco's Open Traffic Generator