How it Works
SonicWall
Loading...
SonicOSX 7
User Manual
51 pgs41.53 Mb0
Administration Guide
101 pgs2.95 Mb0
Administration Guide
81 pgs3.97 Mb0
Administration Guide
12 pgs1.74 Mb0
Administration Guide
31 pgs517.41 Kb0
Administration Guide
39 pgs641.4 Kb0
Administration Guide
45 pgs669.78 Kb0
Table of contents
Loading...

SonicWall SonicOSX 7 Administration Guide

SonicOSX 7 Rules and Policies
Administration Guide
Contents
Settings 5
Configuring App/Match/Malware 6
Settings: Application, Custom Match and Malware Prevention Settings 6 Application Cache 6 Security Services Settings 7
Configuring Content Filtering Service (CFS) 8
SonicWall CFS 8 CFS Custom Category 9
Geo-IP 10
Policy-based Settings 10 Global Settings 10 Custom List 10 Using Geo-IP Diagnostics 11
Botnet 12
Configuring Botnet Settings 12 Creating Custom Botnet Lists 13 Viewing Dynamic Botnets Lists 15 Configuring a Dynamic Botnet List Server 15 Using Botnet Diagnostics 16
Decryption (DPI-SSL) 17
SSL Client Inspection 17 SSL Server Inspection 18 Certificate 18 Common Name 18 SSL Servers 19
Decryption (DPI-SSH) 19
Signature Update 20
Security Policy 21
App/URL/Custom Match 23
Action Profile 24
NAT Policy 25
About NAT in SonicOSX 25
About NAT Load Balancing 26
Determining the NAT LB Method to Use 27 Caveats 27 How Load Balancing Algorithms are Applied 28 Sticky IP Algorithm Examples 28
About NAT64 29
Contents
2
Use of Pref64::/n 29
About FQDN-based NAT 30
About Source MAC Address Override 30
Viewing NAT Policy Entries 30
Changing the Display 31 Filtering the Display 31
Adding or Editing NAT or NAT64 Policies 31
Deleting NAT Policies 36
Creating NAT Rule Policies: Examples 36
Creating a One-to-One NAT Policy for Inbound Traffic 37 Creating a One-to-One NAT Policy for Outbound Traffic 39 Inbound Port Address Translation via One-to-One NAT Policy 41 Inbound Port Address Translation via WAN IP Address 44 Creating a Many-to-One NAT Policy 47 Creating a Many-to-Many NAT Policy 49 Creating a One-to-Many NAT Load Balancing Policy 52 Creating a NAT Load Balancing Policy for Two Web Servers 55 Creating a WAN-to-WAN Security Policy for a NAT64 59 DNS Doctoring 61
Routing Rules 63
About Routing 63
About Metrics and Administrative Distance 64 Route Advertisement 65 ECMP Routing 66 Policy-based Routing 66 Policy-based TOS Routing 66 PBR Metric-based Priority 67 Policy-based Routing and IPv6 68 OSPF and RIP Advanced Routing Services 68 Drop Tunnel Interface 77 App-based Routing 77
Rules and Policies > Routing Rules 78
Configuring Routing Rules 78
Decryption Policy 81
Behavior 81
Decryption Policy Types 81
Client-side SSL Rules 81
Server-side SSL Rules 82
SSH Rules 82
Setting up the Decryption Policy Table 82
Managing the Decryption Policy Toolbars 85 Changing the Policy Priority 86 Creating Decryption Policies 86
Contents
3
DoS Policy 89
Setting up the DoS Policy Table 89
Managing the DoS Policy Toolbars 92 Changing the DoS Policy Priority 93 Creating DoS Policies 93
Endpoint Policy 96
Adding a Policy 96
Shadow 98
SonicWall Support 100
About This Document 101
Contents
4
1

Settings

NOTE: References to SonicOS/X indicate that the functionality is available in both SonicOS and
SonicOSX.
The Settings page is an all-inclusive, unified policy configuration dashboard that combines Layer 2 to Layer 7 policy enforcement. The Settings page shows the licensed security services available within your system. From this page you are able to track service statuses, expiration dates, signature timestamps, and last time those service were checked. The Status tab displays the current status of your Security Service features. You can also update your services by clicking the Update icon at the end of the Signature Database Timestamp entry.
To view the Policy Settings page:
1.
Navigate to POLICY | Rules and Policies > Settings.
The Settings | Status page displays.
2.
Check that services are correctly licensed, updated, and functioning correctly.
You can click the tabs at the top of the page to further configure your services:
l App/Match/Malware
l Configuring Content Filtering Service (CFS)
l Geo-IP
5
Settings
l Botnet
l Decryption (DPI-SSL)
l Decryption (DPI-SSH)
l DoS
l Licenses

Configuring App/Match/Malware

Settings: Application, Custom Match and Malware Prevention Settings

Select the Application Classification (Identification) based on:
Block connections when Application signatures are unavailable and rules need application
Block connections when Anti-Malware databases are not downloaded and rules need Malware info
Zone
Policy
When enabled, all connections are dropped when application signatures are unavailable and policies need application details to classify the packet.
When enabled, all connections are dropped when Malware (Threats, Spyware and Virus) signatures are not downloaded and policies actions need to apply anti-malware profiles.

