Configuring access to a server behind the SonicWall from the LAN / DMZ using Public IP addresses - Wissensdatenbank / IT-Security & Netzwerke / Sonicwall / Firewalls

This document describes how a host on a SonicWall LAN or DMZ can access a server on the SonicWall LAN or DMZ using the server's public IP address or FQDN.

This document describes how a host on a SonicWall LAN can access a server on the SonicWall LAN using the server's public IP address (typically provided by DNS). Imagine a NSA 4500 (SonicOS Enhanced) network in which the Primary LAN Subnet is 10.100.0.0 /24 and the Primary WAN IP is 3.3.2.1. Let's say you have a Web site for your customers, and its hostname is . You have already written the policies and rules needed so that outsiders can get to the web site, but it's really running on a private side server 10.100.0.2. Now imagine that you are a person using a laptop on the private side, with IP of 10.100.0.200. You want to reach the server using its public name, because you do the same thing when your laptop is with you on the road. If you sit on the private side, and request http://www.domain.com>, loopback is what makes it possible for that to work, even though the server is actually right next to you on a local IP address.

To allow this functionality you need to create a loop-back policy.

Resolution

The idea behind this policy is that you must translate your source into a public object if you wish to talk to the public IPs from the LAN.

Login to the SonicWall Management GUI.
Navigate to Network | NAT Policies submenu.
Click on the Add button.
Create the following NAT Policy.
Original Source: LAN Subnets (or Firewalled Subnets if you want hosts in other zones to be included)
Translated Source: WAN Interface IP
Original Destination: WAN Interface IP
Translated Destination: (LAN server object)
Original Service: Any
Translated Service: Original
Inbound Interface: Any
Outbound Interface: Any

Loopback Policy for One-to-One NAT

You can apply this in one-to-one NAT scenario as well when the public IP address is not the WAN interface IP.

Imagine that you now have a working setup with private side 10.100.0.3 (LAN server object) and public side 3.3.2.10 (WAN server object). You would need this custom NAT Policy:

Original Source: LAN Subnets
Translated Source: WAN Interface IP
Original Destination: (WAN server object)
Translated Destination: (LAN server object)
Original Service: Any
Translated Service: Original
Inbound Interface: Any
Outbound Interface: Any

This example can be modified to provide the same access for a server on the DMZ (or other zone) by using DMZ server object in place of the LAN server object.

How to Test this Scenario:

You can now verify whether the loopback NAT policy is functioning by testing from private side to the public ip address of server. It is recommended to use the public IP address of the server instead of DNS names. If using DNS names, make sure it is resolving to the Public IP address.

Resolution for SonicOS 6.5 and Later

SonicOS 6.5 was released September 2017. 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 and later firmware.