How do I configure NAT policies on a SonicWall firewall?

The Network Address Translation (NAT) engine in SonicOS Enhanced allows users to define granular NAT polices for their incoming and outgoing traffic. This article illustrates the different types of NAT policies which can be configured in the SonicWall for various purpose.

For the purpose of this article, we’ll be using the following IP addresses as examples to demonstrate the NAT policy creation and activation. You can use these examples to create NAT policies for your network, substituting your IP addresses for the examples shown here:

• 192.168.1.0/24 IP subnet on interface X0
• 1.1.1.0/24 IP subnet on interface X1
• 192.168.30.0/24 IP subnet on interface X3
• X0 LAN IP address is 192.168.1.1
• X1 WAN IP address is 1.1.1.1
• X3 IP address is 192.168.30.1
• Webserver’s “private” address at 192.168.1.100
• Webserver’s “public” address at 1.1.1.1

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.

Many to One NAT

This is the most common NAT policy which allows you to translate a group of addresses into a single address.This generally means that you are translating a Internal IP(Private Subnet) outgoing request into the IP address of the SonicWall WAN port. In this case, the destination sees the request coming from the IP address of the SonicWall WAN interface and not from the internal IP address.

SonicWall has a default outgoing NAT policy preconfigure for each interface configured under thePolicy|Rules and Policies|NAT Rulespage translating all outgoing requests into the IP address of the SonicWalls primary WAN interface.

To view the default NAT policies preconfigure in the SonicWall, Navigate to Policies|Rules and Policies|NAT Rules.You can add the NAT policies under the same section.

EXAMPLE: The following image is the configuration menu for such a default NAT policy to translate outbound traffic to the IP of the SonicWall's X1 Interface.We can also look the network address translation into the diagram format by enabling show diagram.

However, in certain scenarios it may be necessary to translate a particular subnet to an IP Address other than the WAN Primary IP. Such a NAT policy is simple to create and activate. To create a NAT policy to allow all systems on the X1 interface to initiate traffic using a public IP address other than SonicWalls WAN primary IP address, follow these steps:

• Login to the SonicWall Management Interface.
• Click Object in the top navigation menu.
• Navigate to Match objects|Addresses, Click the Add button to

  add a new address object for the alternate WAN IP you wish to translate to.

   

  
  EXAMPLE:Refer to the screenshot below for an example where a Host object was created and 1.1.1.2 is the example IP is what objects would be NAT translated to

• Navigate to Policy|Rules and Policies page, Click on NAT Rulesand Add to create new NAT policy.
  

  EXAMPLE:Example NAT policy created below for reference following the examples above

  • Original Source:X3 Subnet
  • Translated Source:X3 Public IP
  • Original Destination:Any
  • Translated Destination:Original
  • Original Service:Any
  • Translated Service:Original
  • Source Interface:X3
  • Destination Interface:X1
  • Enable NAT Policy:Enabled
  • Comment:(enter a short description)
    
    
    
  
  

One to One NAT

This is another common NAT policy on a SonicWall and allows you to translate an internal IP address into a unique IP address. This is useful when you want specific systems, such as servers, to use a specific IP address when they initiate traffic to other destinations. Most of the time, a NAT policy such as this is used to map a servers private IP address to a public IP address, and its paired with a mirror policy that allows any system from the public Internet to access the server, along with a matching firewall access rule that permits this.

In this example we have chosen to demonstrate a webserver using HTTP service, however the following steps apply to any service you wish to use (like HTTPS, SMTP, FTP, Terminal Services, SSH, etc).

Creating the necessary Address Objects

• Click Object in the top navigation menu.
• Navigate to Match objects|Addresses.
• Click the Add button and create two address objectsone for Private IP of the device in question and one for the public IP.

• Click the OK button to complete creation of the new address objects.
  

  EXAMPLE: Example provided below for a webserver

Address Object for Server on LAN

Name: Webserver Private
ZoneAssignment:LAN
Type:Host
IPAddress:192.168.1.100

Address Object for Server's Public IP
Name: Webserver Public
ZoneAssignment:WAN
Type:Host
IPAddress:1.1.1.1

Creating an Inbound NAT Policy

This policy allows you to translate an external public IP address into an internal private IP address. This NAT policy, when paired with an allow access rule, allows any source to connect to the internal server using the public IP address. The SonicWall will handle the translation between the private and public address. Below, we will be creating the NAT Policy as well as the rule to allow HTTP access to the server.

