Network/VPN Overlap How-To with SonicOS 2.

0 Enhanced
Updated 9/26/03
SonicWALL,Inc.

Introduction
In this whitepaper, we will configure a VPN tunnel between two SonicWALLs running SonicOS
2.0 Enhanced that use the same IP subnet on their LAN interface. With previous versions of
SonicWALL firmware it was not possible to handle this situation, as the firmware was not
capable of adequately performing NAT on VPN tunnel traffic. This new firmware feature is
intended for use in situations where renumbering one of the networks is not an option, yet
both sides must be able to communicate with each other despite using the same network
numbers. For this test, we will configure both SonicWALLs with the same 192.168.10.0/24
subnet, but will attach “hide” subnets on each side, such that each side appears to have a
separate, unique subnet.

Notes
When dealing with overlapping IP networks, SonicWALL will perform 1-2-1 NATs in each
direction for all traffic flowing across the VPN, in either direction. Because of this, it will be
necessary to make sure the “hide” subnets are the same size as the overlap subnets. This
method of NAT makes it easy to determine the appropriate “hide” address for each side,
respectively. For example, if you have the same Class C network on each side, you’ll need to
use Class C “hide” subnets so that all potential addresses on each side can be mapped
properly. So, when the tunnel is up, if you wished to reach a server on the other side of the
tunnel whose true address is 192.168.10.200, you would contact it at 192.168.50.200; persons
on the other side of the tunnel wishing to reach resources on your side would do the same (i.e.
replace the first three octets with the “hide” subnet, and not change the fourth octet).

Network Map
For this whitepaper, we will use the following network map to show how it is possible to deal
with overlapping IP subnets (see Figure 1, next page). You will need to address the WAN
interfaces of the PRO4060 devices with unique, publically reachable static IP addresses. For
this example, we will be using 192.168.10.0/24 as the example for the overlapping IP subnets.

1
 Figure 1 – Network Testbed for NAT/VPN Overlap Test

Setup Steps
Address both PRO4060 units as shown in the network map above. Make sure that both devices
have the same subnet attached (192.168.10.0/24). Attach and address the servers as shown
(192.168.10.200/24). The LAN interfaces of each PRO4060 should be 192.168.10.1/24. Assign
the unique WAN IP addresses per your ISP-provided settings.

PRO4060 “CHICAGO”
Log into the management GUI of the PRO4060 labelled “CHICAGO” (see network map above),
using a web browser on the server located at 192.168.10.200. Go to the ‘Network > Address
Objects’ section and click on the ‘Add…’ button. Create a network object called “local_hide”
of type “Network” with values ‘192.168.25.0 255.255.255.0’, zone assignment ‘LAN’. Then,
create a network object called “remote_hide” of type ‘Network’ with values ‘192.168.50.0
255.25.255.0’, zone assignment “VPN”. These are the two “hide” subnets that we’ll be using
when creating the VPN tunnel between the two PRO4060 devices. The PRO4060 at “CHICAGO”
will think that the network behind “SEATTLE” is 192.168.50.0/24, and the PRO4060 at
“SEATTLE” will think that the network behind “CHICAGO” is 192.168.25.0/24.

2
 Figure 2 – CHICAGO Hide Networks

Next, go to the ‘VPN > Settings’ menu and click on the ‘Add…’ button. When the pop-up
screen, appears, enter the following values for the ‘General’ tab (figure 3):
IPSec Keying Mode: ‘IKE Using Preshared Secret’
Name: ‘to_seattle’
IPSec Primary Gateway Name or Address: fill in with WAN IP address of other PRO4060
IPSec Secondary Gateway Name or Address: leave blank
Shared Secret: enter complex password; you will need to enter the same on the other
PRO4060
Local IKE ID (optional): leave blank; firewall will autopopulate
Peer IKE ID (optional): leave blank, firewall will autopopulate

