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:

show int tunnel 3 detail
Interface Tunnel3 "ROUTE-BASED", is up, line protocol is up
  Hardware is Virtual Tunnel    MAC address N/A, MTU 1500
    IP address 169.254.224.253, subnet mask 255.255.255.252
  Control Point Interface States:
    Interface number is 17
    Interface config status is active
    Interface state is active
  Tunnel Interface Information:
    Source interface: OUTSIDE   IP address: 1.1.1.1
    Destination IP address: 2.2.2.2
    Mode: ipsec ipv4    IPsec profile: ROUTE-BASED-PROFILE

***********************************************

show ipsec sa peer 2.2.2.2
interface: ROUTE-BASED
    Crypto map tag: __vti-crypto-map-7-0-3, seq num: 65280, local addr: 1.1.1.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: 2.2.2.2


  #pkts encaps: 101, #pkts encrypt: 101, #pkts digest: 101 <<----I have encaps (OUT)
  #pkts decaps: 101, #pkts decrypt: 101, #pkts verify: 101  <<---- I have decaps (IN)
  #pkts compressed: 0, #pkts decompressed: 0
  #pkts not compressed: 101, #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.: 1.1.1.1/0, remote crypto endpt.: 2.2.2.2/0
  path mtu 1500, ipsec overhead 74(44), media mtu 1500
  PMTU time remaining (sec): 0, DF policy: copy-df
  ICMP error validation: disabled, TFC packets: disabled
  current outbound spi: EDD1EBD7
  current inbound spi : 8A03B6F4

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.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.