Source and Destination NAT with IOS VPN

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.

SourceDestinationNAT

 

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

R2

hostname 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
!
//R3 Presents Native IP addresses
ip route 10.1.1.0 255.255.255.0 2.2.2.3
//R1 Presents Translated IP addresses
ip route 10.100.100.0 255.255.255.0 1.1.1.1

R3

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 2.2.2.3 255.255.255.0
 crypto map mymap
!
ip route 0.0.0.0 0.0.0.0 2.2.2.2
!
//crypto configuration
crypto isakmp policy 10
 encryption des
 hash md5
 authentication pre-share
crypto isakmp key cisco address 1.1.1.1
!
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
!
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.

SourceDestnationNATR1

R1 Configuration

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 1.1.1.1 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 1.1.1.2
!
//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.

NatOrder

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 2.2.2.3
!
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
!
//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

Verification

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

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

Host 2

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

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 [80]
*Mar  1 02:56:17.555: NAT*: s=10.100.100.2, d=10.200.200.2->10.1.1.2 [80]
*Mar  1 02:56:19.575: NAT*: s=10.1.1.2->10.100.100.2, d=10.200.200.2 [81]
*Mar  1 02:56:19.575: NAT*: s=10.100.100.2, d=10.200.200.2->10.1.1.2 [81]

Conclusion

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.

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.

8 Responses to Source and Destination NAT with IOS VPN

  1. Scott Klink says:

    Nicely done. Thank you for your work!

  2. anandsolgama says:

    Hi paul but if we only do NAT on INSIDE to OUTSIDE on R1 like 10.100.100.0/24 than ….why we need OUTSIDE to INSIDE ????

    I guess because when outside 10.1.1.0/24 come and meet 10.100.100.0/24 it will know that it is actually 10.1.1.0/24 !!!!!

    Last question that than if we send ping request to R3 than also R1’s host will see that it is like its own network 10.1.1.0/24 than do we need to ping 10.1.1.0/24 of R3 or 10.200.200.0/24 ?????
    Confuse paul !!!!!!

    Thanks for posting BTW !!!!

    • This is a fairly advanced NAT topic. Based on your comment it seems like you are seeing the challenges we are trying to solve. So we are specifically solving the problem from R1’s LAN to R3’s LAN. To test we are sending traffic between Host1 and Host2.

      If you only do source nat (ip nat inside source), you only solve half of the problem. The half of the problem that you solve is your ability to represent Host1 (and the rest of R1’s LAN) as 10.100.100.x to the rest of the network. The problem you haven’t solved is the ability to reach R3’s LAN. Since you haven’t done any destination NAT, you would send traffic to the native address. In this case, Host2’s native address is 10.1.1.2. If Host1 sends traffic to 10.1.1.2, it views this as its own IP address and the packet never touches the wire. In other cases, it would believe anything on 10.1.1.x is local and arp for it directly.

      To solve this, we represent the other network as 10.200.200.x/24 “ip nat outside source”. So what we have is a dual translation.

      Packets Behind R1 Look like this–

      Outbound
      10.1.1.2->10.200.200.2

      Inbound
      10.200.200.2->10.1.1.2

      Packets on the Rest of the Network Look Like this–

      10.100.100.2->10.1.1.2 (where 10.100.100.2 is H1–Translated and 10.1.1.2 is H2–Native)
      10.1.1.2<-10.100.100.2 (where 10.1.1.2 is H2--Native and 10.100.100.2 is H1--Translated) Does that help clarify?

      • anandsolgama says:

        Thanks yes paul I have tried all things in packet tracer as well and yes without OUTSIDE NAT as you mentioned ….tunnel is not working and even I removed MAP from interface still not working because …as you said we need both translation INSIDE and OUTSIDE …thanks again.

  3. anandsolgama says:

    Finally I understand topic very interesting ….. like this post a lot ….

  4. David says:

    Thanks for your post… right now Im studying to present my ccna security cert.

  5. James Smith says:

    I have an issue related to this.
    We have just a normal GRE tunnel setup.

    We need to change the internal IP addresses on our end on, however, not all of them at the same time, but there is a conflict on the other side of the tunnel.

    Let’s say our internal network is 10.1.1.x
    We need to create a new local subnet 10.2.1.x and move most users there, however, we need to leave some PCs on the 10.1.1.x subnet.
    The other side of the tunnel also has the 10.2.1.x subnet, but we do not have control over changing that.

    Is it still possible to do a NAT on the tunnel when only 80% of the local machines are moving to the new subnet, but both local subnets need access to the network on the other end of the tunnel (not the 10.2.1.x subnet on the other end)

Comments are closed.