SonicOS 7.0 Rules and Policies for Classic Mode
- SonicOS 7.0 Rules and Policies
- Access Rules
- Setting Firewall Access Rules
- About Connection Limiting
- Using Bandwidth Management with Access Rules
- Creating Access Rules
- Configuring Access Rules for IPv6
- Enabling and Disabling Access Rules
- Editing Access Rules
- Deleting Access Rules
- Restoring Access Rules to Default Settings
- Displaying Access Rules
- Displaying Access Rule Traffic Statistics
- Configuring Access Rules for NAT64
- Configuring Access Rules for a Zone
- Access Rules for DNS Proxy
- User Priority for Access Rules
- Access Rule Configuration Examples
- Setting Firewall Access Rules
- NAT Rules
- About NAT in SonicOS
- About NAT Load Balancing
- About NAT64
- About FQDN-based NAT
- About Source MAC Address Override
- Viewing NAT Policy Entries
- 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 One-to-Many NAT Load Balancing Policy
- Creating a NAT Load Balancing Policy for Two Web Servers
- Creating a WAN-to-WAN Access Rule for a NAT64 Policy
- DNS Doctoring
- Routing
- Content Filter Rules
- App Rules
- About App Rules
- Rules and Policies > App Rules
- Verifying App Rules Configuration
- App Rules Use Cases
- Creating a Regular Expression in a Match Object
- Policy-based Application Rules
- Logging Application Signature-based Policies
- Compliance Enforcement
- Server Protection
- Hosted Email Environments
- Email Control
- Web Browser Control
- HTTP Post Control
- Forbidden File Type Control
- ActiveX Control
- FTP Control
- Bandwidth Management
- Bypass DPI
- Custom Signature
- Reverse Shell Exploit Prevention
- Endpoint Rules
- SonicWall Support
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
-
Navigate to the OBJECT | Match Objects > Services page. On this page, you can create a custom service for the different port.
-
In the Service Objects view, click +Add to display the Service Objects dialog.
-
Give your custom service a friendly name such as
webserver_public_port
. -
Select TCP(6) from the Protocol drop-down menu.
-
For Port Range, type 9000 into both fields as the starting and ending port numbers for the service.
-
When done, click Save to save the custom service, then click Close.
- The Service Objects screen is updated.
-
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.
-
Click the Edit icon next to the NAT policy. The Editing Rule dialog displays.
-
Edit the NAT policy with the options shown in the Option Choices: Inbound Port Address Translation via One-to-One NAT Policy table.
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).
- Click OK and then click Close.
- 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).
- 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).
- Navigate to the POLICY | Rules and Policies > NAT Rules page and locate the rule for
webserver_public_ip
. - Click the Edit icon to display the rule in the Editing Rule dialog.
-
Edit the values as shown in the Option Choices: Inbound Port Address Translation via One-to-One NAT Policy Rule table.
- 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.
Was This Article Helpful?
Help us to improve our support portal