http://help.mysonicwall.com/sw/eng/305/ui2/23100/Network/Add_NAT_Policy.htm


HELP
TABLE OF CONTENTS
Network > NAT Policies > Add NAT Policy/Edit NAT Policy

The Add NAT Policy window allows you to configure your new NAT policies. The Edit NAT Policy window allows you to edit an existing NAT policy. This window includes the same settings in the Add NAT Policy window.

Alert! Before configuring NAT Policies, be sure to create all Address Objects associated with the policy. For instance, if you are creating a One-to-One NAT policy, be sure you have Address Objects for your public and private IP addresses.

Tip! By default, LAN to WAN has a predefined NAT policy on the SonicWALL.
NAT Policy Settings Explained

The following explains the settings used to create a NAT policy entry in the Add NAT Policy or Edit NAT Policy windows.

Click the Add button in the Network>NAT Policies page to display the Add NAT Policy window to create a new NAT policy or click the Edit icon in the Configure column for the NAT policy you want to edit to display the Edit NAT Policy window.

Original Source: This drop-down menu setting is used to identify the Source IP address(es) in the packet crossing the SonicWALL security appliance, whether it’s across interfaces, or into/out-of VPN tunnels. You can use the default Address Objects in SonicOS Enhanced, or you can create your own Address Objects. These entries can be single host entries, address ranges, or IP subnets.

Translated Source: This drop-down menu setting is what the SonicWALL security appliance translates the specified Original Source to as it exits the SonicWALL security appliance, whether it’s to another interface, or into/out-of VPN tunnels. You can use the default Address Objects in SonicOS Enhanced, or you can create your own Address Objects entries. These entries can be single host entries, address ranges, or IP subnets.

Original Destination: This drop-down menu setting is used to identify the Destination IP address(es) in the packet crossing the SonicWALL security appliance, whether it be across interfaces, or into/out-of VPN tunnels. When creating outbound NAT polices, this entry is usually set to Any since the destination of the packet is not being changed, but the source is being changed. However, these Address Object entries can be single host entries, address ranges, or IP subnets.

Translated Destination: This drop-down menu setting is what the SonicWALL translates the specified Original Destination to as it exits the SonicWALL security appliance, whether it’s to another interface, or into/out-of VPN tunnels. When creating outbound NAT polices, this entry is usually set to Original, since the destination of the packet is not being changed, but the source is being changed. However, these Address Objects entries can be single host entries, address ranges, or IP subnets.

Original Service: This drop-down menu setting is used to identify the IP service in the packet crossing the SonicWALL security appliance, whether it’s across interfaces, or into/out-of VPN tunnels. You can use the default services on the SonicWALL, or you can create your own entries. For many NAT policies, this field is set to Any, as the policy is only altering source or destination IP addresses.

Translated Service: This drop-down menu setting is what the SonicWALL security appliance translates the Original Service to as it exits the SonicWALL security appliance, whether it be to another interface, or into/out-of VPN tunnels. You can use the default services in the SonicWALL security appliance, or you can create your own entries. For many NAT Policies, this field is set to Original, as the policy is only altering source or destination IP addresses.

Inbound Interface: This drop-down menu setting is used to specify the entry interface of the packet. When dealing with VPNs, this is usually set to Any, since VPN tunnels aren’t really interfaces.

Outbound Interface: This drop-down is used to specify the exit interface of the packet once the NAT policy has been applied. This field is mainly used for specifying which WAN interface to apply the translation to. Of all fields in NAT policy, this one has the most potential for confusion. When dealing with VPNs, this is usually set to Any, since VPN tunnels aren’t really interfaces. Also, as noted in the Quick Q&A’ section of this chapter, when creating inbound 1-2-1 NAT Policies where the destination is being remapped from a public IP address to a private IP address, this field must be set to Any.

Comment: This field can be used to describe your NAT policy entry. The field has a 32-character limit, and once saved, can be viewed in the main Network>NAT Policies page by running the mouse over the text balloon next to the NAT policy entry. Your comment appears in a pop-up window as long as the mouse is over the text balloon.

Enable NAT Policy: By default, this box is checked, meaning the new NAT policy is activated the moment it is saved. To create a NAT policy entry but not activate it immediately, uncheck this box.

Create a reflective policy: When you check this box, a mirror outbound or inbound NAT policy for the NAT policy you defined in the Add NAT Policy window is automatically created.

Creating NAT Policies

NAT policies allows you the flexibility to control Network Address Translation based on matching combinations of Source IP address, Destination IP address, and Destination Services. Policy-based NAT allows you to deploy different types of NAT simultaneously.