Application Cache

Enable Active Application Caching This enables/disables active application caching.
Use Cached Applications to Bypass DPI This enables/disables using the cache for
improved performance. If an active app cache entry is found then application identification engine is bypassed to further classify a packet.
Default Application Cache Timeout This is the system default timeout. Timeout in
seconds after when an entry is flushed from application cache on no further activity.
Settings
6
Default Application Cache Threshold Number of session after when an app cache entry
becomes active and usable.
Enable Global Application Cache Timeout This enables a global timeout for all components
of an application. When disabled then firewall controls expiration of each app cache entry and is depended on components inside each app cache entry. Timeout in seconds after when an entry is flushed from application cache on no further activity.
Enable Global Application Cache Threshold This enables a global threshold for all components
of an application. When disabled then firewall controls after how many sessions an application cache becomes active and usable and is depended on components inside each app cache entry. Number of session after when an app cache entry becomes active and usable.

Security Services Settings

Security Services Setting Maximum Security (Recommended): Inspect all
content with any threat probability (high/medium/low). Note: For additional performance capacity in this maximum security setting, utilize SonicOSX DPI Clustering. Performance Optimized: Inspect all content with a high or medium threat probability. Note: Consider this performance optimized security setting for bandwidth/CPU intensive gateway deployments or utilize SonicOSX DPI Clustering.
Reduce Anti-Virus and E-Mail Filter traffic for ISDN connections
Drop all packets while IPS, GAV and Anti­Spyware database is reloading
HTTP Clientless Notification Timeout for Gateway AntiVirus and AntiSpyware
Enable or Disable.
Enable or Disable.
Indicate number of seconds before timeout.
Settings
7

Configuring Content Filtering Service (CFS)

The CFS (Content Filtering Service) page provides a list of the filtering types and gives the link to the pages for finding SonicWall CFS objects and policies. Internet Content Filtering equips SonicWall to monitor usage and control access to objectionable Web content according to established Acceptable Use Policies.
To configure CFS:
1.
Navigate to POLICY | Rules and Policies > Settings | CFS.
The CFS page appears.
2.
Click the tab for the Content Filtering Type to select the content filtering options you want to view:
l SonicWall CFS - SonicWall CFS is the standard content filtering service.
l CFS Custom Category - Allows the configuration of new custom CFS category entries.
Topics:
l Sonicwall CFS l CFS Custom Category

SonicWall CFS

This allows you to configure client Content Filtering Service (CFS) settings in SonicOSX. The default SonicWall Content Filtering Service policy is available without a CFS subscription. With a valid advanced CFS subscription, you can create custom CFS policies and apply them to network zones or to groups of users within your organization.
After you have configured a CFS policy, you can configure client content filtering settings.
SonicOSX offers client content filtering protection on a subscription-basis through a partnership with McAfee.
Topics:
l Global Settings l SonicWall CFS
Settings
8
Global Settings
The Global Settings section of the Content Filter page brings up the information for defining the global settings for CFS policies. Many of the fields on this page have an i (information) icon on the right, which gives more information about that field. The Global Settings section provides these configuration options:
Enable Content Filtering Service This setting defaults to Enabled.
Max URL Cache Entries You can select the maximum number of URL entries that
can be cached. The minimum is 25,600 and the maximum is 51,200. In the note beneath this field, there is a link on the word "here" that gives the supported range for the selected model.
Block if CFS Server is Unavailable When this option is selected, if the CFS server is detected
as unavailable, then all web access is blocked.
Bypass decryption when CFS is not licensed and policies need web content
Bypass decryption when CFS fails to connect to backend rating server and policies need web rating
Server Timeout If the network security appliance does not get a response
Enable Local CFS Server Check this box for the local CFS server. This setting
Primary Local CFS Server This field holds the IP address for primary local CFS server.
Secondary Local CFS Server This field holds the IP address for secondary local CFS
When enabled, all connections are bypassed when the GEO-IP map database is not downloaded and your policies require country details.
When enabled, all web client connections are bypassed when the CFS is unable to connect to the backend servers and your policies require web stream rating data (URL ratings).
from the CFS server within this timeout value, the sever is marked as unavailable. The minimum is two seconds, the maximum is 10 seconds, and the default is five seconds. This setting is not available when Block if CFS Server is Unavailable is not checked.
defaults to disabled.
It becomes available when Enable Local CFS Server is checked.
server. It becomes available when Enable Local CFS Server is checked.

CFS Custom Category

The CFS Custom Category section allows the configuration of new custom CFS category entries. The administrator can create custom policies and categories, and insert the domain name entries into the existing, flexible CFS rating category structure. Categories are added and deleted on the page that follows:
1.
Navigate to POLICY | Rules and Policies > Settings > CFS > CFS Custom Category.
2.
Click Enable CFS Custom Category.
Settings
9
3.
Click +Add to bring up a dialog box where you can choose from a list of categories to add to the CFS categories in your system.
4.
Choose the Domain name and the custom categories, then click Save to add them.
5.
Click Accept on the CFS Custom Category page to save your changes.

Geo-IP

