SonicOS

SonicOS 2.0 Standard NAT How-To

Overview
This whitepaper will document how to configure the Network Address Translation (NAT) functionality on a SonicWALL device running SonicOS 2.0 Standard for your environment. SonicOS 2.0 Standard runs on SonicWALLs TZ170, PRO2040, and PRO3060 platforms. While the NAT engine in SonicOS 2.0 Standard is not as flexible as the one in SonicOS 2.0 Enhanced, it is sufficient for most small to mid-size network deployment scenarios. Before we begin, if you are unfamiliar with the terminology and functions of NAT, heres a quick primer (or, if youre simply looking for a 1-2-1 NAT how-to, you can just skip to page 6). NAT exists to solve several problems that arose in the last decade of networking the first being that as people around the world rapidly connected their own networks to the public network, it became clear that the IP protocols numbering scheme would eventually be exhausted if all computers connected to the internet had their own unique public IP address. The second problem was that there were rather apparent security concerns with everyone doing so, especially if these systems were not protected by any sort of firewall, be it hardware or software-based. In order to address the first problem, NAT was deployed in small networking devices, and allowed customers to place any number of systems behind this device, address these devices with private, non-routable IP addresses (there are several ranges available), and as a systems traffic crossed this device, it would simply replace the private IP address with a public, routable IP address (Usually the WAN IP address of the device itself). As it happens, this also provides an additional layer of security, since all systems behind this device use private IP addresses; they cannot be directly contacted by any system connected to the public Internet. The final reason that most customers need NAT is that most ISPs worldwide are either unwilling to give customers blocks of routable public IP addresses to their customers, or they make it so expensive to do so that it isnt really worth it. Fortunately, SonicWALLs network security appliances have solutions to match most customers environments, whether it is static IPs, or a single dynamic IP assigned by the ISP. The deployment scenarios covered in this paper are: Basic Many-to-One NAT for systems on LAN and/or DMZ using WAN IP Address Basic Many-to-One NAT for systems on DMZ using Unique IP Address Using the WAN IP Address to provide access to Servers on LAN and/or DMZ Assigning Unique 1-2-1 NAT for Servers on LAN and/or DMZ [Optional] Integrating Dynamic DNS Services & Clients

Recommended Versions
SonicWALL recommends upgrading to SonicOS 2.0.0.9 Standard or newer, due to issues with prior versions of firmware. Please note that SonicOS Standard only runs on the TZ170, PRO2040, and PRO3060 models. Customers with current service & software support contracts can obtain updated versions of SonicWALL firmware from the MySonicWALL customer portal at https://www.mysonicwall.com. Updated firmware is also freely available to customers who have registered the SonicWALL device on MySonicWALL for the first 90 days.

Caveats
The NAT engine in SonicOS 2.0 Standard is not capable of performing inbound port address translation (mapping an external port to a different internal port) for any unique 1-2-1 NAT configured on the SonicWALL; if you require this capability, you will need to upgrade to SonicOS 2.0 Enhanced The NAT engine in SonicOS 2.0 Standard is not capable of performing many-to-many NAT (mapping a specified number of internal addresses to a specified number of external addresses); if you require this capability, you will need to upgrade to SonicOS 2.0 Enhanced The NAT engine in SonicOS 2.0 Standard is not capable of performing NAT across VPN tunnels; if you require this capability, you will need to upgrade to SonicOS 2.0 Enhanced

Basic Many-to-One NAT for systems on LAN and/or DMZ

This ones pretty simple -- translating internal systems private IP addresses to the SonicWALLs WAN IP address. Log into the SonicWALLs web management GUI. Unless you have re-addressed the internal LAN interface of the SonicWALL, you should be able to reach it from any system behind the LAN interface at http://192.168.168.168, using a modern web browser such as IE 6.x, Netscape 7,x, or Mozilla 1.x. Note: unless you have already configured the SonicWALL s internal DHCP server, you may need to statically assign the computer youre using with a temporary IP address of 192.168.168.200, subnet mask of 255.255.255.0, gateway of 192.168.168.168, and a DNS server assigned to you by your ISP or network administrator (if you dont know your DNS server settings, try 206.13.28.12 or 206.13.29.12, since these seem to work from anywhere). When youve logged in successfully, go to the Network > Settings page.

