Blog

Quite often I come across an configuration issue where a client has exposed an internal service (for example Outlook Web Access) through their SonicWall firewall using a NAT rule. To make things easy to access they then associate their external WAN IP address with a DNS A Record via their hosting provider, such as webmail.company.com.  The problem arises if the user then tries to access the same URL from behind the firewall.

The solution is commonly known as a DNS NAT Loopback and is discussed in the SonicWALL Technical Note:  SonicOS Enhanced 2.0: Configuring DNS NAT Loopback.

Loopback is supported without any special configurations in both firmware 6.x.x.x and SonicOS 2.0 Standard.

In SonicOS 2.0 Enhanced, you need a custom NAT policy like this:

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

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. You can apply this to 1:1 NAT, as well. 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 Primary IP
Original Destination: (WAN server object)
Translated Destination: (LAN server object)
Original Service: Any
Translated Service: Original
Inbound Interface: LAN Interface
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.