One of the things you may come across as a network engineer is configuring a VPN tunnel between two sites that have the same IP address space, i.e. overlapping subnets. There are many reasons this can happen, such as when two companies merge or if you are connecting to a business partner who is already using your IP address space.

In the first case of a merger, you will probably have access to (or at least control over) the devices at both ends of the VPN tunnel. In the other case of connecting to a business partner, you may or may not have control over the device on the other end of the tunnel. In these articles, we will consider the solution to both scenarios: either you have access to both devices or you have access to just one device.

In this article, we will begin with the simpler case where you have access to both devices at the end of the VPN tunnel. We will be using Cisco ASAs as our VPN terminators, although the same concept applies to Cisco IOS routers (only command syntax will differ). We will be using the diagram below:

For simplification, I have connected the ASAs directly as shown in the GNS3 diagram below:

The challenge with overlapping subnets is in routing. In the above diagram, ASA1 has a direct connection to the 192.168.1.0/24 network via its inside interface. Therefore, there is no way the ASA will forward traffic for the same subnet out of its outside interface towards ASA2.

What if there was a way to “deceive” the ASAs about the network to which they will be connecting to? What I mean is, what if we configure the ASAs to hide the real networks behind them? ASA1 can mask its 192.168.1.0/24 to say 10.10.10.0/24 while ASA2 will change its own 192.168.1.0/24 to something else, like 10.10.20.0/24. Therefore, ASA1 will think it is creating a VPN tunnel between 192.168.1.0/24 and 10.10.20.0/24 and ASA2 will think it is creating a VPN tunnel between 192.168.1.0/24 and 10.10.10.0/24.

The last statement I made above is not entirely correct because of the order of operation on the Cisco ASA. Which one is processed first: NAT or Crypto map? The answer depends on the direction of traffic flow.

  1. When traffic is flowing from the inside to the outside, NAT is processed first before crypto maps.
  2. In the other direction (outside to inside), crypto maps are processed before NAT.

So let’s take a scenario to see what happens. Host1 (192.168.1.10) behind ASA1 wants to send traffic to Host2 (192.168.1.10) behind ASA2. Note that Host1 sees Host2 as 10.10.20.10 because of the NAT performed by ASA2:

  1. Host1 forwards the traffic (src = 192.168.1.10; dst = 10.10.20.10) to its default gateway which is ASA1.
  2. For inside to outside flow, NAT is processed before the crypto map. Therefore, ASA1 will change Host1’s IP address to something like 10.10.10.10.
  3. Since NAT happens first, for the VPN tunnel to be set up between ASA1 and ASA2, the ACL used under the crypto map on ASA1 must match a source network of 10.10.10.0/24 (not 192.168.1.0/24) and destination of 10.10.20.0/24.
  4. If the tunnel is set up successfully, ASA2 receives the traffic. For outside to inside flow, crypto map is processed before NAT. Therefore, the ACL used under the crypto map on ASA2 must match a source network of 10.10.20.0/24 and a destination network of 10.10.10.0/24, i.e. the reverse (mirror) of the ACL used on ASA1.
  5. ASA2 then performs NAT by changing 10.10.20.10 to 192.168.1.10 and sends the traffic to Host2.

As such, we can conclude that on both ASAs, the ACL used to match interesting traffic should contain the translated addresses, not the real addresses.

The configuration on the ASAs is as follows:

ASA1

hostname ASA1
!
interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address 41.1.1.1 255.255.255.252
 no shut
!
interface GigabitEthernet1
 nameif inside
 security-level 100
 ip address 192.168.1.1 255.255.255.0
 no shut
!
object network inside-mapped-network
 subnet 10.10.10.0 255.255.255.0
!
object network inside-real-network
 subnet 192.168.1.0 255.255.255.0
 nat (inside,outside) static inside-mapped-network
