VPN with Overlapping Networks

When connecting two sites together using a Virtual Private Network (VPN), a common issue that is encountered is trying to build a VPN with overlapping networks — where both sites happen to use the same Private IP addresses.

In such cases, hosts on one side of the VPN tunnel will be unable to communicate with the hosts on the other.

The problem can be circumvented, however, with clever use of Network Address Translation.

VPN Overlapping Networks: The Problem

In the example below, there are two sites – Seattle and Denver – connected with a VPN tunnel between R1 and R2. Both Seattle and Denver are using 10.0.0.0/24 for their internal network.

Host A in Seattle (10.0.0.77) needs to speak to Host D in Denver (10.0.0.88).

Since Host A is configured with the IP 10.0.0.77/24, Host A believes that every IP address in the range of 10.0.0.0 – 10.0.0.255 exists on its own local network in Seattle. Therefore, if Host A attempts to send a packet to 10.0.0.88, it will not send the packet to the Router.

Host D will have the same problem, Host D is configured with the IP 10.0.0.88/24 and also believes that the range 10.0.0.0 – 10.0.0.255 exists on its own local network in Denver. Therefore, any packet Host D sends to the IP 10.0.0.77 will be sent to the local network, and not to the Router.

If the packets are not sent to the Router, then the Routers are unable to forward them through the VPN tunnel to the other side. As a result, because of the overlapping networks, neither side will be able to speak to the other.

VPN Overlapping Networks: The Solution

The solution to the problem is to convince each host that the other host is on a foreign network. That would cause them to send packets to the Router, which can then send them through the VPN tunnel.

This will be attained by making the Seattle network appear as 10.1.1.0/24 when speaking to Denver, and making the Denver network appear as 10.2.2.0/24 when speaking to Seattle.

There are two ways of deploying Network Address Translation to facilitate this solution, one involves a NAT configuration on both routers, the other a NAT configuration on one router.

Solution #1 – Policy NAT on Both Sides

The first solution involves using Policy NAT on both routers to mask their internal network when speaking to the opposite side. Recall that a Policy NAT is a type of NAT that involves making a translation decision based upon matching both the source and destination address.

R1’s Policy NAT configuration will match packets with a Source IP of 10.0.0.0/24 (Seattle’s actual network) and a Destination IP of 10.2.2.0/24 (Denver’s masked network), and translate the Source IP to the 10.1.1.0/24 network (Seattle’s masked network).

R2’s Policy NAT configuration will match packets with a Source IP of 10.0.0.0/24 (Denver’s actual network) and a Destination IP of 10.1.1.0/24 (Seattle’s masked network), and translate the Source IP to the 10.2.2.0/24 network (Denver’s masked network).

In this way, R1 is masking the Seattle 10.0.0.0/24 network as 10.1.1.0/24, and R2 is masking the Denver 10.0.0.0/24 network as 10.2.2.0/24.

When Host A sends a packet to Host D, the source IP will be 10.0.0.77 and the destination IP will be 10.2.2.88 – an IP address in a foreign network. Host A will send this packet to R1, who will change the Source IP to 10.1.1.77 in accordance with R1’s Policy NAT configuration.

The same will occur when Host D sends a packet to Host A – the packet will have a source of 10.0.0.88 and a destination of 10.1.1.77. This packet will be sent to R2, who will translate the source IP to 10.2.2.88.

Inside the VPN tunnel, the packets will be appear as if the 10.1.1.x network is speaking to the 10.2.2.x network.

When each hosts’ packet arrives at the opposite router, the router will un-translate the destination address back to the appropriate IP address:

R2 will un-translate the destination IP of the blue packet from 10.2.2.88 to 10.0.0.88 and send the packet to Host D.

R1 will un-translate the destination IP of the red packet from 10.1.1.77 to 10.0.0.77 and send the packet to Host A.

This will enable hosts in Seattle and hosts in Denver to speak to each other, despite both sites having IP addresses in overlapping networks.

The whole process can be seen in the illustration below. This is, essentially, a combination of both images above, with the translations each router is responsible for highlighted:

Solution #2 – Policy Twice NAT on One side

Solution #1 requires both Routers to configure a Policy NAT. However, there are times when the NAT Device on one side does not support a Policy NAT configuration. In those cases, all the address translation will have to occur on a single device. Which brings us to Solution #2.

Solution #2 will still involve a Policy NAT – making a NAT decision based upon the Source and Destination. In addition, Solution #2 will also involve a Twice NAT – translating both the Source and Destination. Combined, Solution #2 will require Policy Twice NAT configuration.

Solution #2 will still solve the overlapping networks problem in the same way – by convincing the local site that the opposite site is on a foreign network. The only difference is Solution #2 will attain this effect by deploying address translation on only one router.

Once again, the goal will be to make the Seattle network appear as 10.1.1.0/24 when speaking to Denver, and make the Denver network appear as 10.2.2.0/24 when speaking to Seattle.

Since Host A (in Seattle) considers Denver as 10.2.2.0/24, R1 must be configured with a Policy NAT that matches traffic with a Source of 10.0.0.0/24 and a destination of 10.2.2.0/24.

For matched traffic, the source will be translated from 10.0.0.0/24 to 10.1.1.0/24 (making Seattle appear as the 10.1.1.0/24 network). Additionally, the destination will be translated from 10.2.2.0/24 to 10.0.0.0/24 (to allow the packet’s to be successfully delivered to Denver’s true network).

On the way back, when Host D is responding, the packet will have a source of 10.0.0.88 and a destination of 10.1.1.77. The packet will be sent to R2, which will forward it through the VPN tunnel. Upon arriving at R1, R1 will un-translate the packet:

The source IP of 10.0.0.88 will be translated to 10.2.2.88 (making Denver appear as the 10.2.2.0/24 network), and the destination IP of 10.1.1.77 will be translated to 10.0.0.77 (to allow the response packet to be successfully delivered to Seattle’s true network).

In this way, we can use a single Policy Twice NAT on one side of the VPN tunnel to mimic the behavior of using a Policy NAT on both sides outlined in Solution #1.

Summary

In the end, both solutions above accomplished the same goal: they made it seem like the IP networks on either side of the VPN tunnel were unique, and did not overlap.

Of course, the ideal situation would be for both sides of the VPN tunnel to actually have unique IP networks. But failing that, the solutions above provide a practical work around.

Comparing the two solutions, Solution #1 is cleaner, and most likely to lend itself to simpler troubleshooting and debugging in the future. Both sides of the VPN tunnel are equally contributing to the overall solution.

Solution #2, while viable, should be reserved only for cases where both sides are unable to or unwilling to configure a Policy NAT.

Either way, solving the problem of overlapping networks on a VPN simply involves using two tools in the Network Address Translation arsenal: Policy NAT and Twice NAT.

Related Posts:

Dynamic NAT

Policy NAT and Twice NAT

Why NAT?

FLSM and VLSM – Part 2