Last week’s article, IOS VPN and Overlapping IP addresses, looked at the art of dealing with address overlap by leveraging our knowledge of source NAT. That article demonstrated a solution when the parties responsible for both VPN devices have the technical ability and the knowledge to do source IP translation. While source translation can be a feasible solution, there are various scenarios that require the solution be worked out in a single device.
This article looks at how a network administrator can address overlap issues by doing both IP source and destination address in a single IOS device. In addition, we will utilize our knowledge of the NAT order of operation to properly build an IPSec tunnel to the remote tunnel endpoint.
As seen in the illustration below, we have an obvious IP address overlap between Host1 and Host2. As can also be seen in the initial router configuration, both R1 and R3 have a common overlapping network of 10.1.1.0/24. Having been told that R2 and R3 are fully configured, it is our responsibility and the goal of this article to make this configuration work by only by configuring R1.
The base (and final) configuration of the Hosts, R2 and R3 are as follows.
Host1 and Host2
hostname HostX ! interface FastEthernet0/0 ip address 10.1.1.2 255.255.255.0 no shutdown ! ip route 0.0.0.0 0.0.0.0 10.1.1.1
hostname R2 ! interface FastEthernet0/0 description to R1 ip address 22.214.171.124 255.255.255.0 ! interface FastEthernet0/1 description to R3 ip address 126.96.36.199 255.255.255.0 ! //R3 Presents Native IP addresses ip route 10.1.1.0 255.255.255.0 188.8.131.52 //R1 Presents Translated IP addresses ip route 10.100.100.0 255.255.255.0 184.108.40.206
hostname R3 ! interface FastEthernet0/0 description to R3 LAN ip address 10.1.1.1 255.255.255.0 ! interface FastEthernet0/1 description to R2 ip address 220.127.116.11 255.255.255.0 crypto map mymap ! ip route 0.0.0.0 0.0.0.0 18.104.22.168 ! //crypto configuration crypto isakmp policy 10 encryption des hash md5 authentication pre-share crypto isakmp key cisco address 22.214.171.124 ! crypto ipsec transform-set myset esp-des esp-sha-hmac ! crypto map mymap 10 ipsec-isakmp set peer 126.96.36.199 set transform-set myset match address crypto ! ip access-list extended crypto permit ip 10.1.1.0 0.0.0.255 10.100.100.0 0.0.0.255
It is our goal to make this configuration work by only configuring the router directly connected to Host1.
To complete this requirement, we must translate the inside source addresses of 10.1.1.0/24 to 10.100.100.0/24 as the packets pass through R1. Likewise, we must also make the remote subnet of 10.1.1.0/24 appear as 10.200.200.0/24 to the host(s) behind R1. Finally, we will configure the IPSec as required to tunnel the traffic to R3.
R1 Base and NAT Configuration
hostname R1 ! interface FastEthernet0/0 ip address 188.8.131.52 255.255.255.0 ip nat outside ! interface FastEthernet0/1 ip address 10.1.1.1 255.255.255.0 ip nat inside ! ip route 0.0.0.0 0.0.0.0 184.108.40.206 ! //IP Source Translation ip nat inside source static network 10.1.1.0 10.100.100.0 /24 //IP Destination Translation ip nat outside source static network 10.1.1.0 10.200.200.0 /24
Most people are pretty comfortable with “ip nat inside source” commands. However, fewer are comfortable with the “ip nat outside source” commands. These commands allow us to manipulate the destination packets flowing from the inside to the outside. In the above example, 10.1.1.x would be represented locally on R1’s LAN as 10.200.200.x. The final requirement in our challenge was to properly configure an IPSec tunnel to R3. Prior to configuring the IPSec policies, it is advisable to review and understand Cisco’s NAT Order of Operation documentation. The relevant steps are shown below.
Based on this information, we would need to create our IPSec SAs based on flows between 10.100.100.0/24 and 10.1.1.0/24. The required crypto configuration is shown below.
R1 Crypto Configuration
crypto isakmp policy 10 encryption des hash md5 authentication pre-share ! crypto isakmp key cisco address 220.127.116.11 ! crypto ipsec transform-set myset esp-des esp-sha-hmac ! crypto map mymap 10 ipsec-isakmp set peer 18.104.22.168 set transform-set myset match address crypto ! //notice the source and destination in the crypto ACL ip access-list extended crypto permit ip 10.100.100.0 0.0.0.255 10.1.1.0 0.0.0.255 ! //and apply the crypto map interface FastEthernet0/0 crypto map mymap
In order to verify our configuration, we can enable various debugs and send traffic between Host1 and Host2. Additionally, we can review the encryption/decryption statistics on either of the VPN endpoints.
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 = 84/92/112 ms
Host2#debug ip icmp ICMP packet debugging is on Host2# *Mar 1 02:53:35.763: ICMP: echo reply sent, src 10.1.1.2, dst 10.100.100.2 *Mar 1 02:53:35.871: ICMP: echo reply sent, src 10.1.1.2, dst 10.100.100.2 *Mar 1 02:53:35.959: ICMP: echo reply sent, src 10.1.1.2, dst 10.100.100.2 *Mar 1 02:53:36.043: ICMP: echo reply sent, src 10.1.1.2, dst 10.100.100.2
R1#debug ip nat IP NAT debugging is on R1# *Mar 1 02:56:17.555: NAT*: s=10.1.1.2->10.100.100.2, d=10.200.200.2  *Mar 1 02:56:17.555: NAT*: s=10.100.100.2, d=10.200.200.2->10.1.1.2  *Mar 1 02:56:19.575: NAT*: s=10.1.1.2->10.100.100.2, d=10.200.200.2  *Mar 1 02:56:19.575: NAT*: s=10.100.100.2, d=10.200.200.2->10.1.1.2 
Many network administrators are familiar and comfortable with the configuration of simple NAT scenarios. The most common configurations only require source translation. In some scenarios more complex configurations are required. This article demonstrated the use of source and destination NAT to fully overcome IP address overlap in a single device. It also addressed the applicable interaction of NAT and IPSec configuration in a more complex NAT configuration.
Disclaimer: This article is for illustration and learning only. The needs of each organization should be met based on THEIR requirements, security policy and stakeholder expectation. Concepts highlighted here should be modified, as required, to meet the specific requirements of the implementing organization.