• SonicOS 7.1 Rules and Policies
• Overview
  • About SonicOS
  • SonicOS Workflow
  • How to Use the SonicOS Administration Guides
  • Guide Conventions
• Settings
  • Configuring App/Match/Malware
  • Configuring Content Filtering Service (CFS)
    • SonicWall CFS
    • CFS Custom Category
  • Geo-IP
    • Custom List
      • Editing a Custom List Entry
      • Deleting Custom List Entries
    • Using Geo-IP Diagnostics
  • Botnet
    • Configuring Botnet Settings
    • Creating Custom Botnet Lists
    • Viewing Dynamic Botnets Lists
    • Configuring a Dynamic Botnet List Server
    • Using Botnet Diagnostics
  • Decryption (DPI-SSL)
    • Certificate
    • Common Name
    • SSL Servers
  • Decryption (DPI-SSH)
  • Signature Update
• Security Policy
  • User & Country
  • App/URL/Custom Match
• NAT Policy
  • About NAT in SonicOS
  • About NAT Load Balancing
    • Determining the NAT LB Method to Use
    • Caveats
    • How Load Balancing Algorithms are Applied
    • Sticky IP Algorithm Examples
      • Example One - Mapping to a Network
      • Example Two - Mapping to an IP Address Range
  • About NAT64
    • Use of Pref64::/n
  • About FQDN-based NAT
  • About Source MAC Address Override
  • Viewing NAT Policy Entries
    • Changing the Display
    • Filtering the Display
  • Adding or Editing NAT or NAT64 Rule Policies
  • Deleting NAT Policies
  • Creating NAT Rule Policies: Examples
    • Creating a One-to-One NAT Policy for Inbound Traffic
    • Creating a One-to-One NAT Policy for Outbound Traffic
    • Inbound Port Address Translation via One-to-One NAT Policy
    • Inbound Port Address Translation via WAN IP Address
    • Creating a Many-to-One NAT Policy
    • Creating a Many-to-Many NAT Policy
    • Creating a NAT Load Balancing Policy for Two Web Servers
• Routing
  • About Routing
    • About Metrics and Administrative Distance
      • About Metrics
      • About Administrative Distance
    • Route Advertisement
    • ECMP Routing
    • Policy-based Routing
    • Policy-based TOS Routing
    • PBR Metric-based Priority
    • Policy-based Routing and IPv6
    • OSPF and RIP Advanced Routing Services
      • About Routing Services
        • Protocol Type
        • Maximum Hops
        • Split-Horizon
        • Poison Reverse
        • Routing Table Updates
        • Subnet Sizes Supported
        • Autonomous System Topologies
      • OSPF Terms
    • Drop Tunnel Interface
    • App-based Routing
  • Rules and Policies >
    • Configuring
      • Adding Static Routes
      • Probe-Enabled Policy-based Routing Configuration
• Decryption Policy
  • Client-side SSL Rules
  • Server-side SSL Rules
  • SSH Rules
  • Setting up the Decryption Policy Table
    • Managing the Decryption Policy Toolbars
    • Changing the Policy Priority
    • Creating Decryption Policies
      • Adding Decryption Policies
      • Editing Decryption Policies
      • Deleting Decryption Policies
• DoS Policy
  • Setting up the DoS Policy Table
    • Managing the DoS Policy Toolbars
    • Changing the DoS Policy Priority
    • Creating DoS Policies
      • Adding DoS Policies
      • Editing DoS Policies
      • Deleting DoS Policies
• DNS Policy
  • Creating DNS Policies
    • Adding DNS Policies
    • Editing DNS Policies
    • Deleting DNS Policies
  • DNS Doctoring
• Endpoint Policy
• Shadow
• SonicWall Support
  • About This Document

Creating a One-to-One NAT Policy for Inbound Traffic

A one-to-one NAT policy is the most commonly used type of NAT policy on SonicWall security appliances. It allows you to translate an external public IP addresses into an internal private IP address. When paired with an Allow access rule, this NAT policy allows any source to connect to the internal server using the public IP address; the firewall handles the translation between the private and public address. With this policy in place, the firewall 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).

You also need to create the access rule that allows anyone to make HTTP connections to the web server through the web server’s public IP address, and also create the NAT policy.

The mirror (reflexive) policy for this one-to-one inbound NAT policy is described in Creating a One-to-One NAT Policy for Outbound Traffic.

To conceal the internal server’s real listening port, but provide public access to the server on a different port, refer to the example configuration described in Inbound Port Address Translation via One-to-One NAT Policy.

To create a one-to-one policy for inbound traffic

1. Navigate to the POLICY | Rules and Policies > Access Rules page.

   

2. Click +Add to display the Adding NAT Rule dialog.

3. Enter in the values shown in Option choices: Access Rule for One-to-one inbound traffic example.

   Option choices: Access Rule for One-to-one inbound traffic example

   Option	Value
   Action	Allow
   Source	WAN
   Destination	Select the zone that the server is in
   Service	Select a port; the default is Any if Source Port/Services is configured, the access rule filters the traffic based on the source port defined in the selected service object/group. The service object/group selected must have the same protocol types as the ones selected in Port/Services.
   Translated Service	HTTP
   Translated Destination	webserver_public_ip (the address object containing the server’s public IP address)
   User Include	All (default)
   User Exclude	None (default)
   Schedule	Always (default)
   Comment	Enter a short description
   Enable Logging	Selected
   Allow Fragmented Packets	Selected
   All other options	Deselected

4. Click Add. The rule is added. You can also continue with Access Rules setting up additional policies.
5. Navigate to the POLICY | Rules and Policies > NAT Rules page.
6. Click +Add to display the Adding NAT Rule dialog.

7. Configure the values shown in the Option Choices: One-to-one Inbound NAT Policy table.

   Option Choices: One-to-one Inbound NAT Policy

   Option	Value
   Original Source	Any
   Translated Source	Original
   Original Destination	webserver_public_ip
   Translated Destination	webserver_private_ip
   Original Service	HTTP
   Inbound Interface	X1
   Outbound Interface	Any NOTE: Select Any rather than the interface that the server is on.
   Translated Service	Original
   Comment	Enter a short description
   Enable	Checked
   Create a reflexive policy	Not checked

8. Click Add and then click Close.

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 Creating a One-to-One NAT Policy for Outbound Traffic section, and ensure that you have configured all required settings correctly.