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