Network > NAT Policies
257
SonicOS Enhanced 4.0 Administrator Guide
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.
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 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 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.
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. Figure 18.1 shows a sample topology and configuration.