• 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

Inbound Port Address Translation via One-to-One NAT Policy

This type of NAT policy is useful when you want to conceal an internal server’s real listening port, but provide public access to the server on a different port. In this example, you create a service object for the different port (TCP 9000), then modify the NAT policy and rule created in the Creating a One-to-One NAT Policy for Inbound Traffic section to allow public users to connect to the private web server on its public IP address via that port instead of the standard HTTP port (TCP 80).

To create a one-to-one policy for inbound port address translation

1. Navigate to the OBJECT | Match Objects > Services page. On this page, you can create a custom service for the different port.

   

2. In the Service Objects view, click +Add to display the Service Objects dialog.

   

3. Give your custom service a friendly name such as webserver_public_port.

4. Select TCP(6) from the Protocol drop-down menu.

5. For Port Range, type 9000 into both fields as the starting and ending port numbers for the service.

6. When done, click Save to save the custom service, then click Close.

   • The Service Objects screen is updated.

7. Navigate to the POLICY | Rules and Policies > NAT page.

   From here, modify the NAT policy created in the Creating a One-to-One NAT Policy for Inbound Traffic section that allowed any public user to connect to the web server on its public IP address.

8. Click the Edit icon next to the NAT policy. The Editing Rule dialog displays.

9. Edit the NAT policy with the options shown in the Option Choices: Inbound Port Address Translation via One-to-One NAT Policy table.

   Option Choices: Inbound Port Address Translation via One-to-One NAT Policy

   Option	Value
   Original Source	Any
   Translated Source	Original
   Original Destination	webserver_public_ip
   Translated Destination	webserver_private_ip
   Original Service	webserver_public_port (or whatever you named it above)
   Translated Service	HTTP
   Inbound Interface	X1
   Outbound Interface	Any
   Comment	Enter a short description
   Enable NAT Policy	Checked

Make sure you choose Any as the Outbound interface rather than the interface that the server is on. This might seem counter-intuitive, but it is actually the correct thing to do (if you try to specify the interface, you get an error).

10. Click OK and then click Close.
11. With this policy in place, the firewall translates the server’s public IP address to the private IP address when connection requests arrive from the WAN interface (by default, the X1 interface), and translates the requested port (TCP 9000) to the server’s actual listening port (TCP 80).
12. Finally, modify the firewall access rule created in the previous section to allow any public user to connect to the web server on the new port (TCP 9000) instead of the server’s actual listening port (TCP 80).
13. Navigate to the POLICY | Rules and Policies > NAT Rules page and locate the rule for webserver_public_ip.
14. Click the Edit icon to display the rule in the Editing Rule dialog.

15. Edit the values as shown in the Option Choices: Inbound Port Address Translation via One-to-One NAT Policy Rule table.

    Option Choices: Inbound Port Address Translation via One-to-One NAT Policy Rule

    Option	Value
    Action	Allow
    Service	webserver_public_port (or whatever you named it)
    Source	Any
    Destination	webserver_public_ip
    Users Allowed	All
    Schedule	Always on
    Logging	Checked
    Comment	Enter a short description

16. Click OK.

To verify, attempt to access the web server’s public IP address using a system located on the public internet on the new custom port (for example: http://67.115.118.70:9000). You should be able to connect successfully. If not, review this section and ensure that you have entered all required settings correctly.