How do I configure NAT policies on a SonicWall firewall?

10/14/2021 4,521 People found this article helpful 112,462 Views

Description

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

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 the Policy|Rules and Policies|NAT Rules page translating all outgoing requests into the IP address of the SonicWall’s 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 SonicWall’s 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 Rules and 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 server’s private IP address to a public IP address, and it’s 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 objects one 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
Zone Assignment: LAN
Type: Host
IP Address: 192.168.1.100

Address Object for Server's Public IP
Name: Webserver Public
Zone Assignment: WAN
Type: Host
IP Address: 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 SonicWall’s management GUI, Click Policies in the top navigation menu.
Navigate to the Rules and Policies| NAT Rules page.
Click the Add button and chose 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).

Login to the SonicWall Management Interface
Click Policy in the top navigation menu.
Navigate to Rules and Policies|NAT Rules
Click Add and 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 SonicWall’s WAN interface.

Below, we’ll provide public access to two internal Webservers via the SonicWall’s WAN IP address; each will be tied to a unique custom port. In the examples, we’ll only be setting up two, but it’s 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 SonicWall’s WAN IP address.
Create two access rule entries to allow any public user to connect to both servers via the SonicWall’s WAN IP address and the servers’ respective unique custom ports

Creating two custom ports:

Login to the SonicWall Management Interface
Click Object in the top navigation menu
Navigate to Match Objects| Services.
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:

Login to the SonicWall Management Interface.
Click Object in the top navigation menu.
Navigate to Match Objects | Addresses.
Click the Addbutton 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 SonicWall’s WAN IP address to the servers’ private addresses, create the following NAT Policies

Login to the SonicWall Management Interface.
Click Policy in the top navigation menu.
Navigate to Rules and Policies | NAT Rules
Click Add and create a NAT Policy following 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 server’s 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 policy in 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 you’re taking an internal “private” IP subnet and translating all outgoing requests into the IP address of the SonicWall’s WAN port, such that the destination sees the request as coming from the IP address of the SonicWall’s 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 SonicWall’s 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 SonicWall’s WAN primary IP address, follow these steps:

Login to the SonicWall Management Interface
Click Manage in the top navigation menu.
Navigate to Objects | 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: 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 server’s private IP address to a public IP address, and it’s 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 objects one 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
Zone Assignment: LAN
Type: Host
IP Address: 192.168.1.100

Address Object for Server's Public IP
Name: Wwebserver Public
Zone Assignment: WAN
Type: Host
IP Address: 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 SonicWall’s management GUI, Click Manage in the top navigation menu.
Navigate to the Rules | NAT Policies page.
Click the Add button and chose 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.

Example Outbound/Reflexive Policy

NOTE: If you need to create an access rule to allow the traffic through the firewall for an inbound NAT policy, refer to How 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
Click Manage in the top navigation menu.
Navigate to Rules | NAT Policies
Click Add and 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 SonicWall’s WAN interface.

Below, we’ll provide public access to two internal Webservers via the SonicWall’s WAN IP address; each will be tied to a unique custom port. In the examples, we’ll only be setting up two, but it’s 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 SonicWall’s WAN IP address
Create two access rule entries to allow any public user to connect to both servers via the SonicWall’s WAN IP address and the servers’ respective unique custom ports

Creating two custom ports:

Login to the SonicWall Management Interface
Click Manage in the top navigation menu
Navigate to Objects | Service Objects.
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:

Login to the SonicWall Management Interface
Click Manage in the top navigation menu.
Navigate to Objects | Address Objects.
Click the Add button 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 SonicWall’s WAN IP address to the servers’ private addresses, create the following NAT Policies

Login to the SonicWall Management Interface
Click Manage in the top navigation menu.
Navigate to Rules | NAT Policies
Click Add and create a NAT Policy following 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 server’s 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.

Not Finding Your Answers?

ASK THE COMMUNITY

Was This Article Helpful?

YES NO

Capture Cloud Platform

Federal

Partner Portal

Support Portal

Capture Cloud Platform

Federal

Partner Portal

Support Portal

How do I configure NAT policies on a SonicWall firewall?

Description

Resolution

Resolution for SonicOS 7.X

Resolution for SonicOS 6.5

Related Articles

Categories

Not Finding Your Answers?

Was This Article Helpful?

Article Helpful Form

Article Not Helpful Form

Stay In Touch