PANEL_addNatPolDlg
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:
• Creating a Many-to-One NAT Policy
• Creating a Many-to-Many NAT Policy
• Creating a One-to-One NAT Policy for Outbound Traffic
• Creating a One-to-One NAT Policy for Inbound Traffic (Reflective)
• Configuring One-to-Many NAT Load Balancing
• Inbound Port Address Translation via One-to-One NAT Policy
• Inbound Port Address Translation via WAN IP Address
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:
• 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 X2
• X0 IP address is 192.168.10.1
• X1 IP address is 67.115.118.68
• X2 ‘Sales’ IP address is 192.168.30.1
• Web server’s “private” address at 192.168.30.200
• Web server’s “public” address at 67.115.118.70
• Public IP range addresses of 67.115.118.71 – 67.115.118.74
Many-to-One is the most common NAT policy on a SonicWALL SuperMassive, 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 SuperMassive (by default, the X1 interface), such that the destination sees the request as coming from the IP address of the SonicWALL SuperMassive 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 SuperMassive’s WAN IP address, choose the following from the drop-down boxes:
• Original Source: X2 Subnet
• Translated Source: WAN Primary IP
• Original Destination: Any
• Translated Destination: Original
• Original Service: Any
• Translated Service: Original
• Inbound Interface: X2
• 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 SuperMassive – just replace the Original Source with the subnet behind that interface, adjust the source interface, and add another 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 SuperMassive to utilize several addresses to perform the dynamic translation.
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:
• 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 SuperMassive 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.
One-to-One NAT for outbound traffic is another common NAT policy on a SonicWALL SuperMassive 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:
• Original Source: webserver_private_ip
• Translated Source: webserver_public_ip
• Original Destination: Any
• Translated Destination: Original
• Original Service: Any
• Translated Service: Original
• Inbound Interface: X2
• 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 SuperMassive 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.
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 SuperMassive handles the translation between the private and public address. With this policy in place, the SonicWALL SuperMassive 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.
Note With previous versions of firmware, it was necessary to write rules to the private IP address. This has been changed as of SonicOS. 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 bring 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 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.
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 SuperMassives can load balance multiple SonicWALL SRA appliances, while still maintaining session persistence by always balancing clients to the correct destination SRA.
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:
• Action: Allow
• Service: HTTPS
• Source: Any
• Destination: WAN Primary IP
• Users Allowed: All
• Schedule: Always on
• Comment: Descriptive text, such as SSLVPN LB
• Logging: Checked
• Allow Fragmented Packets: Unchecked
Next, create the following NAT policy by selecting Network > NAT Policies and clicking on the Add... button:
• Original Source: Any
• Translated Source: Original
• Original Destination: WAN Primary IP
• Translated Destination: Select Create new address object... to bring up the Add Address Object screen.
– Name: A descriptive name, such as mySSLVPN
– Zone assignment: LAN
– Type: Host
– IP Address: The IP addresses for the devices to be load balanced (in the topology shown above, this is 192.168.200.10, 192.168.200.20, and 192.168.200.30.)
• Original Service: HTTPS
• Translated Service: HTTPS
• Inbound Interface: Any
• Outbound Interface: Any
• Comment: Descriptive text, such as SSLVPN LB
• Enable NAT Policy: Checked
• Create a reflective policy: Unchecked
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).
Step 1 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.
Step 2 Modify the NAT policy created in the previous section that allowed any public user to connect to the Web server on its public IP address. Go to the Network > NAT Policies menu 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
Note 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 is actually the correct thing to do (if you try to specify the interface, you get an error).
Step 3 When finished, click on the OK button to add and activate the NAT Policy. With this policy in place, the SonicWALL SuperMassive 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), 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 Web server on the new port (TCP 9000) instead of the server’s actual listening port (TCP 80).
Navigate 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:
• Action: Allow
• Service: server_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 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.
This is one of the more complex NAT policies you can create on a SonicWALL SuperMassive running SonicOS – it allows you to use the WAN IP address of the SonicWALL SuperMassive 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 SuperMassive’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 SuperMassives 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:
1. Create two custom service objects for the unique public ports the servers respond on.
2. Create two address objects for the servers’ private IP addresses.
3. Create two NAT entries to allow the two servers to initiate traffic to the public Internet.
4. 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.
5. 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.
Step 1 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.
Step 2 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.
Step 3 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 SuperMassive’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: X2
• 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: X2
• Outbound Interface: X1
• Comment: Enter a short description
• Enable NAT Policy: Checked
• Create a reflective policy: Unchecked
When finished, click on the OK button to add and activate the NAT policies. With these policies in place, the SonicWALL SuperMassive translates the servers’ private IP addresses to the public IP address when it initiates traffic out the WAN interface (by default, the X1 interface).
Step 4 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 is actually the correct thing to do (if you try to specify the interface, you get an error).
When finished, click on the OK button to add and activate the NAT policies. With these policies in place, the SonicWALL SuperMassive 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).
Step 5 Create the access rules that allows anyone from the public Internet to access the two Web servers using the custom ports and the SonicWALL SuperMassive’s WAN 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 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:
• Action: Allow
• Service: servone_public_port (or whatever you named it above)
• Source: Any
• Destination: WAN 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: WAN IP address
• Users Allowed: All
• Schedule: Always on
• Logging: checked
• Comment: (enter a short description)
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.
This section contains the following subsections:
• Configuring NAT Load Balancing
• Troubleshooting NAT Load Balancing
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.
Note It is strongly advised that you enable logging for all categories, and enable name resolution for logging.
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.
To configure NAT load balancing, you must complete the following tasks:
1. Create address objects.
2. Create address group.
3. Create inbound NAT LB Policy.
4. Create outbound NAT LB Policy.
5. Create Firewall Rule.
6. Verify and troubleshoot the network if necessary.
To complete this configuration, perform the following steps:
Step 1 Create Network Objects -- Go to the Network > Address Objects page in the Management GUI and create the network objects for both of the internal Web servers, and the Virtual IP (VIP) on which external users will access the servers.
Step 2 Create Address Group -- Now create an address group named www_group and add the two internal server address objects you just created.
Step 3 Create Inbound NAT Rule for Group -- Now create a NAT rule to allow anyone attempting to access the VIP to get translated to the address group you just created, using Sticky IP as the NAT method.
Note Do not save the NAT rule just yet.
Step 4 Set LB Type and Server Liveliness Method -- On the Advanced tab of the NAT policy configuration control, you can specify that the object (or group of objects, or group of groups) be monitored via ICMP ping or by checking for TCP sockets opened. For this example, we are going to check to see if the server is up and responding by monitoring TCP port 80 (which is good, since that is what people are trying to access). You can now click on the OK button to save and activate the changes.
Note Before you go any further, check the logs and the status page to see if the resources have been detected and have been logged as online. Two alerts will appear as Firewall Events with the message “Network Monitor: Host 192.160.200.220 is online” (with your IP addresses). If you do not see these two messages below, check the steps above.
Step 5 Create Outbound NAT Rule for LB Group -- Write a NAT rule to allow the internal servers to get translated to the VIP when accessing resources out the WAN interface (by default, the X1 interface).
Step 6 Create Firewall Rule for VIP -- Write a firewall rule to allow traffic from the outside to access the internal Web servers via the VIP.
Step 7 Test Your Work – From a laptop outside the WAN, connect via HTTP to the VIP using a Web browser.
Note If you wish to load balance one or more SonicWALL SRA Appliances, repeat steps 1-7, using HTTPS instead as the allowed service.
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.