Access a server behind the SonicWall from internal networks using public IPs (Loopback NAT)
Description
This document describes how a host can access a server on the SonicWall LAN using the server's public IP address (or FQDN).
Imagine a network in which the primary LAN subnet is 10.100.0.0/24 and the primary WAN IP is 3.3.2.1 while the server's IP address is 192.168.0.254 in your DMZ zone.
If you use a laptop on the private side with IP of 10.100.0.200 you may be able to reach 192.168.0.254 (with proper access rules) directly but in many networks this is not accepted. By following this method, you can reach the server using its public IP or name. If you sit on the private side, and request http://www.domain.com, this loopback NAT is what makes it possible, even though the server is actually right next to you on a local IP address.
This is also known as NAT reflection or hairpin.
NOTE: You have already written the policies and rules needed so that outsiders (WAN) can get to the web site.
Resolution for SonicOS 7.X
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.
The idea behind these policies is to prevent access from the LAN to a server's internal IP address but allow access to the server's external IP address. So, a NAT loopback must be applied.
Loopback Policy using WAN Interface's IP Address
- Login to the SonicWall management GUI.
- Navigate to POLICY | Rules and Polices | NAT Rules page.
- Click Add.
- 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: Server's Private IP Object (i.e. 192.168.0.254).
- Original Service: Any (or a custom service).
- Translated Service: Original.
- Inbound Interface: Any.
- Outbound Interface: Any.
Loopback Policy using 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 (i.e. 3.3.2.10). You would need this custom NAT Policy.
- Original Source: LAN Subnets.
- Translated Source: WAN Interface IP.
- Original Destination: WAN Server's object (i.e. 3.3.2.10).
- Translated Destination: Server's private IP Object (i.e. 192.168.0.254).
- Original Service: Any (or custom).
- Translated Service: Original.
- Inbound Interface: Any.
- Outbound Interface: Any.
NOTE: 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.
Access Rule
Create a LAN to DMZ (or destination zone where the server's private IP is) access rule with the server's public IP address as destination.
- Login to the SonicWall management GUI.
- Navigate to POLICY | Rules and Policies | Access Rules page.
- Click Add.
- From: LAN.
- To: DMZ (or custom zone where the server is).
- Source Port: Any.
- Services: Any (or restrict to specific ports).
- Source: LAN Subnets (or custom subnets).
- Destination: Public IP of the server (i.e. WAN Interface IP or WAN custom 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.
CAUTION: 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
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.
The idea behind these policies is to prevent access from the LAN to a server's internal IP address but allow access to the server's external IP address. So, a NAT loopback must be applied.
Loopback Policy using WAN Interface's IP Address
- Login to the SonicWall management GUI.
- Navigate to Manage | Rules | NAT Policies submenu.
- Click Add.
- 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: Server's Private IP Object (i.e. 192.168.0.254).
- Original Service: Any (or a custom service).
- Translated Service: Original.
- Inbound Interface: Any.
- Outbound Interface: Any.
Loopback Policy using 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 (i.e. 3.3.2.10). You would need this custom NAT Policy.
- Original Source: LAN Subnets.
- Translated Source: WAN Interface IP.
- Original Destination: WAN Server's object (i.e. 3.3.2.10).
- Translated Destination: Server's private IP Object (i.e. 192.168.0.254).
- Original Service: Any (or custom).
- Translated Service: Original.
- Inbound Interface: Any.
- Outbound Interface: Any.
NOTE: 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.
Access Rule
Create a LAN to DMZ (or destination zone where the server's private IP is) access rule with the server's public IP address as destination.
- Login to the SonicWall management GUI.
- Navigate to Manage | Rules | Access Rules submenu.
- Click Add.
- From: LAN.
- To: DMZ (or custom zone where the server is).
- Source Port: Any.
- Services: Any (or restrict to specific ports).
- Source: LAN Subnets (or custom subnets).
- Destination: Public IP of the server (i.e. WAN Interface IP or WAN custom 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.
CAUTION: 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.