Policy-based VPNs encrypt a subsection of traffic flowing through an interface as per configured policy in the access list.The policy dictates either some or all of the interesting traffic should traverse via VPN. In distinction to a Policy-based VPN, a Route-based VPN works on routed tunnel interfaces as the endpoints of the virtual network.All traffic passing through a tunnel interface is. I've got Policy-Based VNET that is connected to Cisco ASA - there is no way to make it Route-Based. I need all of my app deployment (Azure Web App, Azure Cloud Services) to be connectable only from the subnet that lives after Cisco gateway - there is no connection to the internet in this LAN. Policy Based Routing (PBR) is a mechanism which allows you forward packets based on policies manually defined by network administrators. A good use case for PBR is when a company which has multiple outside connections to different ISPs needs to control how traffic can be distributed across these connections. Understand the difference between Cisco Policy-Based and Route-Based VPNs. Learn which VPN technologies are supported on Cisco ASA Firewalls and IOS Routers. Site-to-Site VPN, Hub & spoke VPNs, Client remote access VPNs, are placed within the two VPN categories.
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.
Asa Policy Based Routing NatBelow 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 184.108.40.206:
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:
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:
Add a VTI Tunnel InterfaceThe 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.
- 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):
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):
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.
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.
Cisco Asa Policy Based Routing Failover
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.