Sos2e Enhanced Nat Vpn Overlap

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

8