SonicOS Enhanced 4.0 Feature Guidesoftware.sonicwall.com/firmware/beta/documentation/Sonic...SonicWALL Early Field Trial (EFT) Draft - Internal Use Only Application Firewall Overview

SonicOS Enhanced 4.0 Feature Guide

Document ScopeThis document describes the major features in the SonicOS Enhanced 4.0 firmware release.

This document contains the following sections:

• “Application Firewall Overview” section on page 2

• “Packet Trace Overview” section on page 10

• “RF Management Overview” section on page 13

• “Single Sign-On Overview” section on page 14

• “SSL Control Overview” section on page 21

• “Stateful Failover Overview” section on page 29

• “SonicPoint VAP Overview” section on page 32

• “Dynamic Address Objects (DAO) Overview” section on page 36

• “Layer 2 Bridge Mode Overview” section on page 40

• “Wireless WAN Overview” section on page 56

For a glossary of terms, refer to the “Glossary” section on page 64.

1 SonicWALL SonicOS 4.0 Enhanced Feature Guide

S o n i c WA L L E a r l y F i e l d T r i a l ( E F T ) D r a f t - I n t e r n a l U s e O n l yApplication Firewall Overview

Application Firewall OverviewThis section provides an introduction to the SonicWALL SonicOS Enhanced 4.0 application firewall feature. This section contains the following subsections:

• “What is Application Firewall?” on page 2

• “Benefits” on page 3

• “How Does Application Firewall Work?” on page 4

• “Platforms” on page 9

• “Supported Standards” on page 10

What is Application Firewall?Application firewall is a set of application-specific policies that gives you granular control over network traffic on the level of users, email users, and IP-subnets. The primary functionality of this application-layer access control feature is to regulate Web browsing, file transfer, email, and email attachments.

Application firewall’s digital rights management component provides the ability to scan files and documents for content and keywords. Using application firewall, you can restrict transfer of certain file names, file types, email attachments, attachment types, email with certain subjects, and email or attachments with certain keywords or byte patterns. You can deny internal or external network access based on various criteria.

Based on SonicWALL’s Deep Packet Inspection technology, application firewall also features intelligent prevention functionality which allows you to create custom, policy-based actions. Examples of custom actions include the following:

• Disabling an attachment

• Sending a custom block page

• Sending a custom email reply

• Redirecting an HTTP request

• Sending a custom FTP reply over an FTP control channel

While application firewall primarily provides application level access control and digital rights management functionality, it also includes the ability to create pure custom IPS signatures. You can create a custom policy that matches any protocol you wish, by matching a unique piece of the protocol header.



Application firewall provides excellent functionality for preventing the accidental transfer of proprietary documents. For example, when using the automatic address completion feature of Outlook Exchange, it is a common occurrence for a popular name to complete to the wrong address. See Figure 1 for an example.

Figure 1 Outlook Exchange Automatic Address Completion

BenefitsApplication firewall functionality can be compared to three main categories of products:

• Standalone proxy appliances

• Application proxies integrated into firewall VPN appliances

• Standalone IPS appliances with custom signature support

Standalone proxy appliances are typically designed to provide granular access control for a specific protocol. SonicWALL application firewall provides granular, application level access control across multiple protocols, including HTTP, FTP, SMTP, and POP3. Because application firewall runs on your SonicWALL firewall, you can use it to control both inbound and outbound traffic, unlike a dedicated proxy appliance that is typically deployed in only one direction. Application firewall provides better performance and scalability than a dedicated proxy appliance because it is based on SonicWALL’s proprietary Deep Packet Inspection technology.

Today’s integrated application proxies do not provide granular, application level access control and digital rights management functionality. As with dedicated proxy appliances, SonicWALL application firewall provides much higher performance and far greater scalability than integrated application proxy solutions.

While some standalone IPS appliances provide protocol decoding support, none of these products supports granular, application level access control and digital rights management functionality.

In comparing application firewall to SonicWALL Email Security, there are benefits to using either. Email Security only works with SMTP, but it has a very rich policy space. Application firewall works with SMTP, POP3, HTTP, FTP and other protocols, is integrated into SonicOS on the firewall, and has higher performance than Email Security. However, application firewall does not offer all the policy options for SMTP that are provided by Email Security.

3SonicWALL SonicOS 4.0 Enhanced Feature Guide


How Does Application Firewall Work?Application firewall scans application layer network traffic as it passes through the gateway and looks for content that matches configured keywords. When it finds a match, it performs the configured action. It can match text or binary content. When you configure application firewall, you create policies that define the type of applications to scan, the direction, the content or keywords to match, optionally the user or domain to match, and the action to perform.

The following sections describe the four main components of application firewall:

• “Policies” on page 4

• “Application Objects” on page 5

• “Actions” on page 7

• “Email User Objects” on page 8

PoliciesYou can use application firewall to create custom policies to control specific aspects of traffic on your network. A policy is a set of application objects, properties, and specific prevention actions.When you create a policy, you first create an application object, then select and optionally customize an action, then reference these when you create the policy. The Policy Settings screen is shown in Figure 2.

Figure 2 Policy Settings screen



Some examples of policies include:

• Disable .exe and .vbs email attachments

• Do not allow the Mozilla browser on outgoing HTTP connections

• Do not allow outgoing email or MS Word attachments with the keywords “SonicWALL Confidential”, except from the CEO and CFO

• Do not allow outgoing email that includes a graphic or watermark found in all confidential documents

When you create a policy, you select a policy type. Each policy type specifies the values or value types that are valid for the source, destination, application object type, and action fields in the policy. You can further define the policy to include or exclude specific users or groups, select a schedule, turn on logging, and specify the connection side as well as basic or advanced direction types. A basic direction type simply indicates inbound or outbound. An advanced direction type allows zone to zone direction configuration, such as from the LAN to the WAN.

Application ObjectsApplication objects represent the set of conditions which must be matched in order for actions to take place. This includes the object type, the match type (exact, partial, prefix, or suffix), the input representation (text or hexadecimal), and the actual content to match.

Hexadecimal input representation is used to match binary content such as executable files, while text input representation is used to match things like file or email content. You can also use hexadecimal input representation for binary content found in a graphic image. You could also use text input representation to match the same graphic if it contains a certain string in one of its properties fields.

You can see the available types of application objects in a drop-down list in the Application Objects Setting screen:



In the Application Object screen, you can add multiple entries to create a list of content elements to match. All content that you provide in an application object is case-insensitive for matching purposes. A hexadecimal representation is used to match binary content. You can use a network protocol analyzer like Wireshark (formerly Ethereal) to obtain hex format for binary files.

You can use the Load From File button to import content from predefined text files that contain multiple entries for an application object to match. Each entry in the file must be on its own line.

Multiple entries, either from a text file or entered manually, are displayed in the List area. List entries are matched using the logical OR, so if any item in the list is matched, the action for the policy is executed.

The maximum number of application objects is 500. An application object can include a total of no more than 8000 characters. If each element within an application object contains approximately 30 characters, then you can enter about 260 elements.

Negative Matching

Negative matching provides an alternate way to specify which content to block. You can enable negative matching in an application object when you want to block everything except a particular type of content. When you use the object in a policy, the policy will execute actions based on absence of the content specified in the application object.

Although all application firewall policies are DENY policies, you can simulate an ALLOW policy by using negative matching. For instance, you can allow email .txt attachments and block attachments of all other file types. Or you can allow a few types, and block all others.

Not all application object types can utilize negative matching. For those that can, you will see the Enable Negative Matching checkbox on the Application Object Settings screen.

Figure 3 Enable Negative Matching Checkbox



ActionsActions define how the application firewall policy reacts to matching events. You can choose a customizable action or select one of three predefined actions. The Action Settings dialog box is shown below. Note that only the six customizable actions are available for editing. The three predefined actions cannot be edited or deleted. When you create a policy, the Policy Settings dialog box provides a way for you to select from the predefined actions along with any customized actions that you have defined.

Figure 4 Action Settings



Email User ObjectsApplication firewall allows creation of custom email user lists as email user objects. You can only use email user objects in an SMTP client policy configuration. Email user objects can represent either individual users or the entire domain. You can also create an email user object that represents a group by adding a list of individual users to the object. This provides a way to easily include or exclude a group of users when creating an SMTP client policy.

For example, you can create an email user object to represent the support group:

Figure 5 Email User Object

After you define the group in an email user object, you can create an SMTP client policy that includes or excludes the group.



In Figure 6, the policy excludes the support group from a policy that prevents executable files from being attached to outgoing email. You can use the email user object in either the MAIL FROM or RCPT TO fields of the SMTP client policy. The MAIL FROM field refers to the sender of the email. The RCPT TO field refers to the intended recipient.

Although application firewall cannot extract group members directly from Outlook Exchange or similar applications, you can use the member lists in Outlook to create a text file that lists the group members. Then when you create an email user object for this group, you can use the Load From File button to import the list from your text file. Be sure that each email address is on a line by itself in the text file.

Figure 6 SMTP Client Policy

PlatformsApplication firewall is currently available on the PRO 4060, PRO 4100 and PRO 5060 SonicWALL security appliances running SonicOS Enhanced 4.0. The configuration maximums vary depending on the hardware model, as shown in Table 1.

Table 1 Maximum Configuration per Model

Model Max Policies

Max Application Objects

Max Actions

Max Email User Objects

Max Email Concurrent Connections

PRO 4060 50 50 50 50 20000

PRO 4100 100 100 100 100 64000

PRO 5060 300 300 300 300 128000


S o n i c WA L L E a r l y F i e l d T r i a l ( E F T ) D r a f t - I n t e r n a l U s e O n l yPacket Trace Overview

Supported Standards SonicOS Enhanced 4.0 application firewall feature supports the following protocols:

• HTTP

• FTP

• SMTP

• POP3

• Other protocols - generic TCP streams and UDP packet inspection

You can match any protocol by creating a custom application object.

Packet Trace OverviewThis section provides an introduction to the SonicWALL SonicOS Enhanced packet trace feature. This section contains the following subsections:

• “What is Packet Trace?” section on page 10

• “Benefits” section on page 11

• “How Does Packet Trace Work?” section on page 11

• “Platforms” section on page 13

What is Packet Trace?Packet trace is a mechanism that allows you to capture and examine the contents of individual data packets that traverse your SonicWALL firewall appliance. The captured packets contain both data and addressing information. The captured addressing information from the packet header includes the following:

• Interface identification

• MAC addresses

• Ethernet type

• Internet Protocol (IP) type

• Source and destination IP addresses

• Port numbers

• L2TP payload details

• PPP negotiations details

You can configure the packet trace feature in the SonicOS Enhanced user interface (UI). The UI provides a way to configure the capture criteria, display settings, and file export settings, and displays the captured packets.



BenefitsThe SonicOS Enhanced packet trace feature provides the functionality and flexibility that you need to examine network traffic without the use of external utilities, such as Wireshark (formerly known as Ethereal). SonicOS Enhanced 3.6 includes the following improvements in the packet trace tool:

• Capture control mechanism with improved granularity for custom filtering

• Display filter settings independent from capture filter settings

• Packet status values that indicate whether the packet was dropped, forwarded, generated, or consumed by the firewall

• Three-window output in the UI:

– List of packets

– Decoded output of selected packet

– Hexadecimal dump of selected packet

• Export capabilities include text or HTML format with hex dump of packets, plus CAP file format

• Automatic export to FTP server when the buffer is full

• Bidirectional packet capture based on IP address and port

• Configurable wrap-around of packet capture buffer when full

How Does Packet Trace Work?As an administrator, you can configure the general settings, capture filter, display filter, advanced settings, and FTP settings of the packet trace tool. As network packets enter the packet capture subsystem, the capture filter settings are applied and the resulting packets are written to the capture buffer. The display filter settings are applied as you view the buffer contents in the UI. You can log the capture buffer to view in the UI, or you can configure automatic transfer to the FTP server when the buffer is full.



Default settings are provided so that you can start using packet trace without configuring it first. The basic functionality is as follows:

Refer to the figure below to see a high level view of the packet capture subsystem. This shows the different filters and how they are applied.

Figure 7 High level packet capture on subsystem view

Start: Click Start to begin capturing all packets except those used for communication between the SonicWALL appliance and the UI on your console system.

Stop: Click Stop to stop the packet trace.

Reset: Click Reset to clear the status counters that are displayed at the top of the Packet Trace page.

Refresh: Click Refresh to display new buffer data in the Captured Packets window. You can then click any packet in the window to display its header information and data in the Packet Detail and Hex Dump windows.

Export As: Display or save a snapshot of the current buffer in the file format that you select from the drop-down list. Saved files are placed on your local management system (where the UI is running). Choose from the following formats:

• CAP - Select CAP format if you want to view the data with the Wireshark (formerly Ethereal) network protocol analyzer. This is also known as libcap or pcap format. A dialog box allows you to open the buffer file with Wireshark, or save it to your local hard drive with the extension .pcap.

• HTML - Select HTML to view the data with a browser. You can use File > Save As to save a copy of the buffer to your hard drive.

• Text - Select Text to view the data in a text editor. A dialog box allows you to open the buffer file with the registered text editor, or save it to your local hard drive with the extension .wri.


S o n i c WA L L E a r l y F i e l d T r i a l ( E F T ) D r a f t - I n t e r n a l U s e O n l yRF Management Overview

PlatformsThe updated packet trace feature is available on the SonicWALL TZ 190 running SonicOS Enhanced release 3.6 or later. It will be widely available on all platforms running later releases of SonicOS Enhanced, except for SonicPoint.

