This release includes significant user interface changes and many new features that are different from the SonicOS 6.5 and earlier firmware. The below resolution is for customers using SonicOS 7.X firmware.
Feature/Application:
This article describes a scenario where a Site to Site VPN tunnel has been established between Site A and Site B; a Server behind Site A needs to be accessed by using the WAN IP address of Site B.
For the purpose of this article, we’ll be using the following IP addresses as examples to demonstrate the NAT policy creation. You can use these examples to create a NAT policy for your network, substituting your IP addresses for the examples shown here:
Site A : TZ 670 X1 WAN IP: 67.115.118.68/27 X0 LAN Subnet: 192.168.1.0/24 Terminal Server on LAN: 192.168.1.2 | Site B : TZ 470 X1 WAN IP: 59.82.35.86/27 X0 LAN Subnet: 10.10.10.0/24 |
Procedure:
Configuration on Site B SonicWall (TZ 470)
This article assumes that a site to site VPN tunnel is already established between the two sites and traffic is flowing between them. The process of routing the traffic reaching the X1 interface of Site B SonicWall bound for the server at Site A through the VPN tunnel, involves the following:
Creating an Address Object for the Terminal Server:
Creating a rule from WAN to VPN in the Site B SonicWall.
Creating a NAT Policy in the Site B SonicWall
As the request is coming from the Internet and is not part of the VPN tunnel, the purpose of this NAT Policy is to translate the source IP address to that of the X0 subnet of the SonicWall so it can traverse the tunnel. The server at Site A sees a request from the LAN IP address of the SonicWall at Site B.
How to Test:
From the Internet have a host do a remote desktop connection to the ip address, in this case, 59.82.35.86
Troubleshooting:
This release includes significant user interface changes and many new features that are different from the SonicOS 6.2 and earlier firmware. The below resolution is for customers using SonicOS 6.5 firmware.
Feature/Application:
This article describes a scenario where a Site to Site VPN tunnel has been established between Site A and Site B; a Server behind Site A needs to be accessed by using the WAN IP address of Site B.
For the purpose of this article, we’ll be using the following IP addresses as examples to demonstrate the NAT policy creation. You can use these examples to create a NAT policy for your network, substituting your IP addresses for the examples shown here:
Site A : NSA 2400 X1 WAN IP: 67.115.118.68/27 X0 LAN Subnet: 192.168.1.0/24 Terminal Server on LAN: 192.168.1.2 | Site B : NSA 240 X1 WAN IP: 59.82.35.86/27 X0 LAN Subnet: 10.10.10.0/24 |
Procedure:
Configuration on Site B SonicWall (NSA 240)
This article assumes that a site to site VPN tunnel is already established between the two sites and traffic is flowing between them. The process of routing the traffic reaching the X1 interface of Site B SonicWall bound for the server at Site A through the VPN tunnel, involves the following:
Creating an Address Object for the Terminal Server
Creating a rule from WAN to VPN in the Site B SonicWall.
Creating a NAT Policy in the Site B SonicWall.
As the request is coming from the Internet and is not part of the VPN tunnel, the purpose of this NAT Policy is to translate the source IP address to that of the X0 subnet of the SonicWall so it can traverse the tunnel. The server at Site A sees a request from the LAN IP address of the SonicWall at Site B.
How to Test:
From the Internet have a host do a remote desktop connection to the ip address, in this case, 59.82.35.86
Troubleshooting:
The below resolution is for customers using SonicOS 6.2 and earlier firmware. For firewalls that are generation 6 and newer we suggest to upgrade to the latest general release of SonicOS 6.5 firmware.
Feature/Application:
This article describes a scenario where a Site to Site VPN tunnel has been established between Site A and Site B; a Server behind Site A needs to be accessed by using the WAN IP address of Site B.
For the purpose of this article, we’ll be using the following IP addresses as examples to demonstrate the NAT policy creation. You can use these examples to create a NAT policy for your network, substituting your IP addresses for the examples shown here:
Site A : NSA 2400 X1 WAN IP: 67.115.118.68/27 X0 LAN Subnet: 192.168.1.0/24 Terminal Server on LAN: 192.168.1.2 | Site B : NSA 240 X1 WAN IP: 59.82.35.86/27 X0 LAN Subnet: 10.10.10.0/24 |
Procedure:
Configuration on Site B SonicWall (NSA 240)
This article assumes that a site to site VPN tunnel is already established between the two sites and traffic is flowing between them. The process of routing the traffic reaching the X1 interface of Site B SonicWall bound for the server at Site A through the VPN tunnel, involves the following:
Creating an Address Object for the Terminal Server
Creating a rule from WAN to VPN in the Site B SonicWall.
Creating a NAT Policy in the Site B SonicWall.
As the request is coming from the Internet and is not part of the VPN tunnel, the purpose of this NAT Policy is to translate the source IP address to that of the X0 subnet of the SonicWall so it can traverse the tunnel. The server at Site A sees a request from the LAN IP address of the SonicWall at Site B.
How to Test:
From the Internet have a host do a remote desktop connection to the ip address, in this case, 59.82.35.86
Troubleshooting: