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.
Hello Ed,
Thank you for the excellent explanation on how to solve an issue like this. I have included an example of how your Solution #2 would look on a Cisco device. Is this correct?
SeattleInside
subnet 10.0.0.0/24
Seatle2Denver
subnet 10.1.1.0/24
ToDenver
subnet 10.2.2.0/24
DenverInisde
subnet 10.0.0.0/24
nat (inside,outside) source static SeattleInside Seatle2Denver destination static ToDenver DenverInisde
Thanks again!!
Yeap, looks right to me! You’re configuring a Policy, Twice NAT on a Cisco ASA running 8.4+ code.
Hej Ed,
You are gem in explaining and depicting the network diagrams to clearly focus on the subject, there is always a pleasure reading your posts. Thumps Up!
A gentle request to add the NAT configurations further emphasis the understanding this concept.
Cheers, Tech Kludge
Hi techkludge,
I wanted this article to apply to all vendors, so opted intentionally to avoid any specific configuration.
Hopefully though, there is enough details in the article and in this Cisco ASA NAT configuration guide or Cisco IOS Router NAT configuration guide that readers can put together the relevant NAT commands themselves. =)
Thank you for the kind words.
Good work.
May I know which tool do you use for drawing those topology diagrams?
Hi Jai, Thank you! I use PowerPoint for all my illustrations. It isn’t the best tool, but I’ve gotten pretty accustomed to using it.
Hi Ed,
Your websirte is a treasure for me. Thanks for the great explanations.
I do understand the whole NAT-ting process, However I still don’t get how does the computers in seattle know that they should use the 10.2.2.0/24 to reach Denver (and vice versa) ?
Is this achieved through a DNS manipulation ?
Thanks,
Hi Ibrahima, glad you enjoyed the content =).
That part is somewhat abstracted from this process. Maybe it’s DNS. Maybe it’s the users in Seattle manually typing “ping 10.2.2.x” (or SSH, or RDP, or etc…). Maybe it’s something else. One way or another, the NAT configurations above would simply enable connectivity between the IP subnets. How the user utilizes that connectivity is an entirely different problem to solve.
Hope this helps =)
Hello Ed,
Thank your very much for your article. However I’m not quite sure to understand this part in the #1 solution :
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.
How the router is able to know that the destination adress must be translated ? It only has a Nat rule to translate the source adresse no ?
Thanks for you help.
FXG
Hi FXG. Glad you liked the article.
The NAT configuration on R2 does this:
Notice the configuration translates the source of outbound packets, from 10.0.0.0/24 to 10.2.2.0/24.
For inbound packets, the reverse happens: the destination is translated from 10.2.2.0/24 back to 10.0.0.0/24, hence — untranslated from the outbound translation.
Remember, Static NAT is Bidirectional, which means even if the packet wasn’t initiated from an internal host, the “un-translation” will still occur.
Hello,
great article. How does the routing work ? If I ping a remote address that overlaps with a local address, the router will never know it is a remote address, unless you ping the DNS name associated with the other side, is that the right assumption to make
Hi Georg. That is exactly why you need to mask the other side to so it appears as a different network to the local side. In each example above, Seattle thinks Denver is the 10.2.2.0/24 network, even though Denver is actually the 10.0.0.0/24 network.
Best ever explanation on vpn concept with NAT. Thank you for your effort on emphasizing on each and every major point.
Thank you for the kind words, Richa =)
Hi, thanks for this guidance.
But can you please fix my problem in my network, i try my best to explain it to you.
Main Office with 1 ip Public to mikrotik that have local ip 10.1.10.0/23
second Office with IPsec VPN with local ip 172.23.133.0/29
i can ping to second Office without any problem prom all local ip Main Office 10.1.10.2-10.1.11.255
here is the problem:
since now we have situation (COVID19)
half my people working from home using their home internet.
some of those need to access Second Office local network ip 172.23.133.0/29
so i try to setup new VPN connection for those peoples.
1st i try PPTP (172.2.2.0/24) directly to my mikrotik, the result is i only able to ping my VPN gateway 172.2.2.1, cant ping my main mikrotik gateway 10.1.10.1 (from 10.1.10.0/23) also cant ping to Second Office ip 172.23.133.0/29
2nd i try using OpenVPN also directly to my mikrotik with all the certificate and user. But i have same result, cant ping my main mikrotik gateway 10.1.10.1 (from 10.1.10.0/23) also cant ping to Second Office ip 172.23.133.0/29.
i already try to create NAT but still no clue whats happend.
sorry for my bad english.
and Thank you in advance for the help.
cheers
This doesn’t sound like an Overlapping Networks problem. Sounds like a Hairpinning and VPN problem. I’d encourage you to contact your support vendor or use public help forums like Reddit or Spiceworks.
Good article. helped me a lot. I have one question though . I am assuming but wanted to confirm.
So when traffic sourced out of Seattle with Src ip of 10.2.2.88. I am assuming Seattle network will somehow advertise that src subnet within Seattle network may be a null route and redistribute internally with igp or ibgp etc. So the return traffic is delivered back to this Seattle headend router?
Yes. The Routers in Seattle will have to know about and advertise knowledge of the 10.2.2.x network. Once the traffic gets to the Headend/VPN Router, it can do the NAT necessary to get it to Denver.
In both the case, what will be the VPN Encryption Domain ACL/ Intresting traffic ACL through the VPN is ???
It will be 10.1.1.x/24 and 10.2.2.x/24 on R1 and on R2 vice versa if im not wrong.