IOS VPN and Overlapping Addresses

In an ideal world, we’d not have to deal with IP address overlap. However, there are many factors that may require us to do so. These factors include things like acquisitions, mergers or partner relationships. When the need to address overlap is combined with the complexity of IOS VPN, a seemingly simple solution may seem impossible.

This article demonstrates the use of source NAT on two branch routers in order to address this challenge of IP overlap. The diagram below is used as a reference throughout this article and the key configuration concepts will be made on R1 and R3. It is worth noting that this requires access to both routers. In some cases the routers may be under the administrative control of two different parties. In those cases, the parties would have to work together. Alternatively, one party could do source and destination NAT in a single IOS platform.

IOSVPNOverlap

One crucial point to understanding this is understanding how NAT and crypto relate to each other in regards to the order of packet processing. Cisco has a good document entitled NAT Order of Operation, that addresses this comprehensively. As outlined in the document, processing happens in the following order.

NatOrder

Challenge

In this exercise, we will configure a VPN between R1 and R3 and allow their respective hosts to communicate over the encrypted tunnel. As shown in the diagram, both hosts have an IP address of 10.1.1.2 and both VPN routers have a common inside address space. To overcome this challenge, the IP LAN connected to R1 will be translated from 10.1.1.0/24 to 10.100.100.0/24. Likewise, R3’s LAN will be translated to 10.200.200.0/24.

We will start out with a base configuration that includes the following.

Both Hosts

//using routers as hosts
interface FastEthernet0/0
 ip address 10.1.1.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 10.1.1.1

R1

interface FastEthernet0/0
 description To R2
 ip address 1.1.1.1 255.255.255.0
interface FastEthernet0/1
 description To LAN
 ip address 10.1.1.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 1.1.1.2

R2

interface FastEthernet0/0
 description To R1
 ip address 1.1.1.2 255.255.255.0
!
interface FastEthernet0/1
 description To R3
 ip address 2.2.2.2 255.255.255.0
!
//we will pre add the routes for the NAT pools
//that will be used on R1 and R3 respectively
ip route 10.100.100.0 255.255.255.0 1.1.1.1
ip route 10.200.200.0 255.255.255.0 2.2.2.3

R3

interface FastEthernet0/0
 description To LAN
 ip address 10.1.1.1 255.255.255.0
interface FastEthernet0/1
 description To R2
 ip address 2.2.2.3 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 2.2.2.2

At this point we have a shell of a layer three topology. To complete our goal, we need to create the appropriate NAT configuration and IPSec policies to allow the hosts to communicate with one another. These changes are required on R1 and R3.

R1 Configuration

//phase 1 policy
crypto isakmp policy 10
 authentication pre-share
 encryption des
 hash sha
!
crypto isakmp key cisco address 2.2.2.3

//phase 2 policy
//note the use of the "Outside" addresses

ip access-list extended crypto
 permit ip 10.100.100.0 0.0.0.255 10.200.200.0 0.0.0.255
!
crypto ipsec transform-set myset esp-des esp-sha-hmac
!
crypto map mymap 10 ipsec-isakmp
 set peer 2.2.2.3
 set transform-set myset
 match address crypto

//and for the NAT

ip nat inside source static network 10.1.1.0 10.100.100.0 /24

//then to apply the NAT and Crypto

interface FastEthernet0/1
 ip nat inside
interface FastEthernet0/0
 ip nat outside
 crypto map mymap

R3 Configuration

//phase 1 policy
crypto isakmp policy 10
 authentication pre-share
 encryption des
 hash sha
!
crypto isakmp key cisco address 1.1.1.1

//phase 2 policy
//note the use of the "Outside" addresses

ip access-list extended crypto
 permit ip 10.200.200.0 0.0.0.255 10.100.100.0 0.0.0.255
!
crypto ipsec transform-set myset esp-des esp-sha-hmac
!
crypto map mymap 10 ipsec-isakmp
 set peer 1.1.1.1
 set transform-set myset
 match address crypto