The Settings page in POLICY | Rules and Policies > Settings > GEO-IP > Settings provides a group of settings that can be configured for Geo-IP Filtering. Several of the settings have (information) icons next to them that give screen tips about that setting. The GEO-IP Filter feature allows administrators to block connections to or from a geographic location based. SonicWall appliances use IP addresses to determine the location of the connection.

Policy-based Settings

To enable Policy-based settings:
1.
When Block connections when Geo IP database is not downloaded and rules need Geo locationis enabled, all connections are dropped when the Geo-IP map database is not downloaded and your policies still need country details.
2.
When Bypass decryption when Geo IP database is not downloaded and policies need Geo location is enabled, all connections bypass decryption when the Geo-IP map database is not downloaded and your policies still need country details.

Global Settings

To enable Global settings:
1.
Enable Custom List - This option is selected by default. Custom lists are sometimes used to correct a false country assignment for an IP address. When the checkbox is selected, Override Firewall Countries by Custom List is made available.
2.
Override Firewall Countries by Custom List - This selection is only available when Enable Custom List is enabled. It allows your custom list to override the firewall list where there are
differences. Unless you select this Override, the firewall list takes precedence, even when you have enabled a custom list.
3.
Click Accept to save your settings.

Custom List

The POLICY | Rules and Policies > Settings > GEO-IP > Custom List allows you to create custom country lists of IP addresses to either block or allow. This can be useful, for example, if an IP address is mistakenly associated with a blocked country, and you want it to be allowed. Having a custom country list can solve this problem by overriding the firewall country associated with the particular IP address.
Settings
10
For the network security appliance to use the Custom List first, you must enable it and select Override Firewall List.
To add a custom list address object:
1.
Click +Add to bring up the Add Address Location dialog box.
2.
From the IP Address list, select an IP Address object/group.
3.
From the Country list, select a country.
4.
Optionally, you can add a comment in the Comment field.
5.
Click Save.
Topics:
l Editing a Custom List Entry l Deleting Custom List Entries
Editing a Custom List Entry
To modify an existing Custom Country List:
1.
Navigate to POLICY | Rules and Policies > Settings > GEO-IP > Custom List.
2.
Select the Custom List entry you would like to modify and mouse-over the entry.
The Edit/Delete icons appear on the right side of the entry.
3.
Click the Edit icon.
The Edit Address Location dialog appears.
4.
Make any necessary changes.
5.
Click Save.
Deleting Custom List Entries
To delete an existing Custom Country List:
1.
Navigate to POLICY | Rules and Policies > Settings > GEO-IP > Custom List.
2.
Select the Custom List entry you would like to delete and mouse-over the entry.
The Edit/Delete icons appear on the right side of the entry.
3.
Click the Delete icon.
The Delete Custom Geo-IP Filter List confirmation dialog appears.
4.
Click Confirm to delete the entry.

Using Geo-IP Diagnostics

The POLICY | Rules and Policies > Settings > GEO-IP > Diagnostics page provides access to several tools:
l Geo-IP Cache Statistics
l Custom Countries Statistics
Settings
11
l Show Resolved Locations
l Incorrectly Marked Address
l Check GEO Location Server Lookup

Botnet

The Botnet tab allows you to block connections to or from Botnet command and control servers, and make custom Botnet lists. It also allows you to create a custom message to send when you block a web site, or to allow dynamic Botnet HTTP authentication. Many of the selections on this page have an Information icon that you can hover over for a screen tip.
Topics:
l Configuring Botnet Settings l Creating Custom Botnet Lists l Viewing Dynamic Botnet Lists l Configuring a Dynamic Botnet List Server l Using Botnet Filter Diagnostics

Configuring Botnet Settings

To configure Botnet Policy-based Settings:
1.
Navigate to POLICY | Rules and Policies > Settings > Botnet | Settings.
2.
To block all servers that are designated as Botnet command and control servers, select Block connections when Botnet signatures are unavailable and rules need botnet control. All connection attempts are blocked. This option is selected by default.
Global Settings
1.
To enable the Custom Botnet List, select Enable Custom Botnet List. This option is not selected by default.
If Enable Custom Botnet List is not selected, then only the Botnet database that resides on the network security appliance is searched. Go to Step x. Enabling a custom list by selecting Enable Custom Botnet List can affect country identification for an IP address:
a.
During Botnet identification, the custom Botnet list is searched first.
b.
If the IP address is not resolved, the firewall's Botnet database is searched.
If an IP address is resolved from the custom Botnet list, it can be identified as either a Botnet IP address or a non-Botnet IP address, and action taken accordingly.
2.
Click Enable Dynamic Botnet List to affect the botnet identification, for an IP address, in the following ways:
l If "Enable Dynamic Botnet List" is enabled, the IP address is looked up against the dynamic
botnet list. If not found, the default list from the backend database will be searched.
Settings
12
l When "Enable Custom Botnet List" is enabled, the custom list will take precedence over the
dynamic botnet list. So an IP in the dynamic botnet list will be allowed by the Firewall if it is marked as "not a botnet" in the custom list.
Dynamic Botnet List File Format
• The dynamic botnet file is a .txt file that lists all the IPs seperated by end-of-line character.
• Comment lines should start with # symbol.
• Blocking of only individual IP addresses are supported. If the file contains subnets, they will be ignored.
• Blocking of only public IP addresses are supported. Private IP addresses in the list will be ignored.
• Empty Lines are OK.
• Max file size cannot exceed 32KB.
• Max number of IPs cannot exceed 2000.
• Example file
#------------------------------------
# Sample botnet file (botnet.txt).
#------------------------------------
# Botnet IPs List 1
1.1.1.1
2.2.2.2
# Botnet IPs List 2
1.1.210.16
1.1.210.17
#------------------------------------
# End of Dynamic Botnet List File.
#------------------------------------
3.
Select Enable Logging to log Botnet Filter-related events.
4.
Optionally, you can configure an exclusion list of all IPs belonging to the configured address object/address group. All IPs belonging to the list are excluded from being blocked. To enable an exclusion list, select an address object or address group from the Botnet Exclusion Object list.
5.
Click Accept.

