Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

VPNs with Overlapping Subnets Problem Scenario

 

Overview

The configuration of a services router running Junos OS for virtual private network (VPN) support is quite flexible. You can create route-based VPN tunnels and Network Address Translation (NAT) can be incorporated to provide solutions for certain problematic networking scenarios. This topic discusses one such problem scenario.

Problem Scenario

With corporate mergers, branch office consolidations, and partner collaborations being common, often an organization must create a VPN to another network that uses the same private address subnet. Because both networks use the same internal IP addresses, it is not possible to build a tunnel between these two sites. However, if the tunnel endpoints on both sides are Juniper services routers, it is possible to configure a tunnel between these sites with an advanced configuration using NAT.

Because the range of private IP addresses is relatively small, there is a good chance that the addresses of protected networks of two VPN peers overlap. For bidirectional VPN traffic between two end entities with overlapping addresses, the security devices at both ends of the tunnel must apply Source Network Address Translation (NAT-src) and Destination Network Address Translation (NAT-dst) to the VPN traffic passing between them.

Note

An overlapping address space is when the IP address range in two networks are partially or completely the same.

If a host is attached to a network with the IP address 192.168.10.0/24, and the other device on the remote end is attached to a network using the same IP address subnet, it is not possible to route the traffic through the tunnel. This is because all packets are routed based on the destination IP address. Before routing occurs, determine whether the destination IP address is on the same (local) network. If the destination IP address is on the same network, for example, 10.0.0.10, the destination address is resolved using the Address Resolution Protocol (ARP). However, if the destination IP address resides on a different network, the packet is sent to the next-hop router based on the routing table of the device.

Because both the local and remote networks share the same IP addressing scheme, the packets are handled locally and not routed to the VPN tunnel. To overcome this situation, you can perform static NAT on the source IP address and destination IP address of all traffic destined for the remote network at the other end of the tunnel. For this reason, a route-based approach to IPsec VPNs is needed, because the creation of a virtual network interface on each services router is using a secure tunnel or the st0 interface. Note that when configuring the scenario described in this section, source address and destination address is translated because the packet traverses the VPN tunnel to the end host. Therefore, the services routers at each end of the tunnel must contact each other using a newly created IP address network. You must be aware of this issue because it can introduce administrative problems with certain applications when migrating two networks with overlapping subnets.

This section describes how to configure route-based VPNs using source NAT and static NAT on the st0 interface for both peers respectively. The scenario explained in this section references Figure 1.

Source NAT and Static NAT is configured on tunnel interface at both sites respectively. Figure 1 illustrates the packet flow.

The letters in the illustration correspond to the list of events.

Figure 1: Packet Flow Details
Packet Flow Details

The following settings are assumed for the Corporate and Remote sites:

  • PC1 (Computer 1) and RTR1 (Router 1) are at the Corporate site.

  • PC2 (Computer 2) and RTR2 (Router 2) are at a Remote site with an IPsec VPN tunnel linking the two sites.

  • Both PC1 and PC2 have IP address 192.168.10.10, and all network masks are /24 (255.255.255.0).

VPN traffic between sites with overlapping addresses requires address translation in both directions. Because the source address on outbound traffic cannot be the same as the destination address on inbound traffic, the addresses referenced in the inbound and outbound policies cannot be symmetrical.

A session is initiated to TCP port 80 from PC1 destined for PC2.

  1. A packet leaves PC1 destined for 10.0.20.10 to reach the Remote site host PC2. Note that devices must attempt to reach devices at the remote end of the tunnel using the IP address network owned by the remote device tunnel interface. Based on the default gateway configuration of PC1, the next hop is 192.168.10.1, which is Router RTR1.

    Source IP/Port

    Destination IP/Port

    192.168.10.10/1024

    10.0.20.10/80

  2. The packet arrives at the RTR1 internal interface with no change to the source or destination IP addresses or ports. The packet is then routed internally to the tunnel interface on RTR1.

    Source IP/Port

    Destination IP/Port

    192.168.10.10/1024

    10.0.20.10/80

  3. When the packet reaches the RTR1 tunnel interface, a source NAT setting is applied. The source NAT setting is defined for the entire 10.0.10.0 network range. Therefore, all outgoing traffic from the 192.168.10.0 network destined for the tunnel interface is source-translated to a 10.0.10.0 equivalent address. The packet is encrypted when it is transmitted out of the RTR1 external interface, but the inner packet now has the source IP address changed to 10.0.10.10 (the port does not change with source NAT). Note that even though the source IP address is translated to a 10.0.10.0 address, the security policy still needs to have the original source IP address in the match objects.

    Source IP/Port

    Destination IP/Port

    10.0.10.10/1024

    10.0.20.10/80

  4. The encrypted packet is received by the RTR2 external interface and is decrypted. The inner packet shows the source IP address as 10.0.10.10 and the destination IP address as 10.0.20.10. The packet is sent to the tunnel interface on RTR2.

    Source IP/Port

    Destination IP/Port

    10.0.10.10/1024

    10.0.20.10/80

  5. Router RTR2 has static NAT defined on the tunnel interface, which covers the entire network range for the 10.0.20.0 network. Therefore, all traffic destined for the 10.0.20.0 network is destination-translated to an internal 192.168.10.0 equivalent address. The route lookup determines that the 192.168.10.0 network is routed to the RTR2 internal interface. The packet leaves the RTR2 internal interface with the destination IP address changed to 192.168.10.10.

    Source IP/Port

    Destination IP/Port

    10.0.10.10/1024

    192.168.10.10/80

  6. Since PC2 has IP address 192.168.10.10, it receives the packet with the same source and destination IP addresses and ports as in step e.

    As shown in the previous steps, the original packet was both source and destination NAT translated before reaching PC2. Note that the NAT translations do not occur on the same device. Instead, one device performs the source address translation, and the remote device performs the destination address translation. The reply from PC2 back to PC1 follows similar steps in a reverse format as shown in step g.

  7. The reply packet is sent by PC2 to 10.1.10.10 to reach host PC1. Based on the default gateway configuration of PC2, the next hop is 192.168.10.1, which is RTR2.

    Source IP/Port

    Destination IP/Port

    192.168.10.10/80

    10.0.10.10/1024

  8. The packet arrives at the RTR2 internal interface with no change to the source or destination IP addresses or ports.

    Source IP/Port

    Destination IP/Port

    192.168.10.10/80

    10.0.10.10/1024

  9. The packet matches the existing session in RTR2 where static NAT is defined. Therefore, the traffic from the 192.168.10.0 network destined for the tunnel interface is source-translated to a 10.0.20.0 equivalent address. The packet is encrypted when it leaves the RTR2 external interface, but the inner packet now has the source IP address changed to 10.0.20.10.

    Source IP/Port

    Destination IP/Port

    10.0.20.10/80

    10.0.10.10/1024

  10. The packet arrives at the RTR1 external interface and is decrypted. The inner packet has a source IP address of 10.0.20.10 and a destination IP address of 10.0.10.10.

    Source IP/Port

    Destination IP/Port

    10.0.20.10/80

    10.0.10.10/1024

  11. The packet matches the existing session on RTR1 where source NAT is defined. Thus, the traffic destined for the 10.0.10.0 network translates to an internal 192.168.10.0 equivalent address. The packet leaves the RTR1 internal interface with the destination IP address changed to 192.168.10.10.

    Source IP/Port

    Destination IP/Port

    10.0.20.10/80

    192.168.10.10/1024

  12. The packet arrives at PC1 with the same source and destination IP addresses and ports as in step k.