The examples below use 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.10.0/24 IP subnet on interface X0
67.115.118.64/27 IP subnet on interface X1
192.168.30.0/24 IP subnet on interface X3
X0 LAN IP address is 192.168.10.1
X1 WAN IP address is 67.115.118.68
X3 ‘Sales’ IP address is 192.168.30.1
Webserver’s “private” address at 192.168.30.200
Webserver’s “public” address at 67.115.118.70
Public IP range addresses of 67.115.118.71 – 67.115.118.74

Creating a Many-to-One NAT Policy

Many-to-One is the most common NAT policy on a SonicWALL security appliance, 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 security appliance WAN port, such that the destination sees the request as coming from the IP address of the SonicWALL security appliance WAN port, and not from the internal private IP address.

This policy is easy to set up and activate. From the Management Interface, go to the Network>NAT Policies page and click on the Add button. The Add NAT Policy window is displayed for adding the policy. To create a NAT policy to allow all systems on the X3 interface to initiate traffic using the SonicWALL security appliance’s WAN IP address, choose the following from the drop-down boxes:

Original Source: X3 Subnet
Translated Source: WAN Primary IP
Original Destination: Any
Translated Destination: Original
Original Service: Any
Translated Service: Original
Inbound Interface: X3
Outbound Interface: X1
Comment: Enter a short description
Enable NAT Policy: Checked
Create a reflective policy: Unchecked

When done, click on the OK button to add and activate the NAT Policy. This policy can be duplicated for subnets behind the other interfaces of the SonicWALL security appliance – just replace the Original Source with the subnet behind that interface, adjust the source interface, and add another NAT policy.
Creating a Many-to-Many NAT Policy

The Many-to-Many NAT policy allows you to translate a group of addresses into a group of different addresses. This is useful in environments where there are an extremely high number of concurrent outgoing connections (128,000 +), as it allows the SonicWALL security appliance to utilize several addresses to perform the dynamic translation. This allows the SonicWALL security appliance to perform up to a half-million concurrent connections across the interfaces.

This policy is easy to set up and activate. You first need to go to the Network>Address Objects and click on the Add button at the bottom of the page. When the Add Address Object window appears, enter in a description for the range in the Name field, choose Range from the drop-down menu, enter the range of addresses (usually public IP addresses supplied by your ISP) in the Starting IP Address and Ending IP Address fields, and select WAN as the zone from the Zone Assignment menu. When done, click on the OK button to create the range object.

Select Network>NAT Policies and click on the Add button. The Add NAT Policy window is displayed. To create a NAT policy to allow the systems on the LAN (X0) interface to initiate traffic using the public range addresses, choose the following from the drop-down menus:

Original Source: LAN Primary Subnet
Translated Source: public_range
Original Destination: Any
Translated Destination: Original
Original Service: Any
Translated Service: Original
Inbound Interface: X0
Outbound Interface: X1
Comment: Enter a short description
Enable NAT Policy: Checked
Create a reflective policy: Unchecked

When done, click on the OK button to add and activate the NAT Policy. With this policy in place, the SonicWALL security appliance dynamically maps outgoing traffic using the four available IP addresses in the range we created.

You can test the dynamic mapping by installing several systems on the LAN (X0) interface at a spread-out range of addresses (for example, 192.168.10.10, 192.168.10.100, and 192.168.10.200) and accessing the public website http://www.whatismyip.com from each system. Each system should display a different IP address from the range we created and attached to the NAT policy.
Creating a One-to-One NAT Policy for Outbound Traffic

One-to-One NAT for outbound traffic is another common NAT policy on a SonicWALL security appliance for translating an internal IP address into a unique IP address. This is useful when you need 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 one-to-one NAT policy for outbound traffic is used to map a server’s private IP address to a public IP address, and it’s paired with a reflective (mirror) policy that allows any system from the public Internet to access the server, along with a matching firewall access rule that permits this. Reflective NAT policies are covered in the next section.

This policy is easy to set up and activate. Select Network>Address Objects and click on the Add button at the bottom of the screen. In the Add Address Object window, enter a description for server’s private IP address in the Name field. Choose Host from the Type menu, enter the server’s private IP address in the IP Address field, and select the zone that the server assigned from the Zone Assignment menu. Click OK. Then, create another object in the Add Address Object window for the server’s public IP address and with the correct values, and select WAN from Zone Assignment menu. When done, click on the OK button to create the range object.

Next, select Network>NAT Policies and click on the Add button to display the Add NAT Policy window. To create a NAT policy to allow the webserver to initiate traffic to the public Internet using its mapped public IP address, choose the following from the drop-down menus:

Original Source: webserver_private_ip
Translated Source: webserver_public_ip
Original Destination: Any
Translated Destination: Original
Original Service: Any
Translated Service: Original
Inbound Interface: X3
Outbound Interface: X1
Comment: Enter a short description
Enable NAT Policy: Checked
Create a reflective policy: Checked