Creating Custom Botnet Lists

Address Object Name of the address object or address group object.
Botnet Icon indicating whether the entry was defined as a Botnet when created. A
black circle indicates a Botnet, a white circle a non-Botnet.
Comments Any comments you added about the entry.
Configure Contains Edit and Delete icons for the entry.
Total Displays the number of entries in the Custom Botnet List.
An IP address can be wrongly marked as Botnet. This kind of misclassification can cause incorrect/unwanted filtering of an IP address. Having a custom Botnet list can solve this problem by overriding the Botnet tag for a particular IP address.
Settings
13
Topics:
l Creating a Custom Botnet List
l Editing Custom Botnet List Entries
Creating a Custom Botnet List
For the firewall to use the custom Botnet list, you must enable it as described in Configuring Botnet Filters.
To create a custom Botnet list::
1.
Navigate to the POLICY | Rules and Policies > Settings > Botnet | Custom Botnet List.
2.
Click +Add. The Add Address Location dialog displays.
3.
Select an IP address object or create a new address object from the A Botnet IP Address list:
An address object cannot overlap any other address objects in the custom country list. Different address objects, however, can have the same country ID.
l Create new address object… – the Add Address Location dialog displays.
1.
Create a new address location. Allowed types are:
a.
Host
b.
Range
c.
Network
d.
A group of any combination of the first three types
All other types are disallowed types and cannot be added to the custom Botnet list.
l Create new address group… – the Add Address Location dialog displays.
1.
Create a new address object.
l Already defined address object or address group
1.
If this address object is a known Botnet, select the Botnet checkbox.
2.
Optionally, add a comment in the Comment field.
3.
Click Save.
Editing Custom Botnet List Entries
To edit a custom Botnet list entry:
1.
In the Custom Botnet List table, click the Edit icon in the Configure column for the entry to be edited. The Add Address Locationdialog displays the entry.
2.
Make your changes.
3.
Click Save.
The Custom Botnet List table is updated.
Settings
14

Viewing Dynamic Botnets Lists

Index
IP Address
Total
Name of the botnet or botnet group object.
Location of the botnet source
Displays the number of entries in the Dynamic Botnet List.
An IP address can be wrongly marked as Botnet. This kind of misclassification can cause incorrect/unwanted filtering of an IP address. Having a dynamic Botnet list can solve this problem by overriding the Botnet tag for a particular IP address.

Configuring a Dynamic Botnet List Server

With SonicOSX, username and passwords for HTTP URLs in the dynamic Botnet configuration are accepted, and the information is transmitted in the HTTP header so the network security appliance has the required information.
To configure dynamic HTTP authentication:
1.
Navigate to POLICY | Rules and Policies > Settings > Botnet > Dynamic Botnet List.
2.
Select Enable botnet list download periodically. This option is not selected by default.
3.
From Download Interval, select the frequency of downloads:
l 5 minutes (default) l 15 minutes l 1 hour l 24 hours
The network security appliance downloads the Botnet file from the server at the specified interval.
1.
From Protocol, select the protocol in which the network security appliance has to communicate with the backend server to retrieve the file:
l FTP (default) l HTTPS
2.
In the Server IP Address field, enter the IP address of the server to which the Botnet list file will be downloaded.
3.
In the Login ID field, enter the login ID the network security appliance is to use to connect to the server.
4.
In the Password field, enter the password the network security appliance is to use to connect to the server.
5.
In the Directory Path field, enter the directory path the firewall from which the network security appliance retrieves the Botnet file. This server directory path is relative to the default root directory.
6.
In the File Name field, enter the name of the file on the server to be downloaded .
7.
Click Save.
Settings
15

Using Botnet Diagnostics

