Practical Networking .net

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.


  1. Tim Kowalski says

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

  2. techkludge says

    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

  3. Jai Hind says

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

  4. Ibrahima says

    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 ?


    • 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 =)

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

    • Hi FXG. Glad you liked the article.

      The NAT configuration on R2 does this:

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

      Notice the configuration translates the source of outbound packets, from to

      For inbound packets, the reverse happens: the destination is translated from back to, 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.

  6. Georg Pauwen says


    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 network, even though Denver is actually the network.

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

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


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

  9. yasir ilyas says

    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?

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

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

    • It’s going to differ for each device and vendor, some interpret the Encryption Domain (or Proxy IDs) before translation, and some do it after translation. So I can only speak to the devices I’ve had experience with, and for those devices the Encryption Domain will typically match the traffic as it appears inside the tunnel ( <-->

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

    • Interesting question. Do you mean something like a dedicated subnet that always represents “the other side”. Meaning Seattle and Denver both see the other side as

      If so, the honest answer is I don’t know. I don’t think anything would stop you from configuring the NAT in that way, but I’m wondering if you’ll confuse the Router/Firewall, since now a single subnet exists in two locations?

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

Speak Your Mind