• From the SonicWalls management GUI, Click Policies in the top navigation menu.
• Navigate to the Rules and Policies|NAT Rules page.
• Click the Add button andchose the following settings from the drop-down menu
  
  
  

We can also look the NAT policies created in the structural format by enabling the Show Diagram option:

The users can also enable the Dock Diagram option in the NAT Policies:

Inbound NAT Policy

• Original Source:Any
• Translated Source:Original
• Original Destination:Webserver Public
• Translated Destination:Webserver Private
• Original Service:HTTP
• Translated Service:Original
• Inbound Interface:Any
• Outbound Interface:Any
• Enable NAT Policy:Checked
• Create a reflexive policy: When you check this box, a mirror (outbound or inbound) NAT policy is automatically created as per the settings configured in the Add NAT Policy window. In the example NAT Policy, when the box Create a reflexive policy is checked, it will create an outbound NAT Policy as per the screenshot below.
  

Example Outbound/Reflexive Policy:

DNS Loopback NAT Policy

The purpose of a DNS Loopback NAT Policy is for a host on the LAN or DMZ to be able to access the webserver on the LAN (192.168.1.100) using the server's public IP address (1.1.1.1) or by its fully qualified domain name (FQDN).

1. Login to the SonicWall Management Interface
2. Click Policyin the top navigation menu.
3. Navigate toRules and Policies|NAT Rules
4. Click Addand create a NAT Policy following the below example from the drop-down menus

   EXAMPLE:In the example below Firewalled Subnets is used as the original source, but this may need adjusted to include all subnets behind the SonicWall if you are routing additional subnets through a layer 3 device behind the SonicWall. Traffic is translated to the Webservers public IP (but this can be any public address) to be able to communicate and translate back through the SonicWall appliance. This process can be bypassed by creating a local DNS entry to translate your webserver to it's private IP instead.

• Original Source: Firewalled Subnets
• Translated Source: Wwebserver Public
• Original Destination: Wwebserver Public
• Translated Destination: Wwebserver Private
• Original Service: HTTP
• Translated Service: Original
• Inbound Interface: Any
• Outbound Interface: Any
• Enable NAT Policy: Checked
  

Inbound Port Address Translation via WAN (X1) IP Address:

This is one of the more complex NAT policies you can create on a SonicWall UTM Appliance with SonicOS Enhanced firmware. It allows you to use the WAN IP address of the SonicWall device to provide access to multiple internal servers. This is most useful in situations where your ISP has only provided a single public IP address, and that IP address had to be used by the SonicWalls WAN interface.

Below, well provide public access to two internal Webservers via the SonicWalls WAN IP address; each will be tied to a unique custom port. In the examples, well only be setting up two, but its possible to create more than this as long as the ports are all unique.

In this section, we have five tasks to complete:

• Create two custom service objects for the unique public ports the servers will respond on
• Create two address objects for the servers private IP addresses
• Create two NAT entries to allow the two servers to initiate traffic to the public Internet
• Create two NAT entries to map the custom ports to the actual listening ports, and to map the private IP addresses to the SonicWalls WAN IP address.
• Create two access rule entries to allow any public user to connect to both servers via the SonicWalls WAN IP address and the servers respective unique custom ports

Creating two custom ports:

1. Login to the SonicWall Management Interface
2. Click Object in the top navigation menu
3. Navigate to Match Objects| Services.
4. Click the Add button and create the ports to be used by the servers.
   
   EXAMPLE: In the example below, Webserver 1 will be using port 4433 for 443 services and Webserver 2 will be using 4434 for 443 services.
   
   
   
   
   

Creating two address objects:

1. Login to the SonicWall Management Interface.
2. Click Object in the top navigation menu.
3. Navigate to Match Objects|Addresses.
4. Click theAddbutton and create the private and public IP addresses to be used by the servers.
   
   EXAMPLE: For the purposes of our example, the private webserver IPs will be setup to be 192.168.1.100 and 192.168.1.101
   
   
   

Creating inbound NAT Policies:

To create the NAT policies to map the custom ports to the servers real listening ports and to map the SonicWalls WAN IP address to the servers private addresses, create the following NAT Policies