The POLICY | Rules and Policies > Settings > Botnet > Diagnostics page provides access to several tools:
l Botnet Cache Statistics l Botnets Statistics l Show Resolved Botnet Locations l Check Botnet Server Lookup l Incorrectly Marked Address
Botnet Cache Statistics
The Botnet Cache Statistics table contains this information:
l Location Server IP l Resolved Entries l Unresolved Entries l Current Entry Count l Max. Entry Count l Botnets Detected
Botnets Statistics
The Diagnostics view displays statistics for both custom and dynamic Botnets. Both the Custom Botnets Statistics and Dynamic Botnet Statistics tables display the same information about the number of entries in the list and the number of times lookups have occurred for the entries:
l No of Entries l No of Times Called l No of Times Not Looked-up l No of Times Resolved
Show Resolved Botnet Locations
When you click on Show Botnets in the Diagnostics section, a table of resolved IP addresses displays with this information:
l Index l IP Address – IP address of the Botnet
Check Botnet Server Lookup
The Botnet Filter also provides the ability to look up IP addresses to determine:
l Domain name or IP address l Country of origin and whether the server is classified as a Botnet server
The Botnet Server Lookup tool can also be accessed from the DEVICE > Diagnostics page.
16
Settings
To look up a Botnet server:
1.
Navigate to POLICY | Rules and Policies > Settings > Botnet > Diagnostics.
2.
Scroll to the Check BOTNET Server Lookup section.
3.
In the Lookup IP field, enter the IP address.
4.
Click Save.
Details on the IP address are displayed below the Result heading.
Incorrectly Marked Address
If you believe that a certain address is marked as a Botnet incorrectly, or if you believe an address should be marked as a Botnet, report this issue at SonicWall Botnet IP Status Lookup by either:
l Clicking on the link in the Note in the POLICY | Rules and Policies > Settings > Botnet >
Diagnostics page
l Going to SonicWall Botnet IP Status Lookup.

Decryption (DPI-SSL)

The Decryption (DPI-SSL) page provides a list of inspection types available. In the General tab, you can configure settings for:
l SSL Client Inspection
l SSL Server Inspection
The configure the desired inspection type:
1.
Navigate to POLICY | Rules and Policies > Settings > Decryption (DPI-SSL) > General.

SSL Client Inspection

Enable SSL Client Inspection Click to enable SSL Client Inspection.
17
Settings
Always authenticate server for decrypted connections
Deployments wherein the firewall sees a single server IP for different server domains, such as a Proxy setup
Allow SSL without decryption (bypass) when connection limit exceeded
Audit new default exclusion domain names prior to being added for exclusion
Always authenticate server before applying exclusion policy
When enabled for decrypted/intercepted connections, DPI-SSL: Blocks connections to sites with untrusted certificates. Blocks connections when the domain name in the Client Hello cannot be validated against the Server Certificate for this connection.
When disabled, use of a server IP address-based dynamic cache is marked for exclusion.
When enabled, allows SSL to proceed without decryption (bypass) when exceeding the connection limit. By default, new connections are dropped when the connection exceeds the limit.
Audits new built-in exclusion domain names prior to being added for exclusion.
When enabled for excluded connections, DPI-SSL: Blocks connections to sites with untrusted certificates. Blocks connections when the domain name in the Client Hello cannot be validated against the Server Certificate for this connection.

SSL Server Inspection

Enable SSL Server Inspection
Click to enable SSL Server Inspection.

Certificate

This certificate replaces the original certificate-signing authority only when that authority certificate is trusted by the firewall. If the authority is not trusted, then the certificate is made self-signed.
To avoid certificate errors, choose a certificate that is trusted by devices that are protected by DPI-SSL.
To manage your certificates, go to Device | Settings > Certificates. Certificates signed by an authority trusted by the firewall are re-signed using this certificate.

Common Name

You can use Common Name exclusions and inclusions to exclude particular websites from limitation.
DPI-SSL Default Exclusions Status
Indicates with a timestamp the last time the exclusion list was enforced and the last time the exclusions were checked.
Settings
18
Common Name Exclusions/Inclusions
You can use to Search and filtering options to locate or reduce common names in your list. You can also +Add more exclusions by clicking +Add and completing the form.
Update Default Exclusions Manually
If you work in a closed environment or prefer to update default exclusions manually, download the exclusions file from www.MySonicWall.com to your disk, then import the file.

SSL Servers

Server DPI-SSL allows you to configure pairings of an address object and certificate to typically offload/protect an internal Server from inbound WAN access. Options include:
l Address Object/Group - When the appliance detects SSL connections (from the WAN) to this
address object, it presents the paired certificate and negotiates SSL with the connecting client (typically in the WAN).
l SSL Certificate - This certificate is used to sign traffic for each server that has DPI-SSL Server
inspection performed on its traffic
l Cleartext - If Cleartext is selected, a standard TCP connection is made from the appliance to the
server (in the LAN) on the original port. For this to work, a NAT policy needs to be added. If the pairing is not cleartext, then an SSL connection to the server is negotiated.
To view and manage certificates, go to DEVICE | Settings > Certificates.

Decryption (DPI-SSH)

The Anti-Spyware Service service does not work for DPI-SSH because TCP streams for Anti-Spyware are not supported. If the checkbox is checked, the system takes no action. The Decryption Policies feature allows you to decrypt and bypass connections.
To configure Decryption (DPI-SSH):
1.
Navigate to POLICY | Rules and Policies > Settings > Decryption (DPI-SSH).
2.
For Enable SSH Inspection, click enable to activate SSH Inspection.
Settings
19
3.
Block Port Forwarding - Enable Block Port forwarding to allow local or remote computers (for example, computers on the internet) to connect to a specific computer or service within a private LAN. Port forwarding translates the address and/or port number of a packet to a new destination address and forwards it to that destination according the routing rules. Because these packets have new destinations and port numbers, they can bypass the firewall security policies.
4.
Local Port Forwarding - Enable Local Port Forwarding to allow a computer on the local network to connect to another server that might be an external server.
5.
Remote Port Forwarding - Enable to allow a remote host to connect to an internal server.
6.
X11 Forwarding - Use X11 forwarding as an alternative to forwarding a Remote Port or VNC connection. It differs from Remote Port Forwarding or VNC in that remote application windows appear seamlessly in your desktop, without forwarding a complete desktop. X11 forwarding is best used with UNIX-style servers running applications intended to run under X11. For connections to Windows servers, Remote Port Forwarding is the native option.
7.
Click Accept to save your changes.