Once these values have been set, click on the ‘Network’ tab (figure 4). On this tab, enter the
following values:
Under ‘Local Networks’ select the radio button next to ‘Choose local network from list’
and from the drop-down box next to this, select ‘LAN Primary Subnet’
Under ‘Destination Networks’ select the radio button next to ‘Choose destination
network from list’ and from the drop-down box next to this, select ‘remote_hide’

Once these values have been set, click on the ‘Advanced’ tab (figure 5). We will be using the
defaults on the ‘Proposals’ tab, so please skip this tab. On the ‘Advanced’ tab, enter the
following values:
Check the box next to ‘Apply NAT Policies’
From the drop-down next to ‘Translated Local Network’, select ‘local_hide’
From the drop-down next to ‘Translated Remote Network’, select ‘Original’

Once these values have been set, click on the ‘OK’ button to save and activate the changes.

3
Figure 3 – CHICAGO VPN ‘General’ Policy Tab

Figure 4 – CHICAGO VPN ‘Network’ Policy Tab

4
 Figure 5 – CHICAGO VPN ‘Advanced’ Policy Tab

PRO4060 “SEATTLE”
Log into the management GUI of the PRO4060 labelled “CHICAGO” (see network map on page
2), using a web browser on the server located at 192.168.10.200. Go to the ‘Network > Address
Objects’ section and click on the ‘Add…’ button. Create a network object called “local_hide”
of type ‘Network’ with values ‘192.168.50.0 255.255.255.0’, zone assignment ‘LAN’. Then,
create a network object called “remote_hide” of type “Network” with values ‘192.168.25.0
255.255.255.0’, zone assignment ‘VPN’.

Figure 6 – SEATTLE Hide Networks

5
Next, go to the ‘VPN > Settings’ menu and click on the ‘Add…’ button. When the pop-up
screen, appears, enter the following values for the ‘General’ tab (figure 7):
IPSec Keying Mode: ‘IKE Using Preshared Secret’
Name: ‘to_chicago’
IPSec Primary Gateway Name or Address: fill in with WAN IP address of other PRO4060
IPSec Secondary Gateway Name or Address: leave blank
Shared Secret: enter complex password you used on other PRO4060
Local IKE ID (optional): leave blank; firewall will autopopulate
Peer IKE ID (optional): leave blank, firewall will autopopulate

Once these values have been set, click on the ‘Network’ tab (figure 8). On this tab, enter the
following values:
Under ‘Local Networks’, select the radio button next to ‘Choose local network from
list’ and from the drop-down box next to this, select ‘LAN Primary Subnet’
Under ‘Destination Networks’, select the radio button next to ‘Choose destination
network from list’ and from the drop-down box next to this, select ‘remote_hide’

Once these values have been set, click on the ‘Advanced’ tab (figure 9). We will be using the
defaults on the ‘Proposals’ tab, so please skip this tab. On the ‘Advanced’ tab, enter the
following values:
Check the box next to ‘Apply NAT Policies’
From the drop-down next to ‘Translated Local Network’, select ‘local_hide’
From the drop-down next to ‘Translated Remote Network’, select ‘Original’

Once these values have been set, click on the ‘OK’ button to save and activate the changes.

Figure 7 – SEATTLE VPN ‘General’ Policy Tab

6
Figure 8 – SEATTLE VPN ‘Network’ Policy Tab

Figure 9 – SEATTLE VPN ‘Advanced’ Policy Tab

7
Testing
From each side, activate the tunnel by opening a connection to the other side’s server. In this
test scenario, the server behind the “CHICAGO” firewall can be reached across the tunnel at
192.168.25.200, and the server behind the “SEATTLE” firewall can be reached across the
tunnel at 192.168.50.200. Ensure that you can reach each server via HTTP and FTP from the
other side across the tunnel using these “hide” addresses. If you cannot reach the servers
across the VPN tunnel, log into each PRO4060 device and check to see if the tunnels have
negotiated (if they have negotiated successfully, the firewall will list the active tunnel under
‘Currently Active VPN tunnels’ in the ‘VPN > Settings’ menu).