S o n i c WA L L E a r l y F i e l d T r i a l D r a f t
Single Sign-On in SonicOS Enhanced 4.0

Document Scope

This document describes how to plan, design, implement, and maintain the Single Sign-On feature in the SonicWALL SonicOS Enhanced 4.0. This document contains the following sections:
Single Sign-On Overview section on page 2
What Is Single Sign-On? section on page 2 Benefits section on page 3 Platforms section on page 3 Supported Standards section on page 3 How Does Single Sign-On Work? section on page 4
Configuring Single Sign-On Task List section on page 7
Installing the SonicWALL SSO Agent section on page 8 Configuring the SonicWALL SSO Agent section on page 14 Configuring Your SonicWALL Security Appliance section on page 21
Glossary section on page 33
SonicWALL SonicOS 4.0 Enhanced Single Sign-on

Single Sign-On Overview

This 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 2 Benefits section on page 3 How Does Single Sign-On Work? section on page 4 Platforms section on page 3

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 provide SSO functionality using the SonicWALL Single Sign-On Agent (SSO Agent) to identify user activity based on workstation IP address. 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 SSO Agent 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 SSO Agent, 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 1 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 2 Access Denied

SonicWALL SonicOS 4.0 Enhanced Single Sign-On

Benefits

SonicWALL 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 service 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 Users are not required to re-enter user name and password for authentication. Secure communication Shared key encryption for data transmission protection. SonicWALL SSO Agent can be installed on any workstation on the LAN. Login mechanism works with any protocol, not just HTTP.

Platforms

SSO is available on SonicWALL security appliances running SonicOS Enhanced 4.0.

Supported Standards