RF Management OverviewThe following section provides a brief overview of the RF Management feature found on SonicWALL security appliances running SonicOS 4.0 or higher. This section contains the following subsections:

• “Why RF Management?” section on page 13


• “Deployment Prerequisites” section on page 14

Why RF Management?Radio Frequency (RF) technology used in today’s 802.11-based wireless networking devices poses an attractive target for intruders. If left un-managed, RF devices can leave your wireless (and wired) network open to a variety of outside threats, from Denial of Service (DoS) to network security breaches.

In order to help secure your SonicPoint Wireless Access Point (AP) stations, SonicWALL takes a closer look at these threats, using direct RF management capabilities to detect threats without interrupting the current operation of your wireless or wired network.

BenefitsSonicWALL RF Management provides real-time threat monitoring and management of SonicPoint radio frequency traffic. In addition to its real-time threat management capabilities, SonicWALL RF Management provides network administrators a system for centralized collection of RF threats and traffic statistics; offering a way to easily manage RF capabilities directly from the SonicWALL security appliance gateway.

SonicWALL RF Management is:

• Real-Time - View logged information as it happens

• Transparent - No need to halt legitimate network traffic when managing threats

• Comprehensive - Provides detection of countless types of RF threats, including:

– Long Duration Attacks

– Management Frame Flood

– NullProbe Request

– Broadcasting Deauthentication

– Valid Station with Invalid SSID

– Wellenreiter/NetStumbler Detection

– Ad-Hoc Station Detection

– Unassociated Station

– EAPOL Packet Flood

– Weak WEP IV


S o n i c WA L L E a r l y F i e l d T r i a l ( E F T ) D r a f t - I n t e r n a l U s e O n l ySingle Sign-On Overview

Deployment PrerequisitesThe following prerequisites must be met in order to deploy SonicWALL RF Management on your network:

• A SonicWALL PRO 4060, 4100 or 5060 appliance

• SonicOS 4.0 or above installed on one of the above SonicWALL PRO series appliances

• One or more SonicWALL SonicPoint(s), provisioned by your SonicWALL PRO series appliance

Single Sign-On OverviewThis section provides an introduction to the SonicWALL SonicOS Enhanced 4.0 Single Sign-on feature. This section contains the following subsections:

• “What Is Single Sign-On?” section on page 15


• “How Does Single Sign-On Work?” section on page 17



What Is Single Sign-On?Single Sign-on (SSO) is a transparent user authentication mechanism that provides privileged access to multiple network resources with a single workstation login. SonicWALL PRO and TZ series security appliances (SonicWALL security appliances) running SonicOS Enhanced 4.0 provides SSO functionality using the SonicWALL Centralized Identification Agent (CIA) to identify user activity based on workstation IP addresses. SSO is configured in the Users > Settings page of the SonicOS management interface. SSO is separate from the Authentication method for login settings, which can be used at the same time for authentication of VPN/L2TP client users or administrative users.

SonicWALL CIA identifies users by IP address using a SonicWALL ADConnector-compatible protocol and automatically determines when a user has logged out to prevent unauthorized access. Based on data from SonicWALL CIA, the SonicWALL security appliance queries LDAP or the local database to determine group membership. Memberships are matched against policy, and based on user privileges, access is granted or denied. The configured inactivity and session limit timers apply with SSO, though users who are logged out are automatically and transparently logged back in when they send further traffic. Users logged into a workstation directly but not logged into the domain will not be authenticated. For users that are not logged into the domain, the following screen will display, indicating that a manual login will be required for further authentication.

Figure 8 Authentication Required

Users that are identified but lack the group memberships required by the configured policy rules are redirected to the Access Barred page.

Figure 9 Access Denied



BenefitsSonicWALL SSO is a reliable and time-saving feature that utilizes a single login to provide access to multiple network resources based on administrator-configured group memberships and policy matching. SonicWALL SSO is transparent to end users and requires minimal administrator configuration.

By automatically determining when users have logged in or out based on workstation IP address traffic, SonicWALL SSO is secure and hands-free. SSO authentication is designed to operate with any external agent that can return the identity of a user at a specific IP address using a SonicWALL ADConnector-compatible protocol.

SonicWALL SSO works for any area on the SonicWALL security appliances that uses user-level authentication, including Content Filtering Service (CFS), Firewall Access Rules, group membership and inheritance, and security services (IPS, GAV, SPY and Application firewall) inclusion/exclusion lists.

Other benefits of SonicWALL SSO include:

• Ease of use — Users only need to sign in once to gain automatic access to multiple resources.

• Improved user experience — Windows domain credentials can be used to authenticate a user for any traffic type without logging in using a Web browser.

• Transparency to users — Not required to re-enter use name and password for authentication.

• Secure communication — Shared key encryption for data transmission protection.

• SonicWALL CIA can be installed on any workstation on the LAN.

• Login mechanism works with any protocol, not just HTTP.

Supported Standards SonicOS Enhanced 4.0 SSO feature supports LDAP and local database protocols.

SonicWALL SSO requires that SonicWALL CIA be installed on any workstation within your Windows domain that can reach clients directly using a static IP or through a VPN path. The following requirements must be met in order to run the CIA:

• Port 2258 must be open. The firewall uses UDP port 2258 by default to communicate with SonicWALL CIA.

• Windows 32 or XP, with latest service pack.

• .NET 1.1 framework

• Net API or WMI



How Does Single Sign-On Work?SonicWALL SSO requires minimal administrator configuration and is a transparent to the user. There are six steps involved in SonicWALL SSO authentication, as illustrated in Figure 10.

Figure 10 SonicWALL Single Sign-On Process

SonicWALL SSO authentication is initiated when user traffic passes through a SonicWALL security appliance, for example, when a user accesses the Internet. The sent packets are temporarily blocked and saved while the SonicWALL security appliance sends a “User Name” request and workstation IP address to the authorization agent running CIA.

The authorization agent running CIA provides the SonicWALL security appliance with the username currently logged into the workstation. A User IP Table entry is created for the logged in user, similar to RADIUS and LDAP.

Once a user has been identified, the SonicWALL security appliance queries LDAP or a local database (based on administrator configuration) to find user group memberships, match them against policy, and grant or restrict access accordingly. Upon successful completion of the login sequence, the saved packets are sent on. If packets are received from the same source address before the sequence is completed, only the most recent packet will be saved.



User names are returned from the authorization agent running CIA in the format <domain>/<user-name>. For locally configured user groups, the user name can be configured to be the full name returned from the authorization agent running CIA (configuring the names in the SonicWALL security appliance local user database to match) or a simple user name with the domain component stripped off (default).

For the LDAP protocol, the <domain>/<user-name> format is converted to an LDAP distinguished name by creating an LDAP search for an object of class “domain” with a “dc” (domain component) attribute that matches the domain name. If one is found, then its distinguished name will be used as the directory sub-tree to search for the user’s object. For example, if the user name is returned as “SV/bob” then a search for an object with “objectClass=domain” and “dc=SV” will be performed. If that returns an object with distinguished name “dc=sv,dc=us,dc=sonicwall,dc=com,” then a search under that directory sub-tree will be created for (in the Active Directory case) an object with “objectClass=user” and “sAMAccountName=bob”. If no domain object is found, then the search for the user object will be made from the top of the directory tree.

Once a domain object has been found, the information is saved to avoid searching for the same object. If an attempt to locate a user in a saved domain fails, the saved domain information will be deleted and another search for the domain object will be made.

The SonicWALL security appliance polls the authorization agent running CIA at a configurable rate to determine when a user has logged out. Configurable user session limits, inactivity timers, and User Name request polls are other methods to determine user logout status. Upon user logout, the authentication agent running CIA sends a User Logged Out response to the SonicWALL security appliance, confirming the user has been logged out and terminating the SSO session.



How Does SonicWALL CIA Work?The SonicWALL CIA can be installed on any workstation with a Windows domain that can communicate with clients and the SonicWALL security appliance directly using the IP address or using a path, such as VPN. For installation instructions for the SonicWALL CIA, refer to the Single Sign-On Feature Module. SonicWALL CIA only communicates with clients and the SonicWALL security appliance. SonicWALL CIA uses a shared key for encryption of messages between the CIA and the SonicWALL security appliance. The shared key is generated in the CIA and the key entered in the SonicWALL security appliance during SSO configuration must match the CIA-generated key exactly.

Figure 11 SonicWALL CIA Process

The SonicWALL security appliance queries the SonicWALL CIA over the default port 2258. The CIA then communicates between the client and the SonicWALL security appliance to determine the client’s user ID. The SonicWALL CIA is polled, at a rate that is configurable by the administrator, by the SonicWALL security appliance to continually confirm a user’s login status.



Logging Levels

SonicWALL CIA sends log event messages to the Windows Event Log based on administrator-selected logging levels. For instructions on configuring logging levels, refer to the Single Sign-On Feature Module.

The following is a list of possible log event messages from SonicWALL CIA:

• User login denied - not allowed by policy rule: The user has been identified and does not belong to any user groups allowed by the policy blocking the user’s traffic.

• User login denied - not found locally: The user has not been found locally, and Allow only users listed locally is selected in the SonicWALL security appliance.

• User login denied - CIA agent timeout: Attempts to contact the SonicWALL CIA have timed out.

• User login denied - CIA configuration error: There CIA is not properly configured to allow access for this user.

• User login denied - CIA communication problem: There is a problem communicating with the workstation running the SonicWALL CIA.

• User login denied - CIA agent name resolution failed: SonicWALL CIA is unable to resolve the user name.

• CIA returned user name too long: The user name is too long.

• CIA returned domain name too long: The domain name is too long.

Note The notes field of CIA-reported log messages will contain the text <domain/user-name>, authentication by CIA.


S o n i c WA L L E a r l y F i e l d T r i a l ( E F T ) D r a f t - I n t e r n a l U s e O n l ySSL Control Overview

SSL Control OverviewThis section provides an introduction to the SSL Control feature. This section contains the following subsections:

• “What is SSL Control?” section on page 21

• “How does SSL Control Work?” section on page 22

• “SSL Control Features” section on page 22

• “SSL Control Concepts” section on page 25

• “Caveats and Advisories” section on page 28

What is SSL Control?SonicOS Enhanced 4.0 introduces SSL Control, a system for providing visibility into the handshake of SSL sessions, and a method for constructing policies to control the establishment of SSL connections. SSL (Secure Sockets Layer) is the dominant standard for the encryption of TCP based network communications, with its most common and well-known application being HTTPS (HTTP over SSL). SSL provides digital certificate-based endpoint identification, and cryptographic and digest-based confidentiality to network communications. Figure 12 on page 21 provides an illustration of the steps in SSL Control.

Figure 12 SSL Control



