Access a server behind the SonicWall from internal networks using public IPs (Loopback NAT)

04/22/2021 603 People found this article helpful 88,138 Views

Download

Print

Share

• LinkedIn
• Twitter
• Facebook
• Email
• Copy URL The link has been copied to clipboard

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 NSa 2650 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

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

1. Login to the SonicWall management GUI.
2. Navigate to Manage | Rules | NAT Policies submenu.
3. Click  Add.
4. Create the following NAT policy.
5. Original Source: LAN Subnets (or Firewalled Subnets if you want hosts in other zones to be included).
6. Translated Source: WAN Interface IP.
7. Original Destination: WAN Interface IP.
8. Translated Destination: Server's Private IP Object (i.e. 192.168.0.254).
9. Original Service: Any (or a custom service).
10. Translated Service: Original.
11. Inbound Interface: Any.
12. 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.

Related Articles

• How can I configure a VPN between a SonicWall firewall and Microsoft Azure?
• Supported Public Cloud Servers/Instance Sizes on SonicWall NSv Series Models
• How to force an update of the Security Services Signatures from the Firewall GUI

Categories

• Firewalls > TZ Series > Networking
• Firewalls > SonicWall NSA Series > Networking
• Firewalls > SonicWall SuperMassive 9000 Series > Networking
• Firewalls > NSa Series > Networking
• Firewalls > NSv Series > Networking