Terminating overlapping VPN subnets on ASA

I had a question asked by a colleague on how we could have overlapping VPN networks terminate on an ASA. He was looking for VPN in multi-context ASA basically, or some kind of VRF aware ASA. None of the previous are possible in ASA; VPN is not possible in multi-context mode, and more generally ASA is not VRF aware. Another constraint was that the core router behind the ASA had also overlapping subnets, logically separated by VRFs (then going into an MPLS cloud, but we don't care about that part).

My initial idea was to impact customer sites by adding some nating (Policy NAT) to the remote subnets, so that to the VPN terminating ASA they would appear as a different translated address. That's the easy way out. But the point was not to impact customer sites, so I had to try something different.

And then I thought that we could encapsulate the overlapping subnets in a GRE tunnel that would pass through the ASA and terminate on the core router. The different GRE tunnel addresses would be used to segregate overlapping traffic.

So to sum up, here is the problem:

• Multiple customers on the outside (WAN) with overlapping subnets
• One terminating ASA for VPN traffic
• Multiple customers on the inside (LAN) with overlapping subnets

How do we get these to play nice? Here is the test setup I cane up with:

The idea being to have the ASA as a termination point for VPN traffic, who would then pass through GRE tunnels to the router. The GRE tunnel would forward traffic to the correct VRF. The downside of this is that ASA cannot do GRE inspection, so the traffic flowing through the ASA will not have any policies applied to it.

ASA config:

hostname ASA
enable password 8Ry2YjIyt7RRXU24 encrypted
names
!
interface Ethernet0/0
 nameif outside
 security-level 0
 ip address 10.1.1.1 255.255.255.0
!
interface Ethernet0/1
 nameif inside
 security-level 100
 ip address 192.168.1.1 255.255.255.0
!
access-list VPN extended permit gre host 172.16.1.1 host 10.1.1.2
access-list VPN2 extended permit gre host 172.16.2.1 host 10.1.1.3 

!

route inside 172.16.1.0 255.255.255.0 192.168.1.10 1
route inside 172.16.2.0 255.255.255.0 192.168.1.10 1

!

crypto ipsec transform-set 1 esp-aes esp-sha-hmac
crypto map 1 1 match address VPN
crypto map 1 1 set peer 10.1.1.2
crypto map 1 1 set transform-set 1
crypto map 1 2 match address VPN2
crypto map 1 2 set peer 10.1.1.3
crypto map 1 2 set transform-set 1
crypto map 1 interface outside
crypto isakmp enable outside
crypto isakmp policy 1
 authentication pre-share
 encryption aes
 hash sha
 group 2
 lifetime 86400
tunnel-group 10.1.1.2 type ipsec-l2l
tunnel-group 10.1.1.2 ipsec-attributes
 pre-shared-key *
tunnel-group 10.1.1.3 type ipsec-l2l
tunnel-group 10.1.1.3 ipsec-attributes
 pre-shared-key *

 The important point here is to allow GRE return traffic through the firewall. 172.16.1.1 and 172.16.2.1 are the GRE tunnel source addresses for customer 1 and customer 2, which will terminate on the router inside the ASA.

Now the game is more or less done, all we need to do is to put the traffic terminating on our GRE tunnel into the right VRF. Here is the config on the core router (R2 in our case):

Define the VRFs for our customers to allow the overlapping networks on the inside:

vrf definition c1
 rd 65000:1
 !
 address-family ipv4
 exit-address-family
!
vrf definition c2
 rd 65000:2
 !       
 address-family ipv4
 exit-address-family
!

Create some loopback interfaces to simulate a LAN network and to hold the source IPs of our GRE tunnels

interface Loopback0
 ip address 172.16.1.1 255.255.255.0
!
interface Loopback1
 vrf forwarding c1
 ip address 192.168.10.1 255.255.255.0
!
interface Loopback2
 vrf forwarding c2
 ip address 192.168.10.1 255.255.255.0
!
interface Loopback10
 ip address 172.16.2.1 255.255.255.0
!

Create the GRE tunnel interfaces, and forward traffic to the customers VRF:

interface Tunnel0
 vrf forwarding c1
 ip address 1.1.1.2 255.255.255.0
 tunnel source Loopback0
 tunnel destination 10.1.1.2
!
interface Tunnel2
 vrf forwarding c2
 ip address 2.2.2.2 255.255.255.0
 tunnel source Loopback10
 tunnel destination 10.1.1.3
!

Force the traffic from the VRF to the remote overlapping subnets to flow through our GRE tunnel:

ip route 0.0.0.0 0.0.0.0 192.168.1.1
ip route vrf c1 192.168.1.0 255.255.255.0 1.1.1.1
ip route vrf c2 192.168.1.0 255.255.255.0 2.2.2.1

The last thing is to give the GRE parameters to the customer so that he can setup his tunnel correctly. He can send whatever traffic through the tunnel, it will never overlap with other customers. So let's have a look at customer 1 on R1. We provide him the following parameters:

• GRE: tunnel destination 172.16.1.1 and tunnel source must be his WAN address
• IPSEC: tunnel destination must be 10.1.1.1 and provide him the crypto informations and keys

 R1 config:

crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 2 
crypto isakmp key cisco address 10.1.1.1
!
crypto ipsec transform-set 1 esp-aes esp-sha-hmac
!
crypto map 1 1 ipsec-isakmp
 set peer 10.1.1.1
 set transform-set 1
 match address VPN
!

This is the overlapping subnet for both customers.

interface Loopback0
 ip address 192.168.1.1 255.255.255.0
!

GRE tunnel config: 

interface Tunnel0
 ip address 1.1.1.1 255.255.255.0
 tunnel source FastEthernet1/0
 tunnel destination 172.16.1.1
!
interface FastEthernet1/0
 ip address 10.1.1.2 255.255.255.0
 duplex auto
 speed auto
 crypto map 1
!
ip route 0.0.0.0 0.0.0.0 10.1.1.1
ip route 192.168.10.0 255.255.255.0 1.1.1.2
!        
ip access-list extended VPN
 permit gre host 10.1.1.2 host 172.16.1.1

The config for customer 2 (R3)is very similar (Just putting it here for reference). Only the GRE tunnel destination changes:

crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 2 
crypto isakmp key cisco address 10.1.1.1
!
!
crypto ipsec transform-set 1 esp-aes esp-sha-hmac
!
crypto map 1 1 ipsec-isakmp
 set peer 10.1.1.1
 set transform-set 1
 match address VPN
!
interface Loopback0
 ip address 192.168.1.1 255.255.255.0
!
interface Tunnel0
 ip address 2.2.2.1 255.255.255.0
 tunnel source FastEthernet1/0
 tunnel destination 172.16.2.1
!
interface FastEthernet1/0
 ip address 10.1.1.3 255.255.255.0
 duplex auto
 speed auto
 crypto map 1
!
ip route 0.0.0.0 0.0.0.0 10.1.1.1
ip route 192.168.10.0 255.255.255.0 2.2.2.2
!        
ip access-list extended VPN
 permit gre host 10.1.1.3 host 172.16.2.1

So here we have taken care of overlapping subnets on both ends:

1. On the WAN, we are hiding the overlapping subnets to the ASA using GRE encapsulation
2. On the LAN, we use VRF to mask overlapping traffic to the router

Now let's check that traffic goes through both ways for overlapping subnets:

ASA(config)# sh crypto ipsec sa
interface: outside
    Crypto map tag: 1, seq num: 1, local addr: 10.1.1.1

      access-list VPN permit gre host 172.16.1.1 host 10.1.1.2
      local ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
      remote ident (addr/mask/prot/port): (10.1.1.2/255.255.255.255/47/0)
      current_peer: 10.1.1.2

      #pkts encaps: 15, #pkts encrypt: 15, #pkts digest: 15
      #pkts decaps: 15, #pkts decrypt: 15, #pkts verify: 15

      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 15, #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
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 10.1.1.1, remote crypto endpt.: 10.1.1.2

    Crypto map tag: 1, seq num: 2, local addr: 10.1.1.1

      access-list VPN2 permit gre host 172.16.2.1 host 10.1.1.3
      local ident (addr/mask/prot/port): (172.16.2.1/255.255.255.255/47/0)
      remote ident (addr/mask/prot/port): (10.1.1.3/255.255.255.255/47/0)
      current_peer: 10.1.1.3

      #pkts encaps: 15, #pkts encrypt: 15, #pkts digest: 15
      #pkts decaps: 15, #pkts decrypt: 15, #pkts verify: 15
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 15, #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
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 10.1.1.1, remote crypto endpt.: 10.1.1.3

R2#ping vrf c1 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/33/44 ms

ASA(config)# sh crypto ipsec sa
interface: outside
    Crypto map tag: 1, seq num: 1, local addr: 10.1.1.1

      access-list VPN permit gre host 172.16.1.1 host 10.1.1.2
      local ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
      remote ident (addr/mask/prot/port): (10.1.1.2/255.255.255.255/47/0)
      current_peer: 10.1.1.2

      #pkts encaps: 20, #pkts encrypt: 20, #pkts digest: 20
      #pkts decaps: 20, #pkts decrypt: 20, #pkts verify: 20

      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 20, #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
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 10.1.1.1, remote crypto endpt.: 10.1.1.2

    Crypto map tag: 1, seq num: 2, local addr: 10.1.1.1

      access-list VPN2 permit gre host 172.16.2.1 host 10.1.1.3
      local ident (addr/mask/prot/port): (172.16.2.1/255.255.255.255/47/0)
      remote ident (addr/mask/prot/port): (10.1.1.3/255.255.255.255/47/0)
      current_peer: 10.1.1.3

      #pkts encaps: 15, #pkts encrypt: 15, #pkts digest: 15
      #pkts decaps: 15, #pkts decrypt: 15, #pkts verify: 15
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 15, #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
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 10.1.1.1, remote crypto endpt.: 10.1.1.3

R2#ping vrf c2 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/24/32 ms

Not showing the ipsec sa here for clarity, but the count will increase on second sa.

R1#ping 192.168.10.1 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/32/44 ms

This works, but all of this would be much easier having the router terminate the VPN traffic (using tunnel protection) and put traffic in VRFs that way. The ASA would have just passed ESP traffic to the router. This was not an option in our case, because the core router did not have a hardware crypto card.