ASA Route Based VPN
The ASA only performed Policy Based VPNs prior to 9.7 code which can cause a lot of issues when connecting to other vendors. If you are running 9.7+, you will now be able to create a proper Route Based VPN which will allow you to connect to all other vendors with a lot less headache and overhead.
Route Based VPN
Route Based VPNs differ from Policy Based in the fact that you will only have one IPSec Security Association for each peer. In Policy Based, you would have multiple SAs (Phase 2s) as each tunnel had a Identifier using each Network combination of your Encryption Domain. You can force multiple SAs for the Route Based VPN but all in all, it is generally just the one SA for the entire Encryption Domain.
Basic VPN Configuration Start:
We will start by creating the basics of the Site to Site. This first part will be true whether this is a Route Based or Policy Based.
Here is our requirements for the VPN:
Remote Peer IP: 2.2.2.2
Remote Network: 10.10.0.0/16
Local Peer IP: 1.1.1.1
Local Network: 172.24.0.0/16
Phase 1 Parameters:
Encryption: AES -128
Hash Alg.: SHA1
Lifetime(S): 86400
DH Group: Group2
Phase 2 Parameters:
Encryption: AES -256
Hash Alg.: SHA1
Lifetime(S): 28800
PFS DH: Group5
Pre-Shared-Key: Th1nkN3t$Ec
To configure this on the ASA, the commands would look like the following. Please note that I am simulating as if this is my first VPN on my ASA so some commands you may not need: (Note: If you already have VPNs configured, make sure you are not overwriting your ikev1 policy.)
crypto ikev1 enable OUTSIDE
crypto ikev1 policy 1
encryption aes
hash sha
authentication pre-share
group 2
lifetime 86400
tunnel-group 2.2.2.2 type ipsec-l2l
tunnel-group 2.2.2.2 ipsec-attributes
ikev1 pre-shared-key Th1nkN3t$Ec
crypto ipsec ikev1 transform-set ESP-AES128-SHA esp-aes esp-sha-hmac
New Configuration for Route Based
This next bit of configuration is new and is what is needed to get the Route Based VPN completed. We will be creating an IPSec Profile to reference the settings we created prior. We will bind this to a new VTI (Virtual Tunnel Interface) on the ASA which will be used to specify the Phase 2 configuration. Notice though that we have not used the Remote Network anywhere in this configuration yet. We will configure this next after we create the VTI.
crypto ipsec profile ROUTE-BASED-PROFILE set ikev1 transform-set ESP-AES128-SHA set security-association lifetime seconds 28800 set pfs group5 interface Tunnel0 nameif ROUTE-BASED ip address 169.254.224.253 255.255.255.252 tunnel source interface OUTSIDE tunnel destination 2.2.2.2 tunnel mode ipsec ipv4 tunnel protection ipsec profile ROUTE-BASED-PROFILE
Routing Traffic over the Route Based VPN
In my use case, we will not be doing dynamic routing, but rather, static routing. The Routes will be what defines the encryption domain for the Route Based VPN. Since the ASA can not reference a interface for Routing and needs a Next-Hop, I will use an APIPA IP to simulate the Next-Hop. This APIPA does not have to be configured on the other side of the VPN. This will only be needed to trick the Local ASA and to allow for a static route to be created for the new VTI.
route ROUTE-BASED 10.10.0.0 255.255.0.0 169.254.224.254
If you would like to know more or see more articles on VPNs, please let me know. You can contact me and I will do what I can to help.
11 Comments
olsonnn · March 12, 2018 at 11:55 am
Hello, Thank for this great article, but i was expecting the route to be route ROUTE-BASED 10.10.0.0 255.255.0.0 169.254.224.253 instead of 169.254.224.254
John Finnegan · March 12, 2018 at 2:41 pm
You are very welcome and I am glad you liked the article. The reason for the 169.254.224.254 is that it is the “Next Hop” IP address. We want to force this traffic out of the Tunnel interface and over to the Next Hop. The ASA does not allow the use of its own IPs to specify the Next Hop which is why we have to use an IP within the block that it does not own. Traditionally, the 169.254.224.254 IP should exist on the Remote side but it does not have to exist for the VPN to work. We just want to force this traffic out the Tunnel interface.
Here is the error you will get if you try to use the ASAs IP address.
Lab1-asax5515(config)# route ROUTE-BASED 10.10.0.0 255.255.0.0 169.254.224.253
ERROR: Invalid next hop address 169.254.224.253, it matches our IP address
olsonn · March 12, 2018 at 3:18 pm
Ok, i thnk i got it…In your example you are using a APIPA address, but this can be any ‘not in use’ network /APIPA since it’s a virtual one? Will give it a try tomorrow.. migrating a policy based vpn to route based..
John Finnegan · March 12, 2018 at 3:43 pm
That is correct. It can be any IP range that you want it to be so long as it is not in use somewhere else in the network.
olsonn · March 15, 2018 at 5:02 am
Thanks John! Got it working now…The only issue was that if you replace a peer (in my case) you NEED to remove the old setup and SAVE the config before adding the new setup. If not, still old parts of cryptomaps etc do apply to same peer (stupid asa 😉
John Finnegan · March 16, 2018 at 12:01 pm
I am glad that you were able to get it to work and that is correct. If you had a VPN already, and are converting it to Route Based, you will need to remove the Crypto Maps that are referencing the VPN for it to work properly. Feel free to reach out anytime if you have questions.
olsonn · March 16, 2018 at 12:14 pm
Yes, the crypto map was removed from running config but not saved. Asa still used it. The only thing i noticed was that i don’t see any statistics from the virtual interface. No traffic info in/out. Do you see the same behaviour? Not sure if this is normal for a virtual interface
John Finnegan · March 16, 2018 at 6:57 pm
So the interface will not show RX/TX or IN/OUT. That is just there to show you if the interface is Active or not. If you wish to see that traffic is actually going in and out of the VTI, you should look at the IPSec SA for that tunnel interface. This will show you if you are in fact receiving and sending encrypted traffic over that tunnel (interface).
Here is an example:
Olsonn · March 21, 2018 at 1:25 pm
John, Thanks again for this very detailed explanation! it’s really appreciated. Today i found something interesting: i couldn’t access the asa via ssh anymore when a connection came from a remote location over the VTI interface and running on version 9.8.2. This issue is fixed in version 9.9.1. See here as well https://supportforums.cisco.com/t5/vpn/ssh-snmp-access-to-asa-through-vti-tunnel/td-p/3226319
Shiva · April 17, 2018 at 12:24 pm
Hello Admin,
Thanks for the post. My question is what is local encryption domain here. To identify the remote encryption, atleast we have static route in place. But while troubleshooting how to identify the actual interesting traffic participating in this tunnel ?
Regards,
Shiva
John Finnegan · April 17, 2018 at 12:51 pm
Hey Shiva,
That is a good question. Anything on the ASAs Local Networks, or any network that use the ASA as a default route, will technically be apart of the Encryption Domain. If that needs to be limited to specific networks, then ACL rules or filters would need to be used to only allow specific local traffic to traverse the VPN.
With Route Based VPNs, there isn’t an actual encryption domain that is applied. If you look at the Security Association, you will see that both Local and Remote are 0.0.0.0/0. This is why everything on the ASA is apart of the VPN if the traffic is destined to anything with a Route using the VTI.
If you are troubleshooting and wanting to know what Local traffic is trying to use the tunnel, the easiest way is to perform a capture on all of the internal interfaces looking for anything destined to the VTI. Specifically, any network that is routed over the VTI. This will atleast show you all connections that are trying to send over the VTI but there is no quick way to determine which networks should have access. This is usually provided by either side stating what should be communicating over the tunnel.