The WAN interface has a drop-down box that allows you to choose whether the WAN interface will have a unique static IP address (called NAT Enabled), or four different dynamic IP addressing options (DHCP, PPPoE, L2TP, PPTP). Choosing one of these options will automatically perform Many-to-One NAT for any system connected to the LAN interface. Choose the correct WAN interface addressing method as assigned to you by your ISP, and then click on the Configure icon at the right of the screen for the WAN. On the pop-up that appears, enter in the addressing information assigned to you by your ISP (or network administrator). When done, click on the OK button to save and activate the changes.

Unless you have modified or removed them, SonicWALLs have two default rules that allow all systems on the LAN to reach sites on the WAN, and all systems on the DMZ to reach sites on the WAN. If you have modified or removed these default rules, please check your access policy on the Firewall > Access Rules page before continuing and make any changes necessary to allow testing. If your connection to the ISP is good, you should now be able to connect to sites on the public Internet from any system behind the SonicWALLs LAN interface. To test it out, go to http://whatismyip.com using a web browser. If successful, it will report back to you the WAN IP address of the SonicWALL and not the private IP address of your system. If youre wondering what the Transparent Mode setting was in the WANs Mode drop-down, its for use when you *dont* want the SonicWALL to perform NAT at all. Choosing this mode will place the LAN and the DMZ interfaces on the same logical subnet as the WAN port when chosen, any system connected to the SonicWALLs LAN or DMZ port will need to be assigned an IP address from the same subnet as the WAN belongs to. In this mode, the SonicWALL can still perform full stateful packet inspection of traffic crossing its interfaces, and can be configured for VPNs. If you use this mode, youll have to configure the SonicWALL so that it knows what addresses are where (Check Tuesday) If youd like all systems connected to the DMZ interface of the SonicWALL to be able to use Many-to-One NAT using the WAN interfaces IP address, you will need to make some changes to the DMZ interface. By default, the DMZ interface is in Transparent Mode as noted above, this means that it belongs to the same logical network as the WAN and is not performing NAT. You have a wide range of private IP addresses to use that are not routable on the public Internet and are available for anyone to use. The only caveat is that for each physical and logical segment of your network, you must use different ranges. In other words, if you wish to put the DMZ interface in NAT mode, you must assign the DMZ interface an IP address and subnet not used anywhere else on your network. You are allowed to use the following non-routable private IP addresses on your networks: Class A: network 10.0.0.0 (base subnet mask 255.0.0.0) Class B: networks 172.16.0.0 to 172.31.0.0 (base subnet mask 255.255.0.0) Class C: networks 192.168.0.0 to 192.168.255.0 (base subnet mask 255.255.255.0) In most small to mid-size networks, customers typically use the private, non-routable Class C networks for their internal networks, meaning each network segment can have up to 254 systems. All SonicWALLs, by default, use 192.168.168.0 as the LAN interfaces subnet with the LAN interface addressed at 192.168.168.168, but of course this can be changed. For all systems connected to the DMZ when in NAT mode, make sure to use the DMZ interface IP address (the DMZ Private Address as the gateway. To change the DMZ interface, go to the Network > Settings page and click on the Configure icon to the right of the DMZ interface. Select the radio button next to DMZ in NAT Mode. In the box next to DMZ Private Address:, enter in a unique private IP address for the DMZ. In the example below, weve assigned the DMZ interface the private IP address of 192.168.230.1 In the box next to DMZ Subnet Mask:, enter in the correct subnet mask. In the example below, weve assigned the DMZ interface a subnet mask of 255.255.255.0 Leave the DMZ NAT Many-to-One Public Address (optional): setting as-is Click on OK to save and activate the changes the device may prompt you with a warning about DHCP server addresses being changed you can accept this and continue