Signature Update

Manage signatures by manually uploading signature and map database files. Service licenses can be downloaded, imported, updated, and monitored from the Signature Update tab. Follow the options as shown.
Settings
20
2

Security Policy

To configure Security Policy rules, the service or service group that the policy applies to must first be defined. If it is not, you can define the service or service group and then create one or more rules for it.
The following procedure describes how to add, modify, reset to defaults, or delete Security Policy rules for firewalls running SonicOSX. Paginated navigation and sorting by column header is supported on the Security Policy screen. In the Security Policy table, you can click the column header to use for sorting. An arrow is displayed to the right of the selected column header. You can click the arrow to reverse the sorting order of the entries in the table.
By hovering your mouse over icons on the Security Policy page, you can display information about criteria, such as an Source Port or Service.
IPv6 is supported for Security Policy. Search for IPv6 Security Policies in the Security Policy Search section. A list of results displays in a table.
From there you can click the Configure icon for the Security Policy you want to edit. The IPv6 configuration for Security Policy is almost identical to IPv4.
To configure a Security Policy:
1.
Navigate to POLICY | Rules and Policies > Security Policy. The Security Policy page displays. The POLICY | Rules and Policies > Security Policy page enables you to select multiple configuration screens for your security policies.
2.
From the bottom of the Security Policy table, click Add. The Adding Rule dialog displays.
Security Policy
21
3.
Or, under the Configure column, click the Edit icon for the source and destination zones or interfaces for which you are configuring a rule. The Editing Rule page for that zone/interface pair displays.
4.
In the top view, enter or edit the policy Name and any identifying Tags you would like to enter to help sort your policies.
5.
Enter a Description of the policy and its intent.
6.
Select an Action, whether to Allow, Deny, or Discard access.
NOTE: If a policy has a “No-Edit” policy action, the Action settings are not editable.
7.
Specify the IP version in Type, IPv4 or IPv6.
8.
Set your Security Policy's Priority.
TIP: Higher numbers indicate lower priority. The lowest priority rule is the final/default rule
applied to matching traffic (traffic matching the defined attributes) when no higher priority rules apply. Lower priority rules should be more general than rules with higher priorities. If a higher priority rule does not match all the attributes, then the next rule is evaluated to see if it applies, all the way down the list of rules. Rules with more specific matching attributes need to be set at a higher priority or else a more general rule could match before that specific rule is evaluated.
9.
Specify when the rule is applied by selecting a schedule or Schedule Group from the Schedule drop­down menu. If the rule is always applied, select Always On. If the schedule does not exist, refer to Configuring Schedules.
10.
Click Enable to activate the policy schedule and enable logging.
11.
In the Source/Destination view, select the Source and Destination zones, and network address objects, and port/services for each from the drop-down menus.
There are no default zones. Any is supported for both zone fields.
12.
For the Port/Services object in the Port/Services drop-down menus, if the service does not exist, refer to Configuring Service Objects.
13.
Under Users, specify if this rule applies to all users or to an individual user or group in the Include drop-down menu. You can exclude users as well using the Exclude drop-down menu.
14.
Under GEO Country, indicate a (From/To) Country from the drop-down menu.
15.
Click Save, and continue with App/URL/Custom Match and Action Profile.
Security Policy
22

App/URL/Custom Match

You can add additional rule attributes by indicating the Match Operation, type of application to which this rule would apply, whether or not to include Matched App Signatures, type of Web Categories, URLs, and Custom Matches that could be applied.
To fill the App/URL/Custom Match options:
1.
Navigate to POLICY | Rules and Policies > Security Policy.
2.
Click Add. The Adding Rule dialog displays.
3.
Click the App/URL/Custom Match tab.
Match Operation
Application
AND All Matched APP Signatures
Web Category
URL
Custom Match
4.
5.
Click Save to apply your changes. Click Action Profile to continue with the configuration.
Allows you to indicate whether to use either rule or both rules.
Select which group application to apply to this rule.
When this option is enabled, when more than one App Signature is addressed within a flow or session, then all signatures must be included in the app group configured previously, for the match to be successful. When this option is disabled, any one signature among all the signatures addressed would result in a successful match.
Indicate whether to apply defined group web categories.
Indicate whether to restrict defined URLs.
Indicate which custom match groups to include in the rule.
Security Policy
23

Action Profile

