This article will guide you through the process of configuring the SonicWall to translate multiple networks for use across a Site to Site VPN.
NOTE: Due to the way this is processed, the same application can be completed for a Tunnel Interface (Route Based VPN).
Below is a diagram that will be used as an example case throughout this article as a guide to help establish the concept.
EXAMPLE: As seen in the example, the two sites share the internal networks of 192.168.168.0/24 and 192.168.1.0/24. As a result they will be translated on both ends to ensure there are no overlaps of networks coming across the tunnel. Doing so, we will be establishing the VPN by negotiating the tunnel with the 10.168.168.0/24, 10.168.1.0/24, 10.168.169.0/24, and 10.168.2.0/24 networks.
TIP: If you are trying to setup a Site to Site VPN with a single network translation, the SonicWall has a built in feature for this. See How to Configure NAT over VPN in a Site to Site VPN for more information on how to configure this.
NOTE: The SIte A configuration here is based on firmware SonicOS 6.2 and Below and SIte B configuration is based on firmware SonicOS 6.5 and Later.Based on what firmware you are on, please configure accordingly.
Site A Configuration
EXAMPLE: In the Example below, we are configuring the SonicWall Appliance as though we are at Site A (Chicago).
NOTE: While our example only has two networks being translated, your network may require more NAT Policies than what we display below.
The format for the NAT policies will be as follows:
Outbound NAT policy
Original Source: Local Network
Translated Source: Local Network Translation
Original Destination: Remote Network Translation (Group)
Translated Destination: Original
Inbound NAT policy
Original Source: Remote Network Translation (Group)
Translated Source: Original
Original Destination: Local Network Translation
Translated Destination: Local Network
EXAMPLE: Screenshots included below for our examples of the 2 Inbound and 2 Outbound NAT policies needed for the case study.
NOTE: Ensure at least one side of the VPN has keepalive enabled to keep the tunnel active.
NOTE: You may need to refresh the page for the settings to take effect. This can also be tested with a ping from local to remote or remote to local.
Site B Configuration
EXAMPLE: In the Example below, we are configuring the SonicWall Appliance as though we are at Site B (San Jose).
NOTE: While our example only has two networks being translated, your network may require more NAT Policies than what we display below.
The format for the NAT policies will be as follows:
Outbound NAT policy
Original Source: Local Network
Translated Source: Local Network Translation
Original Destination: Remote Network Translation (Group)
Translated Destination: Original
Inbound NAT policy
Original Source: Remote Network Translation (Group)
Translated Source: Original
Original Destination: Local Network Translation
Translated Destination: Local Network
EXAMPLE: Screenshots included below for our examples of the 2 Inbound and 2 Outbound NAT policies needed for the case study.
NOTE: Ensure at least one side of the VPN has keepalive enabled to keep the tunnel active.
NOTE: You may need to refresh the page for the settings to take effect. This can also be tested with a ping from local to remote or remote to local.