• SonicOSX 7 Rules and Policies
• 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
  • App/URL/Custom Match
  • Action Profile
• NAT Policy
  • About NAT in SonicOSX
  • 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 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 One-to-Many NAT Load Balancing Policy
    • Creating a NAT Load Balancing Policy for Two Web Servers
    • Creating a WAN-to-WAN Security Policy for a NAT64
    • DNS Doctoring
• Routing Rules
  • 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 > Routing Rules
    • Configuring Routing Rules
      • 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
• Endpoint Policy
• Shadow
• SonicWall Support
  • About This Document

About NAT in SonicOSX

Before configuring NAT policies, be sure to create all address objects associated with the policy. For instance, if you are creating a one-to-one NAT policy, be sure you have address objects for your public and private IP addresses.

By default, LAN to WAN has a NAT policy predefined on the firewall.

The Network Address Translation (NAT) engine in SonicOSX allows you to define granular NAT policies for your incoming and outgoing traffic. By default, the firewall has a preconfigured NAT policy to allow all systems connected to the X0 interface to perform many-to-one NAT using the IP address of the X1 interface, and a policy to not perform NAT when traffic crosses between the other interfaces. NAT policies are automatically created when certain features are enabled, such as the Enable Local Radius Server option in WLAN zone configuration, and are deleted when the feature is disabled. This section explains how to set up the most common NAT policies.

Understanding how to use NAT policies starts with examining the construction of an IP packet. Every packet contains addressing information that allows the packet to get to its destination, and for the destination to respond to the original requester. The packet contains (among other things) the requester’s IP address, the protocol information of the requester, and the destination’s IP address. The NAT Policies engine in SonicOSX can inspect the relevant portions of the packet and can dynamically rewrite the information in specified fields for incoming, as well as outgoing traffic.

You can add up to 512 - 2048 NAT policies depending on the SonicWall network security platform, and they can be as granular as you need. It is also possible to create multiple NAT policies for the same object — for instance, you can specify that an internal server use one IP address when accessing Telnet servers, and to use a totally different IP address for all other protocols. Because the NAT engine in SonicOSX supports inbound port forwarding, it is possible to hide multiple internal servers off the WAN IP address of the firewall. The more granular the NAT policy, the more precedence it takes.

The Maximum Routes and NAT Policies Allowed per Firewall Model table shows some of the maximum numbers of routes and NAT policies allowed for each network security appliance model running SonicOSX. Additional models could be supported similarly.