Basic Many-to-One NAT for systems on DMZ using Unique IP Address

If youd like all systems connected to the DMZ interface of the SonicWALL to be able to use Many-to-One NAT using a unique public IP address assigned to you by your ISP, you will need to make some changes to the DMZ interface. With this method, when any system connected to the DMZ accesses a system out on the public Internet, it will use a different address than the SonicWALLs WAN IP address. By default, the DMZ interface is in Transparent Mode as noted above, this means that it belongs to the same logical network as the WAN and is not performing NAT. You have a wide range of private IP addresses to use that are not routable on the public Internet and are available for anyone to use. The only caveat is that for each physical and logical segment of your network, you must use different ranges. In other words, if you wish to put the DMZ interface in NAT mode, you must assign the DMZ interface an IP address and subnet not used anywhere else on your network. You are allowed to use the following non-routable private IP addresses on your networks: Class A: network 10.0.0.0 (base subnet mask 255.0.0.0) Class B: networks 172.16.0.0 to 172.31.0.0 (base subnet mask 255.255.0.0) Class C: networks 192.168.0.0 to 192.168.255.0 (base subnet mask 255.255.255.0) In most small to mid-size networks, customers typically use the private, non-routable Class C networks for their internal networks, meaning each network segment can have up to 254 systems. All SonicWALLs, by default, use 192.168.168.0 as the LAN interfaces subnet with the LAN interface addressed at 192.168.168.168, but of course this can be changed. To change the DMZ interface, go to the Network > Settings page and click on the Configure icon to the right of the DMZ interface. Select the radio button next to DMZ in NAT Mode. In the box next to DMZ Private Address:, enter in a unique private IP address for the DMZ. In the example below, weve assigned the DMZ interface the private IP address of 192.168.230.1 In the box next to DMZ Subnet Mask:, enter in the correct subnet mask. In the example below, weve assigned the DMZ interface a subnet mask of 255.255.255.0 In the box next to DMZ NAT Many-to-One Public Address (optional): enter in the unique public IP address assigned to you by the ISP (i.e. not the SonicWALLs WAN IP address) Click on OK to save and activate the changes the device may prompt you with a warning about

DHCP server addresses being changed you can accept this and continue

If your connection to the ISP is good, you should now be able to connect to sites on the public Internet from any system behind the SonicWALLs DMZ interface. To test it out, go to http://whatismyip.com using a web browser. If successful, it will report back to you the unique IP address you assigned as the DMZ interfaces NAT Many-to-One Public Address and not the private IP address of your system or the WAN IP address of the SonicWALL.

Using the WAN IP Address to provide access to Servers on LAN and/or DMZ
If your ISP cant provide multiple unique public IP addresses to provide public access to your internal servers (or its just too expensive to do so), you may be able to use the SonicWALLs WAN IP address instead. Actually, you can provide access to multiple internal servers, as long as theyre all on unique internal ports and do not conflict with existing rules on the SonicWALL device. For example, you can use the SonicWALLs WAN IP address to provide access to a HTTP webserver, a SMTP mailserver, and a FTP server all off the same address. These servers can be on the DMZ, or on the LAN, although from a security standpoint, its preferable to have these systems on the DMZ, with strict access rules governing access to/from these systems. In the following example, well be providing public and internal access to a mailserver located on the DMZ interface of a SonicWALL, for POP3 and SMTP protocols. The WAN IP address of the SonicWALL is statically assigned, and has a fully-qualified domain name (FQDN) mapped to this static address. If your SonicWALL device has a dynamically assigned WAN IP address, please refer to the Implementing DDNS Service and Client section at the end of this technote. Before we begin, you will need to put the DMZ interface in NAT mode, and assign it a unique private IP address and subnet. All systems connected to this subnet will need their own unique private IP address from this subnet. If you have not already done this, please refer to the previous section on page 3 that covers how to do this. Go to the Firewall > Access Rules page. Click on the Add button at the bottom of the page and create a policy allowing Send E-Mail (SMTP) access from * Source, to Destination LAN address of the private IP address of your mailserver (in our example below, the internal webserver has a private IP address of 192.168.230.200). When done, click on the OK button to save and activate the security policy. Then, create