//and for the NAT

ip nat inside source static network 10.1.1.0 10.200.200.0 /24

//then to apply the NAT and Crypto

interface FastEthernet0/0
 ip nat inside
interface FastEthernet0/1
 ip nat outside
 crypto map mymap

Now we can test the configuration by sending test traffic from Host1 to 10.200.200.2. We should also be able to test by sending traffic from Host2 to 10.100.100.2. To gain clarity and confirm our expectations, we can enable “debug ip icmp” on the device we are pinging.

Test Traffic From Host1

Host1#ping 10.200.200.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.200.200.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 80/85/88 ms
Host1#

ICMP Debug Output on Host2

Host2#debug ip icmp
ICMP packet debugging is on
Host2#
*Mar  1 02:11:07.695: ICMP: echo reply sent, src 10.1.1.2, dst 10.100.100.2
*Mar  1 02:11:07.779: ICMP: echo reply sent, src 10.1.1.2, dst 10.100.100.2
*Mar  1 02:11:07.867: ICMP: echo reply sent, src 10.1.1.2, dst 10.100.100.2
*Mar  1 02:11:07.951: ICMP: echo reply sent, src 10.1.1.2, dst 10.100.100.2

As indicated in the debug, Host2 believes it is communicating with 10.100.100.2 (not 10.1.1.2). We can also verify the encryption and decryption by looking at the output of “show crypto ipsec sa” on R1 or R3.

Verifying Encryption

//notice the local and remote addresses
//and encaps and decps

R1#show crypto ipsec sa

interface: FastEthernet0/0
    Crypto map tag: mymap, local addr 1.1.1.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (10.100.100.0/255.255.255.0/0/0)  <<<
   remote ident (addr/mask/prot/port): (10.200.200.0/255.255.255.0/0/0)  <<<
   current_peer 2.2.2.3 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4    <<<<
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4    <<<<

Conclusion

This article can be used as a starting point for your own network requirements. While this article uses a weak DES encryption algorithm and a common pre-shared-key, the interaction of the NAT and Crypto concepts would remain constant as you apply them to your requirement. I would also caution against the use of unqualified static NAT statements when the IOS device also does the address translation for hosts accessing the Internet. While these work, they would override other dynamic translations that might be required for the hosts to access the Internet.

 

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To. Bookmark the permalink.

6 Responses to IOS VPN and Overlapping Addresses

  1. Peter says:

    Great article! However your configuration assumes that no other NAT is done for the LAN subnets. In real life both LANs will have a dynamic PAT to allow the PCs get internet access. This breaks when you add the static statement because static is prefered over dynamic and so all traffic gets natted according to your static statement, even internet traffic. How would you solve that?

    • Good point, assuming this IOS device is also the device used for internet NAT. In that case, both the internet NAT and the NAT for the VPN would need to be qualified with a route-map. Not necessarily an ideal configuration or one that I’ve tested in a while, but it it should still be possible to get it to work.

      • Peter says:

        Yeah but I don’t see how the NAT for the VPN could be qualified with a route-map. “ip nat inside source network” command does not take a route map at the end, or at least I haven’t seen an IOS version where it does.

        One could probably use a one-to-one static command with a route-map but that would mean creating 254 NAT statements for a class-C network.

        An “ip nat inside source list blah pool blahblah” where the acl matches only vpn traffic would work except that this side of the tunnel must initiate traffic so the NAT entry can be created for before it will accept traffic coming in.

        So for internet NAT and VPN NAT on same router, I don’t see how this would work. I’ve tried it and will be glad to know of a workaround.

        Cheers

      • I agree. That is a frustrating limitation. I’m going to check some later code and see if there are any versions that support that.

  2. Ronie says:

    Hi Both,

    I am sure you could find the solution here,

    http://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/14144-static.html

    We could include route-map in static nat as well.

    Best Regards,
    Ronie

Comments are closed.