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 for their internal network.

Host A in Seattle ( needs to speak to Host D in Denver (

VPN Overlapping Networks - The Problem

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

Host D will have the same problem, Host D is configured with the IP and also believes that the range exists on its own local network in Denver. Therefore, any packet Host D sends to the IP 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 when speaking to Denver, and making the Denver network appear as 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.

This article uses Routers as the device’s performing NAT. Many other devices can also perform NAT and the concepts described will still apply.


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 (Seattle’s actual network) and a Destination IP of (Denver’s masked network), and translate the Source IP to the network (Seattle’s masked network).

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

In this way, R1 is masking the Seattle network as, and R2 is masking the Denver network as

VPN Overlapping Networks - Policy NAT - Outbound Translation

When Host A sends a packet to Host D, the source IP will be and the destination IP will be – an IP address in a foreign network. Host A will send this packet to R1, who will change the Source IP to 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 and a destination of This packet will be sent to R2, who will translate the source IP to

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:

VPN Overlapping Networks - Policy NAT - Inbound Un-Translation

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

R1 will un-translate the destination IP of the red packet from to 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:

VPN Overlapping Networks - Policy NAT - Full Process


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 NATtranslating 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 when speaking to Denver, and make the Denver network appear as when speaking to Seattle.

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

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

VPN Overlapping Networks - Policy Twice NAT

On the way back, when Host D is responding, the packet will have a source of and a destination of 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 will be translated to (making Denver appear as the network), and the destination IP of will be translated to (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.



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.

5 3 votes
Article Rating
Notify of

Newest Most Voted
Inline Feedbacks
View all comments

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?





nat (inside,outside) source static SeattleInside Seatle2Denver destination static ToDenver DenverInisde

Thanks again!!

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

Good work.
May I know which tool do you use for drawing those topology diagrams?

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 to reach Denver (and vice versa) ?
Is this achieved through a DNS manipulation ?


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 to 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.


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

Best ever explanation on vpn concept with NAT. Thank you for your effort on emphasizing on each and every major point.

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
second Office with IPsec VPN with local ip
i can ping to second Office without any problem prom all local ip Main Office

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
so i try to setup new VPN connection for those peoples.
1st i try PPTP ( directly to my mikrotik, the result is i only able to ping my VPN gateway, cant ping my main mikrotik gateway (from also cant ping to Second Office ip
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 (from also cant ping to Second Office ip

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.


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 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?

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.

Hi This is very helpful. Can you elaborate if it is possible for the following scenario for the Solution #2?

Currently your example is using two /24 subnets to mask the source IP for both the West and East endpoints. The Seattle sees Denver as 10.2.2.x/24 and Denver sees Seattle as 10.1.1.x/24.

Can the same configuration for solution #2 be accomplished using a single shared /24 subnet? Or this is only possible to use two subnets?

This fine explanation for fine theory, thank you
I am trying to lab this example in GNS3 with R1 and R2 as IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.6(1)T
and i dont succeed
Could you clarify with the NAT commands to help me

should i find in the course the configuration commands (with IOS) for this example ?

Hi Ed,

Thank you for the explanation. I don’t understand one thing. I want to migrate VMs from Site A to Site B without changing any IP configurations on them. WHat will happen if I move the DC to Site B, how will the VMs from Site A communicate with it? As it is the same subnet…

Thank you!

Thank you, so we are better off creating new network on one side and migrate all machines at once.

Hello, Great Explanation, very useful.
I have a question, for the masked networks we have to provide routing in routers right!! for the packet to be delivered to other side of the peer ??

I have two subnets both on same network ( behind two ubuntu server devices. how I gave NAT to these devices to look that these subnets are on different networks.
My configuration is under:

UbuuntuS2 has IP of (

Question, it seems this is happening between predeterminate locations…what about users trying to access a site from multiple locations, Is there any way to change the settings on their computers so they are able to login via VPN?, as I understand, NAT has to be configured from both sides, but I am talking about users at home. Its admirable that you reach the point to explain this process in such details. Your efforts are appreciated!

Can anyone show or know how to setup DNS for this configuration to get it to work?

VxLAN is a best approach to this topology

Hello Ed Harmoush,

Is Solution #2 (Policy Twice NAT on One side) for overlapping networks is possible with Cisco CSR Router? if so could you please help me with sample commands. 

I watched all your videos including Twice NAT on IOS router but couldn’t configure it. If you provider sample configuration based on above image that would be helpful.
Thank you!

Hi Ed,
Thanks for explaining the need of NAT in Site-to-Site VPN configuration. I have a situation where there might be a problem utilizing NAT for VPN configuration and I need your advise on that.

Taking reference from the example network used in blog, lets suppose both PC”A” and PC”D” wants to transfer data using some protocol where only their original IP address can be used (not the translated one) to address the Host. How in that scenario, they would be able to communicate?

Thanks Ed for the reply.
Let’s say PC”A” (eg. and PC”B” (eg. wants to communicate over VPN tunnel but they are sharing same subnet mask ( In this case, is this possible to avoid NAT and use some other means to have communication?

try some vpn of this list https://vpnmag.ru/vpn-po-snizhennym-cenam/