1. Login to the SonicWall Management Interface.
2. Click Policy in the top navigation menu.
3. Navigate toRules and Policies | NAT Rules
4. ClickAddandcreate a NAT Policyfollowing the below examples from the drop-down menus
   
   EXAMPLE:Below are the two example NAT policies created using the same information from the Service and Address objects created above. Both private IPs are translated from the same public IP but are based on different source ports.With these policies in place, the SonicWall will translate the servers public IP address to the private IP address when connection requests arrive from the WAN interface bound for the IP of the Webserver Public address. To access the web server 192.168.1.100, users on the Internet have to enter https://1.1.1.1:4433 in their web browser.
   
   
   
   Likewise, to access the web server 192.168.1.101, enter https://1.1.1.1:4434.
   
   
   
   

NOTE: Outbound NAT policies will need to be created if traffic is to be generated from the servers separately and to be translated to the same public IP.

We can also enable Create a Reflexive policyin the NAT Policies in Advanced/Actions section. Source port Remap can also be enabled and disabled under the same section.

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.

Many to One NAT

This is the most common NAT policy on a SonicWall, and allows you to translate a group of addresses into a single address. Most of the time, this means that youre taking an internal “private” IP subnet and translating all outgoing requests into the IP address of the SonicWalls WAN port, such that the destination sees the request as coming from the IP address of the SonicWalls WAN port, and not from the internal private IP address.

SonicWall has a default outgoing NAT policy preconfigure for each interface configured under the Manage | Network | Interfaces page translating all outgoing requests into the IP address of the SonicWalls primary WAN port (WAN Primary IP). To view the default NAT policies preconfigure in the SonicWall click Manage | Rules|NAT Policies.

EXAMPLE:The following image is the configuration menu for such a default NAT policy to translate outbound traffic to the IP of the SonicWall's X1 Interface.

However, in certain scenarios it may be necessary to translate a particular subnet to an IP Address other than the WAN Primary IP. Such a NAT policy is simple to create and activate. To create a NAT policy to allow all systems on the X1 interface to initiate traffic using a public IP address other than SonicWalls WAN primary IP address, follow these steps:

• Login to the SonicWall Management Interface
• Click Manage in the top navigation menu.
• Navigate toObjects|Address Objects.
• Click the Add button to add a new address object for the alternate WAN IP you wish to translate to.

  EXAMPLE:Refer to the screenshot below for an example where a Host object was created and 1.1.1.2 is the example IP is what objects would be NAT translated to
  

• Navigate to the Rules|NAT Policies page.
• Click on Add to create a new NAT policy.
  

  EXAMPLE: ExampleNAT policy created below for reference following the examples above

  • Original Source: X3 Subnet
  • Translated Source: X3 Public IP
  • Original Destination: Any
  • Translated Destination: Original
  • Original Service: Any
  • Translated Service: Original
  • Source Interface: X3
  • Destination Interface: X1
  • Enable NAT Policy: Enabled
  • Comment: (enter a short description)

  

One to One NAT

This is another common NAT policy on a SonicWall, and allows you to translate an internal IP address into a unique IP address. This is useful when you want specific systems, such as servers, to use a specific IP address when they initiate traffic to other destinations. Most of the time, a NAT policy such as this is used to map a servers private IP address to a public IP address, and its paired with a mirror policy that allows any system from the public Internet to access the server, along with a matching firewall access rule that permits this.

In this example we have chosen to demonstrate a webserver using HTTP service, however the following steps apply to any service you wish to use (like HTTPS, SMTP, FTP, Terminal Services, SSH, etc).

Creating the necessary Address Objects

• Click Manage in the top navigation menu.
• Navigate to Objects |Address Objects.
• Click the Add button and create two address objectsone for Private IP of the device in question and one for the public IP.

• Click the OK button to complete creation of the new address objects.
  

  EXAMPLE: Example provided below for a webserver

Address Object for Server on LAN

Name:Wwebserver Private
ZoneAssignment:LAN
Type:Host
IPAddress:192.168.1.100

Address Object for Server's Public IP
Name:Wwebserver Public
ZoneAssignment:WAN
Type:Host
IPAddress:1.1.1.1

Creating an Inbound NAT Policy

This policy allows you to translate an external public IP address into an internal private IP address. This NAT policy, when paired with an allow access rule, allows any source to connect to the internal server using the public IP address. The SonicWall will handle the translation between the private and public address. Below, we will be creating the NAT Policy as well as the rule to allow HTTP access to the server.

• From the SonicWalls management GUI, Click Manage in the top navigation menu.
• Navigate to theRules |NAT Policies page.
• Click the Add button andchose the following settings from the drop-down menu:

Inbound NAT Policy Original Source: Any Translated Source: Original Original Destination: Webserver Public Translated Destination: Webserver Private Original Service: HTTP Translated Service: Original Inbound Interface: Any Outbound Interface: Any Enable NAT Policy: Checked Create a reflexive policy:When you check this box, a mirror (outbound or inbound) NAT policy is automatically created as per the settings configured in the Add NAT Policy window. In the example NAT Policy, when the box Create a reflexive policy is checked, it will create an outbound NAT Policy as per the screenshot below.

NOTE:If you need to create an access rule to allow the traffic through the firewall for an inbound NAT policy, refer toHow to Enable Port Forwarding and Allow Access to a Server Through the SonicWall

DNS Loopback NAT Policy

The purpose of a DNS Loopback NAT Policy is for a host on the LAN or DMZ to be able to access the webserver on the LAN (192.168.1.100) using the server's public IP address (1.1.1.1) or by its fully qualified domain name (FQDN).

• Login to the SonicWall Management Interface
• ClickManagein the top navigation menu.
• Navigate to Rules | NAT Policies
• Click Addand create a NAT Policy following the below example from the drop-down menus

  EXAMPLE:In the example below Firewalled Subnets is used as the original source, but this may need adjusted to include all subnets behind the SonicWall if you are routing additional subnets through a layer 3 device behind the SonicWall. Traffic is translated to the Webservers public IP (but this can be any public address) to be able to communicate and translate back through the SonicWall appliance. This process can be bypassed by creating a local DNS entry to translate your webserver to it's private IP instead.

• Original Source:Firewalled Subnets
• Translated Source: Mywebserver Public
• Original Destination: Mywebserver Public
• Translated Destination: Mywebserver Private
• Original Service: HTTP
• Translated Service: Original
• Inbound Interface: Any
• Outbound Interface: Any
• Enable NAT Policy: Checked
• Create a reflexive policy:unchecked

Inbound Port Address Translation via WAN (X1) IP Address

This is one of the more complex NAT policies you can create on a SonicWall UTM Appliance with SonicOS Enhanced firmware. It allows you to use the WAN IP address of the SonicWall device to provide access to multiple internal servers. This is most useful in situations where your ISP has only provided a single public IP address, and that IP address had to be used by the SonicWalls WAN interface.

Below, well provide public access to two internal Webservers via the SonicWalls WAN IP address; each will be tied to a unique custom port. In the examples, well only be setting up two, but its possible to create more than this as long as the ports are all unique.

In this section, we have five tasks to complete:

• Create two custom service objects for the unique public ports the servers will respond on
• Create two address objects for the servers private IP addresses
• Create two NAT entries to allow the two servers to initiate traffic to the public Internet
• Create two NAT entries to map the custom ports to the actual listening ports, and to map the private IP addresses to the SonicWalls WAN IP address
• Create two access rule entries to allow any public user to connect to both servers via the SonicWalls WAN IP address and the servers respective unique custom ports

Creating two custom ports:

• Login to the SonicWall Management Interface
• ClickManagein the top navigation menu
• Navigate toObjects|ServiceObjects.
• Click theAddbutton and create the ports to be used by the servers.

  EXAMPLE:In the example below, Webserver 1 will be using port 4433 for 443 services and Webserver 2 will be using 4434 for 443 services

Creating two address objects:

• Login to the SonicWall Management Interface
• ClickManagein the top navigation menu.
• Navigate toObjects|Address Objects.
• Click theAddbutton and create the private and public IP addresses to be used by the servers.

  EXAMPLE:For the purposes of our example, the private webserver IPs will be setup to be 192.168.1.100 and 192.168.1.101

Creating inbound NAT Policies:

To create the NAT policies to map the custom ports to the servers real listening ports and to map the SonicWalls WAN IP address to the servers private addresses, create the following NAT Policies

• Login to the SonicWall Management Interface
• ClickManagein the top navigation menu.
• Navigate toRules | NAT Policies
• ClickAddandcreate a NAT Policyfollowing the below examples from the drop-down menus

  EXAMPLE:Below are the two example NAT policies created using the same information from the Service and Address objects created above. Both private IPs are translated from the same public IP but are based on different source ports.With these policies in place, the SonicWall will translate the servers public IP address to the private IP address when connection requests arrive from the WAN interface bound for the IP of the Webserver Public address. To access the web server 192.168.1.100, users on the Internet have to enter https://1.1.1.1:4433 in their web browser. Likewise, to access the web server 192.168.1.101, enter https://1.1.1.1:4434.

  NOTE:Outbound NAT policies will need to be created if traffic is to be generated from the servers separately and to be translated to the same public IP.