When done, click on the OK button to add and activate the NAT Policy. With this policy in place, the SonicWALL security appliance translates the server’s private IP address to the public IP address when it initiates traffic out the WAN (X1) interface.

You can test the one-to-one mapping by opening up a web powser on the server and accessing the public website http://www.whatismyip.com. The website should display the public IP address we attached to the private IP address in the NAT policy we just created.
Creating a One-to-One NAT Policy for Inbound Traffic (Reflective)

This is the mirror policy for the one created in the previous section when you check Create a reflective policy. It allows you to translate an external public IP addresses into an internal private IP address. This NAT policy, when paired with a ‘permit’ access policy, allows any source to connect to the internal server using the public IP address; the SonicWALL security appliance handles the translation between the private and public address. With this policy in place, the SonicWALL security appliance translates the server’s public IP address to the private IP address when connection requests arrive via the WAN (X1) interface.

Below, you create the entry as well as the rule to allow HTTP access to the server. You need to create the access policy that allows anyone to make HTTP connections to the webserver via the webserver’s public IP address.

Note! With previous versions of firmware, it was necessary to write rules to the private IP address. This has been changed as of SonicOS Enhanced. If you write a rule to the private IP address, the rule does not work.

Go to the Firewall>Access Rules page and choose the policy for the ‘WAN’ to ‘Sales’ zone intersection (or, whatever zone you put your server in). Click on the Add button to ping up the pop-up access policy screen. When the pop-up appears, enter in the following values:

Action: Allow
Service: HTTP
Source: Any
Destination: webserver_public_ip
Users Allowed: All
Schedule: Always on
Logging: checked
Comment: (enter a short description)

When you are done, attempt to access the webserver’s public IP address using a system located on the public Internet. You should be able to successfully connect. If not, review this section, and the section before, and ensure that you have entered in all required settings correctly.
Inbound Port Address Translation via One-to-One NAT Policy

This type of NAT policy is useful when you want to conceal an internal server’s real listening port, but provide public access to the server on a different port. In the example below, you modify the NAT policy and rule created in the previous section to allow public users to connect to the private webserver on its public IP address, but via a different port (TCP 9000), instead of the standard HTTP port (TCP 80).

First, your need to create a custom service for the different port. Go to the Firewall>Custom Services page and select the Add button. When the pop-up screen appears, give your custom service a name such as “webserver_public_port”, enter in “9000” as the starting and ending port, and choose “TCP(6)” as the protocol. When done, click on the OK button to save the custom service.

Next, you modify the NAT policy created in the previous section that allowed any public user to connect to the webserver on its public IP address. Go to the Network>NAT Policies page and click on the Edit button next to this NAT policy. The Edit NAT Policy window is displayed for editing the policy. Edit the NAT policy so that it includes the following from the drop-down menus:

Original Source: Any
Translated Source: Original
Original Destination: webserver_public_ip
Translated Destination: webserver_private_ip
Original Service: webserver_public_port (or whatever you named it above)
Translated Service: HTTP
Inbound Interface: X1
Outbound Interface: Any
Comment: Enter a short description
Enable NAT Policy: Checked
Create a reflective policy: Unchecked

Make sure you chose Any as the destination interface, and not the interface that the server is on. This may seem counter-intuitive, but it’s actually the correct thing to do (if you try to specify the interface, you get an error).

When done, click on the OK button to add and activate the NAT Policy. With this policy in place, the SonicWALL security appliance translates the server’s public IP address to the private IP address when connection requests arrive from the WAN (X1) interface, and translates the requested protocol (TCP 9000) to the server’s actual listening port (TCP 80).

Finally, you’re going to modify the firewall access rule created in the previous section to allow any public user to connect to the webserver on the new port (TCP 9000) instead of the server’s actual listening port (TCP 80).

Note! With previous versions of firmware, it was necessary to write rules to the private IP address. This has been changed as of SonicOS Enhanced. If you write a rule to the private IP address, the rule does not work.

Go to the Firewall>Access Rules page and choose the policy for the WAN to Sales zone intersection (or, whatever zone you put your server in). Click on the Configure button to ping up the previously created policy. When the pop-up appears, edit in the following values:

Action: Allow
Service: webserver_public_port (or whatever you named it above)
Source: Any
Destination: webserver_public_ip
Users Allowed: All
Schedule: Always on
Logging: checked
Comment: (enter a short description)

