VPN

Configuring VPNs with Overlapping Networks

This document describes how to create VPN Tunnel between Sites that have identical and hence overlapping IPAddresses. The following scenarios will be covered in this document in detail: VPN between Headquarters & remote sites with identical IP-Addresses VPN between Headquarters & remote sites with identical IP-Addresses, apply many-to-one NAT VPN between Headquarters & remote sites with identical IP-Addresses, hub and spoke

Testbed-Setup In all examples, we will use a PRO 3060 in the Headquarters, running SonicOS 3.1. As well we have two remote sites (TZ170) running SonicOS enhanced 3.1.

Scenario 1: Headquarters & remote sites with identical IP-Addresses

Scenario This company has a Headquarters and two remote offices. The Remote Sites have not been connected in any way to the Headquarters in the past. To make installation as easy as possible, the same IP-Subnet has been used in all locations. Connecting all locations with each other typically causes some routing difficulties. In all Offices we have an existing IP-Addressing Scheme of 10.10.1.x Now, all remote sites have to be connected by VPNs. In this scenario, changing the IP-Addresses is not possible or would cause a lot of work, so they have to remain the same. To make this work, we have to use a Hide-NAT in the VPN Configuration. This way every local network may remain the same, the existing IP-Addresses will be hidden behind a 1:1 NAT unique IP-Range. Note that for this scenario, SonicOS enhanced is required on all SonicWALL UTM appliance.

Setup Headquarters Two VPN Tunnels will be terminated to / from here, for RemoteSite1 and RemoteSite2. Adding the VPN Tunnel at Headquarters Configure a standard VPN Tunnel. There are only two changes needed to create the hide-NAT.

The object RemoteSite1_LAN specifies the IP-address range of RemoteSite1 (10.10.5.0) this will be translated to 10.10.1.0.

Configuration in Remote Site 1 Create a normal VPN tunnel and apply NAT.

Configuration on RemoteSite 2 The configuration here is basically identical to RemoteSite 1. The only difference is the RemoteSite2_LAN needs to refer to a 10.10.6.0 Address. How does it work? IP-Addresses now get translated 1:1. If you want to reach an IP-Address in RemoteSite1, for example the LAN IP of the SonicWALL UTM appliance, which is configured to be 10.0.1.254 locally, use 10.10.5.254 from the headquarters instead. Additional Information: When creating the VPN Tunnel as described above, two NAT Policies will get created automatically. This way, the administrator still has full control over what has been configured and may, if needed, alter this configuration.

VPN Settings Screen at Headquarters appliance:

Extension to this scenario: Apply Many to one NAT In some cases, it is required that all communication from the remote offices is hidden behind 1 IP address (Many to one NAT). This can be helpful if, for example, Terminal Services Access from the Remote Office to the Headquarter is needed (and only one IP from the remote location accesses the HQ), it can be accomplished by changing the following: RemoteSite:

In the Headquarters change the configuration as follows:

Note: By setting it up this way, only a one-way communication from the Remote Office to the Headquarter is possible.

Step Two: Extended Solution. Allow traffic between RemoteSite1 & 2 across VPN In this example, we will enhance the scenario we set up in Step 1 (without the latest addition One to Many NAT) to allow network-traffic flow to the Headquarters AND between the Remote Sites, using the existing Tunnels and by routing all traffic through the headquarters. This scenario (called Hub & Spoke) will eliminate the need for the administrator to create a fully meshed VPN network, requiring fewer total VPN policies. Even now, the existing overlapping IP-networks do not have to be changed.

RemoteSite1 can reach RemoteSite2 per VPN without having a direct tunnel between both locations.

Setup Headquarter: Tunnel to Remote Site 1 As we can only specify one Object in the Tunnel-definition, a new Address-Group Object which groups the Local LAN and LAN of RemoteSide2 needs to be created.

Use this group in the Tunnel definition

Now review the NAT Policies, manual intervention is required here. Make sure the following policies exist:

Policy to handle traffic from RemoteSite2 to the LAN.

NAT Policy to handle traffic from the LAN to RemoteSite2

Policy to handle traffic to RemoteSite1.

Policy for traffic from RemoteSite1 to HQ-LAN.

Setup RemoteLocation1 In the Remote Locations only one change needs to be applied, you have to extend the VPN Destination Network to reflect all Networks that should be made available through this tunnel. At RemoteSite1, the LAN of RemoteLocation2 must be added. Create a Network Object for RemoteSite2_LAN

Now group this with the Headquarters_LAN Object

And refer to this object in the VPN Tunnel definition:

Summary Now all sites can communicate with each other. From the RemoteLocations, the Headquarters can be reached under the 10.10.4.x addresses. Remote Location1 is available from the Headquarters and RemoteSite2 using 10.10.5.x, Remote Location 2 can be reached by 10.10.6.x Addresses from outside.

VPN Settings overview for Headquarters

VPN Settings overview for RemoteSite1

Additional Comment: In this document, default settings have been used wherever possible. For maximum security we strongly recommend to use a stronger encryption algorithm (e.g. AES), enable PFS and to use longer / more sophisticated pre-shared keys!