an additional policy allowing Retrieve E-Mail (POP3) access from * Source, to Destination LAN address of the private IP address of your mailserver (in our example below, the internal webserver has a private IP address of 192.168.230.200). When done, click on the OK button to save and activate the security policy.

NOTE: Unlike SonicOS Enhanced, rules are written to the servers private IP address not the unique public IP address. Make sure you enter in the servers private IP address into the Address Range Begin: and Address Range End: fields. IMPORTANT NOTE: By specifying * in the rules we just created, the SonicWALL activates a special DNS Loopback feature that allows LAN systems to contact the server on the DMZ by either its private IP address, or more importantly, by its public IP address (in this case, its borrowing the address of the SonicWALLs WAN interface). This is extremely useful in situations where your internal users do not know the private IP address of the server on the DMZ, but they *do* know the fully-qualified domain name of the server, and would much rather just use the friendly name than have to remember to use separate addresses depending on where theyre accessing the server from. To test this rule, attempt to access the internal server from an external system connected to the public Internet using a POP3 client. You should be able to log in. Perform this test again, but this time do it from an internal system connected to the SonicWALLs LAN interface. Again, you should be able to log in. If you are not able to access the server, check the steps on the previous page and try again.

Assigning Unique 1-2-1 NAT for Servers on LAN and/or DMZ

In most cases, its preferable and more flexible to assign internal servers their own public IP address, which you may be able to obtain from your ISP. In the examples below, well be activating 1-2-1 NAT on the SonicWALL, mapping a public IP address to the servers private IP address on the DMZ interface, and creating an access rule to allow internal and public access to the server for HTTP traffic. As noted previously, you can assign a 1-2-1 NAT to an internal server on either the LAN interface or the DMZ interface. When this server initiates traffic out the WAN interface, it will use its unique public IP address. To start, go to the Network > One-to-One NAT page. Check the box next to Enable One-to-One NAT, and click on the Apply button in the upper-right to save and activate the change. The SonicWALL may issue a pop-up warning notifying you that Computers in the affected One-To-One NAT IP range(s) will lose current

connections accept this warning by clicking on the OK button to continue. When done, your screen should look like this (see below):

Next, click on the Add button on this screen to create a 1-2-1 NAT mapping. On the pop-up that appears, enter the private IP address of your server in the field next to Private Range Start:, enter the unique public IP address you wish to map to this server in the field next to Public Range Start:, and enter 1 in the field next to Range Length:. An example can be found at the top of the next page.

NOTE: If youre wondering why the pop-up screen uses the term range its actually possible to map multiple private and public IP addresses at once. Its a rarely used feature, but to use it all you have to do is put in the first private address, the first public address, and the range length it will then create mappings sequentially to the length of the range you specify. For example, if you were to enter 192.168.230.200 as the Private Range Start:, then 67.115.118.90 as the Public Range Start:, and specified a Range Length: of 3, the SonicWALL would then map 192.168.230.200 to 67.115.118.90, 192.168.230.201 to 67.115.118.91, and 192.168.230.202 to 67.115.118.92. Finally, we need to configure the firewall policy in the SonicWALL to allow public access to the internal server. Go to the Firewall > Access Rules page. Click on the Add button at the bottom of the page and create a policy allowing Web (HTTP) access from * Source, to Destination LAN address of the private IP address of your webserver (see example below -- the internal webserver has a private IP address of 192.168.168.200). When done, click on the OK button to save and activate the security policy.