To enforce a predetermined Action Profile with your security policy.
To fill the Action Profile options:
1.
Navigate to POLICY | Rules and Policies > Security Policy.
2.
Click Add. The Adding Rule dialog displays.
3.
Click the Action Profile tab.
To enforce specific predetermined policy rules, select from the
Action Profile
Default for Service Action
available Action Profiles.
The default is to Allow use of the Action Profile.
Security Policy
24
Topics:
l About NAT in SonicOS
l About NAT Load Balancing
l About NAT64
l About FQDN Based NAT
l About Source MAC Address Override
l Viewing NAT Policy Entries
l Adding or Editing NAT or NAT64 Policies
l Deleting NAT Policies
l Creating NAT Policies: Examples
3

NAT Policy

About NAT in SonicOSX

IMPORTANT: 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.
TIP: 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.
NAT Policy
25
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.
MAXIMUM ROUTES AND NAT POLICIES ALLOWED PER FIREWALL MODEL
Model
NSa 9650
NSa9450
NSa9250
NSa6650
NSa 5650
NSa4650
NSa3650
NSa2650
SM 9600
SM 9400
SM 9200
Routes
NAT Policies Model
4096 8192 2048
4096 8192 2048
4096 8192 2048
3072 4096 2048
2048 4096 2048
2048 4096 2048
1088 2048 1024
1088 2048 1024
3072 4096 2048
3072 4096 2048
3072 4096 2048
NSA 6600
NSA 5600
NSA 4600
NSA 3600
NSA 2600
Routes
2048 4096 2048
2048 4096 2048
1088 2048 1024
1088 2048 1024
1088 2048 1024
NAT PoliciesStatic Dynamic Static Dynamic

About NAT Load Balancing

Network Address Translation (NAT) and Load Balancing (LB) provide the ability to balance incoming traffic across multiple, similar network resources. Do not confuse this with the Failover & Load Balancing feature in SonicOS. While both features can be used in conjunction, Failover & Load Balancing is used to actively monitor WAN connections and act accordingly on failure/recovery of the WAN interface(s), and NAT LB is primarily used to balance incoming traffic.
Load Balancing distributes traffic among similar network resources so that no single server becomes overwhelmed, allowing for reliability and redundancy. If one server becomes unavailable, traffic is routed to available resources, providing maximum up-time.
This details how to configure the necessary NAT, load balancing, health checks, logging, and firewall rules to allow systems from the public Internet to access a virtual IP that maps to one or more internal systems, such as web servers, FTP servers, or SonicWall SMA appliances. This virtual can be independent of the firewall or it can be shared, assuming the firewall itself is not using the port(s) in question.
NAT Policy
26
NOTE: The load balancing capability in SonicOS, while fairly basic, satisfies the requirements for many
network deployments. Network administrators with environments needing more granular load balancing, persistence and health-check mechanisms are advised to use a dedicated third-party load­balancing appliance.
Topics:
l Determining the NAT LB Method to Use l Caveats l How Load Balancing Algorithms are Applied l Sticky IP Algorithm Examples

Determining the NAT LB Method to Use

DETERMINE WHICH NAT LB METHOD TO USE
Requirement Deployment Example NAT LB Method
Distribute load on server equally without need for
External/Internal servers (such as, web or FTP)
persistence
Indiscriminate load balancing without need for persistence
Requires persistence of client connection
External/Internal servers (such as, web or FTP)
E-commerce site, Email Security, SonicWall SMA appliance
(Any publicly accessible servers requiring persistence)
Precise control of remap of source network to a destination range
Precise control of remap of source network and destination
LAN to DMZ Servers
Email Security, SonicWall SMA appliance
Internal Servers (such as, Intranets or Extranets)
network

Caveats

l Only two health-check mechanisms (ICMP ping and TCP socket open)
l No higher-layer persistence mechanisms (Sticky IP only)
l No “sorry-server” mechanism if all servers in group are not responding
l No “round robin with persistence” mechanism
l No “weighted round robin” mechanism
l No method for detecting if resource is strained
Round Robin
Random Distribution
Sticky IP
Block Remap
Symmetrical Remap
While there is no limit to the number of internal resources that the SonicWall network security appliance can load-balance to and there is no limit to the number of hosts it can monitor, abnormally large load-balancing groups (25+ resources) may impact performance.
NAT Policy
27

How Load Balancing Algorithms are Applied

Round Robin Source Address connects to Destination Address alternately
Random Distribution
Sticky IP Source Address connects to same Destination Address
Block Remap Source network is divided by size of the Destination pool to create logical
Symmetrical Remap Source Address maps to Destination Address (for example, 10.1.1.10 >
Source Address connects to Destination Address randomly
segments
192.168.60.10)

Sticky IP Algorithm Examples

Source IP is modulo with the size of the server cluster to determine the server to remap it to. The following two examples show how the Sticky IP algorithm works:
l Example One - Mapping to a Network
l Example Two - Mapping to a IP Address Range
Example One - Mapping to a Network
192.168.0.2 to 192.168.0.4
Translated Destination = 10.50.165.0/30 (Network)
Packet Source IP = 192.168.0.2
192.168.0.2 = C0A80002 = 3232235522 = 11000000101010000000000000000010
(IP -> Hex -> Dec -> Binary)
Sticky IP Formula = Packet Src IP = 3232235522 [modulo] TransDest Size = 2 = 3232235522 [modulo] 2 = 0 (2 divides into numerator evenly. There is no remainder, thus 0)
Sticky IP Formula yields offset of 0.
Destination remapping = 10.50.165.1
Example Two - Mapping to an IP Address Range
192.168.0.2 to 192.168.0.4
Translated Destination = 10.50.165.1 - 10.50.165.3 (Range)
Packet Src IP = 192.168.0.2
192.168.0.2 = C0A80002 = 3232235522 = 11000000101010000000000000000010
(IP -> Hex -> Dec -> Binary)
Sticky IP Formula = Packet Src IP = 3232235522 [modulo] TransDest Size = 3
= 3232235522 [modulo] 4 = 1077411840.6666667 - 1077411840
NAT Policy
28
= 0.6666667 * 3 = 2
Sticky IP Formula yields offset of 2.
Destination remapping to 10.50.165.3