How does SSL Control Work?An effect of the security provided by SSL is that all payload is obscured, including the URL (Uniform Resource Locator, for example, https://www.mysonicwall.com) being requested by a client when establishing an HTTPS session. This is due to the fact that HTTP is transported within the encrypted SSL tunnel when using HTTPS. It is not until the SSL session is established (step 14, figure 1) that the actual target resource (www.mysonicwall.com) is requested by the client, but since the SSL session is already established, no inspection of the session data by the firewall or any other intermediate device is possible. As a result, URL based content filtering systems cannot consider the request to determine permissibility in any way other than by IP address.

While IP address based filtering does not work well for unencrypted HTTP because of the efficiency and popularity of Host-header based virtual hosting (defined in Key Concepts below), IP filtering can work effectively for HTTPS due to the rarity of Host-header based HTTPS sites. But this trust relies on the integrity of the HTTPS server operator, and assumes that SSL is not being used for deceptive purposes.

For the most part, SSL is employed legitimately, being used to secure sensitive communications, such as online shopping or banking, or any session where there is an exchange of personal or valuable information. The ever decreasing cost and complexity of SSL, however, has also spurred the growth of more dubious applications of SSL, designed primarily for the purposes of obfuscation or concealment rather than security.

An increasingly common camouflage is the use of SSL encrypted web-based proxy servers for the purpose of hiding browsing details, and bypassing content filters. While it is simple to block well known HTTPS proxy services of this sort by their IP address, it is virtually impossible to block the thousands of privately-hosted proxy servers that are readily available through a simple web-search. The challenge is not the ever-increasing number of such services, but rather their unpredictable nature. Since these services are often hosted on home networks using dynamically addressed DSL and cable modem connections, the targets are constantly moving. Trying to block an unknown SSL target would require blocking all SSL traffic, which is practically infeasible.

SSL Control provides a number of methods to address this challenge by arming the security administrator with the ability to dissect and apply policy based controls to SSL session establishment. While the current implementation does not decode the SSL application data, it does allow for gateway-based identification and disallowance of suspicious SSL traffic.

SSL Control FeaturesTable 1 on page 21 provides a list of SSL Control features.



Figure 13 SSL Control Features

Feature BenefitCommon Name- based White/Black Lists

The administrator can define lists of explicitly allowed or denied certificate subject common names (described in Key Concepts). Entries will be matched on substrings, for example, a blacklist entry for “prox” will match “www.megaproxy.com”, “www.proxify.com” and “proxify.net”. This allows the administrator to easily block all SSL exchanges employing certificates issued to subjects with potentially objectionable names. Inversely, the administrator can easily authorize all certificates within an organization by white listing a common substring for the organization. Each list can contain up to 1,024 entries.

Since the evaluation is performed on the subject common-name embedded in the certificate, even if the client attempts to conceal access to these sites by using an alternative hostname or even an IP address, the subject will always be detected in the certificate, and policy will be applied.

Self-Signed Certificate Control

It is common practice for legitimate sites secured by SSL to use certificates issued by well-known certificate authorities, as this is the foundation of trust within SSL. It is almost equally common for network appliances secured by SSL (such as SonicWALL security appliances) to use self-signed certificates for their default method of security. So while self-signed certificates in closed-environments are not suspicious, the use of self-signed certificates by publicly or commercially available sites is. A public site using a self-signed certificate is often an indication that SSL is being used strictly for encryption rather than for trust and identification. While not absolutely incriminating, this sometimes suggests that concealment is the goal, as is commonly the case for SSL encrypted proxy sites.

The ability to set a policy to block self-signed certificates allows security administrators to protect against this potential exposure. To prevent discontinuity of communications to known/trusted SSL sites using self-signed certificates, the whitelist feature can be used for explicit allowance.

Untrusted Certificate Authority Control

Like the use of self-signed certificates, encountering a certificate issued by an untrusted CA isn’t an absolute indication of disreputable obscuration, but it does suggest questionable trust.

SSL Control can compare the issuer of the certificate in SSL exchanges against the certificates in the SonicWALL’s certificate store. The certificate store contains approximately 100 well-known CA certificates, exactly like today’s web-browsers. If SSL Control encounters a certificate that was issued by a CA not in its certificate store, it can disallow the SSL connection.

For organizations running their own private certificate authorities, the private CA certificate can easily be imported into the SonicWALL’s certificate store to recognize the private CA as trusted. The store can hold up to 256 certificates.

SSL version, Cipher Strength, and Certificate Validity Control

SSL Control provides additional management of SSL sessions based on characteristics of the negotiation, including the ability to disallow the potentially exploitable SSLv2, the ability to disallow weak encryption (ciphers less than 64 bits), and the ability to disallow SSL negotiations where a certificate’s date ranges are invalid. This enables the administrator to create a rigidly secure environment for network users, eliminating exposure to risk through unseen cryptographic weaknesses, or through disregard for or misunderstanding of security warnings.



Zone-Based Application

SSL Control is applied at the zone level, allowing the administrator to enforce SSL policy on the network. When SSL Control is enabled on the zone, the SonicWALL looks for Client Hellos sent from clients on that zone through the SonicWALL will trigger inspection. The SonicWALL then looks for the Server Hello and Certificate that is sent in response for evaluation against the configured policy. Enabling SSL Control on the LAN Zone, for example, will inspect all SSL traffic initiated by clients on the LAN to any destination zone.

Configurable Actions and Event Notifications

When SSL Control detects a policy violation, it can log the event and block the connection, or it can simply log the event while allowing the connection to proceed.

Feature Benefit



SSL Control Concepts • SSL - SSL, or Secure Sockets Layer, is a network security mechanism introduced by Netscape in 1995.

SSL was designed “to provide privacy between two communicating applications (a client and a server) … [and also] to authenticate the server, and optionally the client.” SSL's most popular application is HTTPS, designated by a URL beginning with https:// rather than simply http://, and it is recognized as the standard method of encrypting web traffic on the Internet. An SSL HTTP transfer typically uses TCP port 443, whereas a regular HTTP transfer uses TCP port 80. Although HTTPS is what SSL is best known for, SSL is not limited to securing HTTP, but can also be used to secure other TCP protocols such as SMTP, POP3, IMAP, and LDAP. SSL session establishment occurs as described in Figure 12 on page 21.

Figure 14 SSL Session Establishment



• SSLv2 – The earliest version of SSL still in common use. SSLv2 was found to have a number of weaknesses, limitations, and theoretical deficiencies (comparatively noted in the SSLv3 entry), and is looked upon with scorn, disdain, and righteous indignation by security purists.

• SSLv3 – SSLv3 was designed to maintain backward compatibility with SSLv2, while adding the following enhancements:

– Alternate key exchange methods, including Diffie-Hellman.

– Hardware token support for both key exchange and bulk encryption.1

– SHA, DSS, and Fortezza support

– Out-of-Band data transfer.

• TLS – Transport Layer Security (version 1.0), also known as SSLv3.1, is very similar to SSLv3, but improves upon SSLv3 in the following ways:

• MAC – A MAC (Message Authentication Code) is calculated by applying an algorithm (such as MD5 or SHA1) to data. The MAC is a message digest, or a one-way hash code that is fairly easy to compute, but which is virtually irreversible. In other words, with the MAC alone, it would be theoretically impossible to determine the message upon which the digest was based. It is equally difficult to find two different messages that would result in the same MAC. If the receiver’s MAC calculation matches the sender’s MAC calculation on a given piece of data, the receiver is assured that the data has not been altered in transit

• Client Hello – The first message sent by the client to the server following TCP session establishment. This message starts the SSL session, and consists of the following components:

– Version – The version of SSL that the client wishes to use in communications. This is usually the most recent version of SSL supported by the client.

– Random – a 32-bit timestamp coupled with a 28 byte random structure.

– Session ID – This can either be empty if no Session ID data exists (essentially requesting a new session) or can reference a previously issued Session ID.

– Cipher Suites – A list of the cryptographic algorithms, in preferential order, supported by the clients.

– Compression Methods – A list of the compression methods supported by the client (typically null).

• Server Hello – The SSL server’s response to the Client Hello. It is this portion of the SSL exchange that SSL Control inspects. The Server Hello contains the version of SSL negotiated in the session, along with cipher, session ID and certificate information. The actual X.509 server certificate itself, although a separate step of the SSL exchange, usually begins (and often ends) in the same packet as the Server Hello.

1.

SSL TLS Uses a preliminary HMAC algorithm Uses HMAC as described in RFC 2104 Does not apply MAC to version info Applies MAC to version info Does not specify a padding value Initializes padding to a specific value Limited set of alerts and warning Detailed Alert and Warning messages



• Certificates - X.509 certificates are unalterable digital stamps of approval for electronic security. There are four main characteristics of certificates:

– Identify the subject of a certificate by a common name or distinguished name (CN or DN).

– Contain the public key that can be used to encrypt and decrypt messages between parties

– Provide a digital signature from the trusted organization (Certificate Authority) that issued the certificate.

– Indicate the valid date range of the certificate

• Subject – The grantee of a certificate identified by a common name (CN). When a client browses to an SSL site, such as https://www.mysonicwall.com, the server sends its certificate which is then evaluated by the client. The client checks that the certificate’s dates are valid, that is was issued by a trusted CA, and that the subject CN matches the requested host name (i.e. they are both “www.mysonicwall.com”). Although a subject CN mismatch elicits a browser alert, it is not always a sure sign of deception. For example, if a client browses to https://mysonicwall.com, which resolves to the same IP address as www.mysonicwall.com, the server will present its certificate bearing the subject CN of www.mysonicwall.com. An alert will be presented to the client, despite the total legitimacy of the connection.

• Certificate Authority (CA) - A Certificate Authority (CA) is a trusted entity that has the ability to sign certificates intended, primarily, to validate the identity of the certificate’s subject. Well-known certificate authorities include VeriSign, Thawte, Equifax, and Digital Signature Trust. In general, for a CA to be trusted within the SSL framework, its certificate must be stored within a trusted store, such as that employed by most web-browsers, operating systems and run-time environments. The SonicOS trusted store is accessible from the System > Certificates page. The CA model is built on associative trust, where the client rusts a CA (by having the CA's certificate in its trusted store), the CA trusts a subject (by having issued the subject a certificate), and therefore the client can trust the subject.

• Untrusted CA – An untrusted CA is a CA that is not contained in the trusted store of the client. In the case of SSL Control, an untrusted CA is any CA whose certificate is not present in System > Certificates.

• Self-Signed Certificates – Any certificate where the issuer’s common-name and the subject’s common-name are the same, indicating that the certificate was self-signed.

• Virtual Hosting – A method employed by web-servers to host more than one web-site on a single server. A common implementation of virtual hosting is name-based (Host-header) virtual hosting, which allows for a single IP address to host multiple web-sites. With Host-header virtual hosting, the server determines the requested site by evaluating the “Host:” header sent by the client. For example, both www.website1.com and www.website2.com might resolve to 64.41.140.173. If the client sends a “GET /” along with “Host: www.website1.com”, the server can return content corresponding to that site. Host-header virtual hosting is generally not employed in HTTPS because the host header cannot be read until the SSL connection is established, but the SSL connection cannot be established until the server sends its Certificate. Since the server cannot determine which site the client will request (all that is known during the SSL handshake is the IP address) it cannot determine the appropriate certificate to send. While sending any certificate might allow the SSL handshake to commence, a certificate name (subject) mismatch will trigger a browser alert.



• Weak Ciphers – Relatively weak symmetric cryptography ciphers. Ciphers are classified as weak when they are less than 64 bits. For the most part, export ciphers are weak ciphers. The following is a list of common weak ciphers:

Caveats and Advisories1. Self-signed and Untrusted CA enforcement – If enforcing either of these two options, it is strongly

advised that you add the common names of any SSL secured network appliances within your organization to the whitelist to ensure that connectivity to these devices is not interrupted. For example, the default subject name of SonicWALL UTM appliances is “192.168.168.168”, and the default common name of SonicWALL SSL-VPN appliances is “192.168.200.1”.

2. If your organization employs its own private Certificate Authority (CA), it is strongly advised that you import your private CA’s certificate into the System > Certificates store, particularly if you will be enforcing blocking of certificates issued by untrusted CAs. Refer to the System > Certificates section of the SonicOS Enhanced Administrator’s Guide for more information on this process.

3. SSL Control inspection is currently only performed on TCP port 443 traffic. SSL negotiations occurring on non-standard ports will not be inspected at this time.

4. Server Hello fragmentation – In some rare instances, an SSL server will fragment the Server Hello. If this occurs, the current implementation of SSL Control will not decode the Server Hello. SSL Control policies will not be applied to the SSL session, and the SSL session will be allowed.

5. Session termination handling – When SSL Control detects a policy violation and terminates an SSL session, it will simply terminate the session at the TCP layer. Because the SSL session is in an embryonic state at this point, it is not currently possible to redirect the client, or to provide any kind of informational notification of termination to the client.

6. Whitelist precedence – The whitelist takes precedence over all other SSL Control elements. Any SSL server certificate which matches an entry in the whitelist will allow the SSL session to proceed, even if other elements of the SSL session are in violation of the configured policy. This is by design.

7. SonicOS Enhanced 4.0 increased the number of pre-installed (well-known) CA certificates from 8 to 93. The resulting repository is very similar to what can be found in most web-browsers. Other certificate related changes:

– The maximum number of CA certificates was raised from 6 to 256

– The maximum size of an individual certificate was raised from 2,048 to 4,096.

8. The maximum number of entries in the whitelist and blacklist is 1,024 each.ssl.

Cipher Encryption Occurs In EXP1024-DHE-DSS-DES-CBC-SHA DES (56) SSLv3, TLS (export) EXP1024-DES-CBC-SHA DES (56) SSLv3, TLS (export) EXP1024-RC2-CBC-MD5 RC2 (56) SSLv3, TLS (export) EDH-RSA-DES-CBC-SHA DES (56) SSLv3, TLS EDH-DSS-DES-CBC-SHA DES (56) SSLv3, TLS DES-CBC-SHA DES (56) SSLv2, SSLv3, TLS EXP1024-DHE-DSS-RC4-SHA RC4 (56) SSLv3, TLS (export) EXP1024-RC4-SHA RC4 (56) SSLv3, TLS (export) EXP1024-RC4-MD5 RC4 (56) SSLv3, TLS (export) EXP-EDH-RSA-DES-CBC-SHA DES (40) SSLv3, TLS (export) EXP-EDH-DSS-DES-CBC-SHA DES (40) SSLv3, TLS (export) EXP-DES-CBC-SHA DES (40) SSLv3, TLS (export) EXP-RC2-CBC-MD5 RC2 (40) SSLv2, SSLv3, TLS (export) EXP-RC4-MD5 RC4 (40) SSLv2, SSLv3, TLS (export)


S o n i c WA L L E a r l y F i e l d T r i a l ( E F T ) D r a f t - I n t e r n a l U s e O n l yStateful Failover Overview

Stateful Failover OverviewThe original version of SonicOS Enhanced provided a basic Hardware Failover feature where a backup firewall assumes the interface IP addresses of the configured interfaces when the primary unit fails. Upon failover layer 2 broadcasts are issued (ARP) to inform the network that the IP addresses are now owned by the backup unit. All pre-existing network connections must be rebuilt. For example, Telnet and FTP sessions must be re-established and VPN tunnels must be renegotiated.

SonicOS Enhanced release 4.0 introduces Stateful Hardware Failover (SHF), which provides dramatically improved failover performance. The primary and backup appliances are continuously synchronized so that the backup can seamlessly assume all network responsibilities if the primary appliance fails, with no interruptions to existing network connections.

The following sections provide an overview of the Stateful Hardware Failover feature:


• “How Does Stateful Hardware Failover Work?” section on page 29

• “Supported Platforms” section on page 30

• “Prerequisites” section on page 31

BenefitsStateful Hardware Failover provides the following benefits:

• Dramatically improved reliability - by synchronizing most critical network connection information, Stateful Hardware Failover prevents down time and dropped connections in case of appliance failure.

• Minimal impact on CPU performance - Typically less than 1% usage

• Minimal impact on bandwidth - Transmission of synchronization data is throttled so as not interfere with other data.

• Simplified configuration and management - Configuration changes and firmware upgrades are performed only on the primary appliance. Stateful Hardware Failover automatically propagates any configuration changes to the backup appliance. Firmware upgrades are propagated to the backup appliance by simply clicking the Synchronize Firmware button.

How Does Stateful Hardware Failover Work?When Stateful Hardware Failover is enabled, the primary appliance actively communicates with the backup to update most network connection information. As the primary appliance creates and updates network connection information (VPN tunnels, active users, connection cache entries, etc.), it immediately informs the backup appliance. This ensures that the backup appliance is always prepared to seamlessly take over the active connections in case the primary appliance fails.

Table 2 lists the types of information that currently are and are not synchronized by Stateful Hardware Failover.



Table 2 Information Synchronized by Stateful Hardware Failover

Supported PlatformsStateful Hardware Failover is available on the SonicWALL PRO 4060, PRO 4100, and PRO 5060 security appliances.

Information that is Synchronized Information that is not SynchronizedVPN information Dynamic WAN clients (L2TP, PPPoE, and PPTP)

Basic connection cache Deep Packet Inspection (GAV, IPS, and Anti Spyware)

FTP IPHelper bindings (such as NetBIOS and DHCP)

Oracle SQL*NET SYNFlood protection information

Real Audio Content Filtering Service information

RTSP VoIP protocols

GVC information Dynamic ARP entries and ARP cache timeouts

Dynamic Address Objects Active wireless client information

DHCP server information wireless client packet statistics

Multicast and IGMP Rogue AP list

Active users

ARP

SonicPoint status

Wireless guest status

RIP and OSPF information

License information

Weighted Load Balancing information



PrerequisitesYour network environment must me the following prerequisites before configuring Stateful Hardware Failover:

• The primary and backup appliances must be the same model.

• The primary and backup appliances must be running the same version of SonicOS Enhanced firmware.

• The primary and backup appliances must have the same security services enabled.

• The WAN virtual IP address and interfaces must use static IP addresses.

• Three LAN IP addresses are required:

– LAN virtual IP address - Configured on the X0 interface of the primary unit. This is the default gateway for all devices configured on the LAN.

– Primary management IP address - Configured under Hardware > Monitoring, this is the IP address for management over the LAN interface of the Primary unit, regardless if the device is in an active or idle state.

– Backup Management P Address - Configured under Hardware > Monitoring, this is the IP address for management over the LAN interface of the Backup unit, regardless if the device is in an active or idle state.

• Between one and three WAN IP addresses are required:

– (Required) WAN Virtual IP address - Configured on the X1 Interface of the Primary Unit, this IP address is used to access whichever unit is current active, whether it is the primary or backup unit.

– (Optional) Primary WAN Management IP address - Configured under Hardware > Monitoring on the primary unit, this IP address is used to access the primary unit, regardless if it is in an active or idle state.

– (Optional) Backup Management IP Address - Configured under Hardware > Monitoring on the backup unit, this IP address is used to access the backup unit, regardless if it is in an active or idle state.


S o n i c WA L L E a r l y F i e l d T r i a l ( E F T ) D r a f t - I n t e r n a l U s e O n l ySonicPoint VAP Overview

SonicPoint VAP OverviewThis section provides an introduction to the Single Sign-on feature. This section contains the following subsections:

• “What Is a Virtual Access Point?” section on page 33

• “What Is an SSID?” section on page 34

• “Wireless Roaming with ESSID” section on page 34

• “What Is a BSSID?” section on page 34

• “Benefits of Using Virtual APs” section on page 35

• “Benefits of Using Virtual APs with VLANs” section on page 35

• “Supported Platforms” section on page 35

• “Prerequisites” section on page 36

• “Deployment Restrictions” section on page 36



What Is a Virtual Access Point?A “Virtual Access Point” is a multiplexed instantiation of a single physical Access Point (AP) so that it presents itself as multiple discrete Access Points. To wireless LAN clients, each Virtual AP appears to be an independent physical AP, when in actuality there is only a single physical AP. Before the evolution of the Virtual AP feature support, wireless networks were relegated to a one-to-one relationship between physical Access Points and wireless network security characteristics, such as authentication and encryption. In other words, an Access Point providing WPA-PSK security could not simultaneously offer Open or WPA-EAP connectivity to clients, and if the latter were required, they would had to have been provided by a separate, distinctly configured Access Points. This forced WLAN network administrators to find a solution to scale their existing wireless LAN infrastructure to provide differentiated levels of service. With the Virtual APs (VAP) feature, multiple VAPs can exist within a single physical AP in compliance with the IEEE 802.11 standard for the media access control (MAC) protocol layer that includes a unique Basic Service Set Identifier (BSSID) and Service Set Identified (SSID). This allows for segmenting wireless network services within a single radio frequency footprint of a single physical access point device.

VAPs allow the network administrator to control wireless user access and security settings by setting up multiple custom configurations on a single physical interface. Each of these custom configurations acts as a separate (virtual) access point, and can be grouped and enforced on single or multiple physical SonicPoint access points simultaneously as illustrated below in Figure 15.

Figure 15 VAP Deployment with SonicWALL SonicPoint

For more information on SonicOS Secure Wireless features, refer to the SonicWALL Secure Wireless Integrated Solutions Guide.

SonicWALL PRO 2040Radius Server

Internet

VLAN 50 - SSID: VAP-CorporateVLAN 100 - SSID: VAP-LegacyVLAN 150 - SSID: VAP-Guest_SecureVLAN 200 - SSID: VAP-GuestVLAN 250 - SSID: VAP-SSL-VPN

VLAN IDs Provisioned to SonicPoints

SSID:VAP-SSL-VPN

SSID:VAP-Corporate

SSID:VAP-Guest

SSID:VAP-Legacy

SSID:VAP-Guest

Secure

SSID:VAP-Guest



What Is an SSID?A Service Set IDentifier (SSID) is the name assigned to a wireless network. Wireless clients must use this same, case-sensitive SSID to communicate to the SonicPoint. The SSID consists of a text string up to 32 bytes long. Multiple SonicPoints on a network can use the same SSIDs. You can configure up to 8 unique SSIDs on SonicPoints and assign different configuration settings to each SSID.

SonicPoints broadcast a beacon (announcements of availability of a wireless network) for every SSID configured. By default, the SSID is included within the beacon so that wireless clients can see the wireless networks. The option to suppress the SSID within the beacon is provided on a per-SSID (e.g. per-VAP or per-AP) basis to help conceal the presence of a wireless network, while still allowing clients to connect by manually specifying the SSID.

The following settings can be assigned to each VAP:

• Authentication method

• VLAN

• Maximum number of client associations using the SSID

• SSID Suppression

Wireless Roaming with ESSIDAn ESSID (Extended Service Set IDentifier) is a collection of Access Points (or Virtual Access Points) sharing the same SSID. A typical wireless network comprises more than one AP for the purpose of covering geographic areas larger than can be serviced by a single AP. As clients move through the wireless network, the strength of their wireless connection decreases as they move away from one Access Point (AP1) and increases as they move toward another (AP2). Providing AP1 and AP2 are on the same ESSID (for example, ‘sonicwall’) and that the (V)APs share the same SSID and security configurations, the client will be able to roam from one to the other. This roaming process is controlled by the wireless client hardware and driver, so roaming behavior can differ from one client to the next, but it is generally dependent upon the signal strength of each AP within an ESSID.

What Is a BSSID?A BSSID (Basic Service Set IDentifier) is the wireless equivalent of a MAC (Media Access Control) address, or a unique hardware address of an AP or VAP for the purposes of identification. Continuing the example of the roaming wireless client from the ESSID section above, as the client on the ‘sonicwall’ ESSID moves away from AP1 and toward AP2, the strength of the signal from the former will decrease while the latter increases. The client’s wireless card and driver constantly monitors these levels, differentiating between the (V)APs by their BSSID. When the card/driver’s criteria for roaming are met, the client will detach from the BSSID of AP1 and attach to the BSSID or AP2, all the while remaining connected the ‘sonicwall’ ESSID.



Benefits of Using Virtual APsThis section includes a list of benefits in using the Virtual AP feature:

• Radio Channel Conservation—Prevents building overlapped infrastructures by allowing a single Physical Access Point to be used for multiple purposes to avoid channel collision problem. Channel conservation. Multiple providers are becoming the norm within public spaces such as airports. Within an airport, it might be necessary to support an FAA network, one or more airline networks, and perhaps one or more Wireless ISPs. However, in the US and Europe, 802.11b networks can only support three usable (non-overlapping) channels, and in France and Japan only one channel is available. Once the channels are utilized by existing APs, additional APs will interfere with each other and reduce performance. By allowing a single network to be used for multiple purposes, Virtual APs conserve channels.

• Optimize SonicPoint LAN Infrastructure—Share the same SonicPoint LAN infrastructure among multiple providers, rather than building an overlapping infrastructure, to lower down the capital expenditure for installation and maintenance of your WLANs.

Benefits of Using Virtual APs with VLANsAlthough the implementation of VAPs does not require the use of VLANs, VLAN use does provide practical traffic differentiation benefits. When not using VLANs, the traffic from each VAP is handled by a common interface on the SonicWALL security appliance. This means that all traffic from each VAP will belong to the same Zone and same subnet (Note: a future version of SonicOS Enhanced will allow for traffic from different VAPs to exist on different subnets within the same Zone, providing a measure of traffic differentiation even without VLAN tagging). By tagging the traffic from each VAP with a unique VLAN ID, and by creating the corresponding sub-interfaces on the SonicWALL security appliance, it is possible to have each VAP occupy a unique subnet, and to assign each sub-interface to its own Zone.

This affords the following benefits:

• Each VAP can have its own security services settings (e.g. GAV, IPS, CFS, etc.)

• Traffic from each VAP can be easily controlled using Access Rules configured from the Zone level.

• Separate Wireless Guest Services (WGS) or Lightweight Hotspot Messaging (LHM) configurations can be applied to each, facilitating the presentation of multiple guest service providers with a common set of SonicPoint hardware.

• Bandwidth management and other Access Rule-based controls can easily be applied.

Supported PlatformsThis feature is supported on the following platforms running SonicOS Enhanced 3.5 or higher:

• SonicWALL PRO 2040






S o n i c WA L L E a r l y F i e l d T r i a l ( E F T ) D r a f t - I n t e r n a l U s e O n l yDynamic Address Objects (DAO) Overview

Prerequisites • Each SonicWALL SonicPoint must be explicitly enabled for Virtual Access Point support by selecting

the SonicPoint > SonicPoints > General Settings Tab: “Enable SonicPoint” checkbox in the SonicOS management interface and enabling either Radio A or G.

• SonicPoints must be linked to a WLAN zone on your SonicWALL UTM appliance in order for provisioning of APs to take place.

• When using VAPs with VLANs, you must ensure that the physical SonicPoint discovery and provisioning packets remain untagged (unless being terminated natively into a VLAN sub-interface on the SonicWALL). You must also ensure that VAP packets that are VLAN tagged by the SonicPoint are delivered unaltered (neither un-encapsulated nor double-encapsulated) by any intermediate equipment, such as a VLAN capable switch, on the network.

Deployment RestrictionsWhen configuring your VAP setup, be aware of the following deployment restrictions:

• Maximum SonicPoint restrictions apply and differ based on your SonicWALL PRO series hardware. Review these restrictions in the SonicWALL 3.5 Enhanced Administrator’s Guide.

Dynamic Address Objects (DAO) OverviewThis section provides an introduction to Dynamic Address Objects (DAO). This section contains the following subsection:

• “Introduction to DAO” section on page 36

• “Key Features of DAOs” section on page 37

Introduction to DAOFrom its inception, SonicOS Enhanced has used Address Objects (AOs) to represent IP addresses in most areas throughout the user interface. Address Objects come in the following varieties:

• Host – An individual IP address, netmask and Zone association.

• MAC (original) – Media Access Control, or the unique hardware address of an Ethernet host. MAC AOs were originally introduced in SonicOS 2.5 and were used for:

– Identifying SonicPoints

– Allowing hosts to bypass Wireless Guest Services authentication

– Authorizing the BSSID (Basic Service Set Identifier, or WLAN MAC) of wireless access points detected during wireless scans.

– MAC AOs were originally not allowable targets in other areas of the management interface, such as Access Rules, so historically they could not be used to control a host’s access by its hardware address.

• Range – A starting and ending IP address, inclusive of all addresses in between.



• Group – A collection of Address Objects of any assortment of types. Groups may contain other Groups, Host, MAC, Range, or FQDN Address Objects.

SonicOS Enhanced 3.5 redefines the operation of MAC AOs, and introduces Fully Qualified Domain Name (FQDN) AOs:

• MAC (3.5.x+) – SonicOS Enhanced 3.5. and higher will resolve MAC AOs to an IP address by referring to the ARP cache on the SonicWALL.

• FQDN – Fully Qualified Domain Names, such as ‘www.reallybadwebsite.com’, will be resolved to their IP address (or IP addresses) using the DNS server configured on the SonicWALL. Wildcard entries are supported through the gleaning of responses to queries sent to the sanctioned DNS servers.

While more effort is involved in creating an Address Object than in simply entering an IP address, AOs were implemented to complement the management scheme of SonicOS Enhanced, providing the following characteristics:

• Zone Association – When defined, Host, MAC, and FQDN AOs require an explicit Zone designation. In most areas of the interface (such as Access Rules) this is only used referentially. The functional application are the contextually accurate populations of Address Object drop-down lists, and the area of “VPN Access” definitions assigned to Users and Groups; when AOs are used to define VPN Access, the Access Rule auto-creation process refers to the AO’s Zone to determine the correct intersection of VPN◊[Zone] for rule placement. In other words, if the “192.168.168.200 Host” Host AO, belonging to the LAN Zone was added to “VPN Access” for the “Trusted Users” User Group, the auto-created Access Rule would be assigned to the VPN◊LAN Zone.

• Management and Handling – The versatilely typed family of Address Objects can be easily used throughout the SonicOS Enhanced interface, allowing for handles (e.g. from Access Rules) to be quickly defined and managed. The ability to simply add or remove members from Address Object Groups effectively enables modifications of referencing rules and policies without requiring direct manipulation.

• Reusability – Objects only need to be defined once, and can then be easily referenced as many times as needed.

Key Features of DAOsThe term Dynamic Address Object (DAO) describes the underlying framework enabling MAC and FQDN AOs. By transforming AOs from static to dynamic structures Firewall > Access Rules can automatically respond to changes in the network.

Note The initial SonicOS Enhanced 3.5.x release will only support Dynamic Address Objects within Access Rules. Future versions of SonicOS Enhanced might introduce DAO support to other subsystem, such as NAT, VPN, etc.



Features and BenefitsThis section provides a list of features and benefits for DAO.

• FQDN resolution using DNS - FQDN Address Objects are resolved using the DNS servers configured on the SonicWALL in the Network > DNS page. Since it is common for DNS entries to resolve to multiple IP addresses, the FQDN DAO resolution process will retrieve all of the addresses to which a host name resolves, up to 256 entries per AO. In addition to resolving the FQDN to its IPs, the resolution process will also associate the entry’s TTL (time to live) as configured by the DNS administrator. TTL will then be honored to ensure the FQDN information does not become stale.

• FQDN wildcard support - FQDN Address Objects support wildcard entries, such as “*.somedomainname.com”, by first resolving the base domain name to all its defined host IP addresses, and then by constantly actively gleaning DNS responses as they pass through the firewall.For example, creating an FQDN AO for “*.myspace.com” will first use the DNS servers configured on the firewall to resolve “myspace.com” to 63.208.226.40, 63.208.226.41, 63.208.226.42, and 63.208.226.43 (as can be confirmed by nslookup myspace.com or equivalent). Since most DNS servers do not allow zone transfers, it is typically not possibly to automatically enumerate all the hosts in a domain. Instead, the SonicWALL will look for DNS responses coming from sanctioned DNS servers as they traverse the firewall. So if a host behind the firewall queries an external DNS server which is also a configured/defined DNS server on the SonicWALL, the SonicWALL will parse the response to see if it matches the domain of any wildcard FQDN AOs.

Note ‘Sanctioned’ DNS servers are those DNS servers configured for use by the SonicWALL firewall. The reason that responses from only sanctioned DNS servers are used in the wildcard learning process is to protect against the possibility of FQDN AO poisoning through the use of unsanctioned DNS servers with deliberately incorrect host entries. Future versions of SonicOS Enhanced might offer the option to support responses from all DNS server. The use of sanctioned DNS servers can be enforced with the use of Access Rules, as described later in the “Enforcing the use of sanctioned servers on the network” section.To illustrate, assume the firewall is configured to use DNS servers 4.2.2.1 and 4.2.2.2, and is providing these DNS servers to all firewalled client via DHCP. If firewalled client-A performs a DNS query against 4.2.2.1 or 4.2.2.2 for “vids.myspace.com”, the response will be examined by the firewall, and will be matched to the defined “*.myspace.com” FQDN AO. The result (63.208.226.224) will then be added to the resolved values of the “*.myspace.com” DAO.

Note If the workstation, client-A, in the example above had resolved and cached vids.myspace.com prior to the creation of the “*.myspace.com” AO, vids.myspace.com would not be resolved by the firewall because the client would use its resolver’s cache rather than issuing a new DNS request. As a result, the firewall would not have the chance to learn about vids.myspace.com, unless it was resolved by another host. On a Microsoft Windows workstation, the local resolver cache can be cleared using the command ipconfig /flushdns. This will force the client to resolve all FQDNs, allowing the firewall to learn them as they are accessed.Wildcard FQDN entries will resolve all hostnames within the context of the domain name, up to 256 entries per AO. For example, “*.sonicwall.com” will resolve www.sonicwall.com, software.sonicwall.com, licensemanager,sonicwall.com, to their respective IP addresses, but it will not resolve sslvpn.demo.sonicwall.com because it is in a different context; for sslvpn.demo.sonicwall.com to be resolved by a wildcard FQDN AO, the entry “*.demo.sonicwall.com” would be required, and would also resolve sonicos-enhanced.demo.sonicwall.com, csm.demo.sonicwall.com, sonicos-standard.demo.sonicwall.com, etc.



Note Wildcards only support full matches, not partial matches. In other words, “*.sonicwall.com” is a legitimate entry, but “w*.sonicwall.com”, “*w.sonicwall.com”, and “w*w.sonicwall.com” are not. A wildcard can only be specified once per entry, so “*.*.sonicwall.com”, for example, will not be functional.

• FQDN entry caching - Resolved FQDN values will be cached in the event of resolution attempt failures subsequent to initial resolution. In other words, if “www.moosifer.com” resolves to 71.35.249.153 with a TTL of 300, but fails to resolve upon TTL expiry (for example, due to temporary DNS server unavailability), the 71.35.249.153 will be cached and used as valid until resolution succeeds, or until manually purged. Newly created FQDN entries that never successfully resolve, or entries that are purged and then fail to resolve will appear in an unresolved state.

• MAC Address resolution using live ARP cache data - When a node is detected on any of the SonicWALL’s physical segments through the ARP (Address Resolution Protocol) mechanism, the SonicWALL’s ARP cache is updated with that node’s MAC and IP address. When this update occurs, if a MAC Address Objects referencing that node’s MAC is present, it will instantly be updated with the resolved address pairing. When a node times out of the ARP cache due to disuse (e.g. the host is no longer L2 connected to the firewall) the MAC AO will transition to an “unresolved” state.

• MAC Address Object multi-homing support - MAC AOs can be configured to support multi-homed nodes, where multi-homed refers to nodes with more than one IP address per physical interface. Up to 256 resolved entries are allowed per AO. This way, if a single MAC address resolves to multiple IPs, all of the IP will be applicable to the Access Rules, etc. that refer to the MAC AO.

• Automatic and manual refresh processes - MAC AO entries are automatically synchronized to the SonicWALL’s ARP cache, and FQDN AO entries abide by DNS entry TTL values, ensuring that the resolved values are always fresh. In addition to these automatic update processes, manual Refresh and Purge capabilities are provided for individual DAOs, or for all defined DAOs.

• FQDN resolution using DNS - FQDN Address Objects are resolved using the DNS servers configured on the SonicWALL in the Network > DNS page. Since it is common for DNS entries to resolve to multiple IP addresses, the FQDN DAO resolution process will retrieve all of the addresses to which a host name resolves, up to 256 entries per AO. In addition to resolving the FQDN to its IPs, the resolution process will also associate the entry’s TTL (time to live) as configured by the DNS administrator. TTL will then be honored to ensure the FQDN information does not become stale.


S o n i c WA L L E a r l y F i e l d T r i a l ( E F T ) D r a f t - I n t e r n a l U s e O n l yLayer 2 Bridge Mode Overview

Layer 2 Bridge Mode OverviewThis section provides an introduction to Layer 2 Bridge Mode. This section contains the following subsections:

• “Layer 2 Bridge Mode Introduction” section on page 40

• “Key Features of SonicOS Enhanced Layer 2 Bridge Mode” section on page 41

• “Key Concepts to Configuring L2 Bridge Mode and Transparent Mode” section on page 41

• “Comparing L2 Bridge Mode to Transparent Mode” on page 43

Layer 2 Bridge Mode IntroductionSonicOS Enhanced 3.5 introduces L2 (Layer 2) Bridge Mode, a new method of unobtrusively integrating a SonicWALL security appliance into any Ethernet network. L2 Bridge Mode is ostensibly similar to SonicOS Enhanced’s Transparent Mode in that it enables a SonicWALL security appliance to share a common subnet across two interfaces, and to perform stateful and deep-packet inspection on all traversing IP traffic, but it is functionally more versatile.

In particular, L2 Bridge Mode employs a secure learning bridge architecture, enabling it to pass and inspect traffic types that cannot be handled by many other methods of transparent security appliance integration. Using L2 Bridge Mode, a SonicWALL security appliance can be non-disruptively added to any Ethernet network to provide in-line deep-packet inspection for all traversing IPv4 TCP and UDP traffic. Unlike other transparent solutions, L2 Bridge Mode can pass all traffic types, including IEEE 802.1Q VLANs, Spanning Tree Protocol, multicast, broadcast, and IPv6, ensuring that all network communications will continue uninterrupted.

L2 Bridge Mode provides an ideal solution for networks that already have an existing firewall, and do not have immediate plans to replace their existing firewall but wish to add the security of SonicWALL Unified Threat Management (UTM) deep-packet inspection, such as Intrusion Prevention Services, Gateway Anti Virus, and Gateway Anti Spyware. If you do not have SonicWALL UTM security services subscriptions, you may sign up for free trials from the Security Service > Summary page of your SonicWALL, and you can obtain more information at: http://www.sonicwall.com/products/gav_ips_spyware.html and http://www.sonicwall.com/products/cfs.html



Key Features of SonicOS Enhanced Layer 2 Bridge ModeThe following table outlines the benefits of each key feature of layer 2 bridge mode:

Key Concepts to Configuring L2 Bridge Mode and Transparent Mode

The following terms will be used when referring to the operation and configuration of L2 Bridge Mode:

• L2 Bridge Mode – A method of configuring a SonicWALL PRO security appliance (with the exception of the PRO 1260), which enables the SonicWALL to be inserted inline into an existing network with absolute transparency, beyond even that provided by Transparent Mode. Layer 2 Bridge Mode also refers to the IP Assignment configuration that is selected for Secondary Bridge Interfaces that are placed into a Bridge-Pair.

• Transparent Mode – A method of configuring a SonicWALL security appliance, introduced in SonicOS Enhanced 2.5, which allows the SonicWALL to be inserted into an existing network without the need for IP reconfiguration by spanning a single IP subnet across two or more interfaces through the use of automatically applied ARP and routing logic.

Feature Benefit

L2 Bridging with Deep Packet Inspection

This method of transparent operation means that a SonicWALL security appliance can be added to any network without the need for readdressing or reconfiguration, ena-bling the addition of deep-packet inspection security services with no disruption to existing network designs. Developed with connectivity in mind as much as security, L2 Bridge Mode can pass all Ethernet frame types, ensuring seamless integration.

Secure Learning Bridge Architecture

True L2 behaviour means that all allowed traffic flows natively through the L2 Bridge. Whereas other methods of transparent operation rely on ARP and route manipulation to achieve transparency, which frequently proves problematic, L2 Bridge Mode dynamically learns the topology of the network to determine optimal traffic paths.

Universal Ethernet Frame-Type Support

All Ethernet traffic can be passed across an L2 Bridge, meaning that all network com-munications will continue uninterrupted. While many other methods of transparent operation will only support IPv4 traffic, L2 Bridge Mode will inspect all IPv4 traffic, and will pass (or block, if desired) all other traffic, including LLC, all Ethertypes, and even proprietary frame formats.

Mixed-Mode Operation L2 Bridge Mode can concurrently provide L2 Bridging and conventional security appli-ance services, such as routing, NAT, VPN, and wireless operations. This means it can be used as an L2 Bridge for one segment of the network, while providing a complete set of security services to the remainder of the network. This also allows for the intro-duction of the SonicWALL security appliance as a pure L2 bridge, with a smooth migration path to full security services operation.



• IP Assignment – When configuring a Trusted (LAN) or Public (DMZ) interface, the IP Assignment for the interface can either be:

– Static – The IP address for the interface is manually entered.

– Transparent Mode – The IP address (es) for the interface is assigned using an Address Object (Host, Range, or Group) that falls within the WAN Primary IP subnet, effectively spanning the subnet from the WAN interface to the assigned interface.

– Layer 2 Bridge Mode – An interface placed in this mode becomes the Secondary Bridge Interface to the Primary Bridge Interface to which it is paired. The resulting Bridge-Pair will then behave like a two-port learning bridge with full L2 transparency, and all IP traffic that passes though will be subjected to full stateful and deep-packet inspection.

• Bridge-Pair – The logical interface set composed of a Primary Bridge Interface and a Secondary Bridge Interface. The terms primary and secondary do not imply any inherent level of operational dominance or subordination; both interfaces continue to be treated according to their Zone type, and to pass IP traffic according to their configured Access Rules. Non-IPv4 traffic across the Bridge-Pair is controlled by the Block all non-IPv4 traffic setting on the Secondary Bridge Interface. A system may support as many Bridge Pairs as it has interface pairs available. In other words, the maximum number of Bridge-Pairs is equal to ½ the number of physical interfaces on the platform. Membership in a Bridge-Pair does not preclude an interface from conventional behavior; for example, if X1 is configured as a Primary Bridge Interface paired to X3 as a Secondary Bridge Interface, X1 can simultaneously operate in its traditional role as the Primary WAN, performing NAT for Internet-bound traffic through the Auto-added X1 Default NAT Policy.

• Primary Bridge Interface – A designation that is assigned to an interface once a Secondary Bridge Interface has been paired to it. A Primary Bridge Interface can belong to an Untrusted (WAN), Trusted (LAN), or Public (DMZ) Zone.

• Secondary Bridge Interface – A designation that is assigned to an interface whose IP Assignment has been configured for Layer 2 Bridge Mode. A Secondary Bridge Interface can belong to a Trusted (LAN), or Public (DMZ) Zone.

• Bridge Management Address – The address of the Primary Bridge Interface is shared by both interfaces of the Bridge-Pair. If the Primary Bridge Interface also happens to be the Primary WAN interface, it is this address that is uses for outbound communications by the SonicWALL, such as NTP, and License Manager updates. Hosts that are connected to either segment of the Bridge-Pair may also use the Bridge Management Address as their gateway, as will be common in Mixed-Mode deployments.

• Bridge-Partner – The term used to refer to the ‘other’ member of a Bridge-Pair.

• Non-IPv4 Traffic - SonicOS Enhanced supports the following IP protocol types: ICMP (1), IGMP (2), TCP (6), UDP (17), GRE (47), ESP (50), AH (51), EIGRP (88), OSPF (89), PIM-SM (103), L2TP (115). More esoteric IP types, such as Combat Radio Transport Protocol (126), are not natively handled by the SonicWALL, nor are non-IPv4 traffic types such as IPX or (currently) IPv6. L2 Bridge Mode can be configured to either pass or drop Non-IPv4 traffic.

• Pure L2 Bridge Topology – Refers to deployments where the SonicWALL will be used strictly in L2 Bridge Mode for the purposes of providing in-line security to a network. This means that all traffic entering one side of the Bridge-Pair will be bound for the other side, and will not be routed/NATed through a different interface. This will be common in cases where there is an existing perimeter security appliance, or where in-line security is desired along some path (for example, inter-departmentally, or on a trunked link between two switches) of an existing network. Pure L2 Bridge Topology is not a functional limitation, but rather a topological description of a common deployment in heterogeneous environments.



• Mixed-Mode Topology – Refers to deployments where the Bridge-Pair will not will not be the only point of ingress/egress through the SonicWALL. This means that traffic entering one side of the Bridge-Pair may be destined to be routed/NATed through a different interface. This will be common when the SonicWALL is simultaneously used to provide security to one or more Bridge-Pair while also providing:

– Perimeter security, such as WAN connectivity, to hosts on the Bridge-Pair or on other interfaces.

– Firewall and Security services to additional segments, such as Trusted (LAN) or Public (DMZ) interface, where communications will occur between hosts on those segments and hosts on the Bridge-Pair.

– Wireless services with SonicPoints, where communications will occur between wireless clients and hosts on the Bridge-Pair.

Comparing L2 Bridge Mode to Transparent ModeWhile Transparent Mode allows a security appliance running SonicOS Enhanced to be introduced into an existing network without the need for re-addressing, it presents a certain level of disruptiveness, particularly with regard to ARP, VLAN support, multiple subnets, and non-IPv4 traffic types. Consider the diagram below, in a scenario where a Transparent Mode SonicWALL appliance has just been added to the network with a goal of minimally disruptive integration, particularly:

• Negligible or no unscheduled downtime

• No need to re-address any portion of the network

• No need reconfigure or otherwise modify the gateway router (as is common when the router is owned by the ISP)



ARP in Transparent ModeARP – Address Resolution Protocol (the mechanism by which unique hardware addresses on network interface cards are associated to IP addresses) is proxied in Transparent Mode. If the Workstation on Server on the left had previously resolved the Router (192.168.0.1) to its MAC address 00:99:10:10:10:10, this cached ARP entry would have to be cleared before these hosts could communicate through the SonicWALL. This is because the SonicWALL proxies (or answers on behalf of) the gateway’s IP (192.168.0.1) for hosts connected to interfaces operating in Transparent Mode. So when the Workstation at the left attempts to resolve 192.168.0.1, the ARP request it sends is responded to by the SonicWALL with its own X0 MAC address (00:06:B1:10:10:10).

The SonicWALL also proxy ARPs the IP addresses specified in the Transparent Range (192.168.0.100 to 192.168.0.250) assigned to an interface in Transparent Mode for ARP requests received on the X1 (Primary WAN) interface. If the Router had previously resolved the Server (192.168.0.100) to its MAC address 00:AA:BB:CC:DD:EE, this cached ARP entry would have to be cleared before the router could communicate with the host through the SonicWALL. This typically requires a flushing of the router’s ARP cache either from its management interface or through a reboot. Once the router’s ARP cache is cleared, it can then send a new ARP request for 192.168.0.100, to which the SonicWALL will respond with its X1 MAC 00:06:B1:10:10:11.

VLAN Support in Transparent ModeWhile the network depicted in the above diagram is simple, it is not uncommon for larger networks to use VLANs for segmentation of traffic. If this were such a network, where the link between the switch and the router was a VLAN trunk, a Transparent Mode SonicWALL would have been able to terminate the VLANs to sub-interfaces on either side of the link, but it would have required unique addressing; that is,non-Transparent Mode operation requiring re-addressing on at least one side. This is because only the Primary WAN interface can be used as the source for Transparent Mode address space.



Multiple Subnets in Transparent ModeIt is also common for larger networks to employ multiple subnets, be they on a single wire, on separate VLANs, multiple wires, or some combination. While Transparent Mode is capable of supporting multiple subnets through the use of Static ARP and Route entries.

Non-IPv4 Traffic in Transparent ModeTransparent Mode will drop (and generally log) all non-IPv4 traffic, precluding it from passing other traffic types, such as IPX, or unhandled IP types.

L2 Bridge Mode addresses these common Transparent Mode deployment issues and is described in the following section.

Simple L2 Bridge Topology

ARP in L2 Bridge ModeL2 Bridge Mode employs a learning bridge design where it will dynamically determine which hosts are on which interface of an L2 Bridge (referred to as a Bridge-Pair). ARP is passed through natively, meaning that a host communicating across an L2 Bridge will see the actual host MAC addresses of their peers. For example, the Workstation communicating with the Router (192.168.0.1) will see the router as 00:99:10:10:10:10, and the Router will see the Workstation (192.168.0.100) as 00:AA:BB:CC:DD:EE.

This behavior allows for a SonicWALL operating in L2 Bridge Mode to be introduced into an existing network with no disruption to most network communications other than that caused by the momentary discontinuity of the physical insertion.

It should be noted that stream-based TCP protocols communications (for example, an FTP session between a client and a server) will need to be re-established upon the insertion of an L2 Bridge Mode SonicWALL. This is by design so as to maintain the security afforded by stateful packet inspection (SPI); since the SPI engine can not have knowledge of the TCP connections which pre-existed it, it will drop these established packets with a log event such as TCP packet received on non-existent/closed connection; TCP packet dropped.



VLAN Support in L2 Bridge ModeL2 Bridge Mode provides fine control over 802.1Q VLAN traffic traversing an L2 Bridge. The default handling of VLANs is to allow and preserve all 802.1Q VLAN tags as they pass through an L2 Bridge, while still applying all firewall rules, and stateful and deep-packet inspection to the encapsulated traffic. It is further possible to specify white/black lists for allowed/disallowed VLAN IDs through the L2 Bridge.

This allows a SonicWALL operating in L2 Bridge Mode to be inserted, for example, inline into a VLAN trunk carrying any number of VLANs, and to provide full security services to all IPv4 traffic traversing the VLAN without the need for explicit configuration of any of the VLAN IDs or subnets. Firewall Access Rules can also, optionally, be applied to all VLAN traffic passing through the L2 Bridge Mode because of the method of handling VLAN traffic.

L2 Bridge IP Packet Path

• 802.1Q encapsulated frame enters an L2 Bridge interface (this first step, the next step, and the final step apply only to 802.1Q VLAN traffic)

• The 802.1Q VLAN ID is checked against the VLAN ID white/black list:

– If the VLAN ID is disallowed, the packet is dropped and logged.

– If the VLAN ID is allowed, the packet is de-capsulated, the VLAN ID is stored, and the inner packet (including the IP header) is passed through the full packet handler.



• Since any number of subnets is supported by L2 Bridging, no source IP spoof checking is performed on the source IP of the packet. It is possible to configure L2 Bridges to only support a certain subnet or subnets using Firewall Access Rules.

• SYN Flood checking is performed.

• A destination route lookup is performed to the destination Zone, so that the appropriate Firewall Access rule can be applied. Any Zone is a valid destination, including the same Zone as the source Zone (e.g. LAN to LAN), the Untrusted Zone (WAN), the Encrypted (VPN), Wireless (WLAN), Multicast, or custom Zones of any type.

• A NAT lookup is performed and applied, as needed.

– In general, the destination for packets entering an L2 Bridge will be the Bridge-Partner interface (that is, the other side of the bridge). In these cases, no translation will be performed.

– In cases where the L2 Bridge Management Address is the gateway, as will sometimes be the case in Mixed-Mode topologies, then NAT will be applied as need (see the L2 Bridge Path Determination section for more details).

• Firewall Access Rules are applied to the packet. For example, the following packet decode shows an ICMP packet bearing VLAN ID 10, source IP address 110.110.110.110 destined for IP address 4.2.2.1.

It is possible to construct a Firewall Access Rule to control any IP packet, independent of its VLAN membership, by any of its IP elements, such as source IP, destination IP, or service type. If the packet is disallowed, it will be dropped and logged. If the packet is allowed, it will continue.

• A connection cache entry is made for the packet, and required NAT translations (if any) are performed.

• Stateful packet inspection and transformations are performed for TCP, VoIP, FTP, MSN, Oracle, RTSP and other media streams, PPTP and L2TP. If the packet is disallowed, it will be dropped and logged. If the packet is allowed, it will continue.

• Deep packet inspection, including GAV, IPS, Anti-Spyware, CFS and email-filtering is performed. If the packet is disallowed, it will be dropped and logged. If the packet is allowed, it will continue. Client notification will be performed as configured.

• If the packet is destined for the Encrypted Zone (VPN), the Untrusted Zone (WAN), or some other connected interface (the last two of which might be the case in Mixed-Mode Topologies) the packet will be sent via the appropriate path.

• If the packet is not destined for the VPN/WAN/Connected interface, the stored VLAN tag will be restored, and the packet (again bearing the original VLAN tag) will be sent out the Bridge-Partner interface.

Multiple Subnets in L2 Bridge ModeL2 Bridge Mode is capable of handling any number of subnets across the bridge, as described above. The default behavior is to allow all subnets, but Access Rules can be applied to control traffic as needed.

Non-IPv4 Traffic in L2 Bridge ModeUnsupported traffic will, by default, be passed from one L2 Bridge interface to the Bridge-Partner interface. This allows the SonicWALL to pass other traffic types, including LLC packets such as Spanning Tree, other EtherTypes, such as MPLS label switched packets (EtherType 0x8847), Appletalk (EtherType 0x809b), and the ever-popular Banyan Vines (EtherType 0xbad). These non-IPv4 packets will only be passed across the Bridge, they will not be inspected or controlled by the packet handler. If these traffic types are not needed



or desired, the bridging behavior can be changed by enabling the Block all non-IPv4 traffic option on the Secondary Bridge Interface configuration page.

Comparison of L2 Bridge Mode to Transparent Mode

The following table provides a comparison of L2 Bridge Mode and Transparent Mode.

L2 Bridge Mode Transparent Mode

Layer of Operation Layer 2 (MAC) Layer 3 (IP)

ARP behavior ARP (Address Resolution Protocol) information is unaltered. MAC addresses natively traverse the L2 bridge. Packets that are destined for SonicWALL’s MAC addresses will be processed, others will be passed, and the source and destinations will be learned and cached.

ARP is proxied by the interfaces operat-ing in Transparent Mode.

Path determination Hosts on either side of a Bridge-Pair are dynamically learned. There is no need to declare interface affinities.

The Primary WAN interface is always the master ingress/egress point for Transparent mode traffic, and for subnet space determination. Hosts transpar-ently sharing this subnet space must be explicitly declared through the use of Address Object assignments.

Maximum interfaces Two interfaces, a Primary Bridge Inter-face and a Secondary Bridge Interface.

Two or more interfaces. The master interface is always the Primary WAN. There can be as many transparent sub-ordinate interfaces as there are inter-faces available.

Maximum pairings The maximum number of Bridge-Pairs allowed is limited only by available physical interfaces. For example, a PRO 2040 could have two Bridge-Pairs (X1+X0, X2+X3), and a PRO 4100 could have five Bridge-Pairs, etc. This can be described as “many one-to-one pair-ings”.

Transparent Mode only allows the Pri-mary WAN subnet to be spanned to other interfaces, although it allows for multiple interfaces to simultaneously operate as transparent partners to the Primary WAN. This can be described as “a single one-to-one” or “a single one-to-many pairing”.

Zone restrictions The Primary Bridge Interface can be Untrusted, Trusted, or Public. The Sec-ondary Bridge Interface can be Trusted or Public.

Interfaces in a Transparent Mode pair must consist of one Untrusted interface (the Primary WAN, as the master of the pair’s subnet) and one or more Trusted/Public interface (e.g. LAN or DMZ).



Subnets supported Any number of subnets is supported. Firewall Access Rules can be written to control traffic to/from any of the sub-nets as needed.

In its default configuration, Transparent Mode only supports a single subnet (that which is assigned to, and spanned from the Primary WAN). It is possible to manually add support for additional sub-nets through the use of ARP entries and routes.

Non-IPv4 Traffic All non-IPv4 traffic, by default, is bridged from one Bridge-Pair interface to the Bridge-Partner interface, unless disabled on the Secondary Bridge Interface configuration page. This includes IPv6 traffic, STP (Spanning Tree Protocol), and unrecognized IP types.

Non IPv4 traffic is not handled by Trans-parent Mode, and is dropped and logged.

VLAN traffic VLAN traffic is passed through the L2 Bridge, and is fully inspected by the Stateful and Deep Packet Inspection engines.

VLAN sub-interfaces can be created and can be given Transparent Mode Address Object assignments, but the VLANs will be terminated by the Son-icWALL rather than passed.

VLAN sub-interfaces VLAN sub-interfaces can be configured on Bridge-Pair interfaces, but they will be passed through the bridge to the Bridge-Partner unless the destination IP address in the VLAN frame matches the IP address of the VLAN sub-interface on the Son-icWALL, in which case it will be proc-essed (e.g. as management traffic).

VLAN sub-interfaces can be assigned to physical interfaces operating in Trans-parent Mode, but their mode of opera-tion will be independent of their parent. These VLAN sub-interfaces can also be given Transparent Mode Address Object assignments, but in any event VLAN sub-interfaces will be terminated rather than passed.

PortShield interfaces PortShield interfaces cannot be assigned to either interface of an L2 Bridge Pair.

PortShield interfaces may be assigned a Transparent Mode range.

Dynamic addressing Although a Primary Bridge Interface may be assigned to the WAN Zone, only static addressing is allowable for Primary Bridge Interfaces.

Although Transparent Mode employs the Primary WAN as a master interface, only static addressing is allowable for Transparent Mode.

VPN support VPN operation is supported with no special configuration requirements.

VPN operation is supported with no spe-cial configuration requirements.

DHCP support DHCP can be passed through a Bridge-Pair.

Interfaces operating in Transparent Mode can provide DHCP services, or they can pass DHCP using IP Helper.

Routing and NAT Traffic will be intelligently routed in/out of the L2 Bridge-Pair from/to other paths. By default, traffic will not be NATed from one Bridge-Pair interface to the Bridge-Partner, but it can be NATed to other paths, as needed. Cus-tom routes and NAT policies can be added as needed.

Traffic will be intelligently routed from/to other paths. By default, traffic will not be NATed from/to the WAN to/from Trans-parent Mode interface, but it can be NATed to other paths, as needed. Cus-tom routes and NAT policies can be added as needed.



Benefits of Transparent Mode over L2 Bridge ModeThe following are circumstances in which Transparent Mode might be preferable over L2 Bridge Mode:

• Two interfaces are the maximum allowed in an L2 Bridge Pair. If more than two interfaces are required to operate on the same subnet, Transparent Mode should be considered.

• PortShield interface may not operate within an L2 Bridge Pair. If PortShield interfaces are required to operate on the same subnet, Transparent Mode should be considered.

• VLAN sub-interfaces may not operate within an L2 Bridge Pair. If VLAN sub-interfaces are required to operate on the same subnet, Transparent Mode should be considered. It is, however, possible to configure a VLAN sub-interface on an interface that is part of a Bridge-Pair; the sub-interface will simply operate independently on the Bridge-Pair in every respect.

Comparing L2 Bridge Mode to the CSM ApplianceL2 Bridge Mode is more similar in function to the CSM than it is to Transparent Mode, but it differs from the current (SonicOS CF 2.x Software) CSM behavior in that it handles VLANs and non-IPv4 traffic types,

Stateful Packet Inspec-tion

Full stateful packet inspection will be applied to all IPv4 traffic traversing the L2 Bridge, for all subnets, including VLAN traffic.

Full stateful packet inspection will applied to traffic from/to the subnets defined by Transparent Mode Address Object assignment.

Security services All security services (GAV, IPS, Anti-Spy, CFS) are fully supported. All regular IP traffic, as well as all 802.1Q encapsulated VLAN traffic.

All security services (GAV, IPS, Anti-Spy, CFS) are fully supported from/to the subnets defined by Trans-parent Mode Address Object assign-ment.

Broadcast traffic Broadcast traffic is passed from the receiving Bridge-Pair interface to the Bridge-Partner interface.

Broadcast traffic is dropped and logged, with the possible exception of NetBIOS which can be handled by IP Helper.

Multicast traffic Multicast traffic is inspected and passed across L2 Bridge-Pairs provid-ing Multicast has been activated on the Firewall > Multicast page. It is not dependent upon IGMP messaging, nor is it necessary to enable multicast sup-port on the individual interfaces.

Multicast traffic, with IGMP dependency, is inspected and passed by Transparent Mode providing Multicast has been acti-vated on the Firewall > Multicast page, and multicast support has been enabled on the relevant interfaces.



which the CSM does not. Future versions of the SonicOS CF Software for the CSM will likely adopt the more versatile traffic handling capabilities of L2 Bridge Mode.

L2 Bridge Path DeterminationPackets received by the SonicWALL on Bridge-Pair interfaces must be forwarded along to the appropriate and optimal path toward their destination, whether that path is the Bridge-Partner, some other physical or sub interface, or a VPN tunnel. Similarly, packets arriving from other paths (physical, virtual or VPN) bound for a host on a Bridge-Pair must be sent out the correct Bridge-Pair interface. The following summary describes, in order, the logic that is applied to path determinations for these cases:

1. If present, the most specific non-default route to the destination is chosen. This would cover, for example:

a. A packet arriving on X3 (non-L2 Bridge LAN) destined for host 15.1.1.100 subnet, where a route to the 15.1.1.0/24 subnet exists through 192.168.0.254 via the X0 (Secondary Bridge Interface, LAN) interface. The packet would be forwarded via X0 to the destination MAC address of 192.168.0.254, with the destination IP address 15.1.1.100.

b. A packet arriving on X4 (Primary Bridge Interface, LAN) destined for host 10.0.1.100, where a route to the 10.0.1.0/24 exists through 192.168.10.50 via the X5 (DMZ) interface. The packet would be forwarded via X5 to the destination MAC address of 192.168.10.50, with the destination IP address 10.0.1.100.

2. If no specific route to the destination exists, an ARP cache lookup is performed for the destination IP address. A match will indicate the appropriate destination interface. This would cover, for example:

a. A packet arriving on X3 (non-L2 Bridge LAN) destined for host 192.168.0.100 (residing on L2 Primary Bridge Interface X2). The packet would be forwarded via X2 to the known destination MAC and IP address of 192.168.0.100, as derived from the ARP cache.

b. A packet arriving on X4 (Primary Bridge Interface, LAN) destined for host 10.0.1.10 (residing on X5 – DMZ). The packet would be forwarded via X5 to the known destination MAC and IP address of 10.0.1.10, as derived from the ARP cache.

3. If no ARP entry is found:

a. If the packet arrived on a Bridge-Pair interface, it will be sent to the Bridge-Partner interface.

b. If the packet arrived from some other path, the SonicWALL will send an ARP request out both interfaces of the Bridge-Pair to determine on which segment the destination IP resides.

In this last case, since the destination is unknown until after an ARP response is received, the destination Zone also remains unknown until that time. This precludes the SonicWALL from being able to apply the appropriate Access Rule until after path determination is completed. Upon completion, the correct Access Rule will be applied to subsequent related traffic.

With regard address translation (NAT) of traffic arriving on an L2 Bridge-Pair interface:

• If it is determined to be bound for the Bridge-Partner interface, no IP translation (NAT) will be performed.

• If it is determined to be bound for a different path, appropriate NAT policies will apply:

• If the path is another connected (local) interface, there will likely be no translation. That is, it will effectively be routed as a result of hitting the last-resort Any->Original NAT Policy.

• If the path is determined to be via the WAN (which will be common in the case of Mixed-Mode topologies, such as that depicted in the Internal Security example on page 8) then the default Auto-added [interface] outbound NAT Policy for X1 WAN will apply, and the packet’s source will be translated for delivery to the Internet.



L2 Bridge Interface Zone SelectionBridge-Pair interface Zone assignment should be done according to your network’s traffic flow requirements. Unlike Transparent Mode, which imposes a system of “more trusted to less trusted” by requiring that the source interface be the Primary WAN, and the transparent interface be Trusted or Public, L2 Bridge mode allows for greater control of operational levels of trust. Specifically, L2 Bridge Mode allows for the Primary and Secondary Bridge Interfaces to be assigned to the same or different Zones (e.g. LAN+LAN, LAN+DMZ, WAN+CustomLAN, etc.) This will affect not only the default Access Rules that are applied to the traffic, but also the manner in which Deep Packet Inspection security services are applied to the traffic traversing the bridge. Important areas to consider when choosing and configuring interfaces to use for in a Bridge-Pair are Security Services, Access Rules, and WAN connectivity:

Security Services Directionality

As it will be one of the primary employments of L2 Bridge mode, understanding the application of security services is important to the proper Zone selection for Bridge-Pair interfaces. Security services applicability is based on the following criteria:

1. The direction of the service:

• GAV is primarily an Inbound service, inspecting inbound HTTP, FTP, IMAP, SMTP, POP3, and TCP Streams. It also has an additional Outbound element for SMTP.

• Anti Spyware is also primarily Inbound, inspecting inbound HTTP, FTP, IMAP, SMTP, POP3 for the delivery (i.e. retrieval) of Spyware components as generally recognized by their class IDs.

• It also has an additional Outbound component, where Outbound is used relative to the directionality (namely, Outgoing) ascribed to it by the IPS signatures that trigger the recognition of these Spyware components. The Outgoing classifier (described in the table below) is used because these components are generally retrieved by the client (e.g. LAN host) via HTTP from a web-server on the internet (WAN host). Referring to the table below, that would be an Outgoing connection, and requires a signature with an Outgoing directional classification.

• IPS has three directions: Incoming, Outgoing, and Bidirectional. Incoming and Outgoing are described in the table below, and Bidirectional refers to all points of intersection on the table.

• For additional accuracy, other elements are also considered, such as the state of the connection (e.g. SYN or Established), and the source of the packet relative to the flow (i.e. initiator or responder).

2. The direction of the traffic. The direction of the traffic as it pertains to IPS is primarily determined by the Source and Destination Zone of the traffic flow. When a packet is received by the SonicWALL, its source Zone is generally immediately known, and its destination Zone is quickly determined by doing a route (or VPN) lookup. Based on the source and destination, the packet’s directionality is categorized as either Incoming or Outgoing, (not to be confused with Inbound and Outbound) where the following criteria is used to make the determination:

In addition to this categorization, packets traveling to/from Zones with levels of additional trust, which are inherently afforded heightened levels of security (LAN|Wireless|Encrypted<-->LAN|Wireless|Encrypted) are given the special Trust classification. Traffic with the Trust classification has all signatures applied (Incoming, Outgoing, and Bidirectional).

Dest Src Untrusted Public Wireless Encrypted Trusted Multicast

Untrusted Incoming Incoming Incoming Incoming Incoming Incoming Public Outgoing Outgoing Outgoing Incoming Incoming Incoming Wireless Outgoing Outgoing Trust Trust Trust Incoming Encrypted Outgoing Outgoing Trust Trust Trust Outgoing Trusted Outgoing Outgoing Trust Trust Trust Outgoing



3. The direction of the signature. This pertains primarily to IPS, where each signature is assigned a direction by SonicWALL’s signature development team. This is done as an optimization to minimize false positives. Signature directions are:

• Incoming – Applies to Incoming and Trust. The majority of signatures are Incoming, and they include all forms of application exploits and all enumeration and footprinting attempts. Approximately 85% of signatures are Incoming.

• Outgoing – Applies to Outgoing and Trust. Examples of Outgoing signatures would include IM and P2P login attempts, and responses to successfully launched exploits (e.g. Attack Responses). Approximately 10% of signatures are Outgoing.

• Bidirectional – Applies to all. Examples of Bidirectional signatures would include IM file transfers, various NetBIOS attacks (e.g. Sasser communications) and a variety of DoS attacks (e.g. UDP/TCP traffic destined to port 0). Approximately 5% of signatures are Bidirectional.

4. Zone application. For a signature to be triggered, the desired security service must be active on at least one of the Zones it traverses. For example, a host on the internet (X1, WAN) accessing a Microsoft Terminal Server (on X3, Secondary Bridge Interface, LAN) will trigger the Incoming signature “IPS Detection Alert: MISC MS Terminal server request, SID: 436, Priority: Low” if IPS is active on the WAN, the LAN, or both.

Access Rule DefaultsDefault Zone to Zone Access Rules. The default Access Rules should be considered, although they can be modified as needed. The defaults are as follows:

WAN ConnectivityInternet (WAN) connectivity is required for stack communications, such as licensing, security services signature downloads, NTP (time synchronization), and CFS (Content Filtering Services). At present, these communications can only occur through the Primary WAN interface. If you require these types of communication, the Primary WAN should have a path to the Internet. Whether or not the Primary WAN is employed as part of a Bridge-Pair will not affect its ability to provide these stack communications (for example on a PRO 4100, X0+X2 and X3+X4 could be used to create two Bridge-Pairs separate of X1).

Tip If Internet connectivity is not available, licensing can be performed manually (http://www.sonicwall.com/support/pdfs/technotes/Manual_Upgrade_Closed_Environments_Technote.pdf) and signature updates can also be performed manually (http://www.sonicwall.com/support/pdfs/Configuring_Manual_Signature_Updates.pdf).



Sample TopologiesThe following are sample topologies depicting common deployments. Perimeter Security represents the addition of a SonicWALL security appliance in pure L2 bridge-mode to an existing network, where the SonicWALL is placed near the perimeter of the network. Internal Security represents the full integration of a SonicWALL security appliance in mixed-mode, where it provides simultaneous L2 bridging, WLAN services, and NATed WAN access.

Perimeter Security

The above diagram depicts a network where the SonicWALL is added to the perimeter for the purposes of providing security services (the network may or may not have an existing firewall between the SonicWALL and the router). In this scenario, everything to the right of the SonicWALL (the Primary Bridge Interface segment) will generally be considered as having a lower level of trust than everything to the left of the SonicWALL (the Secondary Bridge Interface segment). For that reason, it would be appropriate to use X1 (Primary WAN) as the Primary Bridge Interface.

Traffic from hosts connected to the Secondary Bridge Interface (LAN) would be permitted outbound through the SonicWALL to their gateways (VLAN interfaces on the L3 switch and then through the router), while traffic from the Primary Bridge Interface (WAN) would, by default, not be permitted inbound.

If there were public servers, for example, a mail and web server, on the Secondary Bridge Interface (LAN) segment, an Access Rule allowing WAN->LAN traffic for the appropriate IP addresses and services could be added to allow inbound traffic to those servers.



Internal Security

This diagram depicts a network where the SonicWALL will act as the perimeter security device and secure wireless platform. Simultaneously, it will provide L2 Bridge security between the workstation and server segments of the network without having to readdress any of the workstation or servers.

This typical inter-departmental Mixed Mode topology deployment demonstrates how the SonicWALL can simultaneously Bridge and route/NAT. Traffic to/from the Primary Bridge Interface (Server) segment from/to the Secondary Bridge Interface (Workstation) segment will pass through the L2 Bridge.

Since both interfaces of the Bridge-Pair are assigned to a Trusted (LAN) Zone, all traffic will be allowed by default, but Access Rules could be constructed as needed.

Consider, for the point of contrast, what would occur if the X2 (Primary Bridge Interface) was instead assigned to a Public (DMZ) Zone: All the Workstations would be able to reach the Servers, but the Servers would not be able to initiate communications to the Workstations. While this would probably support the traffic flow requirements (i.e. Workstations initiating sessions to Servers), it would have two undesirable effects:

1. The DHCP server would be in the DMZ. DHCP requests from the Workstations would pass through the L2 Bridge to the DHCP server (192.168.0.100), but the DHCP offers from the server would be dropped by the default DMZ->LAN Deny Access Rule. An Access Rule would have to be added, or the default modified, to allow this traffic from the DMZ to the LAN.

2. Security services directionality would be classified as Outgoing for traffic from the Workstations to the Server since the traffic would have a Trusted source Zone and a Public destination Zone. This might be sub-optimal since it would provide less scrutiny than the Incoming or (ideally) Trust classifications.

• Security services directionality would be classified as Trust, and all signatures (Incoming, Outgoing, and Bidirectional) will be applied, providing the highest level of security to/from both segments.


S o n i c WA L L E a r l y F i e l d T r i a l ( E F T ) D r a f t - I n t e r n a l U s e O n l yWireless WAN Overview

Wireless WAN OverviewThis section provides an overview of WWAN. It contains the following sections:

• “What is WWAN?” on page 56

• “Understanding Wireless WAN Connection Models” on page 56

• “Understanding WWAN Failover” on page 58

• “Wireless WAN PC Card Support” on page 63

• “3G Wireless WAN Service Provider Support” on page 63

What is WWAN?The SonicWALL TZ 190 security appliance introduces support for 3G (Third Generation) Wireless WAN connections that utilize data connections over 3G Cellular networks. The Wireless WAN (WWAN) can be used for:

• WAN Failover to a connection that is not dependent on wire or cable.

• Temporary networks where a pre-configured connection may not be available, such as trade-shows and kiosks.

• Mobile networks, were the SonicWALL TZ 190 is based in a vehicle.

• Primary WAN connection where wire-based connections are not available and 3G Cellular is.

Wireless Wide Area Networks provide untethered remote network access through the use of mobile or cellular data networks. While legacy cellular networks, such as GSM, were only able to provide data rates of about 14 Kbps, today's emerging WWAN technologies (such as UMTS and HSDPA) provide theoretical data rates of up to 10 Mbps, rivaling many wired technologies.

The cellular networks powering Wireless Wide Area Networking have been evolving very quickly, and as a result comprise many different implementations. Fundamentally, they fall into two protocols:

• GSM - Global System for Mobile Communication - The most widely used protocol outside of the Americas. GSM is often regarded as less susceptible to signal degradation indoors. Although GSM is used both in the Americas and the rest of the world, the American implementation operates on a different frequency, and interoperability is not guaranteed unless explicitly supported by the equipment.

• CDMA - Code Division Multiple Access - The most widely used protocol in the Americas. CDMA has capacity advantages over GSM, but congestion tends to reduce its operating range.

Understanding Wireless WAN Connection ModelsThe TZ190 with SonicOS Enhanced 3.6 provides flexible control over WAN connectivity with the WAN Connection Model setting. Accessible from the Network > Interfaces page of the management interface, the WAN Connection Model settings allows the administrator to precisely control the behavior of the WWAN connection. The three settings are as follows:



• WWAN Only – For use when the WWAN is the only WAN connection in use on the TZ190.

• Ethernet Only – For use when the WWAN is to be disabled. The Ethernet WAN (the WAN port, OPT port, or both) is the only WAN connection in use on the TZ190.

• Ethernet with WWAN Failover – For use when both the WWAN and the Ethernet WAN (the WAN port, OPT port, or both) are to serve as WAN connections on the TZ190.

In addition to the WAN Connection Model setting, the following changes were also introduced in SonicOS Enhanced 3.6 to optimize the operation of the WWAN interface:

• To more accurately reflect the operation of WAN load balancing and Failover sub-system, the WAN Failover & LB page has been renamed to Ethernet LB.

• Failover between the Ethernet WAN (the WAN port, OPT port, or both) and the WWAN is supported through the WAN Connection Model setting, but Load-balancing is currently only supported on Ethernet WAN interfaces. WWAN interface traffic statistics will continue to be displayed in the WAN Load Balancing Statistics table on the Network > Ethernet LB page.

• The WAN Load-balancing and Failover sub-system is now permanently enabled for more transparent support of the WAN Connection Model setting. This was previously controlled by the Enable Load Balancing setting on the WAN Failover & LB page.

• WWAN interface probe monitoring appears on the WWAN > Settings page under the WWAN Probe Settings heading. (Ethernet WAN interface probe settings is unchanged on the Network > Ethernet LB page under the WAN Interfaces Monitoring section.)



Understanding WWAN FailoverWhen the WAN Connection Model is set to Ethernet with WWAN Failover, the WAN (Ethernet) interface is the primary connection. If the WAN interface fails, the SonicWALL TZ 190 fails over to the WWAN interface.

Note It is important to note that the WAN-to-WWAN failover process is different for the three different WWAN Connection Profile dial types: Persistent, Dial on Data, and Manual Dial.

The following sections describe the three different methods of WAN-to-WWAN failover:

• “Persistent Connection WWAN Failover” on page 59

• “Dial on Data WWAN Failover” on page 60

• “Manual Dial WWAN Failover” on page 62



Persistent Connection WWAN FailoverThe following diagram depicts the sequence of events that occur when the WAN ethernet connection fails and the WWAN Connection Profile is configured for Persistent Connection.

1. Primary Ethernet connection available – The Ethernet WAN interface is connected and used as the primary connection. WWAN is never connected while the Ethernet WAN interface is available (unless an explicit route has been configured which specifies WWAN as the destination interface).

2. Primary Ethernet connection fails – The WWAN connection is initiated and remains in an “always-on” state while the Ethernet WAN connection is down.

3. If a secondary Ethernet WAN (the OPT port) is configured, the TZ190 will first failover to the secondary Ethernet WAN before failing over to the WWAN. In this situation, WWAN failover will only occur when both the WAN and OPT paths are unavailable.

4. Reestablishing Primary Ethernet Connectivity After Failover – When the Ethernet WAN connection (either the WAN port or the OPT port, if so configured) becomes available again, all LAN-to-WAN traffic is automatically routed back to the available Ethernet WAN connection. This includes active connections and VPN connections. The WWAN connection is closed.



Note It is not recommended to configure a policy-based route that uses the WWAN connection when the WAN Connection Model is set for Ethernet with WWAN Failover. If a policy-based route is configured to use the WWAN connection, the connection will remain up until the Maximum Connection Time (if configured) is reached.

Dial on Data WWAN FailoverThe following diagram depicts the sequence of events that occur when the WAN ethernet connection fails and the WWAN Connection Profile is configured for Dial on Data.

1. Primary Ethernet connection available – The Ethernet WAN interface is connected and used as the primary connection. WWAN is never connected while the Ethernet WAN interface is available (unless an explicit route has been configured which specifies WWAN as the destination interface).



2. Primary Ethernet Connection Fails – The WWAN connection is not established until qualifying outbound data attempts to pass through the SonicWALL TZ 190 appliance.

3. WWAN Connection Established – The WWAN connection is established when the device or a network node attempts to transfer qualifying data to the Internet. The WWAN connection stays enabled until the Maximum Connection Time (if configured) is reached.

4. Reestablishing WAN Ethernet Connectivity After Failover – When an Ethernet WAN connection becomes available again, all LAN-to-WAN traffic is automatically routed back to the available Ethernet WAN connection. The WWAN connection is closed.

Note It is not recommended to configure a policy-based route that uses the WWAN connection when the WAN Connection Model is set for Ethernet with WWAN Failover. If a policy-based route is configured to use the WWAN connection, the connection will remain up until the Maximum Connection Time (if configured) is reached.



Manual Dial WWAN FailoverThe following diagram depicts the sequence of events that occur when the WAN ethernet connection fails and the WWAN Connection Profile is configured for Manual Dial.

Note It is not recommended to use a Manual Dial WWAN Connection Profile when the WAN Connection Model is set for Ethernet with WWAN Failover. The Manual Dial WWAN Connection Profile is only intended to be used when the device's WAN Connection Model is set to WWAN Only in the Network > Interfaces page.

1. Primary Ethernet Connection Available - The Ethernet WAN is connected and used as the primary connection. WWAN is never connected while the Ethernet WAN connection is available.

2. Primary Ethernet Connection Fails - The WWAN connection is not established until the administrator manually enables the connection.



3. WWAN Connection Established – A WWAN connection is established when the administrator manually enables the connection on the SonicWALL TZ 190. The WWAN connection stays enabled until the administrator manually disables the connection.

4. Reestablishing WAN Ethernet Connectivity After Failover – Regardless of whether the an Ethernet connection becomes available again, all LAN-to-WAN traffic will still use the manually enabled WWAN connection until the connection is manually disabled by the administrator. After a manual disconnect, the available Ethernet connection will be used.

Wireless WAN PC Card SupportTo use the wireless WAN interface you must have a wireless WAN PC card and a contract with a wireless service provider. Because both GSM and CDMA provide virtually the same performance, a WWAN service provider should be selected based primarily on the availability of supported hardware. SonicOS 3.6 Enhanced and the SonicWALL TZ 190 support the following wireless WAN PC cards (this list subject to change):

• Option Globe Trotter GTmax World (GPRS/EDGE/UMTS/HSDPA)

• Option Globe Trotter HSDPA (GPRS/EDGE/UMTS/HSDPA)

• Sierra Wireless Aircard 860 (GPRS/EDGE/UMTS/HSDPA)

• Sprint Novatel Merlin s620 (CDMA/EVDO)

• Verizon Wireless v620 (CDMA/EVDO)

3G Wireless WAN Service Provider SupportSonicOS 3.6 Enhanced and the SonicWALL TZ 190 support the following 3G Wireless network providers (this list is subject to change):

• Cingular Wireless

• H3G

• Sprint PCS Wireless

• Verizon Wireless

• Vodafone

• Telecom Italia Mobile

• Telefonica

• T-Mobile

• TDC Song

• Orange

Wireless WAN PrerequisitesBefore configuring the Wireless WAN interface on the SonicWALL TZ 190, you must complete the following prerequisites:

– Purchase a wireless WAN service plan from a supported third-party wireless provider

– Configure and activate your wireless WAN PC card

– Insert the Wireless WAN PC card into the SonicWALL TZ 190


S o n i c WA L L E a r l y F i e l d T r i a l ( E F T ) D r a f t - I n t e r n a l U s e O n l yGlossary

For information on configuring these prerequisites, see the SonicWALL TZ 190 Getting Started Guide.

GlossaryADConnector (ADC) - A SonicWALL Active Directory authentication agent.

Centralized Identification Agent (CIA) - The authentication method used by SonicWALL security appliances to return the identity of a user at an IP address using ADConnector-compatible protocol.

Single Sign-on - A method of automatic authentication that recognizes a user upon network login.

Solution Document Version History

Version Number Date Notes1 10/10/2006 This document was created.

2 1/31/2007 Added 3.5 and 3.6 features.


Documents

SonicOS Enhanced 4.0 Feature Guidesoftware.sonicwall.com/firmware/beta/documentation/Sonic...SonicWALL Early Field Trial (EFT) Draft - Internal Use Only Application Firewall Overview