When you’re done, attempt to access the webserver’s public IP address using a system located on the public Internet on the new custom port (example: http://67.115.118.70:9000). You should be able to successfully connect. If not, review this section, and the section before, and ensure that you have entered in all required settings correctly.
Inbound Port Address Translation via WAN (X1) IP Address

This is one of the more complex NAT policies you can create on a SonicWALL security appliance running SonicOS Enhanced – it allows you to use the WAN IP address of the SonicWALL security appliance 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 has to be used by the SonicWALL security appliance’s WAN interface.

Below, you create the programming to provide public access to two internal webservers via the SonicWALL security appliances WAN IP address; each is tied to a unique custom port. In the following examples, you set up two, but it’s possible to create more than these 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 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.

First, you need to create a custom service for the different port. Go to the Firewall>Custom Services page and click on the Add button. When the pop-up screen appears, give your custom services names such as “servone_public_port” and “servtwo_public_port”, enter in “9100” and “9200” as the starting and ending port, and choose “TCP(6)” as the protocol. When done, click on the OK button to save the custom services.

Second, to go to the Network>Address Objects and click on the Add button at the bottom of the page. In the Add Address Objects window, enter in a description for server’s private IP addresses, choose ‘Host’ from the drop-down box, enter the server’s private IP addresses, and select the zone that the servers are in. When done, click on the ‘OK’ button to create the range object.

Third, from the SonicWALL’s management GUI, go to the Network>NAT Policies menu and click on the Add button. The Add NAT Policy window is displayed. To create a NAT policy to allow the two servers to initiate traffic to the public Internet using the SonicWALL security appliance’s WAN IP address, choose the following from the drop-down boxes:

Original Source: servone_private_ip
Translated Source: WAN Primary IP
Original Destination: Any
Translated Destination: Original
Original Service: Any
Translated Service: Original
Inbound Interface: X3
Outbound Interface: X1
Comment: Enter a short description
Enable NAT Policy: Checked
Create a reflective policy: Unchecked

And:

Original Source: servtwo_private_ip
Translated Source: WAN Primary IP
Original Destination: Any
Translated Destination: Original
Original Service: Any
Translated Service: Original
Inbound Interface: X3
Outbound Interface: X1
Comment: Enter a short description
Enable NAT Policy: Checked
Create a reflective policy: Unchecked

When done, click on the OK button to add and activate the NAT policies. With these policies in place, the SonicWALL security appliance translates the servers’ private IP addresses to the public IP address when it initiates traffic out the WAN (X1) interface.

Fourth, go to the Network>NAT Policies menu and click on the Add button. The Add NAT Policy window is displayed. 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, choose the following from the drop-down boxes:

Original Source: Any
Translated Source: Original
Original Destination: WAN Primary IP
Translated Destination: servone_private_ip
Original Service: servone_public_port
Translated Service: HTTP
Inbound Interface: X1
Outbound Interface: Any
Comment: Enter a short description
Enable NAT Policy: Checked
Create a reflective policy: Unchecked

And:

Original Source: Any
Translated Source: Original
Original Destination: WAN Primary IP
Translated Destination: servtwo_private_ip
Original Service: servtwo_public_port
Translated Service: HTTP
Source Interface: X1
Destination Interface: Any
Comment: Enter a short description
Enable NAT Policy: Checked
Create a reflective policy: Unchecked

Note! Make sure you choose Any as the destination interface, and not the interface that the server is on. This may seem counter-intuitive, but it’s actually the correct thing to do (if you try to specify the interface, you get an error).

When done, click on the OK button to add and activate the NAT policies. With these policies in place, the SonicWALL security appliance translates the server’s public IP address to the private IP address when connection requests arrive from the WAN (X1) interface.

Fifth, you need to create the access rules that allows anyone from the public Internet to access the two webservers using the custom ports and the SonicWALL security appliance’s WAN IP address.

Note! With previous versions of firmware, it was necessary to write rules to the private IP address. This has been changed as of SonicOS Enhanced. If you write a rule to the private IP address, the rule does not work.

Go to the Firewall>Access Rules page and choose the policy for the ‘WAN’ to ‘Sales’ zone intersection (or, whatever zone you put your serves in). Click on the Add button to ping up the pop-up window to create the policies. When the pop-up appears, enter the following values:

Action: Allow
Service: servone_public_port (or whatever you named it above)
Source: Any
Destination: X1 IP Address
Users Allowed: All
Schedule: Always on
Logging: checked
Comment: (enter a short description)

And:

Action: Allow
Service: servtwo_public_port (or whatever you named it above)
Source: Any
Destination: X1 IP Address
Users Allowed: All
Schedule: Always on
Logging: checked
Comment: (enter a short description)

When you’re done, attempt to access the webservers via the SonicWALL’s WAN IP address using a system located on the public Internet on the new custom port (example: http://67.115.118.70:9100 and http://67.115.118.70:9200 ). You should be able to successfully connect. If not, review this section, and the section before, and ensure that you have entered in all required settings correctly.

Help Table of Contents

http://help.mysonicwall.com/sw/eng/305/ui2/23100/Network/Add_NAT_Policy.htm