In the first article of this series, we considered a scenario in which we wanted to set up a VPN tunnel between two overlapping subnets. In that article, we assumed that we had access to both devices (Cisco ASAs) at the end of the tunnel so we used source NAT to change the IP address spaces to something else.

In this article, we will consider the case where you have access to only one side of the VPN tunnel. This can happen if you are connecting to a business partner and for some reason, that organization is not willing or cannot perform source NAT at their end.

Our network diagram remains the same as with the first article as shown below:

The GNS3 diagram is as shown below:

I’m excited about this particular article because I had to do a lot of research and labs to come up with a viable solution. You will see what I mean in a minute.

In this article, we will assume we have access to only ASA1 although I will paste the configuration of the devices on the other side (ASA2 and R2) just for explanation purposes. As with the last article, since we have overlapping subnets, we still need to employ NAT. The difference now is that our entire NAT configuration needs to be done on ASA1.

To break down what is required, ASA1 has to do the following:

  1. Translate the local network (the 192.168.1.0/24 network behind ASA1) to a different IP address space.
  2. Translate the remote network (the 192.168.1.0/24 network behind ASA2) into another IP address space.

The first item needs to be done so that when traffic from behind ASA1 reaches ASA2, ASA2 does not drop it thinking it is an attack (since it also has the same network on its inside interface). The second item needs to be done so that hosts on the inside network behind ASA1 do not think they are connecting to a local host on the network (since it is the same subnet).

We can achieve both of these items using source/destination NAT just the way we did at the end of the last article. In that article, we had the following configuration:

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

In the above configuration, notice the “destination static VPN-destination VPN-destination” configuration – we translated the VPN-destination network to itself. For this article, we need to translate that network to another subnet.

Since this is a somewhat complex NAT scenario, let us take the NAT configuration out of the way first before we add the VPN configuration. The configuration on ASA1 including NAT is as follows:

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
!
object network remote-real-network
 subnet 192.168.1.0 255.255.255.0
!
object network remote-mapped-network
 subnet 10.10.20.0 255.255.255.0
!
nat (inside,outside) source static inside-real-network inside-mapped-network destination static remote-mapped-network remote-real-network

The configuration on ASA2 is as follows:

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
!
route outside 10.10.10.0 255.255.255.0 41.1.1.1

Notice that the configuration on ASA2 is just basic configuration with a route for the translated network behind ASA1 pointing towards ASA1. ASA2 does not perform any NAT translations relevant to this article.

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

Now, this is where things begin to get interesting. Let’s see if R1 can ping R2. Since ICMP is not permitted by default through the firewall, I will create an access-list to permit this on both ASAs.

access-list OUT_IN extended permit icmp any any
access-group OUT_IN in interface outside

I will also enable logging on ASA1 just to see what happens.

Keep in mind that R1 will try to ping the translated IP address of R2 which is 10.10.20.10.

The ping was unsuccessful. If we look at the logging output on the ASA, we will see something like the following:

If you look at that output closely, you will see the problem: Routing failed to locate next hop for ICMP from inside:10.10.10.10/18 to outside:192.168.1.10/0. The ASA is saying it doesn’t know how to reach R2 – so this is a routing issue. But if we were to add a route, what network will we use: the real network (192.168.1.0/24) or the mapped network (10.10.20.0/24)?

Looking at that routing failed message, we see that the ASA does not know how to reach the 192.168.1.10 host on the outside interface. This means the ASA expects a route for the real network because it tries to perform the route lookup AFTER it has performed (untranslated) the destination NAT.

Note: I will dedicate another article to the packet flow on a Cisco ASA especially as it relates to NAT and route lookup. In some cases, the ASA can do a partial route lookup before NAT to determine what interface to forward traffic out from.

So let’s try to add a route for 192.168.1.0/24 pointing to ASA2 through the outside interface (humor me):

Of course! Since there is already a directly connected route on the ASA, you cannot add a static route of the same network. There are two ways around this:

  1. Add a default route pointing towards ASA2. The problem with this solution is: how will you handle all other non-ASA2 traffic such as Internet traffic?
  2. Split the subnet into two. This option is really genius and I don’t claim credit; it belongs to Cisco themselves. You can split the 192.168.1.0/24 network into two /25 networks.

Now, if we test the ping again from R1 to R2, it goes through:

Having sorted out our NAT configuration, we can now add VPN on top of it. The only tricky part about the VPN configuration is what subnets to match in the crypto map access list. We can glean the needed information from that routing failed log:

The packet that generated this message was from R1 (192.168.1.10) trying to ping R2 (10.10.20.10). However, from the error log, we see that the ASA has translated the IP address of R1 to 10.10.10.10 and has untranslated the IP address of R2 to 192.168.1.10.

In the last article, we said that for inside to outside flow, NAT is done before crypto map. Therefore, we can conclude that the crypto map ACL on ASA1 will match the translated address of the inside network as the source and the real address of the remote network as the destination. Thus, our VPN configuration on ASA1 is as follows:

access-list CRYPTO_ACL extended permit ip 10.10.10.0 255.255.255.0 192.168.1.0 255.255.255.0
!
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

The VPN configuration on ASA2 is similar except that the crypto map ACL is the mirror of the one on ASA1:

access-list CRYPTO_ACL extended permit ip 192.168.1.0 255.255.255.0 10.10.10.0 255.255.255.0
!
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

We can also remove the ACL we configured on both ASAs for testing the ping traffic between R1 and R2 since tunneled traffic are not subject to interface ACLs (by default).

no access-group OUT_IN in interface outside

We can test our VPN tunnel by pinging from R1 to R2.

We can view the IPsec SAs to verify that the packets are indeed going through the tunnel:

Conclusion

In this article, we configured a VPN tunnel between two ASAs protecting networks with the same subnet. We considered a scenario where we have access to just one of the devices and used source/destination NAT for this solution.

I hope you have found this article insightful.

References and further reading