The SonicOS Enhanced 4.0 SSO feature supports LDAP and local database protocols. To use SonicWALL SSO, it is required that the SonicWALL SSO Agent be installed on the workstations 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 SSO Agent:
Port 2258 must be open; the firewall uses UDP port 2258 by default to communicate with SonicWALL SSO Agent Windows 32 or XP, with latest service pack.NET Framework 2.0 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 3.
Figure 3 SonicWALL Single Sign-On Process
The SonicWALL SSO authentication process 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 the SSO Agent. The authorization agent running the SSO Agent 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 the memberships against policy, and grant or restrict access to the user 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 the SSO Agent 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 the SSO Agent (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 users 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 the SSO Agent 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 the SSO Agent sends a User Logged Out response to the SonicWALL security appliance, confirming the user has been logged out and terminating the SSO session.

The notes field of log messages specific to the SSO Agent will contain the text <domain/user-name>, authentication by SSO Agent.
Configuring SSO is a process that includes installing and configuring the SonicWALL SSO Agent and configuring a SonicWALL security appliance running SonicOS Enhanced 4.0 to use the SSO Agent. This section contains the following subsections:
Installing the SonicWALL SSO Agent section on page 8 Configuring the SonicWALL SSO Agent section on page 14
Adding a SonicWALL Security Appliance section on page 18 Editing Appliances in SonicWALL SSO Agent section on page 20 Deleting Appliances in SonicWALL SSO Agent section on page 20 Modifying Services in SonicWALL SSO Agent section on page 20
Configuring Your SonicWALL Security Appliance section on page 21
Advanced LDAP Configuration section on page 25
Configuring Firewall Access Rules section on page 32
Viewing User Status section on page 32 Configuring User Settings section on page 33
Installing the SonicWALL SSO Agent
The SonicWALL SSO Agent is part of the SonicWALL Directory Connector. The SonicWALL SSO Agent must be installed on a workstation or server in the Windows domain that is accessible using VPN or IP. The SonicWALL SSO Agent must have access to your SonicWALL security appliance running SonicOS 4.0 or higher. To install the SonicWALL SSO Agent, perform the following steps:

Step 1

Locate the SonicWALL Directory Connector executable file and double click it. It may take several seconds for the InstallShield to prepare for the installation.

Step 2

On the Welcome page, click Next to continue.

Step 3

The License Agreement displays. Select I accept the terms in the license agreement and click Next to continue.

Step 4

On the Customer Information page, enter your name in the User Name field and your organization name in the Organization field. Select to install the application for Anyone who uses this computer (all users) or Only for me. Click Next to continue.

Step 5

Select the destination folder. To use the default folder, C:\Program Files\SonicWALL\DCON, click Next. To specify a custom location, click Browse, select the folder, and click Next.

Step 6

On the Custom Setup page, the installation icon Agent feature. Click Next.
is displayed by default next to the SonicWALL SSO

Step 7

Click Install to install SSO Agent.

Step 8

To configure a common service account that the SSO Agent will use to log into a specified Windows domain, enter the username of an account with administrative privileges in the Username field, the password for the account in the Password field, and the domain name of the account in the Domain Name field. Click Next.

You can edit all settings on SonicWALL security appliances previously added in SonicWALL SSO Agent, including IP address, port number, friendly name, and shared key. To edit a SonicWALL security appliance in SonicWALL SSO Agent, select the appliance from the left-hand navigation panel and click the edit icon above the left-hand navigation panel. You can also click the Edit tab at the bottom of the right-hand window.
Deleting Appliances in SonicWALL SSO Agent
To delete a SonicWALL security appliance you previously added in SonicWALL SSO Agent, select the appliance from the left-hand navigation panel and click the delete icon above the left-hand navigation panel.
Modifying Services in SonicWALL SSO Agent
You can start, stop, and pause SonicWALL SSO Agent services to SonicWALL security appliances. To pause services for an appliance, select the appliance from the left-hand navigation panel and click the pause button. To stop services for an appliance, select the appliance from the left-hand navigation panel and click the stop button. To resume services, click the start button.
You may be prompted to restart services after making configuration changes to a SonicWALL security appliance in the SonicWALL SSO Agent. To restart services, press the stop button then press the start button.
Configuring Your SonicWALL Security Appliance
Your SonicWALL security appliance running SonicOS Enhanced 4.0 must be configured to use SonicWALL SSO Agent as the SSO method. To configure your SonicWALL security appliance, perform the following steps:

Step 1 Step 2 Step 3

Login to your SonicWALL security appliance running SonicOS Enhanced 4.0. Navigate to Users > Settings. In the Single-sign-on method drop-down menu, select SonicWALL SSO Agent.
Click Configure.The Authentication Agent Settings page displays.
Step 5 Step 6 Step 7 Step 8 Step 9
In the Name or IP Address field, enter the name or IP Address of the workstation on which SonicWALL SSO Agent is installed. In Port Number, enter the port number of the workstation on which SonicWALL SSO Agent is installed. The default port is 2258. In the Shared Key field, enter the shared key that you created or generated in the SonicWALL SSO Agent. The shared key must match exactly. Re-enter the shared key in the Confirm Shared Key field. In the Timeout (seconds) field, enter a number of seconds before the authentication attempt times out. In the Retries field, enter the number of authentication attempts.

Step 10 Click the Users tab. The User Settings page displays.
Step 11 Check the box next to Allow only users listed locally to allow only users listed locally to be authenticated. Step 12 Check the box next to Simple user names in local database to use simple user names. This setting ignores
the domain component of a user name. If this box is not checked, user names in the local database must match exactly the full names returned from the agent, including the domain component.
Step 13 To use LDAP to retrieve user information, select the Use LDAP to retrieve user group information radio
button. Click Configure to configure the LDAP settings. The LDAP Configuration page displays. For configuration information for this page, refer to Advanced LDAP Configuration section on page 25.
Step 14 To use local configuration, select the Local configuration radio button. Step 15 In the Polling rate (minutes) field, enter a polling interval, in minutes, that the security appliance will poll
the workstation running SSO Agent to verify that users are still logged on.
Step 16 In the Hold time after (minutes) field, enter a time, in minutes, that the security appliance will wait before
trying again to identify traffic after an initial failure to do so. This feature rate-limits requests to the agent.
Step 17 Click the Test tab. The Test Authentication Agent Settings page displays.
Step 18 Select the Check agent connectivity radio button then click the Test button. This will test communication
with the authentication agent. If the SonicWALL security appliance can connect to the agent, you will see the message Agent is ready.
Step 19 Select the Check user radio button, enter the IP address of a workstation in the Workstation IP address
field, then click Test. This will test if the agent is property configured to identify the user logged into a workstation.
Performing tests on this page applies any changes that have been made.
If you receive the messages Agent is not responding or Configuration error, check your settings and perform these tests again.
Step 20 When you are finished, click OK.
Advanced LDAP Configuration
If you selected Use LDAP to retrieve user group information in step 13 of Configuring Your SonicWALL Security Appliance section on page 21, you must configure your LDAP settings. To configure LDAP settings, perform the following steps:
The Settings tab displays. In the Name or IP address field, enter the name or IP address of your LDAP server.

Step 2 Step 3

In the Port Number field, enter the port number of your LDAP server. The default port is 636. In the Server timeout (seconds) field, enter a number of seconds the SonicWALL security appliance will wait for a response from the LDAP server before the attempt times out. Allowable values are 1 to 99999. The default is 10 seconds. Check the Anonymous login box to login anonymously. Some LDAP servers allow for the tree to be accessed anonymously. If your server supports this (MS AD generally does not), you may select this option.

To login with a users name and password, enter the users name in the Login user name field and the password in the Login password field. The login name will automatically be presented to the LDAP server in full dn notation.
Use the users name in the Login user name field, not a username or login ID. For example, John Doe would login as John Doe, not jdoe. Select the LDAP version from the Protocol version drop-down menu, either LDAP version 2 I (LDAPv2) or LDAP version 3 (LDAPv3). Most implementations of LDAP, including AD, employ LDAPv3. Check the Use TLS (SSL) box to use Transport Layer Security (SSL) to login to the LDAP server. It is strongly recommended to use TLS to protect the username and password information that will be sent across the network. Most implementations of LDAP server, including AD, support TLS. Check the Send LDAP Start TLS request to allow the LDAP server to operate in TLS and non-TLS mode on the same TCP port. Some LDAP server implementations support the Start TLS directive rather than using native LDAP over TLS. This allows the LDAP server to listen on one port (normally 389) for LDAP connections, and to switch to TLS as directed by the client. AD does not use this option, and it should only be selected if required by your LDAP server.

Step 6 Step 7

Only check the Send LDAP Start TLS request box if your LDAP server uses the same port number for TLS and non-TLS. Check the Require valid certificate from server to require a valid certificate from the server. Validates the certificate presented by the server during the TLS exchange, matching the name specified above to the name on the certificate. Deselecting this default option will present an alert, but exchanges between the SonicWALL security appliance and the LDAP server will still use TLS only without issuance validation. only if the LDAP server requires a client certificate for connections. This feature is useful for LDAP server implementations that return passwords to ensure the identity of the LDAP client (AD does not return passwords). This setting is not required for AD.
Step 10 Select a local certificate from the Local certificate for TLS drop-down menu. This is optional, to be used

Step 11 Click Apply.

Step 12 Click the Schema tab.
Step 13 From the LDAP Schema pull-down menu, select one of the following LDAP schemas. Selecting any of the
predefined schemas will automatically populate the fields used by that schema with their correct values. Selecting user-defined will allow you to specify your own values use this only if you have a specific or proprietary LDAP schema configuration.

Microsoft Active Directory RFC2798 InetOrgPerson RFC2307 Network Information Service Samba SMB Novell eDirectory User defined Step 14 The Object class field defines which attribute represents the individual user account to which the next two
fields apply. This will not be modifiable unless you select User defined.
Step 15 The Login name attribute field defines which attribute is used for login authentication. This will not be
modifiable unless you select User defined.
Step 16 If the Qualified login name attribute field is not empty, it specifies an attribute of a user object that sets
an alternative login name for the user in name@domain format. This may be needed with multiple domains in particular, where the simple login name may not be unique across domains. This is set to mail for Microsoft Active Directory and RFC2798 inetOrgPerson.
Step 17 The User group membership attribute field contains the information in the user object of which groups
it belongs to. This is memberOf in Microsoft Active Directory. The other pre-defined schemas store group membership information in the group object rather than the user object, and therefore do not use this field.
Step 18 The Framed IP address attribute field can be used to retrieve a static IP address that is assigned to a user
in the directory. Currently it is only used for a user connecting using L2TP with the SonicWALL security appliance L2TP server. In future releases, this may also be supported for the SonicWALL Global VPN Client (GVC). In Active Director, the static IP address is configured on the Dial-in tab of a users properties.
Step 19 The Object class field defines the type of entries that an LDAP directory may contain. A sample object
class, as used by AD, would be user or group.
Step 20 The Member attribute field defines which attribute is used for login authentication. Step 21 Select the Directory tab.
Step 22 In the Primary Domain field, specify the user domain used by your LDAP implementation. For AD, this
will be the Active Directory domain name, such as yourADdomain.com. Changes to this field will, optionally, automatically update the tree information in the rest of the page. This is set to mydomain.com by default for all schemas except Novell eDirectory, for which it is set to o=mydomain.

Step 23 In the User tree for login to server field, specify the tree in which the user specified in the Settings tab
resides. For example, in AD the administrator accounts default tree is the same as the user tree.
Step 24 In the Trees containing users field, specify the trees where users commonly reside in the LDAP directory.
One default value is provided that can be edited, a maximum of 64 DN values may be provided, and the SonicWALL security appliance searches the directory until a match is found, or the list is exhausted. If you have created other user containers within your LDAP or AD directory, you should specify them here.
Step 25 In the Trees containing user groups specify the trees where user groups commonly reside in the LDAP
directory. A maximum of 32 DN values may be provided. These are only applicable when there is no user group membership attribute in the schema's user object, and are not used with AD. The above-mentioned trees are normally given in URL format but can alternatively be specified as distinguished names (for example, myDom.com/Sales/Users could alternatively be given as the DN ou=Users,ou=Sales,dc=myDom,dc=com). The latter form will be necessary if the DN does not conform to the normal formatting rules as per that example. In Active Directory the URL corresponding to the distinguished name for a tree is displayed on the Object tab in the properties of the container at the top of the tree.
AD has some built-in containers that do not conform (for example, the DN for the top level Users container is formatted as cn=Users,dc=, using cn rather than ou) but the SonicWALL knows about and deals with these, so they can be entered in the simpler URL format. Ordering is not critical, but since they are searched in the given order it is most efficient to place the most commonly used trees first in each list. If referrals between multiple LDAP servers are to be used, then the trees are best ordered with those on the primary server first, and the rest in the same order that they will be referred.
When working with AD, to locate the location of a user in the directory for the User tree for login to server field, the directory can be searched manually from the Active Directory Users and Settings control panel applet on the server, or a directory search utility such as queryad.vbs in the Windows NT/2000/XP Resource Kit can be run from any PC in the domain.

Step 26 The Auto-configure button causes the SonicWALL security appliance to auto-configure the Trees
containing users and Trees containing user groups fields by scanning through the directory/directories looking for all trees that contain user objects. The User tree for login to server must first be set. Select whether to append new located trees to the current configuration, or to start from scratch removing all currently configured trees first, and then click OK. Note that it will quite likely locate trees that are not needed for user login and manually removing such entries is recommended. If using multiple LDAP/AD servers with referrals, this process can be repeated for each, replacing the Domain to search accordingly and selecting Append to existing trees on each subsequent run.
Step 27 Select the LDAP Users tab.
Step 28 Check the Allow only users listed locally box to require that LDAP users also be present in the
SonicWALL security appliance local user database for logins to be allowed.
Step 29 Check the User group membership can be set locally by duplicating LDAP user names box to allow
for group membership (and privileges) to be determined by the intersection of local user and LDAP user configurations.
Step 30 From the Default LDAP User Group pull-down menu, select a default group on the SonicWALL security
appliance to which LDAP users will belong in addition to group memberships configured on the LDAP server. Group memberships (and privileges) can also be assigned simply with LDAP. By creating user groups on the LDAP/AD server with the same name as SonicWALL security appliance built-in groups (such as Guest Services, Content Filtering Bypass, Limited Administrators) and assigning users to these groups in the directory, or creating user groups on the SonicWALL security appliance with the same name as existing LDAP/AD user groups, SonicWALL group memberships will be granted upon successful LDAP authentication. The SonicWALL security appliance can retrieve group memberships more efficiently in the case of Active Directory by taking advantage of its unique trait of returning a memberOf attribute for a user.
Step 31 Select the LDAP Relay tab.
Step 32 Check the Enable RADIUS to LDAP Relay box to enable RADIUS to LDAP relay. The RADIUS to
LDAP Relay feature is designed for use in a topology where there is a central site with an LDAP/AD server and a central SonicWALL security appliance with remote satellite sites connected into it using SonicWALL security appliances that may not support LDAP. In that case the central SonicWALL security appliance can operate as a RADIUS server for the remote SonicWALL security appliances, acting as a gateway between RADIUS and LDAP, and relaying authentication requests from them to the LDAP server. Additionally, for remote SonicWALL security appliances running non-enhanced firmware, with this feature the central SonicWALL security appliance can return legacy user privilege information to them based on user group memberships learned using LDAP. This avoids what can be very complex configuration of an external RADIUS server such as IAS for those SonicWALL security appliances. 30

Step 33 Under Allow RADIUS clients to connect via, check the relevant checkboxes and policy rules will be added
to allow incoming Radius requests accordingly. The options are:
Trusted Zones WAN Zone Public Zones Wireless Zones VPN Zone Step 34 In the RADIUS shared secret field, enter a shared secret common to all remote SonicWALL security

appliances.

Step 35 In the User groups for legacy users fields, define the user groups that correspond to the legacy VPN
users, VPN client users, L2TP users and users with Internet access privileges. When a user in one of the given user groups is authenticated, the remote SonicWALL security appliances will be informed that the user is to be given the relevant privilege.
The Bypass filters and Limited management capabilities privileges are returned based on membership to user groups named Content Filtering Bypass and Limited Administrators these are not configurable.
Step 36 Select the Test tab.
The Test page allows for the configured LDAP settings to be tested by attempting authentication with specified user and password credentials. Any user group memberships and/or framed IP address configured on the LDAP/AD server for the user will be displayed.
Step 37 In the Username and Password fields, enter a valid LDAP login name for the LDAP server you configured. Step 38 Select Password authentication or CHAP (Challenge Handshake Authentication Protocol).
CHAP only works with a server that supports retrieving user passwords using LDAP and in some cases requires that the LDAP server to be configured to store passwords reversibly. CHAP cannot be used with Active Directory.

Step 39 Click Test.

Configuring Firewall Access Rules
Firewall access rules provide the administrator with the ability to control user access. Rules set under Firewall > Access Rules are checked against the user group memberships returned from a SSO LDAP query, and are applied automatically. Access rules are network management tools that allow you to define inbound and outbound access policy, configure user authentication, and enable remote management of the SonicWALL security appliance. The SonicOS Firewall > Access Rules page provides a sortable access rule management interface. The subsequent sections provide high-level overviews on configuring access rules by zones and configuring bandwidth management using access rules.
More specific policy rules should be given higher priority than general policy rules. The general specificity hierarchy is source, destination, service. User identification elements, for example, user name and corresponding group permissions, are not included in defining the specificity of a policy rule. By default, SonicWALL security appliances stateful packet inspection allows all communication from the LAN to the Internet, and blocks all traffic to the LAN from the Internet. Additional network access rules can be defined to extend or override the default access rules. For example, access rules can be created that block certain types of traffic such as IRC from the LAN to the WAN, or allow certain types of traffic, such as Lotus Notes database synchronization, from specific hosts on the Internet to specific hosts on the LAN, or restrict use of certain protocols such as Telnet to authorized users on the LAN.

The ability to define network access rules is a powerful tool. Using custom access rules can disable firewall protection or block all access to the Internet. Use caution when creating or deleting network access rules. For detailed information about the Firewall > Access Rules page, refer to the SonicOS Enhanced 4.0 Administrators Guide.

Viewing User Status

The Users > Status page displays Active User Sessions on the SonicWALL security appliance. The table lists User Name, IP Address, Session Time, Time Remaining, Inactivity Remaining, Settings, and Logout. For users authenticated using SonicWALL SSO Agent, the message Auth. by SSO Agent will display. To logout a user, click the trash can icon next to the users entry.
Changes in a users settings, configured under Users > Settings, will not be reflected during that users current session; you must manually log the user out for changes to take effect. The user will be transparently logged in again, with the changes reflected.

Glossary

Configuring User Settings
The Users > Settings page provides the administrator with configuration options for user session settings, global user settings, and acceptable use policy settings, in addition to SSO and other user login settings. The Enable login session limit and corresponding Login session limit (minutes) settings under User Session Settings apply to users logged in using SSO. SSO users will be logged out according to session limit settings, but will be automatically and transparently logged back in when they send further traffic.
Do not set the login session limit interval too low. This could potentially cause performance problems, especially for deployments with many users. Changes applied in the Users > Setting s page during an active SSO session will not be reflected during that session.
You must log the user out for changes to take effect. The user will immediately and automatically be logged in again, with the changes made. For information about the Users > Settings page, refer to the SonicOS Enhanced 4.0 Administrators Guide.

ADConnector (ADC) - A SonicWALL Active Directory authentication agent. Single Sign-On Agent (SSO Agent) - 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 3

Date 7/31/2006 9/25/2006 3/1/2007
Notes This document was created. Document updated. Document updated.

Release Notes

SonicOS Enhanced 4.0.0.0 Release Notes
SonicWALL, Inc. Firmware Release: June 29, 2007

CONTENTS

PLATFORM COMPATIBILITY KEY FEATURES ENHANCEMENTS KNOWN ISSUES UPGRADING SONICOS STANDARD/ENHANCED IMAGE PROCEDURES

PLATFORM COMPATIBILITY

SonicOS Enhanced version 4.0.0.0 is a supported release for the following platforms: SonicWALL PRO 4060 SonicWALL PRO 4100 SonicWALL PRO 5060
Strong SSL and TLS Encryption The internal SonicWALL Web server now only supports SSL version 3.0 and TLS with strong ciphers (128 bits or greater) when negotiating HTTPS management sessions. SSL implementations prior to version 3.0 and weak ciphers (symmetric ciphers less than 128 bits) are not supported. This heightened level of HTTPS security protects against potential SSLv2 roll-back vulnerabilities and ensures compliance with the Payment Card Industry (PCI) and other security and risk-management standards. TIP: By default, Mozilla Firefox 2.0 and Microsoft Internet Explorer 7.0 enable SSL 3.0 and TLS, and disable SSL 2.0. SonicWALL recommends using these most recent Web browser releases. If you are using a previous release of these browsers, you should enable SSL 3.0 and TLS and disable SSL 2.0. In Internet Explorer, go to Tools > Internet Options, click on the Advanced tab, and scroll to the bottom of the Settings menu. In Firefox, go to Tools > Options, click on the Advanced tab, and then click on the Encryption tab.

Page 1 of 19

2007 SonicWALL, Inc. SonicWALL is a registered trademark of SonicWALL, Inc. Other product and company names mentioned herein may be trademarks and/or registered trademarks of their respective companies.
P/N 232-001195-00 Rev A 6/07

KEY FEATURES

The following are the key features supported in SonicOS Enhanced 4.0.0.0: Single Sign-On User Authentication SonicOS Enhanced 4.0.0.0 introduces Single Sign-On User Authentication, which provides privileged access to multiple network resources with a single workstation login. Single Sign-On uses the SonicWALL SSO Agent to identify user activity based on workstation IP addresses. Access to resources is based on policy for the group to which the user belongs. Stateful Hardware Failover SonicOS Enhanced 4.0.0.0 introduces Stateful Hardware Failover, which provides improved failover performance. With Stateful Hardware Failover, the primary and backup security 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. Once the primary and backup appliances have been associated as a hardware failover pair on mysonicwall.com, you can enable this feature by selecting Enable Stateful Synchronization in the Hardware Failover > Advanced page.
Application Firewall SonicOS Enhanced 4.0.0.0 introduces Application Firewall, which provides a way to create application-specific policies to regulate Web browsing, file transfer, email, and email attachments. Application Firewall enables application layer bandwidth management, and also allows you to create custom policies for any protocol. It gives you granular control over network traffic on the level of users, email users, and IP subnets.

Page 2 of 19

HTTPS Filtering SonicOS Enhanced 4.0.0.0 uses HTTPS Filtering to allow administrators to control user access to Web sites when using the encrypted HTTPS protocol. HTTPS Filtering is based on the ratings of Web sites, such as Gambling, Online Banking, Online Brokerage and Trading, Shopping, and Hacking/Proxy Avoidance. Note that HTTPS Filtering is IP-based, so IP addresses must be used rather than domain names in the Allowed or Forbidden lists. You can use the nslookup command in a DOS cmd window to convert a domain name to its IP address(es). There may be more than one IP address associated with a domain, and if so, all must be added to the Allowed or Forbidden list.

Press the Configure button to display the following screen where you can enable IP based HTTPS content filtering:

Page 3 of 19

SSL Control SonicOS Enhanced 4.0.0.0 introduces SSL Control, which is a system that provides visibility into the handshake of Secure Socket Layer (SSL) sessions, and a method for configuring policies to control the establishment of SSL sessions.
Certificate Blocking SonicOS Enhanced 4.0.0.0 provides a way to specify which HTTPS certificates to block. This feature is closely integrated with SSL Control. Inbound NAT Load Balancing with Server Monitoring SonicOS Enhanced 4.0.0.0 introduces Inbound NAT Load Balancing with Server Monitoring, which detects when a server is unavailable and stops forwarding requests to it. Inbound NAT Load Balancing spreads the load across two or more servers. When Stateful High Availability (Stateful Hardware Failover) is configured in the environment, during a failover SonicOS forwards all requests to the alternate server(s) until it detects that the offline server is back online. Inbound NAT Load Balancing also works with SonicWALL SSL-VPN appliances. Security Dashboard Web Page SonicOS Enhanced 4.0.0.0 includes the Security Dashboard page in the user interface, which displays a summary of threats stopped by the SonicWALL security appliance. The Security Dashboard shows two types of reports: o A Global Report that displays a summary of threat data received from all SonicWALL security appliances worldwide. o An Individual Appliance Report that displays a summary of attacks detected by the local SonicWALL security appliance. License Wizard As part of the new Security Dashboard, SonicOS Enhanced 4.0.0.0 provides a License Wizard for both firewall registration and the purchase of security service licenses. The available security services are the same as those that enable Global Reports by providing threat data from SonicWALL devices around the world.

Page 4 of 19

Multiple SSH Support SonicOS Enhanced 4.0.0.0 provides support for multiple concurrent SSH sessions on the SonicWALL security appliance. When connected over SSH, you can run command line interface (CLI) commands to monitor and manage the device. The number of concurrent SSH sessions is determined by device capacity. Note that only one session at a time can configure the SonicWALL, whether the session is on the GUI or the CLI (SSH or serial console). For instance, if a CLI session goes to the config level, it will ask you if you want to preempt an administrator who is at config level in the GUI or an SSH session. Multiple and Read-only Administrator Login SonicOS Enhanced 4.0.0.0 introduces Multiple Administrator Login, which provides a way for multiple users to be given administration rights, either full or read-only, for the SonicOS security appliance. Additionally, SonicOS Enhanced 4.0.0.0 allows multiple users to concurrently manage the appliance, but only one user at a time can be in config mode with the ability to change configuration settings. This feature applies to both the graphical user interface (GUI) and the command line interface (CLI). IP-Based Connection Limit SonicOS Enhanced 4.0.0.0 provides a way to limit the number of connections on a per-source or per-destination IP address basis. This feature protects against worms on the LAN side that initiate large numbers of connections in denial of service attacks.

Page 5 of 19

IKEv2 Secondary Gateway Support SonicOS Enhanced 4.0.0.0 introduces IKEv2 Secondary Gateway Support, which provides a way to configure a secondary VPN gateway to act as an alternative tunnel end-point if the primary gateway becomes unreachable. While using the secondary gateway, SonicOS can periodically check for availability of the primary gateway and revert to it, if configured to do so. Configuration for the secondary VPN gateway is available under VPN > Settings > Add Policy in the management interface. IKEv2 Dynamic Client Support SonicOS Enhanced 4.0.0.0 introduces IKEv2 Dynamic Client Support, which provides a way to configure the Internet Key Exchange (IKE) attributes rather than using the default settings. Previously, only the default settings were supported: Diffie-Hellman (DH) Group 2, the 3DES encryption algorithm, and the SHA1 authentication method. SonicOS now allows the following IKE Proposal settings: o DH Group: 1, 2, or 5 o Encryption: DES, 3DES, AES-128, AES-192, AES-256 o Authentication: MD5, SHA1 These settings are available by pressing the Configure button in the VPN > Advanced screen of the management interface. However, if a VPN Policy with IKEv2 exchange mode and a 0.0.0.0 IPsec gateway is defined, you cannot configure these IKE Proposal settings on an individual policy basis. Note that the VPN policy on the remote gateway must also be configured with the same settings. Wireless IDS Rogue Detection SonicOS Enhanced 4.0.0.0 supports wireless intrusion detection on SonicPoint devices. Wireless IDS Rogue Detection allows you to configure a set of authorized access points, defined by address object groups. If contact is attempted from an unauthorized access point, SonicOS generates an alert. RF Management SonicOS Enhanced 4.0.0.0 introduces Radio Frequency Management on SonicPoint devices. RF Management provides detection of eleven types of wireless threats: o Long duration attack o Management frame flood o Null probe request o Broadcasting de-authentication o Valid station with invalid SSID o Ad-Hoc station o Unassociated station o Wellenreiter attack o NetStumbler attack o EAPOL packet flood o Weak WEP IV

Page 6 of 19

SMTP Authentication SonicOS Enhanced 4.0.0.0 supports RFC 2554, which defines an SMTP service extension that allows the SMTP client to indicate an authentication method to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. This feature helps prevent viruses that attack the SMTP server on port 25. Generic DHCP Option Support SonicOS Enhanced 4.0.0.0 supports generic DHCP configuration, which allows vendor-specific DHCP options in DHCP server leases. DHCP Server Lease Cross-Reboot Persistence SonicOS Enhanced 4.0.0.0 introduces DHCP Server Lease Cross-Reboot Persistence, which provides the ability to record and return to DHCP server lease bindings across power cycles. The SonicWALL security appliance does not have to depend on dynamic network responses to regain its IP address after a reboot or power cycle. This feature is supported on all SonicWALL PRO platforms. It is not supported on SonicWALL TZ platforms. Custom IP Type Service Objects SonicOS Enhanced 4.0.0.0 introduces support for Custom IP Type Service Objects, allowing administrators to augment the pre-defined set of Service Objects. Dynamic Address Objects SonicOS Enhanced 4.0.0.0 supports two changes to Address Objects: o MAC SonicOS Enhanced 4.0.0.0 will resolve MAC AOs to an IP address by referring to the ARP cache on the SonicWALL. o FQDN Fully Qualified Domain Names (FQDN), such as www.sonicwall.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. Apple VPN Client Support SonicOS Enhanced 4.0.0.0 will be compatible with the upcoming Equinux 5.0 VPN Tracker client for Mac OS X.

Page 7 of 19

Virtual Access Points A Virtual Access Point (VAP) 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 there is actually only a single physical AP. Before 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. For example, an Access Point providing WPA-PSK security could not simultaneously offer Open or WPA-EAP connectivity to clients. If Open or WPA-EAP were required, they would need to have been provided by a separate, distinctly configured APs. 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 segmenting wireless network services within a single radio frequency footprint of a single physical access point device. In SonicOS Enhanced 4.0.0.0, 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. You can configure up to eight VAPs per SonicPoint access point.

Page 8 of 19

Layer 2 Bridge Mode SonicOS Enhanced 4.0.0.0 supports Layer 2 (L2) Bridge Mode, a new method of unobtrusively integrating a SonicWALL security appliance into any Ethernet network. L2 Bridge Mode is 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. 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.

Key Features of SonicOS Enhanced Layer 2 Bridge Mode
The following table outlines the benefits of each key feature of layer 2 bridge mode: Feature L2 Bridging with Deep Packet Inspection Benefit This method of transparent operation means that a SonicWALL security appliance can be added to any network without the need for readdressing or reconfiguration, enabling the addition of deeppacket 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. True L2 behavior 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. All Ethernet traffic can be passed across an L2 Bridge, meaning that all network communications 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. L2 Bridge Mode can concurrently provide L2 Bridging and conventional security appliance 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 introduction of the SonicWALL security appliance as a pure L2 bridge, with a smooth migration path to full security services operation.
Secure Learning Bridge Architecture
Universal Ethernet FrameType Support

Mixed-Mode Operation

Page 9 of 19

ENHANCEMENTS

The following enhancements are included in SonicOS Enhanced 4.0.0.0: Enhanced Packet Capture SonicOS Enhanced 4.0.0.0 provides an enhanced version of the Packet Capture feature. Enhanced Packet Capture contains improvements in both functionality and flexibility, including the following: o Capture control mechanism with improved granularity for custom filtering o Display filter settings independent from capture filter settings o Packet status indicating dropped, forwarded, generated, or consumed o Three-window output in the user interface that provides the packet list, decoded output of selected packet, and hexadecimal dump of selected packet o Export capabilities that include text, HTML, hex dump, and CAP file format o Automatic buffer export to FTP server when full o Bidirectional packet capture based on IP address and port o Configurable wrap-around of capture buffer when full User Authentication There are a number of enhancements to user authentication in SonicOS Enhanced 4.0.0.0, including optional case-sensitive user names, optional enforcement of unique login names, support for MSCHAP version 2, and support for VPN and L2TP clients changing expired passwords (when that is supported by the back-end authentication server and protocols used). Note that for this purpose there is a new setting on the VPN > Advanced page to cause RADIUS to be used in MSCHAP mode when authenticating VPN client users. IP Helper Scalability SonicOS Enhanced 4.0.0.0 provides enhancements to the IP Helper architecture to support large networks. Improvements include changes to DHCP relay and NetBIOS functionality. DHCP relay over VPN is now fully integrated. Diagnostics Page Tool Tips SonicOS Enhanced 4.0.0.0 incorporates self-documenting mouse-over descriptions for diagnostic controls in the graphical user interface. BWM Rate Limiting SonicOS Enhanced 4.0.0.0 enhances the Bandwidth Management feature to provide rate limiting functionality. You can now create traffic policies that specify maximum rates for Layer 2, 3, or 4 network traffic. This enables modem bandwidth management in cases where the primary WAN link fails over to a secondary modem connection that cannot handle as much traffic. DHCP Client Reboot Behavior Control In SonicOS Enhanced 4.0.0.0 you can configure the WAN DHCP client to perform a DHCP RENEW or a DHCP DISCOVERY query when attempting to obtain a lease. The previous behavior was to always perform a RENEW, which caused lease failures on some networks, particularly certain cable modem service providers. The new behavior it to perform a DISCOVERY, but it is configurable. A checkbox has been added to the Network > Interfaces > WAN >DHCP Client page: o Enabled: when the appliance reboots, the DHCP client performs a DHCP RENEW query. o Disabled: (Default) when the appliance reboots, the DHCP client performs a DHCP DISCOVERY query.

Page 10 of 19

Dynamic Route Metric Recalculation Based on Interface Availability To better support redundant or multiple path Advanced Routing configurations, when a default-route's interface is unavailable (due to no-link or negative WAN LB probe response), that default route's metric will be changed to 255, and the route will be instantly disabled. When a default-route's interface is again determined to be available, its metric will be changed back to 20, and the route will be nondisruptively enabled.

Page 11 of 19

KNOWN ISSUES
Apple Macintosh Users and Single Sign-On
Single Sign-On utilizes Windows APIs that are not supported by the Apple Macintosh, hence Mac users in a Windows environment will not get authenticated automatically by Single Sign-On. Mac users must log in to the appliance using a Web browser in order to get access when authentication is required. Note that this may require setting additional policy rules that would not otherwise be required with Single Sign-On, such as to allow access to external DNS servers.

Anti-Spyware

46218: Symptom: Anti-Spyware enforcement fails when spyware traffic is passed from DMZ to WLAN. Condition: Occurs when Anti-Spyware service is enabled on both WLAN and DMZ zones.
50341: Symptom: The SonicWALL sometimes reboots unexpectedly. Condition: Occurs when allocating or freeing memory from the heap during HTTPS access. May be related to use of Application Firewall feature.
50453: Symptom: Attempting to change the SSH port causes the SonicWALL to reboot. Condition: Occurs when attempting to change the SSH port either in the CLI or on the System > Administration page in the user interface. After rebooting, the SSH port is changed if the CLI was used, but not if the UI was used. 49918: Symptom: In the CLI, the command show address-object will cause the SonicWALL to reboot. Condition: Occurs when the command is executed right after uploading firmware and clicking the boot icon for Uploaded Firmware with Factory Default Settings. 45309: Symptom: An SSH session with an invalid IP address cannot be removed. Condition: Occurs when using SSH to attempt a connection with an invalid IP address. Specifically, this can occur when using Tera Term Pro 3.1 to connect and disconnect. The session cannot be removed by clear ssh all, clear ssh ID or disable ssh, enable ssh.
46355: Symptom: GAV IMAP sometimes fails to catch virus attached to email. Condition: Occurs when GAV IMAP fails to catch the virus when bad email (with virus attached) sits between good emails.

Networking

49411: Symptom: In transmitted IP packets that are subject to QoS control, the packet classification field is not set to the right value by the SonicWALL. Condition: Occurs when DCSP marking is set to Preserve, and the 802.1p marking is set to Map in a LAN > WAN rule. The DCSP value in the packets that are sent from the LAN is set to 8, Class Selector = 1. VLAN user priority = 4. Packets captured on the WAN show VLAN priority 4. The VLAN priority is not changed to 1 as it should be according to the QoS mapping table. 49099: Symptom: The number of dropped packets can be incorrectly displayed as 11922944 when bandwidth management is enabled. Condition: Occurs when only outbound bandwidth management is configured on the Ethernet BWM tab in the Firewall > Access Rules > Add Rule dialog box.

Page 12 of 19

48977: Symptom: After changing the LAN IP address and subnet, the DHCP server configuration for the LAN zone is not updated accordingly, preventing a client computer from receiving a DHCP address on the LAN. Condition: Occurs when the changes are made while connected to the X0 (LAN zone) interface. Workaround: Make the LAN IP address and subnet changes while connected to the WAN interface using HTTP/HTTPS management. 45010: Symptom: One-to-one NAT policy works with LAN but doesn't work with DMZ interface. Condition: Occurs when using LAN-DMZ mixed bridge mode. 44972: Symptom: Primary and secondary interfaces can have sub-interfaces configured with the same VLAN ID. Condition: Occurs when creating a sub-interface for both interfaces in a bridged pair, and then assigning the same VLAN ID to both sub-interfaces. The bridged pair might be WAN-LAN (X1-X2) or LAN-DMZ (X3-X4).
Stateful Hardware Failover
50476: Symptom: With Stateful Hardware Failover enabled, in certain conditions network traffic stops after failover occurs. Condition: Occurs when the traffic is being transmitted from a DMZ client to the WAN over the DMZ interface, and the WAN is a Class B network (/16) while the DMZ interface is in transparent mode (configured as a Transparent Host). Workaround: Configure the WAN as a Class C (/24) network or smaller, with a maximum of 256 hosts allowed in the Transparent Range. 50264: Symptom: The Single Sign-On domain does not display on the Users > Status screen after failover to the hardware failover backup unit. Condition: Occurs because the SSO domain is not synchronized to the backup unit. 49992: Symptom: The SonicWALL sometimes reboots unexpectedly during synchronization between the primary and backup units. Condition: Occurs when a system daemon dies during synchronization with the backup unit. 49081: Symptom: Licensed services such as Stateful HA Upgrade, Intrusion Prevention Services, Gateway Anti-Virus, and Anti-Spyware are sometimes not activated on the backup Stateful HA unit. Condition: Occurs when applying manual keysets to either the primary or backup unit. Workaround: Do not use manual keysets. 46342: Symptom: With Stateful Hardware Failover enabled and probe monitoring enabled for LAN, WAN, and DMZ interfaces, failover sometimes does not occur when a LAN cable is unplugged to simulate physical failure of the unit. Condition: Occurs when Layer 2 Bridged mode is configured between the WAN and DMZ interfaces. 45626: Symptom: The backup unit in an HA pair does not show the user in an active tunnel on the VPN > Settings page. Condition: Occurs when WAN GroupVPN is enabled on the primary unit, with Trusted Users selected for the user group for XAUTH users, and a static address is set for the SonicWALL Virtual Adapter. A user then connects using the GVC client, and is displayed in the active tunnel on the VPN > Settings page on the primary unit only.

Page 13 of 19

50489: Symptom: Single sign-on users may get redirected to log in to the appliance when the agent is using WMI on a busy network. Condition: Occurs when the network response time is slow and the default Single Sign-On timeout is set. Workaround: Increase the SSO timeout to something longer than the default of 3 seconds. 50118: Symptom: Some features are not working properly for Limited or Non-Config mode admin users. Condition: Occurs when a Limited Admin attempts to make a change on the Log > Automation or Log > Syslog pages, or clicks Flush ARP Cache on the Network > ARP page, and when a Non-Config Admin clicks Flush ARP Cache on the Network > ARP page. An error message saying not allowed in current mode will be reported, and the operation may or may not be successful. 50108: Symptom: User sessions are sometimes disconnected after only one or two minutes for users who are members of a local group that corresponds to an Active Directory group and has a group-based access policy for another LAN segment. Condition: Occurs when Single Sign-On is being used.
49914: Symptom: Back to Back User Agent: SonicOS Enhanced 4.0 firmware cannot consistently handle transfer calls and conference calls in different network zones. Condition: Occurs when more than two calls are transferred or conferenced to a different zone. 49912: Symptom: Back to Back User Agent: A Network Busy error message may be displayed, or a call may be connected to the recipients voicemail rather than ringing their phone when making phone calls. Condition: Occurs when calls are made using IP phones between one LAN and another LAN interface. 49884: Symptom: Back to Back User Agent: Outgoing calls result in a Network Busy error message, and incoming calls may be connected to the recipients voicemail rather than ringing their phone. Condition: Occurs when calls are made using IP phones with SIP (Session Initiation Protocol) in the following cases: o Outgoing calls from the LAN to the DMZ o Incoming calls from the DMZ to the LAN

Page 14 of 19

UPGRADING SONICOS STANDARD/ENHANCED IMAGE PROCEDURES
The following procedures are for upgrading an existing SonicOS Standard or SonicOS Enhanced image to a newer version. OBTAINING THE LATEST SONICOS STANDARD/ENHANCED IMAGE VERSION SAVING A BACKUP COPY OF YOUR CONFIGURATION PREFERENCES UPGRADING A SONICOS STANDARD/ENHANCED IMAGE WITH CURRENT PREFERENCES UPGRADING A SONICOS STANDARD/ENHANCED IMAGE WITH FACTORY DEFAULTS RESETTING THE SONICWALL SECURITY APPLIANCE USING SAFEMODE

Obtaining the Latest SonicOS Standard/Enhanced Image Version
1. To obtain a new SonicOS Standard/Enhanced image file for your SonicWALL security appliance, connect to your mySonicWALL.com account at <http://www.mysonicwall.com>. Note: If you have already registered your SonicWALL security appliance, and you selected Notify me when new firmware is available on the System > Settings page, you are automatically notified of any updates available for your model. 2. Copy the new SonicOS Standard/Enhanced image file to a directory on your management station. You can update the SonicOS Standard/Enhanced image on a SonicWALL security appliance remotely if the LAN interface or the WAN interface is configured for management access.
Saving a Backup Copy of Your Configuration Preferences
Before beginning the update process, make a system backup of your SonicWALL security appliance configuration settings. The backup feature saves a copy of your current configuration settings on your SonicWALL security appliance, protecting all your existing settings in the event it becomes necessary to return to a previous configuration state. In addition to using the backup feature to save your current configuration state to the SonicWALL security appliance, you can export the configuration preferences file to a directory on your local management station. This file serves as an external backup of the configuration preferences, and can be imported back into the SonicWALL security appliance. Perform the following procedures to save a backup of your configuration settings and export them to a file on your local management station: 1. To save a backup of your settings on a SonicWALL PRO 4060, SonicWALL PRO 4100, or SonicWALL PRO 5060, click the Create Backup Settings button on the System > Settings page of the SonicWALL management interface. When you select Create Backup, SonicOS saves both the current SonicOS Standard/Enhanced image and your current configuration preferences.

Page 15 of 19

2. On the System > Settings page, click the button and save the preferences file to your local machine. The default preferences file is named sonicwall.exp. You can rename the file but you should keep the.exp extension. Tip: Rename the.exp file to include the version of the SonicOS Standard/Enhanced image from which you are exporting the settings. For example, if you export the settings from the SonicOS Standard 3.0 image, rename the file using the format: [date]_[version]_[mac].exp to 021605_3.0.0.627s_000611223344.exp (the [mac] format entry is the serial number of the SonicWALL security appliance). Then if you need to roll back to that version of the SonicOS Standard/Enhanced image, you can correctly choose the file to import.
Upgrading a SonicOS Standard/Enhanced Image with Current Preferences
Note: SonicWALL security appliances do not support downgrading a SonicOS Standard/Enhanced image and using the configuration preferences file from a higher version. If you are downgrading to a lower version of a SonicOS Standard/Enhanced image, you must select Uploaded Firmware with. You can import a preferences file previously saved from the downgrade Factory Defaults New! version or reconfigure manually. Refer to Updating SonicOS Standard/Enhanced with Factory Default Settings. 1. Download the SonicOS Standard/Enhanced image file from mysonicwall.com and save it to a location on your local computer. 2. Select Upload New Firmware from the SonicWALLs System > Settings page. Browse to the location where you saved the SonicOS Standard/Enhanced image file, select the file, and click the Upload button. The upload process can take up to one minute.
3. When the upload is complete, you are ready to reboot your SonicWALL security appliance with the new SonicOS Standard/Enhanced image. From the SonicOS System > Settings page, select the boot icon for the following entry:

Uploaded Firmware New!

4. A message dialog is displayed informing you that the image update booting process will take between one and two minutes, and a warning is displayed that warns you not to power off the device while the image is being uploaded to the flash memory. Click OK to proceed.

Page 16 of 19

5. After successfully uploading the image to your SonicWALL security appliance, the login screen is displayed. Enter your user name and password. Your new SonicOS Standard/Enhanced image version information is listed on the System > Settings page.
Upgrading a SonicOS Standard/Enhanced Image with Factory Defaults
1. Download the SonicOS Standard/Enhanced image file from mysonicwall.com and save it to a known location on your local computer. 2. Make a system backup of your SonicWALL security appliance configuration settings by selecting Create Backup Settings or Create Backup from the System > Settings page of the SonicWALL management interface. 3. Select Upload New Firmware from the SonicWALLs System > Settings page. Browse to the location where you saved the SonicOS Standard/Enhanced image, select the file, and click the Upload button. The upload process can take up to one minute. 4. When the upload is complete, you are ready to reboot your SonicWALL security appliance with the new SonicOS Standard/Enhanced image. From the SonicWALLs System > Settings page, select the boot icon for the following entry:
Uploaded Firmware with Factory Defaults New!
5. A message dialog is displayed informing you that the firmware booting process will take between one and two minutes, and a warning is displayed that warns you not to power off the device while the image is being uploaded to the flash memory. Click OK to proceed. 6. After successfully uploading the firmware to your SonicWALL security appliance, the login screen is displayed. Enter your user name and password to access the SonicWALL management interface. Your new firmware is listed on the System > Settings page.
Resetting the SonicWALL Security Appliance Using SafeMode
If you are unable to connect to the SonicWALL security appliances management interface, you can restart the SonicWALL security appliance in SafeMode. The SafeMode feature allows you to quickly recover from uncertain configuration states with a simplified management interface that includes the same settings available on the System > Settings page. To reset the SonicWALL security appliance, perform the following steps: 1. Connect your management station to a LAN port on the SonicWALL security appliance and configure your management station IP address with an address on the 192.168.168.0/24 subnet, such as 192.168.168.20. Note: The SonicWALL security appliance can also respond to the last configured LAN IP address in SafeMode. This is useful for remote management recovery or hands off recovery in a datacenter.

Page 17 of 19

2. Use a narrow, straight object, like a straightened paper clip or a toothpick, to press and hold the reset button on the security appliance for five to ten seconds. The reset button is in a small hole next to the console port or next to the power supply, depending on your SonicWALL security appliance model. Tip: If this procedure does not work while the power is on, turn the unit off and on while holding the reset button until the Test light starts blinking.
The Test light starts blinking when the SonicWALL security appliance has rebooted into SafeMode. 3. Connect to the management interface: Point the Web browser on your management station to 192.168.168.168. The SafeMode management interface displays.

Page 18 of 19

4. If you have made any configuration changes to the security appliance, make a backup copy of your current settings. Click Create Backup Settings. 5. Try rebooting the SonicWALL security appliance with your current settings. Click the boot icon in the same line with Current Firmware. 6. After the SonicWALL security appliance has rebooted, try to open the management interface again. If you still cannot open the management interface, use the reset button to restart the appliance in SafeMode again. In SafeMode, restart the SonicOS Standard image with the factory in the same line with Current Firmware with Factory default settings. Click the boot icon Default Settings. 7. After the SonicWALL security appliance has rebooted, try to open the management interface again. If you are able to connect, you can recreate your configuration or try to reboot with the backup settings: Restart the security appliance in SafeMode again, and click the boot icon in the same line with Current Firmware with Backup Settings.
Document Version: June 29, 2007

Page 19 of 19