About NAT64

SonicOS supports the NAT64 feature that enables an IPv6-only client to contact an IPv4-only server through an IPv6-to-IPv4 translation device known as a NAT64 translator. NAT64 provides the ability to access legacy IPv4-only servers from IPv6 networks; a SonicWall with NAT64 is placed as the intermediary router.
As a NAT64 translator, SonicOS allows an IPv6-only client from any zone to initiate communication to an IPv4-only server with proper route configuration. SonicOS maps IPv6 addresses to IPv4 addresses so IPv6 traffic changes to IPv4 traffic and vice versa. IPv6 address pools (represented as address objects) and IPv4 address pools are created to allow mapping by translating packet headers between IPv6 and IPv4. The IPv4 addresses of IPv4 hosts are translated to and from IPv6 addresses by using an IPv6 prefix configured in SonicOS.
The DNS64 translator enables NAT64. Either an IPv6 client must configure a DNS64 server or the DNS server address the IPv6 client gets automatically from the gateway must be a DNS64 server. The DNS64 server of an IPv6-only client creates AAAA (IPv6) records with A (IPv4) records. SonicOS does not act as a DNS64 server.
IMPORTANT: Currently, NAT64:
l Only translates Unicast packets carrying TCP, UDP, and ICMP traffic.
l Supports FTP and TFTP application-layer protocol streams, but does not support H.323, MSN,
Oracle, PPTP, RTSP, and RealAudio application-layer protocol streams.
l Does not support IPv4-initiated communications to a subset of the IPv6 hosts.
l Does not support Stateful High Availability.
For NAT64 traffic matches, two mixed connection caches are created. Thus, the capacity for NAT64 connection caches is half that for pure IPv4 or IPv6 connections.

Use of Pref64::/n

Pref64::/n is an IPv6 prefix used on the access network for protocol translation between IPv6 and IPv4. The Pref64::/n prefix is configured in SonicOS. A well-known Pref64::/n prefix, 64:ff9b::/96, is automatically created by SonicOS.
Pref64::/n defines a network that can go from an IPv6-only client through NAT64 to an IPv4-only client. In SonicOS, an address object of Network type can be configured to include all addresses with Pref64::/n. This address object represents all IPv6 clients that can do NAT64.
The DNS64 server uses Pref64::/n to judge if an IPv6 address is an IPv4-embedded IPv6 address by comparing the first n bits with Pref64::/n. DNS64 creates IPv4-embedded IPv6 addresses by synthesizing Pref64::/n with IPv4 address records and sending a DNS response to IPv6-only clients.
For configuring a Pref64::/n address object, see Default Pref64 Address Object.
29
NAT Policy

About FQDN-based NAT

SonicOS/X supports NAT policies using FQDN Address Objects for the original source/destination.
Use cases include:
l Specifying public IP addresses with FQDN to a local server
l Specifying a public server with FQDN for consistency across replacement with a server that has a
known IP address
l Routing traffic from/to a FQDN to have a source IP address other than the outbound interface IP.
The following functionality is supported:
l The original source/destination can be a pure FQDN or an address group with FQDN(s) and other
IPv4 or IPv6 addresses, depending on the IP version of the NAT policy. A new FQDN address object can be directly created from the POLICY | Rules and Policies > NAT Policy page.
FQDN is not supported for the translated source/destination.
l IP version options are provided for a NAT policy only if the version is ambiguous based on settings for
original/translated source/destination fields. Either IPv4 or IPv6 must be selected.
l Mousing over an FQDN object of a NAT policy displays the IP addresses in the same IP version as
the NAT policy.
l When NAT translation is performed, only the IP addresses in the NAT's IP version are considered.
l The Advanced page is disabled if FQDN is used in either or both the original source/destination
fields.
If probing is enabled and/or the NAT method is configured to a non-default value such as Sticky IP, neither of original source/destination address objects can be modified to contain an FQDN.
l FQDN based NAT policies are supported in High Availability configurations.

About Source MAC Address Override

An internal option has been added that allows you to replace the source MAC address of an outbound or port-forwarded packet with the MAC address specified in a NAT policy. By default, without this option, the MAC address of the output interface is used as the source MAC address of the packet.
This feature is also disabled by default, but can be enabled using an internal setting. Contact SonicWall Technical Support for information about internal settings.

Viewing NAT Policy Entries

Topics:
l Changing the Display l Filtering the Display
NAT Policy
30
Loading...
+ 71 hidden pages
Buy Points How it Works FAQ Contact Us Questions and Suggestions Privacy Policy Cookie Policy Terms of Use