PANEL_addNatPolDlg

Creating NAT Policies

For general information on NAT Policies, see Network > NAT Policies .

NAT policies allow 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. This section contains the following subsections:

For this chapter, the examples 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:

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 WAN interface of the SonicWALL security appliance (by default, the X1 interface), such that the destination sees the request as coming from the IP address of the SonicWALL security appliance WAN interface, 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 X2 interface to initiate traffic using the SonicWALL security appliance’s WAN IP address, choose the following from the drop-down boxes:

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 allows the SonicWALL security appliance to utilize several addresses to perform the dynamic translation. Thus allowing a much higher number of concurrent 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 screen. 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 interface (by default, the X0 interface) to initiate traffic using the public range addresses, choose the following from the drop-down menus:

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 interface (by default, the 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 is 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 Web server to initiate traffic to the public Internet using its mapped public IP address, choose the following from the drop-down menus:

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 interface (by default, the X1 interface).

You can test the One-to-One mapping by opening up a Web browser 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 interface (by default, the 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 Web server via the Web server’s public IP address.

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 bring up the pop-up access policy screen. When the pop-up appears, enter in the following values:

When you are done, attempt to access the Web server’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.

Configuring One-to-Many NAT Load Balancing

One-to-Many NAT policies can be used to persistently load balance the translated destination using the original source IP address as the key to persistence. For example, SonicWALL security appliances can load balance multiple SonicWALL SSL VPN appliances, while still maintaining session persistence by always balancing clients to the correct destination SSL VPN. The following figure shows a sample topology and configuration.

To configure One-to-Many NAT load balancing, first go to the Firewall > Access Rules page and choose the policy for WAN to LAN . Click on the Add… button to bring up the pop-up access policy screen. When the pop-up appears, enter in the following values:

Next, create the following NAT policy by selecting Network > NAT Policies and clicking on the Add... button:

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 Web server on its public IP address, but via a different port (TCP 9000), instead of the standard HTTP 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 Web server on the new port (TCP 9000) instead of the server’s actual listening port (TCP 80).

Go to the Firewall > Access Rules section 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 bring up the previously created policy. When the pop-up appears, edit in the following values:

When you’re done, attempt to access the Web server’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 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 (by default, the X1 interface).

Below, you create the programming to provide public access to two internal Web servers 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 is possible to create more than these as long as the ports are all unique.

In this section, we have five tasks to complete:

And:

When finished, 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 interface (by default, the X1 interface).

And:

When finished, 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 interface (by default, the X1 interface).

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 bring up the pop-up window to create the policies. When the pop-up appears, enter the following values:

And:

When you’re finished, attempt to access the Web servers 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.

Using NAT Load Balancing

This section contains the following subsections:

NAT Load Balancing Topology

The following figure shows the topology for the NAT load balancing network.

Prerequisites

The examples shown in the Tasklist section on the next few pages utilize IP addressing information from a demo setup – please make sure and replace any IP addressing information shown in the examples with the correct addressing information for your setup. Also note that the interface names may be different.

To enable logging and alerting, log into the SonicWALL’s Management GUI, go to Log > Categories , choose Debug from the drop-down next to Logging Level , chose All Categories from the drop-down next to View Style , check the boxes in the title bar next to Log and Alerts to capture all categories, and click on the Apply button in the upper right hand corner to save and activate the changes. For an example, see the screenshot below. Debug logs should only be used for initial configuration and troubleshooting, and it is advised that once setup is complete, you set the logging level to a more appropriate level for your network environment.

To enable log name resolution, go to Log > Name Resolution , choose DNS then NetBIOS from the Name Resolution Menu drop-down list, and click on the Apply button in the upper right hand corner to save and activate the changes.

Configuring NAT Load Balancing

To configure NAT load balancing, you must complete the following tasks:

To complete this configuration, perform the following steps:

Troubleshooting NAT Load Balancing

If the Web servers do not seem to be accessible, go to the Firewall > Access Rules page and mouseover the Statistics icon.

If the rule is configured incorrectly you will not see any Rx or TX Bytes; if it is working, you will see these increment with each successful external access of the load balanced resources.You can also check the Firewall > NAT Policies page and mouseover the Statistics icon. If the policy is configured incorrectly you will not see any Rx or TX Bytes; if it is working, you will see these increment with each successful external access of the load balanced resources.

Finally, check the logs and the status page to see if there are any alerts (noted in yellow) about the Network Monitor noting hosts that are offline; it may be that all of your load balancing resources are not reachable by the SonicWALL appliance and that the probing mechanism has marked them offline and out of service. Check the load balancing resources to ensure that they are functional and check the networking connections between them and the SonicWALL appliance.