NOTE: Unlike SonicOS Enhanced, rules are written to the servers private IP address not the unique public IP address. Make sure you enter in the servers private IP address into the Address Range Begin: and Address Range End: fields. IMPORTANT NOTE: By specifying * in the rules we just created, the SonicWALL activates a special DNS Loopback feature that allows LAN systems to contact the server on the DMZ by either its private IP address, or more importantly, by its public IP address (in this case, its borrowing the address of the SonicWALLs WAN interface). This is extremely useful in situations where your internal users do not know the private IP address of the server on the DMZ, but they *do* know the fully-qualified domain name of the server, and would much rather just use the friendly name than have to remember to use separate addresses depending on where theyre accessing the server from.

Optional Implementing a DDNS Service and Client

In the following example, well be configuring a SonicWALL device running SonicOS 2.0.0.9 Standard to provide access to a single internal webserver via a single fully-qualified domain name (FQDN), utilizing the free public DDNS service from DynDNS and a third-party DDNS Client (in this case, DirectUpdate) running on the internal webserver. The webserver will be accessed using the SonicWALLs WAN IP address and will not have its own unique public IP addresses, since the SonicWALL is getting its WAN IP address dynamically, and the ISP is not routing any static IP addresses to us. Using this setup, the DDNS Client will perform scheduled checks to ensure that the IP address registered to the FQDN has not changed; in the event that the SonicWALLs WAN IP address changes, the DDNS Client will detect this within a few minutes, and will automatically change the IP address associated with the FQDN on DynDNSs servers. This ensures that external users out on the public Internet can always access the internal webserver with only a single FQDN, regardless of the fact that the SonicWALLs WAN IP address may be changing frequently. Steps: If you do not already have one, create a free account at http://www.dyndns.org/services/dyndns/. During the account creation process, you will need to provide an email address that DynDNS can contact you at to verify the account creation (they will provide full details for activating the free account in this email). Log into DynDNS using your account, go to the Dynamic DNS section, and click on Add Host. On the page

that appears, create the FQDN you wish to use (for example, siebelweb.dyndns.org), enter in the WAN IP address of the SonicWALL, and click on the Add Host button. This creates the record that the DDNS Client will then update to reflect which WAN interface is currently active. Obtain and install a DDNS Client on the internal webserver. In this example, well be using DirectUpdate, which can be downloaded from http://www.directupdate.net/ (its shareware, and costs only $15 to register). Once the software installs, you will need to configure it with the DynDNS account information. Launch the DirectUpdate admin program and click on the Status page. Next to Accounts:, click on the Create button. In the pop-up button that appears, choose dyndns.org (dynamic from the drop-down list, enter in your DynDNS account and password, and then click on the OK button. Check the box next to Force update every 28 days to keep the account active. Click on the Edit Detection Settings button, and set it to check the IP every 60 seconds. When done with these settings, close the program to save and activate the changes. Next, we need to configure the firewall policy in the SonicWALL to allow public access to the internal webserver on the SonicWALLs WAN IP address. Go to the Firewall > Access Rules page. Click on the Add button at the bottom of the page and create a policy allowing Web (HTTP) access from * Source, to Destination LAN address of the private IP address of your webserver (see example on next page in our example, the internal webserver has a private IP address of 192.168.168.200). When done, click on the OK button to save and activate the security policy.

Test connectivity from an external source by accessing the internal webserver using the custom FQDN you created on the DynDNS site. If you cannot access it, check the previous steps and try again. Then, reboot the SonicWALL, and see if the WAN IP address has changed; please note that your ISP may assign you the same address. If the WAN IP address has changed, wait 5-10 minutes, and check access to the internal webserver from an external source you should be able to access the internal webserver again, even though the SonicWALL is running on a different WAN IP address. Note: your system may cache the initial DNS resolution of the initial WAN IP address; if youre using the same external system to test, it may be necessary to reboot, or wait a while before testing. Version 1.1 by Dave Parry, SonicWALL Inc. Last Edited: May 2008

10