!
access-list CRYPTO_ACL extended permit ip 10.10.10.0 255.255.255.0 10.10.20.0 255.255.255.0
!
route outside 10.10.20.0 255.255.255.0 41.1.1.2
!
crypto ipsec ikev1 transform-set TRANS_SET esp-3des esp-md5-hmac
crypto map CRYP_MAP 10 match address CRYPTO_ACL
crypto map CRYP_MAP 10 set peer 41.1.1.2
crypto map CRYP_MAP 10 set ikev1 transform-set TRANS_SET
crypto map CRYP_MAP interface outside
crypto ikev1 enable outside
crypto ikev1 policy 1
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400
!
tunnel-group 41.1.1.2 type ipsec-l2l
tunnel-group 41.1.1.2 ipsec-attributes
 ikev1 pre-shared-key cisco

ASA2

hostname ASA2
!
interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address 41.1.1.2 255.255.255.252
 no shut
!
interface GigabitEthernet1
 nameif inside
 security-level 100
 ip address 192.168.1.1 255.255.255.0
 no shut
!
object network inside-mapped-network
 subnet 10.10.20.0 255.255.255.0
!
object network inside-real-network
 subnet 192.168.1.0 255.255.255.0
 nat (inside,outside) static inside-mapped-network
!
access-list CRYPTO_ACL extended permit ip 10.10.20.0 255.255.255.0 10.10.10.0 255.255.255.0
!
route outside 10.10.10.0 255.255.255.0 41.1.1.1
!
crypto ipsec ikev1 transform-set TRANS_SET esp-3des esp-md5-hmac
crypto map CRYP_MAP 10 match address CRYPTO_ACL
crypto map CRYP_MAP 10 set peer 41.1.1.1
crypto map CRYP_MAP 10 set ikev1 transform-set TRANS_SET
crypto map CRYP_MAP interface outside
crypto ikev1 enable outside
crypto ikev1 policy 1
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400
!
tunnel-group 41.1.1.1 type ipsec-l2l
tunnel-group 41.1.1.1 ipsec-attributes
 ikev1 pre-shared-key cisco

The configuration on both routers acting as hosts is shown below:

interface FastEthernet0/0
 ip address 192.168.1.10 255.255.255.0
 no shut
!
ip route 0.0.0.0 0.0.0.0 192.168.1.1

To test our VPN, I will ping the translated IP address of R2 (10.10.20.10) from R1.

The first ping did not succeed because the tunnel was just being set up. We can check the ISAKMP and IPsec SAs on any of the ASAs.

We can look at the NAT translation tables on the ASAs to see the static NAT happening:

Extra NAT configuration

In the NAT configuration on the ASAs, I translated the inside network (192.168.1.0/24) to a mapped address space (10.10.10.0/24 or 10.10.20.0/24). This NAT translation is not destination-based, meaning that any traffic from 192.168.1.0/24 to any destination will be translated to the mapped address space.

The problem with this configuration is that the mapped address space used for the VPN will probably be from the private IP address space. So how will the internal hosts connect to the Internet for example? A more likely scenario is that you will be doing dynamic NAT or PAT for the internal network to access the Internet. Therefore, to implement the NAT needed for the VPN, you will need a source-and-destination based NAT.

A more realistic NAT configuration is as follows:

ASA1

object network inside-real-network
 subnet 192.168.1.0 255.255.255.0
 nat (inside,outside) dynamic interface
!
object network inside-mapped-network
 subnet 10.10.10.0 255.255.255.0
!
object network VPN-destination
 subnet 10.10.20.0 255.255.255.0
!
nat (inside,outside) source static inside-real-network inside-mapped-network destination static VPN-destination VPN-destination

ASA2

object network inside-real-network
 subnet 192.168.1.0 255.255.255.0
 nat (inside,outside) dynamic interface
!
object network inside-mapped-network
 subnet 10.10.20.0 255.255.255.0
!
object network VPN-destination
 subnet 10.10.10.0 255.255.255.0
!
nat (inside,outside) source static inside-real-network inside-mapped-network destination static VPN-destination VPN-destination

This configuration still achieves what we intended but with the added benefit that the internal hosts can connect to the public network using the IP address of the ASA’s outside interface.

Conclusion

In this article, we have configured site-to-site VPN between two Cisco ASAs that have the same IP address space behind them. We considered a scenario where we have access to both devices at the end of the VPN tunnel. We discovered that the workaround is to use NAT to translate the networks to different IP address spaces.

In the next article, we will consider the scenario where you have control over the configuration of only one of the devices terminating the VPN tunnel.

References and further reading