• 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

Adding or Editing NAT or NAT64 Policies

You cannot edit default NAT policies.

For examples of different types of NAT policies, see Creating NAT Policies: Examples.

To create or edit a NAT or NAT64 policy

1. Navigate to POLICY | Rules and Policies > NAT Policy.

2. Do one of the following:

   • To create a new NAT policy, click +Add at the bottom of the page. The Adding NAT Rule dialog displays.

   • To edit an existing custom NAT rule, click the Edit icon in the Configure column for the NAT policy. The Editing NAT Rule dialog displays.

     The two dialogs are identical, although some changes cannot be made to some options in the Editing NAT Rule dialog. The options change when NAT64 is selected for IP Version.

     

3. On the Original screen, configure these settings:

• Name: Enter a descriptive, unique name to identify the NAT rule.

  • Original Source or IPv6 Original Source: This drop-down menu setting is used to identify the Source IP address(es) in the packet crossing the firewall, whether it is across interfaces, or into/out of VPN tunnels. You can:

    • Select predefined address objects
    • Select Any

    • Create your own address objects

    These entries can be single host entries, address ranges, or IP subnets. FQDN address objects are supported.

    For IPv6 Original Source, only IPv6 address objects are shown in the drop-down menu or can be created.

  • Original Destination or Pref64: This drop-down menu setting identifies the Destination IP address(es) in the packet crossing the firewall, whether it be across interfaces, or into/out of VPN tunnels. When creating outbound NAT policies, this entry is usually set to Any as the destination of the packet is not being changed, but the source is being changed. However, these address object entries can be single host entries, address ranges, or IP subnets. FQDN address objects are supported.

    For Pref64, this is the original destination of the NAT policy. Only IPv6 network address objects are shown in the drop-down menu or can be created. Pref64 is always pref64::/n network, as this is used by DNS64 to create AAAA records.
    You can select Well-known Pref64 or configure a network address object as Pref64.
    

  • Original Service: This drop-down menu setting identifies the IP service in the packet crossing the firewall, whether it is across interfaces, or into/out-of VPN tunnels. You can use the predefined services on the firewall, or you can create your own entries. For many NAT policies, this field is set to Any, as the policy is only altering source or destination IP addresses.

    For IP Version NAT64 Only, this option is set to ICMP UDP TCP and cannot be changed.

  • Inbound Interface: This drop-down menu setting specifies the entry interface of the packet. The default is Any.

    When dealing with VPNs, this is usually set to Any (the default), as VPN tunnels aren’t really interfaces.

  • Outbound Interface: This drop-down menu specifies the exit interface of the packet after the NAT policy has been applied. This field is mainly used for specifying to which WAN interface to apply the translation.

    Of all fields in a NAT policy, this one has the most potential for confusion.

    When dealing with VPNs, this is usually set to Any (the default), as VPN tunnels are not really interfaces. Also, as noted in Creating NAT Policies: Examples, when creating inbound one-to-one NAT Policies where the destination is being remapped from a public IP address to a private IP address, this field must be set to Any. Click the Translated tab.

  • Translated Source or Translated IPv4 Source: This drop-down menu setting is to what the specified Original Source is translated upon exiting the firewall, whether it is to another interface, or into/out of VPN tunnels. You can:
    • Specify predefined address objects
    • Select Original
    • Create your own address objects entries.

    These entries can be single host entries, address ranges, or IP subnets.

  • Translated Destination: This drop-down menu setting is to what the firewall translates the specified Original Destination upon exiting the firewall, whether it is to another interface or into/out-of VPN tunnels. When creating outbound NAT policies, this entry is usually set to Original, as the destination of the packet is not being changed, but the source is being changed. However, these address objects entries can be single host entries, address ranges, or IP subnets.

    For IP Version NAT64 Only, this option is set to Embedded IPv4 Address and cannot be changed.

  • Translated Service: This drop-down menu setting is to what the firewall translates the Original Service upon exiting the firewall, whether it be to another interface, or into/out of VPN tunnels. You can use the predefined services in the firewall, or you can create your own entries. For many NAT Policies, this field is set to Original, as the policy is only altering source or destination IP addresses.

    For IP Version NAT64 Only, this option is set to Original and cannot be changed.

  • Comment: This field can be used to describe your NAT policy entry. The field has a 32-character limit, and once saved, can be viewed in the main POLICY | Rules and Policies > NAT Policy page by running the mouse over the Comment icon of the NAT policy entry. Your comment appears in a pop-up dialog as long as the mouse is over the Comment icon.

  • IP Version: Select the IP version:

    The IP Version cannot be changed in the Editing NAT Rules dialog.

    • IPv4 (default)

    • IPv6

    • NAT64

    The options on the Add NAT Policy dialog change when NAT64 Only is selected and the Advanced view is not available.

  • Enable: By default, this checkbox is selected, meaning the new NAT policy is activated the moment it is saved. To create a NAT policy entry but not activate it immediately, clear this checkbox.

  4. To configure NAT load balancing options, click Advanced. Otherwise, skip to Step 8 to add the policy with the current configuration.

     The Advanced view does not display if NAT64 Only is selected for IP Version or if a FQDN address object/group is selected for either Original Source or Original Destination.

     

     Except for the Disable Source Port Remap option, the options on this screen can only be activated when a group is specified in one of the drop-down menus on the General screen. Otherwise, the NAT policy defaults to Sticky IP as the NAT Method.

  • Enable DNS doctoring: Selecting this check box enables the NSv to change the embedded IP addresses in Domain Name System response so clients may have the correct IP addresses of servers. Refer to DNS Doctoring.

  • Create a reflexive policy: When you select this checkbox, a mirror outbound or inbound NAT policy for the NAT policy you defined in the Add NAT Policy dialog is automatically created. This option is not selected by default.

  5. On the Advanced screen under NAT Method, select one of the following from the NAT Method drop-down list:

  • Sticky IP – Source IP always connects to the same Destination IP (assuming it is alive). This method is best for publicly hosted sites requiring connection persistence, such as web applications, web forms, or shopping cart applications. This is the default mechanism, and is recommended for most deployments.

  • Round Robin – Source IP cycles through each live load-balanced resource for each connection. This method is best for equal load distribution when persistence is not required.

  • Block Remap/Symmetrical Remap – These two methods are useful when you know the source IP addresses/networks (for example, when you want to precisely control how traffic from one subnet is translated to another).

  • Random Distribution – Source IP connects to Destination IP randomly. This method is useful when you wish to randomly spread traffic across internal resources.

    If the NAT Method is set to anything other than Sticky IP, FQDN-based address objects cannot be used for Original Source or Original Destination.

  6. Optionally, to force the firewall to only do IP address translation and no port translation for the NAT policy, select the Disable Source Port Remap checkbox. SonicOSX preserves the source port of the connection while executing other NAT mapping. This option is available when adding or editing a NAT policy if the source IP address is being translated. This option is not selected by default.

     This option is unavailable and dimmed if the Translated Source (on the General view) is set to Original.

     You can select this option to temporarily take the interface offline for maintenance or other reasons. If connected, the link goes down. Clear the checkbox to activate the interface and allow the link to come back up.

  7. In the High Availability section, optionally select Enable Probing. When checked, SonicOSX uses one of two methods to probe the addresses in the load-balancing group, using either a simple ICMP ping query to determine if the resource is alive, or a TCP socket open query to determine if the resource is alive. Per the configurable intervals, the firewall can direct traffic away from a non-responding resource, and return traffic to the resource after it has begun to respond again.

     When Enable Probing is selected, the following options become available:

  • Probe hosts every n seconds – Specify the interval between host probes. The default is 5 seconds.

  • Probe type — Select the probe type, such as TCP, from the drop-down menu. The default is Ping (ICMP).

    • Port – Specify the port. The default is 80.

  • Reply time out – Specify the maximum length of time before a time out. The default is 1 second.

  • Deactivate host after n missed intervals – Specify the maximum number of intervals that a host can miss before being deactivated. The default is 3.

  • Reactivate host after n successful intervals – Specify the minimum number of successful intervals before a host can be reactivated. The default is 3.

  • Enable Port Probing – Select to enable port probing using the Probe type selected above. Selecting this option enhances NAT to also consider the port while load balancing. This option is disabled by default.

  • RST Response Counts As Miss – Select to count RST responses as misses. The option is selected by default if Enable Port Probing is selected.

    If probing is enabled, FQDN based address objects cannot be used for Original Source or Original Destination.

  8. Click Add to add the NAT policy or click OK if editing a policy.