en-US
search-icon

Secure Mobile Access 8.6 Admin Guide

Introduction

About This Guide

This SonicWall Inc. Secure Mobile Access Administration Guide provides network administrators with a high-level overview of Secure Mobile Access (SMA) technology, including activation, configuration, and administration of SonicWall Inc. SMA/SRA appliances using the Secure Mobile Access management interface.

Refer to SMA Documentation for the latest version of this guide as well as other SonicWall Inc. product and services documentation.

Guide Conventions

The following conventions are used in this guide:

 

Conventions used in this guide

Convention

Use

Bold

Highlights field, button, and tab names. Also highlights window, dialog box, and screen names. Also used for file names and text or values you are being instructed to type into the interface.

Italic

Indicates the name of a technical manual, emphasis on certain words in a sentence, or the first instance of a significant term or concept.

Menu Item > Menu Item

Indicates a multiple step management interface menu choice. For example, System > Status means select the Status page under the System menu.

Secure Mobile Access Overview

This section provides an overview of the Secure Mobile Access (SMA) technology, concepts, basic navigational elements and standard deployment guidelines.

Topics:

Overview of SMA/SRA Hardware and Components

The SMA and SRA appliances provide organizations with a simple, secure and clientless method of access to applications and network resources specifically for remote and mobile employees. Organizations can use SMA connections without the need to have a pre-configured, large-installation host. Users can easily and securely access email files, intranet sites, applications, and other resources on the corporate Local Area Network (LAN) from any location by accessing a standard Web browser.

This section contains the following subsections:

SMA Software Components

SMA/SRA appliances provide clientless identity-based secure remote access to the protected internal network. Using the Virtual Office environment, SMA/SRA appliances can provide users with secure remote access to your entire private network, or to individual components such as File Shares, Web servers, FTP servers, remote desktops, or even individual applications hosted on Citrix or Microsoft Terminal Servers.

Although SMA protocols are described as clientless, the typical SMA portal combines Web, Java, and ActiveX components that are downloaded from the portal transparently, allowing users to connect to a remote network without needing to manually install and configure a VPN client application. In addition, SMA enables users to connect from a variety of devices, including Windows, Macintosh, and Linux PCs. ActiveX components are only supported on Windows platforms.

For administrators, the SMA web-based management interface provides an end-to-end SMA solution. This interface can configure SMA users, access policies, authentication methods, user bookmarks for network resources, and system settings.

For clients, web-based SMA customizable user portals enable users to access, update, upload, and download files and use remote applications installed on desktop machines or hosted on an application server. The platform also supports secure web-based FTP access, network neighborhood-like interface for file sharing, Secure Shell version 2 (SSHv2), Telnet emulation, VNC (Virtual Network Computing) and RDP (Remote Desktop Protocol) support, Citrix Web access, bookmarks for offloaded portals (external Web sites), and Web and HTTPS proxy forwarding.

The SMA network extension client, NetExtender, is available through the SMA Web portal through an ActiveX control on Windows or using Java on MacOS or Linux systems. It is also available through stand-alone applications for Windows, Linux, and MacOS platforms. The NetExtender standalone applications are automatically installed on a client system the first time the user clicks the NetExtender link in the Virtual Office portal. NetExtender enables end users to connect to the remote network without needing to install and configure complex software, providing a secure means to access any type of data on the remote network. NetExtender supports IPv6 client connections from Windows systems running Vista or newer, and from Linux clients.

* 
NOTE: The SSHv2 applet requires SUN JRE 1.6.0_10 or higher and can only connect to a server that supports SSHv2. The RDP Java applet requires SUN JRE 1.6.0_10 or higher. Telnet and VNC applets support MS JVM in Internet Explorer, and run on other browsers with SUN JRE 1.6.0_10 or higher.

SMA Hardware Components

See the following sections for descriptions of the hardware components on SMA appliances:

SMA 400 Front and Back Panels Overview

 

SMA 400 Front Panel Features 

Front Panel Feature

Description

Console Port

RJ-45 port, provides access to console messages with serial connection (115200 Baud). Provides access to command line interface (for future use).

USB/SSD Ports

Provides access to external USB and SSD hard drive support.

Reset Button

Provides access to SafeMode.

Power LED

Indicates the SMA 400 is powered on.

Test LED

Indicates the SMA 400 is in test mode.

Alarm LED

Indicates a critical error or failure.

X3

Provides access to the X3 interface and to SMA resources.

X2

Provides access to the X2 interface and to SMA resources.

X1

Provides access to the X1 interface and to SMA resources.

X0

Default management port. Provides connectivity between the SMA 400 and your gateway.

 

SMA 400 Back Panel Features  

Back Panel Feature

Description

Exhaust fans

Provides optimal cooling for the SMA 400 appliance.

Power supply plug

Provides power connection using supplied power cord.

SMA 200 Front and Back Panels Overview

 

SMA 200 Front Panel Features 

Front Panel Feature

Description

Console Port

RJ-45 port, provides access to console messages with serial connection (115200 Baud). Provides access to command line interface.

USB/SSD Ports

Provides access to external USB and SSD hard drive support.

Reset Button

Provides access to SafeMode.

Power LED

Indicates the SMA 200 is powered on.

Test LED

Indicates the SMA 200 is in test mode.

Alarm LED

Indicates a critical error or failure.

X1

Provides access to the X1 interface and to SMA resources.

X0

Default management port. Provides connectivity between the SMA 200 and your gateway.

 

SMA 200 Back Panel Features 

Back Panel Feature

Description

Exhaust fans

Provides optimal cooling for the SMA 200 appliance.

Power supply plug

Provides power connection using supplied power cord.

SRA Hardware Components

See the following sections for descriptions of the hardware components on SRA appliances:

SRA 4600 Front and Back Panels Overview

SRA 4600 Front and Back Panels

 

SRA 4600 Front Panel Features 

Front Panel Feature

Description

Console Port

RJ-45 port, provides access to console messages with serial connection (115200 Baud). Provides access to command line interface (for future use).

USB Ports

Provides access to USB interface (for future use).

Reset Button

Provides access to SafeMode.

Power LED

Indicates the SRA 4600 is powered on.

Test LED

Indicates the SRA 4600 is in test mode.

Alarm LED

Indicates a critical error or failure.

X3

Provides access to the X3 interface and to SRA resources.

X2

Provides access to the X2 interface and to SRA resources.

X1

Provides access to the X1 interface and to SRA resources.

X0

Default management port. Provides connectivity between the SRA 4600 and your gateway.

 

SRA 4600 Back Panel Features 

Back Panel Feature

Description

Exhaust fan

Provides optimal cooling for the SRA 4600 appliance.

Power plug

Provides power connection using supplied power cord.

Power switch

Powers the SRA 4600 on and off.

SRA 1600 Front and Back Panels Overview

SRA 1600 Front and Back Panels

 

SRA 1600 Front Panel Features 

Front Panel Feature

Description

Console Port

RJ-45 port, provides access to console messages with serial connection (115200 Baud). Provides access to command line interface (for future use).

USB Ports

Provides access to USB interface (for future use).

Reset Button

Provides access to SafeMode.

Power LED

Indicates the SRA 1600 is powered on.

Test LED

Indicates the SRA 1600 is in test mode.

Alarm LED

Indicates a critical error or failure.

X1

Provides access to the X1 interface and to SRA resources.

X0

Default management port. Provides connectivity between the SRA 1600 and your gateway.

 

SRA 1600 Back Panel Features 

Back Panel Feature

Description

Exhaust fan

Provides optimal cooling for the SRA 1600 appliance.

Power plug

Provides power connection using supplied power cord.

Power switch

Powers the SRA 1600 on and off.

SMA 500v Virtual Appliance

The SMA 500v Virtual Appliance is a virtual machine that runs the SMA software on a VMware platform. All software components, features, and functionality described in this guide are supported by the SMA 500v Virtual Appliance, except High Availability and SSL Off-loading.

Deploying SMA as a virtual appliance allows leveraging of shared computing resources to optimize utilization, easy migration and reduced capital costs. The SMA 500v Virtual Appliance provides the following benefits:

Cost savings:
Multiple virtual machines can run on a single server, reducing hardware costs, power consumption, and maintenance costs.
Microsoft Windows Server is not required, eliminating the cost of the Windows license.
Operational ease:
In a virtual environment, it is easy to commission new servers or decommission old ones, or to bring servers up or down.
Installation is accomplished by importing a file into the virtual environment, with no need to run an installer.
Security:
The SMA 500v Virtual Appliance provides the same hardened operating system that comes with the SMA/SRA hardware appliances.

The elements of basic VMware structure must be implemented prior to deploying the SMA 500v Virtual Appliance. For detailed information about deploying the SMA 500v Virtual Appliance, see the SonicWall Inc. SMA 500v Virtual Appliance Getting Started Guide, available at: SMA Documentation

Concepts for Secure Mobile Access

This section provides an overview of the following key concepts that the administrator should be familiar with when using the SMA/SRA appliance and SMA web-based management interface:

Encryption Overview

Encryption enables users to encode data, making it secure from unauthorized viewers. Encryption provides a private and secure method of communication over the Internet.

A special type of encryption known as Public Key Encryption (PKE) comprises a public and a private key for encrypting and decrypting data. With public key encryption, an entity, such as a secure Web site, generates a public and a private key. A secure Web server sends a public key to a user who accesses the Web site. The public key allows the user’s Web browser to decrypt data that had been encrypted with the private key. The user’s Web browser can also transparently encrypt data using the public key and this data can only be decrypted by the secure Web server’s private key.

Public key encryption allows the user to confirm the identity of the Web site through an SSL certificate. After a user contacts the SMA/SRA appliance, the appliance sends the user its own encryption information, including an SSL certificate with a public encryption key.

SSL for Virtual Private Networking (VPN)

A Secure Socket Layer-based Virtual Private Network (SSL VPN) allows applications and private network resources to be accessed remotely through a secure connection. Using SSL VPN, mobile workers, business partners, and customers can access files or applications on a company’s intranet or within a private local area network.

Organizations use Virtual Private Networks (VPNs) to establish secure, end-to-end private network connections over a public networking infrastructure, allowing them to reduce their communications expenses and to provide private, secure connections between a user and a site in the organization. By offering Secure Socket Layer (SSL) VPN, without the expense of special feature licensing, the SMA/SRA appliance provides customers with cost-effective alternatives to deploying parallel remote-access infrastructures.

SSL Handshake Procedure

The following procedure is an example of the standard steps required to establish an SSL session between a user and an SMA/SRA gateway using the Secure Mobile Access web-based management interface:

1
When a user attempts to connect to the SMA/SRA appliance, the user’s Web browser sends information about the types of encryption supported by the browser to the appliance.
2
The appliance sends the user its own encryption information, including an SSL certificate with a public encryption key.
3
The Web browser validates the SSL certificate with the Certificate Authority identified by the SSL certificate.
4
The Web browser generates a pre-master encryption key, encrypts the pre-master key using the public key included with the SSL certificate and sends the encrypted pre-master key to the SMA/SRA gateway.
5
The SMA/SRA gateway uses the pre-master key to create a master key and sends the new master key to the user’s Web browser.
6
The browser and the SMA/SRA gateway use the master key and the agreed upon encryption algorithm to establish an SSL connection. From this point on, the user and the SMA/SRA gateway encrypts and decrypts data using the same encryption key. This is called symmetric encryption.
7
After the SSL connection is established, the SMA/SRA gateway encrypts and sends the Web browser the SMA/SRA gateway login page.
8
The user submits their user name, password, and domain name.
9
If the user’s domain name requires authentication through a RADIUS, LDAP, or Active Directory Server, the SMA/SRA gateway forwards the user’s information to the appropriate server for authentication.
10
After being authenticated, the user can access the Secure Mobile Access portal.

IPv6 Support Overview

Internet Protocol version 6 (IPv6) is a replacement for IPv4 that is becoming more frequently used on networked devices. IPv6 is a suite of protocols and standards developed by the Internet Engineering Task Force (IETF) that provides a larger address space than IPv4, additional functionality and security, and resolves IPv4 design issues. You can use IPv6 without affecting IPv4 communications.

IPv6 supports stateful address configuration that is used with a DHCPv6 server, and stateless address configuration, where hosts on a link automatically configure themselves with IPv6 addresses for the link, called link-local addresses.

In IPv6, source and destination addresses are 128 bits (16 bytes) in length. For reference, the 32-bit IPv4 address is represented in dotted-decimal format, divided by periods along 8-bit boundaries. The 128-bit IPv6 address is divided by colons along 16-bit boundaries, where each 16-bit block is represented as a 4-digit hexadecimal number. This is called colon-hexadecimal.

The IPv6 address, 2008:0AB1:0000:1E2A:0123:0045:EE37:C9B4 can be simplified by removing the leading zeros within each 16-bit block, as long as each block has at least one digit. When suppressing leading zeros, the address representation becomes: 2008:AB1:0:1E2A:123:45:EE37:C9B4

When addresses contain contiguous sequences of 16-bit blocks set to zeros, the sequence can be compressed to ::, a double-colon. For example, the link-local address of 2008:0:0:0:B67:89:ABCD:1234 can be compressed to 2008::B67:89:ABCD:1234. The multicast address 2008:0:0:0:0:0:0:2 can be compressed to 2008::2.

The IPv6 prefix is the part of the address that indicates the bits of the subnet prefix. Prefixes for IPv6 subnets, routes, and address ranges are written as address/prefix-length, or CIDR notation. For example, 2008:AA::/48 and 2007:BB:0:89AB::/64 are IPv6 address prefixes.

Secure Mobile Access supports IPv6 in the following areas:

Services
FTP Bookmark – Define a FTP bookmark using an IPv6 address.
Telnet Bookmark – Define a Telnet bookmark using an IPv6 address.
SSHv2 Bookmark – Define an SSHv2 bookmark using an IPv6 address.
Reverse proxy for HTTP/HTTPS Bookmark – Define an HTTP or HTTPS bookmark using an IPv6 address.
Citrix Bookmark – Define a Citrix bookmark using an IPv6 address.
RDP Bookmark - Define an RDP bookmark using an IPv6 address.
VNC Bookmark - Define a VNC bookmark using an IPv6 address.
* 
NOTE: IPv6 is not supported for File Shares (CIFS).
Settings
Interface Settings – Define an IPv6 address for the interface. The link-local address is displayed in a tooltip on Interfaces page.
Route Settings – Define a static route with IPv6 destination network and gateway.
Network Object – Define the network object using IPv6. An IPv6 address and IPv6 network can be attached to this network object.
NetExtender

When a client connects to NetExtender, it can get an IPv6 address from the SMA/SRA appliance if the client machine supports IPv6 and an IPv6 address pool is configured on the SMA/SRA appliance. NetExtender supports IPv6 client connections from Windows systems running Vista or newer, and from Linux clients.

Secure Virtual Assist

Users and Technicians can request and provide support when using IPv6 addresses.

Rules
Policy rule – User or Group Policies. Three IPv6 options in the Apply Policy To drop-down list:
IPv6 Address
IPv6 Address Range
All IPv6 Address
Login rule – Use IPv6 for address fields:
Define Login From Defined Addresses using IPv6
Two IPv6 options in the Source Address drop-down list: IPv6 Address / IPv6 Network
Virtual Hosts

An administrator can assign an IPv6 address to a virtual host, and can use this address to access the virtual host.

Application Offloading

An administrator can assign an IPv6 address to an application server used for application offloading, and can use this address to access the server.

Portals Overview

Secure Mobile Access provides a mechanism called Virtual Office that is a web-based portal interface that provides clients with easy access to internal resources in your organization. Components such as NetExtender, Secure Virtual Assist, and bookmarks to file shares and other network resources are presented to users through the Virtual Office portal. For organizations with multiple user types, the SMA/SRA appliance allows for multiple customized portals, each with its own set of shared resource bookmarks. Portals also allow for individual domain and security certificates on a per-portal basis. The components in a portal are customized when adding a portal.

File Shares

File shares provide remote users with a secure Web interface to Microsoft File Shares using the CIFS (Common Internet File System) or SMB (Server Message Block) protocols. Using a Web interface similar in style to Microsoft’s familiar Network Neighborhood or My Network Places, File Shares allow users with appropriate permissions to browse network shares, rename, delete, retrieve, and upload files, and to create bookmarks for later recall. File shares can be configured to allow restricted server path access.

Custom Portals

SMA/SRA appliances allow you to configure multiple portals, each with their own title, banner, login message, logo and set of available resources. Each portal also enables you to set individual Virtual Hosts/Domain Names to create a unique default portal URL. When a user logs into a portal, he or she sees a set of pre-configured links and bookmarks that are specific to that portal. You can configure whether or not NetExtender is displayed on a Virtual Office portal, and if you want NetExtender to automatically launch when users log in to the portal. The administrator configures which elements each portal displays through the Portal Settings window. For information on configuring portals, refer to Portals > Portals.

Domains Overview

A domain in the Secure Mobile Access environment is a mechanism that enables authentication of users attempting to access the network being serviced by the SMA/SRA appliance. Domain types include the Secure Mobile Access internal LocalDomain, and the external platforms Microsoft Active Directory, LDAP, and RADIUS. Often, only one domain suffices to provide authentication to your organization, although a larger organization might require distributed domains to handle multiple nodes or collections of users attempting to access applications through the portal.

Application Offloading and HTTP(S) Bookmarks Overview

SMA/SRA appliances use HTTP(S) bookmarks and application offloading to provide access to web-based applications running on servers within the intranet. This includes SharePoint 2007 and the enhanced versions of commonly-used Web mail interfaces, such as Microsoft OWA Premium and Domino Web Access 8.0.1, 8.5.1, and 8.5.2. SharePoint 2010 is supported with application offloading, but not with HTTP(S) bookmarks. SharePoint 2013 is supported with application offloading. Note that third-party modules that are not proxy friendly might not be supported by SharePoint.

Both application offloading and HTTP(S) bookmarks use an HTTP(S) reverse proxy. A reverse proxy is a proxy server that is deployed between a remote user outside an intranet and a target Web server within the intranet. The reverse proxy intercepts and forwards packets that originate from outside the intranet. An HTTP(S) reverse proxy specifically intercepts HTTP(S) requests and responses.

Application Offloading provides secure access to both internal and publicly hosted Web applications. An application offloading host is created as a special-purpose portal with an associated virtual host acting as a proxy for the backend Web application.

Unlike HTTP(S) bookmarks, access to offloaded applications is not limited to remote users. The administrator can enforce strong authentication and access policies for specific users or groups. For instance, in an organization certain guest users might need Two-factor or Client Certificate authentication to access Outlook Web Access (OWA), but are not allowed to access OWA public folders. If authentication is enabled, multiple layers of advanced authentication features such as One Time Password, Two-factor Authentication, Client Certificate Authentication and Single Sign-On can be applied on top of each other for the offloaded host.

The offloaded application portal must be configured as a virtual host with a suitable Secure Mobile Access domain. It is possible to disable authentication and access policy enforcement for such an offloaded host.

Web transactions can be centrally monitored by viewing the logs. In addition, Web Application Firewall can protect offloaded application hosts from any unexpected intrusion, such as Cross-site scripting or SQL Injection.

Access to offloaded Web applications happens seamlessly as URLs in the proxied page are not rewritten in the manner used by HTTP or HTTPS bookmarks.

Benefits of HTTP(S) Bookmarks

By using HTTP(S) bookmarks, users can access the full-featured versions of SharePoint 2007, Microsoft OWA Premium, and Domino Web Access 8.0.1, 8.5.1, and 8.5.2 Web mail interfaces. These interfaces are easier to use and provide more enhanced features than their basic counterparts.

Benefits of Application Offloading

An offloaded Web application has the following advantages over configuring the Web application as an HTTP(S) bookmark in Secure Mobile Access:

No URL rewriting is necessary, thereby improving throughput significantly.
The functionality of the original Web application is retained almost completely, while an HTTP(S) bookmark is a best-effort solution.
Application offloading extends Secure Mobile Access security features to publicly hosted Web sites.

Application offloading can be used in any of the following scenarios:

To function as an SSL offloader and add HTTPS support to the offloaded Web application, using SSL acceleration of the SMA/SRA appliance.
In conjunction with the Web Application Firewall subscription service to provide the offloaded Web application continuous protection from malicious Web attacks.
To add strong or stacked authentication to the offloaded Web application, including Two-factor authentication, One Time Passwords and Client Certificate authentication.
To control granular access to the offloaded Web application using global, group or user based access policies.
To support Web applications not currently supported by HTTP/HTTPS bookmarks. Application Offloading does not require URL rewriting, thereby delivering complete application functionality without compromising throughput.
To authenticate ActiveSync Application Offloading technology that delivers Web applications using Virtual Hosting and Reverse Proxy. ActiveSync authentication does not require URL rewriting in order to deliver the Web applications seamlessly. As an example, the ActiveSync protocol is used by a mobile phone’s email client to synchronize with an Exchange server, as explained in ActiveSync Authentication.

Supported Platforms

Appliance Platforms

Application Offloading and HTTP(S) bookmarks are supported on all the SMA/SRA appliances that support the Secure Mobile Access 8.6 release:

SMA 400
SMA 200
SRA 4600
SRA 1600
SMA 500v Virtual Appliance
HTTP Versions

HTTP(S) bookmarks and application offloading portals support both HTTP/1.0 and HTTP/1.1.

Certain performance optimization features, such as caching, compression, SSL hardware acceleration, HTTP connection persistence, TCP connection multiplexing and transfer-chunk encoding for proxies are automatically enabled depending on the usage.

Applications

SharePoint 2010 and SharePoint 2013 are supported with application offloading, but not with HTTP(S) bookmarks. The following features have been tested and verified as working well on the indicated browsers:

 

Supported SharePoint features 

SharePoint Features

Browsers

Add Announcement

Delete Announcement

Download Document

Add Document

Delete Document

Add New Item

Delete Item

Internet Explorer 9

Firefox 16.0 and later

Chrome 22.0 and later

The following Web applications have been tested and verified to work with HTTP(S) bookmarks and as offloaded applications:

Microsoft Outlook Web Access 2013

Microsoft Outlook Web Access 2010

Microsoft Outlook Web Access 2007

* 
NOTE: Outlook Web Access is supported on the SMA 400/200, SRA 4600/1600, and the SMA 500v Virtual Appliance platforms.
Windows SharePoint 2013 (supported only using App Offloading)

Windows SharePoint 2007 (supported only using App Offloading)

Windows SharePoint Services 3.0

* 
NOTE: The integrated client features of SharePoint are not supported.
Lotus Domino Web Access 8.0.1

Lotus Domino Web Access 8.5.1

Lotus Domino Web Access 8.5.2

* 
NOTE: Domino Web Access is supported on the SMA 400/200, SRA 4600/1600, and the SMA 500v Virtual Appliance platforms.
Novell Groupwise Web Access 7.0
ActiveSync with Microsoft Exchange 2010
ActiveSync with Microsoft Exchange 2007
ActiveSync with Microsoft Exchange 2003

Exchange ActiveSync is supported on the following:

Apple iPhone
Apple iPad
Android 2.3.x (Gingerbread), 4.0.x (ICS) and 4.1 (Jelly Bean) based phones
* 
NOTE: Application Offloading supports authentication for ActiveSync. ActiveSync is a protocol used by a mobile phone’s email client to synchronize with an Exchange server. The Administrator can create an offloading portal and set the application server host to the backend Exchange server. Then, a user can use the new virtual host name in a mobile phone’s email client, and synchronize with the backend Exchange server through the SMA/SRA appliance.
Authentication Schemes

The following authentication schemes are supported for use with application offloading and HTTP(S) bookmarks:

Basic – Collects credentials in the form of a username and password.
Forms-based authentication – Uses a Web form to collect credentials.

Software Prerequisites

The following end-user requirements must be met in order to access the complete set of application offloading and HTTP(S) bookmarks features:

Internet Explorer 9.0 or newer
Windows 10 and Windows 7
* 
NOTE:  
The maximum number of users supported is limited by the number of applications being accessed and the volume of application traffic being sent.
Feature support varies based on your hardware and installation, see the respective sections for more detailed information about specific application support.
 
* 
TIP: If you are using the correct Web browser and operating system, and a supported application does not work, delete the browser session cookies, close and reopen all instances of your browser, clear the browser cache, and then try again.

Supported Application Deployment Considerations

Be aware of these installation and general feature caveats when using application offloading and HTTP(S) bookmarks with the following software applications:

SharePoint
SharePoint 2013 and SharePoint 2010 are supported with application offloading, but not with HTTP(S) bookmarks.
Outlook Anywhere
SMA/SRAs with Application Offloading.
Outlook Anywhere uses Microsoft’s MS-RPCH proprietary protocol that could conflict with normal HTTP(S) protocol.

Application Offloading is only supported on SharePoint 2013 and with any application using HTTP/HTTPS. Secure Mobile Access has limited support for applications using Web services and no support for non-HTTP protocols wrapped within HTTP.

The application should not contain hard-coded self-referencing URLs. If these are present, the Application Offloading proxy must rewrite the URLs. Because Web site development does not usually conform to HTML standards, the proxy can only do a best-effort translation when rewriting these URLs. Specifying hard-coded, self-referencing URLs is not recommended when developing a Web site because content developers must modify the Web pages whenever the hosting server is moved to a different IP or hostname.

For example, if the backend application has a hard-coded IP address and scheme within URLs as follows, Application Offloading must rewrite the URL.

<a href="http://1.1.1.1/doAction.cgi?test=foo">

This can be done by enabling the Enable URL Rewriting for self-referenced URLs setting for the Application Offloading Portal, but all the URLs might not be rewritten, depending on how the Web application has been developed. (This limitation is usually the same for other vendors employing reverse proxy mode.)

Cross Domain Single Sign-On

External Website Bookmarks can be created for application offloading portals to achieve a single point of access for users. This allows users to automatically log in to application offloading portals after logging into the main portal.

To use Cross Domain Single Sign-on (SSO):
1
Create two or more portals with the same shared domain (from Virtual Host Domain name) and that need authentication. One portal should be a regular portal. These portals are also in the same SMA/SRA appliance’s domain so that a user can log in to both of them with the same credentials. Adding Portals explains how to create a portal.
2
Log in to the portal and create a bookmark, as explained in Adding or Editing User Bookmarks.
3
Set the service to External Web Site, as explained in External Web Site.
4
Enable Automatically log in for the bookmark that enables Cross Domain SSO for this bookmark.
5
Specify a Host that is a portal with the same shared domain name.
6
Save the bookmark and launch it. The new portal is logged in automatically without any credential.

The shared domain names do not need to be identical; a sub-domain also works. For example, one portal is a regular portal whose virtual host domain name is “www.example.com” and its shared domain name is “.example.com.” The other portal’s virtual host domain name is “intranet.eng.example.com” and the shared domain name is “.eng.example.com.” If a bookmark to xyz.eng.example.com is created in the www.example.com portal, Cross Domain SSO works because “.eng.example.com” is a sub-domain of “.example.com.”

ActiveSync Authentication

Application Offloading now supports authentication for ActiveSync. Application Offloading technology delivers Web applications using Virtual Hosting and Reverse Proxy. Users still need to authenticate with the SMA/SRA appliance before accessing the backend Web application. However, the proxy avoids URL rewriting in order to deliver the Web applications seamlessly.

ActiveSync is a protocol used by a mobile phone’s email client to synchronize with an Exchange server. The Administrator can create an offloading portal and set the application server host to the backend Exchange server. Then, a user can use the new virtual host name in a mobile phone’s email client, and synchronize with the backend Exchange server through the SMA/SRA appliance.

* 
NOTE: On iPhones/iPads running versions earlier than iOS 6.1.2, initial account synchronization might fail if a calendar contains a recurring invite.
NOTE: To provide better protection for the Exchange Server, anonymous ActiveSync access will not be supported in the future.

ActiveSync is managed through the Portals > Offload Web Application > Offloading > Security Settings page:

To configure ActiveSync authentication, clear Disable Authentication Controls to display the authentication fields. Select Enable ActiveSync authentication and then type the default domain name. The default domain name cannot be used when the domain name is set in the email client’s setting.

ActiveSync Log Entries

The Log > View page is updated when a Web application is offloaded. Most mobile systems (iPhone, Android, and so on) support ActiveSync. These log entries identify when the client began to use ActiveSync through the offloading portal. The ActiveSync message identifies the device ID (ActiveSync: Device ID is…) for an ActiveSync request unless a client sets up the account and the request does not contain a device ID.

* 
NOTE: A user’s credential in the Exchange server must be the same as the one in the SMA/SRA appliance. Many authentication types are available for each domain in the appliance. If using the Local User Database, make sure the user name and password is the same as the one for the Exchange server. Fortunately, other authentication types like Active Directory can share credentials for both the Exchange server and SMA/SRA appliance. However, authentication using authentication types that share credentials might take longer and the first ActiveSync request can time out. After authentication succeeds, a session is created and other requests are not necessary to be authenticated again.

Configuring a Portal to Check Email From an Android Device

The following example shows how to set up ActiveSync to check emails from an Android device. Be sure to replace entries shown in the examples with entries for your environment, and be careful to input the correct password. Otherwise, the account is blocked.

1
Create a Domain name of webmail.example.com. Set the Active Directory domain and Server address to webmail.example.com. Set the Portal name to VirtualOffice.

2
In the Secure Mobile Access management interface, scroll down to the relevant section and create an offloading portal with the name sales.

3
Set the Scheme to Secure Web (HTTPS).
4
Set the Application Server Host to your Exchange server, for example webmail.example.com.
5
Set the virtual host name, for example, webmail.example.com. The virtual host name should be resolved by the DNS server. Otherwise, modify the hosts file in the Android phone.
6
Select Enable Email Clients Authentication. Leave the default domain name blank or input webmail.example.com.
7
Click the Virtual Host tab.

8
Turn on the Android phone, open the Email application, and type your email address and password. Click Next.

9
Choose Exchange.
10
Input your Domain\Username, Password, and Server. No domain name is displayed, so use the default domain name specified in the offloading portal’s setting. Select Accept all SSL certificates and click Next.
11
If the AD authentication times out, the Setup could not finish message is displayed. Wait about 20 seconds and try again. You can also check the Secure Mobile Access log to see if the user logged in successfully. You might not encounter this problem if the AD authentication is fast.

12
When the authentication finishes, a security warning appears. Click OK to continue, modify your account settings, and click Next.

13
Try to send and receive emails, and ensure that ActiveSync entries are included in the Secure Mobile Access log.

Network Resources Overview

Network Resources are the granular components of a trusted network that can be accessed using the SMA/SRA appliance. Network Resources can be pre-defined by the administrator and assigned to users or groups as bookmarks, or users can define and bookmark their own Network Resources.

The following sections describe types of network resources supported by the SMA/SRA appliance:

HTTP (Web) and Secure HTTPS (Web)

The SMA/SRA appliance provides proxy access to an HTTP or HTTPS server on the internal network, Internet, or any other network segment that can be reached by the appliance. The remote user communicates with the SMA/SRA appliance using HTTPS and requests a URL. The URL is then retrieved over HTTP by the SMA/SRA appliance. The URL is transformed as needed, and returned encrypted to the remote user.

The Secure Mobile Access administrator can configure Web (HTTP) or Secure Web (HTTPS) bookmarks to allow user access to web-based resources and applications such as Microsoft OWA Premium, Windows SharePoint 2007, Novell Groupwise Web Access 7.0, or Domino Web Access 8.0.1, 8.5.1, and 8.5.2 with HTTP(S) reverse proxy support. Reverse-proxy bookmarks also support the HTTP 1.1 protocol and connection persistence.

HTTPS bookmarks on SMA 400 and SRA 4600 appliances support keys of up to 2048 bits.

HTTP(S) caching is supported on the SMA/SRA appliance for use when it is acting as a proxy Web server deployed between a remote user and a local Web server. The proxy is allowed to cache HTTP(S) content on the SMA/SRA appliance which the internal Web server deems cacheable based on the HTTP(S) protocol specifications. For subsequent requests, the cached content is returned only after ensuring that the user is authenticated with the SMA/SRA appliance and is cleared for access by the access policies. However, Secure Mobile Access optimizes traffic to the backend Web server by using TCP connection multiplexing, where a single TCP connection is used for multiple user sessions to the same web server. Caching is predominantly used for static Web content like JavaScript files, style sheets, and images. The proxy can parse HTML/JavaScript/CSS documents of indefinite length. The administrator can enable or disable caching, flush cached content and set the maximum size for the cache.

Content received by the SMA/SRA appliance from the local Web server is compressed using gzip before sending it over the Internet to the remote client. Compressing content sent from the appliance saves bandwidth and results in higher throughput. Furthermore, only compressed content is cached, saving nearly 40-50 percent of the required memory. Note that gzip compression is not available on the local (clear text side) of the SMA/SRA appliance, or for HTTPS requests from the remote client.

Telnet

Java is being deprecated. Going forward, use HTML5 bookmarks. 8.6 utilizes HTML5 by default.

To enable Java for legacy support, call SonicWall Customer Support for assistance. Note that Java will not be supported in the future.

Telnet client is delivered through the remote user’s Web browser. The remote user can specify the IP address of any accessible Telnet server and the SMA/SRA appliance makes a connection to the server. Communication between the user over SSL and the server is proxied using native Telnet. The Telnet applet supports MS JVM (Microsoft Java Virtual Machine) in Internet Explorer, and requires Sun Java Runtime Environment (JRE) 1.1 or higher for other browsers. Telnet also supports HTML5 and Smart Access selection.

SSHv2

Java is being deprecated. Going forward, use HTML5 bookmarks. 8.6 utilizes HTML5 by default.

To enable Java for legacy support, call SonicWall Customer Support for assistance. Note that Java will not be supported in the future.

SSH clients delivered through the remote user’s Web browser. The remote user can specify the IP address of any accessible SSH server and the SMA/SRA appliance makes a connection to the server. Communication between the user over SSL and the server is proxied using natively encrypted SSH. SSHv2 provides stronger encryption and has other advanced features, and can only connect to a server that supports SSHv2. SSHv2 support sets the terminal type to VT100. SSHv2 requires JRE 1.6.0_10 or higher, available from http://java.sun.com. SSHv2 also supports HTML5 and Smart Access selection.

FTP (Web)

Proxy access to an FTP server on the internal network, the Internet, or any other network segment that can be reached by the SMA/SRA appliance. The remote user communicates with the SMA/SRA appliance by HTTPS and requests a URL that is retrieved over HTTP by the SMA/SRA appliance, transformed as needed, and returned encrypted to the remote user. FTP supports 25 character sets, including four Japanese sets, two Chinese sets, and two Korean sets. The client browser and operating system must support the desired character set, and language packs might be required. FTP also supports HTML5 and Smart Access selection.

File Shares (CIFS)

File Shares provide remote users with a secure Web interface to Microsoft File Shares using the CIFS (Common Internet File System) or the older SMB (Server Message Block) protocols. Using a Web interface similar in style to Microsoft’s familiar Network Neighborhood or My Network Places, File Shares allow users with appropriate permissions to browse network shares, rename, delete, retrieve, and upload files, and to create bookmarks for later recall. File shares can be configured to allow restricted server path access.

Remote Desktop Protocols and Virtual Network Computing

RDP and VNC are supported on Windows, Linux, and Mac operating systems. Most Microsoft workstations and servers have RDP server capabilities that can be enabled for remote access, and there are a number of freely available VNC servers that can be downloaded and installed on most operating systems. RDP and VNC also supports HTML5 and Smart Access selection. The RDP and VNC clients are automatically delivered to authorized remote users through their Web browser in the following formats:

VNC - VNC was originally developed by AT&T, but is today widely available as open source software. Any one of the many variants of VNC servers available can be installed on most any workstation or server for remote access. The VNC client to connect to those servers is delivered to remote users through the Web browser as a Java client.
RDP 7 Support

The SMA/SRA appliance supports connections with RDP 7 clients and supports the RDP 7 feature set. RDP 7 is available on following operating systems:

Windows Server 2016
Windows Server 2012
Windows 10
Windows 7
Windows Vista SP2
Windows Vista SP1
RDP 6 Support

The SMA/SRA appliance supports connections with RDP 6.1 and RDP 6 clients, and supports the RDP 5 feature set plus four RDP 6 features.

RDC 6.1 is included with the following operating systems:

Windows 7
Windows Server 2008
Windows Vista Service Pack 1 (SP1)

RDC 6.1 incorporates the following functionality in Windows Server 2008:

Terminal Services RemoteApp
Terminal Services EasyPrint driver
Single Sign-On

For more information, see Adding or Editing User Bookmarks.

* 
NOTE: RDP 6 and RDP 7 end client systems must have the client installed on their system. The SMA/SRA appliance does not provision the mstsc client and utilizes the locally installed client for those connections.

Application Protocols Using RDP

Applications protocols are RDP sessions that provide access to a specific application rather than to an entire desktop. This allows defined access to an individual application, such as CRM or accounting software. When the application is closed, the session closes. The following RDP formats can be used as applications protocols:

RDP Native – Uses the native RDP client to connect to the terminal server, and to automatically invoke an application at the specified path (for example, C:\programfiles\microsoft office\office11\winword.exe)
RDP HTML5 – Uses the HTML5-based RDP client to connect to the terminal server, and to automatically invoke an application at the specified path (for example, C:\programfiles\wireshark\wireshark.exe).
Application Support for SSO, User Policies, Bookmarks

The following table provides a list of application-specific support for Single Sign-On (SSO), global/group/user policies, and bookmark Single Sign-On control policies.

Application Support Table

Application

Supports SSO

Global/Group/
User Policies

Bookmark Policies

Terminal Services (RDP - Native)

Yes

Yes

Yes

Terminal Services (RDP - HTML5)

Yes

Yes

Yes

Virtual Network Computing (VNC - HTML5)

Yes

Yes

Yes

File Transfer Protocol (FTP)

Yes

Yes

Yes

Telnet

Yes

Yes

Yes

Telnet (HTML5)

Yes

Yes

Yes

Secure Shell (SSH)

Yes

Yes

Yes

Web (HTTP)

Yes

Yes

Yes

Secure Web (HTTPS)

Yes

Yes

Yes

File Shares (CIFS)

Yes

Yes

Yes

Citrix Portal (Citrix)

No

Yes

Yes

Microsoft Outlook Web Access

Secure Mobile Access includes reverse proxy application support for all versions of OWA 2013, 2010, and 2007.

Microsoft OWA Premium mode is a Web client for Microsoft Outlook that simulates the Microsoft Outlook interface and provides more features than basic OWA. Microsoft OWA Premium includes features such as spell check, creation and modification of server-side rules, Web beacon blocking, support for tasks, auto-signature support, and address book enhancements. Secure Mobile Access HTTP(S) reverse proxy supports Microsoft OWA Premium.

See Creating Unique Access Policies for AD Groups for a use case involving configuring group-based access policies for multiple Active Directory groups needing access to Outlook Web Access.

Windows SharePoint Services

The Secure Mobile Access reverse proxy application support for Windows SharePoint 2007 and Windows SharePoint Services 3.0 includes the following features:

Site Templates
Wiki Sites
Blogs
RSS Feeds
Project Manager
Mobile Access to Content
My Site
Search Center
Document Center
Document Translation Management
Web Content Management
Workflows
Report Center

Lotus Domino Web Access

The SMA/SRA appliance reverse proxy application supports for Domino Web Access 8.0.1, 8.5.1, and 8.5.2 includes the following features:

 

Lotus Domino web access: Supported features 

8.5.1 and 8.5.2 Features

8.0.1 Features

Full Mode:

Email

Email

Calendar

Calendar

Contacts

Contacts

To Do

To Do

Notebook

Notebook

Lite Mode:

Email

Email

Calendar

Calendar

Contacts

 

Ultra Lite Mode:

Inbox

 

Sent

 

All Docs

 

Day At a Glance

 

Contacts

 

Trash

 

Citrix Portal

Citrix is a remote access, application sharing service, similar to RDP. It enables users to remotely access files and applications on a central computer over a secure connection.

The Citrix Receiver clients for ActiveX and Java are supported, as well as the earlier XenApp and ICA clients. In previous versions of Citrix, the Citrix ICA Client was renamed as the Citrix XenApp plug-in.

Secure Mobile Access supports Citrix XenApp Server 7.6, 6.5, XenApp Server 6.0, and XenApp Server 5.0.

Secure Mobile Access supports Citrix Receiver for Windows 4.2, 4.1, 4.0(Online Plug-in 14.2, 14.1, 14.0); Java client version 10.1.006 or higher.

* 
NOTE: Citrix Java Bookmarks are no longer officially supported by SonicWall Inc. because Citrix has ended support for the Java Receiver. SonicWall Inc. recommends using the HTML5 or ActiveX access methods for Citrix Bookmarks.

SNMP Overview

SMA/SRA appliances support Simple Network Management Protocol (SNMP) that reports remote access statistics. SNMP support facilitates network management for administrators, allowing them to leverage standardized reporting tools.

DNS Overview

The administrator can configure DNS on the SMA/SRA appliance to enable it to resolve host names with IP addresses. The Secure Mobile Access web-based management interface allows the administrator to configure a hostname, DNS server addresses, and WINS server addresses.

Network Routes Overview

Configuring a default network route allows your SMA/SRA appliance to reach remote IP networks through the designated default gateway. The gateway is typically the upstream firewall to which the SMA/SRA appliance is connected. In addition to default routes, it also possible to configure specific static routes to hosts and networks as a preferred path, rather than using the default gateway.

NetExtender Overview

This section provides an overview to the NetExtender feature.

Topics:

For information on using NetExtender, refer to the NetExtender > Status or refer to the Secure Mobile Access User’s Guide.

What is NetExtender?

SonicWall Inc. NetExtender is a transparent software application for Windows and Linux users that enables remote users to securely connect to the remote network. With NetExtender, remote users can securely run any application on the remote network. Users can upload and download files, mount network drives, and access resources as if they were on the local network. The NetExtender connection uses a Point-to-Point Protocol (PPP) connection.

NetExtender capabilities include the SonicWall Inc. Mobile Connect app for Mac, Apple iPhone, iPad, and iPod Touch. Mobile Connect enables secure, mobile connections to private networks protected by SonicWall Inc. security appliances. For information about installing and using SonicWall Inc. Mobile Connect, see the SonicWall Inc. Mobile Connect User’s Guide.

Benefits

NetExtender provides remote users with full access to your protected internal network. The experience is virtually identical to that of using a traditional IPSec VPN client, but NetExtender does not require any manual client installation. Instead, the NetExtender Windows client is automatically installed on a remote user’s PC by an ActiveX control when using the Internet Explorer browser or Firefox. On Linux systems, supported browsers use Java controls to automatically install NetExtender from the Virtual Office portal.

The NetExtender Windows client also has a custom-dialer that allows it to be launched from the Windows Network Connections menu. This custom-dialer allows NetExtender to be connected before the Windows domain login. The NetExtender Windows client also supports a single active connection, and displays real-time throughput and data compression ratios in the client.

After installation, NetExtender automatically launches and connects a virtual adapter for SSL-secure NetExtender point-to-point access to permitted hosts and subnets on the internal network.

NetExtender Concepts

The following sections describe advanced NetExtender concepts:

Stand-Alone Client

Secure Mobile Access provides a stand-alone NetExtender application. NetExtender is a browser-installed lightweight application that provides comprehensive remote access without requiring users to manually download and install the application. The first time a user launches NetExtender, the NetExtender stand-alone client is automatically installed on the user’s PC. The installer creates a profile based on the user’s login information. The installer window then closes and automatically launches NetExtender. If the user has a legacy version of NetExtender installed, the installer first uninstalls the old NetExtender and installs the new version.

After the NetExtender stand-alone client has been installed, Windows users can launch NetExtender from their PC’s Start > Programs menu and configure NetExtender to launch when Windows boots.

NetExtender can establish a VPN session before the user logs into the Windows domain. For Windows Vista or later, users can click Switch User on the Windows login screen and click the blue computer icon that appears at the right bottom of the screen to view the dialup connection list, and then can select NetExtender to connect.

On Linux systems, the installer creates a desktop shortcut in /usr/share/NetExtender. This can be dragged to the shortcut bar in environments like Gnome and KDE.

NetExtender is compatible with the following SonicWall Inc. appliances:

SMA 400/200
SRA 4600/1600
SMA 500v Virtual Appliance
NSA, TZ, and SuperMassive 9000 series (with an SSL VPN license)

NetExtender is also backward compatible with older SRA 1200/4200 and SSL-VPN 2000/4000 appliances for connectivity.

NetExtender is officially supported on the following client platforms:

Fedora 14+
Ubuntu 11.04+
OpenSUSE 10.3+
Windows 10, Windows 7, Windows 2012, Windows Server 2008 R2.

NetExtender might work properly on other Linux distributions, but they are not officially supported by SonicWall Inc..

* 
NOTE: The Mobile Connect application is now available for iOS 4.3 or higher and Android 4.0 or higher.
Multiple Ranges and Routes

Multiple range and route support for NetExtender on SMA/SRA appliances enables network administrators to easily segment groups and users without the need to configure firewall rules to govern access. This user segmentation allows for granular control of access to the network—allowing users access to necessary resources while restricting access to sensitive resources to only those who require it.

For networks that do not require segmentation, client addresses and routes can be configured globally. The following sections describe the multiple range and route enhancements:

IP Address User Segmentation

Administrators can configure separate NetExtender IP address ranges for users and groups. These settings are configured on the Users > Local Users and Users > Local Groups pages, using the NetExtender tab in the Edit User and Edit Group windows.

When configuring multiple user and group NetExtender IP address ranges, it is important to know how the SMA/SRA appliance assigns IP addresses. When assigning an IP address to a NetExtender client, the SMA/SRA appliance uses the following hierarchy of ranges:

1
An IP address from the range defined in the user’s local profile.
2
An IP address from the range defined in the group profile to which the user belongs.
3
An IP address from the global NetExtender range.

To reserve a single IP address for an individual user, the administrator can enter the same IP address in both the Client Address Range Begin and Client Address Range End fields on the NetExtender tab of the Edit Group window.

Client Routes

NetExtender client routes are used to allow and deny access to various network resources. Client routes can also be configured at the user and group level. NetExtender client routes are also configured on the Edit User and Edit Group windows. The segmentation of client routes is fully customizable, allowing the administrator to specify any possible permutation of user, group, and global routes (such as only group routes, only user routes, group and global routes, user, group, and global routes, and so on). This segmentation is controlled by Add Global NetExtender Client routes and Add Group NetExtender Client routes.

NetExtender with External Authentication Methods

Networks that use an external authentication server are not configured with local usernames on the SMA/SRA appliance. In such cases, when a user is successfully authenticated, a local user account is created when the Add Global NetExtender Client routes and Add Group NetExtender Client routes settings are enabled.

Point to Point Server IP Address

In Secure Mobile Access, the PPP server IP address is 192.0.2.1 for all connecting clients. This IP address is transparent to both the remote users connecting to the internal network and to the internal network hosts communicating with remote NetExtender clients. Because the PPP server IP address is independent from the NetExtender address pool, all IP addresses in the global NetExtender address pool are used for NetExtender clients.

Connection Scripts

SMA/SRA appliances provide users with the ability to run batch file scripts when NetExtender connects and disconnects. The scripts can be used to map or disconnect network drives and printers, launch applications, or open files or Web sites. NetExtender Connection Scripts can support any valid batch file commands.

Tunnel All Mode

Tunnel All mode routes all traffic to and from the remote user over the Secure Mobile Access NetExtender tunnel—including traffic destined for the remote user’s local network. This is accomplished by adding the following routes to the remote client’s route table:

 

Tunnel All mode: Routes to be added to remote client’s route table 

IP Address

Subnet mask

0.0.0.0

0.0.0.0

0.0.0.0

128.0.0.0

128.0.0.0

128.0.0.0

NetExtender also adds routes for the local networks of all connected Network Connections. These routes are configured with higher metrics than any existing routes to force traffic destined for the local network over the Secure Mobile Access tunnel instead. For example, if a remote user is has the IP address 10.0.67.64 on the 10.0.*.* network, the route 10.0.0.0/255.255.0.0 is added to route traffic through the Secure Mobile Access tunnel.

Tunnel All mode can be configured at the global, group, and user levels.

Proxy Configuration

SMA/SRA appliances support NetExtender sessions using proxy configurations. Currently, only HTTPS proxy is supported. When launching NetExtender from the Web portal, if your browser is already configured for proxy access, NetExtender automatically inherits the proxy settings. The proxy settings can also be manually configured in the NetExtender client preferences. NetExtender can automatically detect proxy settings for proxy servers that support the Web Proxy Auto Discovery (WPAD) Protocol.

NetExtender provides three options for configuring proxy settings:

Automatically detect settings - To use this setting, the proxy server must support Web Proxy Auto Discovery Protocol (WPAD)) that can push the proxy settings script to the client automatically.
Use automatic configuration script - If you know the location of the proxy settings script, you can select this option and provide the URL of the script.
Use proxy server - You can use this option to specify the IP address and port of the proxy server. Optionally, you can enter an IP address or domain in the BypassProxy field to allow direct connections to those addresses and bypass the proxy server. If required, you can enter a user name and password for the proxy server. If the proxy server requires a username and password, but you do not specify them, a NetExtender pop-up window prompts you to enter them when you first connect.

When NetExtender connects using proxy settings, it establishes an HTTPS connection to the proxy server instead of connecting to the SMA/SRA server directly. The proxy server then forwards traffic to the SMA/SRA server. All traffic is encrypted by SSL with the certificate negotiated by NetExtender, of which the proxy server has no knowledge. The connecting process is identical for proxy and non-proxy users.

Two-Factor Authentication Overview

Two-factor authentication is an authentication method that requires two independent pieces of information to establish identity and privileges. Two-factor authentication is stronger and more rigorous than traditional password authentication that only requires one factor (the user’s password).

SonicWall Inc.’s implementation of two-factor authentication partners with two of the leaders in advanced user authentication: RSA and VASCO.

Two RADIUS servers can be used for two-factor authentication, allowing users to be authenticated through the Web portal or with an Secure Mobile Access client such as NetExtender or Secure Virtual Assist.

* 
NOTE: Single sign-on (SSO) in SMA/SRA appliances do not support two-factor authentication.

See the following sections:

Benefits of Two-Factor Authentication

Two-factor authentication offers the following benefits:

Greatly enhances security by requiring two independent pieces of information for authentication.
Reduces the risk posed by weak user passwords that are easily cracked.
Minimizes the time administrators spend training and supporting users by providing a strong authentication process that is simple, intuitive, and automated.

How Does Two-Factor Authentication Work?

Two-factor authentication requires the use of a third-party authentication service, or two separate RADIUS authentication servers.

With two-factor authentication, users must enter a valid temporary passcode to gain access. A passcode consists of the following:

The user’s personal identification number (PIN)
A temporary token code or password

When two RADIUS servers are used, the second stage PIN or password can be sent to the user through SMS or email. NetExtender login and Secure Virtual Assist both provide extra challenge(s) for entering it.

When a third-party authentication service is used, it consists of two components:

An authentication server on which the administrator configures user names, assigns tokens, and manages authentication-related tasks.
Physical tokens that the administrator gives to users which display temporary token codes.

Users receive the temporary token codes from their RSA or VASCO token cards. The token cards display a new temporary token code every minute. When the RSA or VASCO server authenticates the user, it verifies that the token code timestamp is current. If the PIN is correct and the token code is correct and current, the user is authenticated.

Because user authentication requires these two factors, the dual RADIUS servers solution, the RSA SecureID solution, and the VASCO DIGIPASS solution offers stronger security than traditional passwords (single-factor authentication).

Supported Two-Factor Authentication Providers

RSA

RSA is an algorithm for public-key cryptography. RSA utilizes RSA SecurID tokens to authenticate through an RSA Authentication Manager server. RSA is not supported on all hardware platforms and is supported through RADIUS only.

VASCO

VASCO is a public company that provides user authentication products. VASCO utilizes Digipass tokens to authenticate through a VASCO IdentiKey server. VASCO is supported on all SMA/SRA platforms.

VASCO Data Security delivers reliable authentication through the use of One Time Password technology. VASCO IdentiKey combined with SMA/SRA and firewall VPN appliances creates an open-market approach delivered through VASCO IdentiKey technology.

VASCO IdentiKey allows users to utilize the VASCO DIGIPASS concept that uses One Time Passwords that are assigned for time segments that provide easy and secure remote access. The One Time Password within the authentication request is verified on the VASCO IdentiKey. After verification, a RADIUS access-accept message is sent to the SMA/SRA server for authentication.

Two-Factor Authentication Login Processes

This section provides examples of the two-factor authentication login prompts when using Web login and NetExtender.

With Web login, the Username and Password fields are used to enter the first-stage credentials.

When prompting the user to input the challenge code, the message “Please enter the M.ID PIN:” is the reply message from the RADIUS server in this example; different RADIUS servers can have different reply message formats.

Some RADIUS servers might require the user to respond to several challenges to complete the authentication. In this example, the M.ID server asks the user to supply two challenges. The following passcode can be received through email or cellphone (if SMS is configured).

When using two-factor authentication with the NetExtender Windows client, the login process through the client is very similar to logging in through the Web page.

Initially, the Username and Password fields are used to enter the first-stage credentials.

This is followed by the PIN challenge.

Last, the Passcode challenge is displayed.

One Time Password Overview

This section provides an introduction to the One Time Password feature. This section contains the following topics:

What is One Time Password?

The Secure Mobile Access One Time Password feature adds a second layer of login security to the standard username and password. A one-time password is a randomly generated, single-use password. The Secure Mobile Access One Time Password feature is a two-factor authentication scheme that utilizes one-time passwords in addition to standard user name and password credentials, providing additional security for Secure Mobile Access users.

The Secure Mobile Access One Time Password feature requires users to first submit the correct Secure Mobile Access login credentials. After following the standard login procedure, Secure Mobile Access generates a one-time password that is sent to the user at a pre-defined email address. The user must log in to that email account to retrieve the one-time password and type it into the Secure Mobile Access login screen when prompted, before the one-time password expires.

Benefits of One Time Passwords

The Secure Mobile Access One Time Password feature provides more security than single, static passwords alone. Using a one-time password in addition to regular login credentials effectively adds a second layer of authentication. Users must be able to access the email address defined by the Secure Mobile Access administrator before completing the Secure Mobile Access One Time Password login process. Each one-time password is single-use and expires after a set time period, requiring that a new one-time password be generated after each successful login, cancelled or failed login attempt, or login attempt that has timed out, thus reducing the likelihood of a one-time password being compromised.

How Does the One Time Password Feature Work?

The Secure Mobile Access administrator can enable the One Time Password feature on a per-user or per-domain basis. To enable the One Time Password feature on a per-user basis, the administrator must edit the user settings in the Secure Mobile Access management interface. The administrator must also enter an external email address for each user who is enabled for One Time Passwords. For users of Active Directory and LDAP, the administrator can enable the One Time Password feature on a per-domain basis.

Enabling the One Time Password feature on a per-domain basis overrides individual “enabled” or “disabled” One Time Password settings. Enabling the One Time Password feature for domains does not override manually entered email addresses that take precedence over those auto-configured by a domain policy and over AD/LDAP settings.

In order to use the Secure Mobile Access One Time Password feature, the administrator must configure valid mail server settings in the Log > Settings page of the Secure Mobile Access management interface. The administrator can configure the One Time Password feature on a per-user or per-domain basis, and can configure timeout policies for users.

If the email addresses to which you want to deliver your One Time Passwords are in an external domain (such as SMS addresses or external webmail addresses), you might need to configure your SMTP server to allow relaying from the SMA/SRA appliance to the external domain.

For users enabled for the One Time Password feature either on a per-user or per-domain basis, the login process begins with entering standard user name and password credentials in the Secure Mobile Access interface. After login, users receive a message that a temporary password has been sent to a pre-defined email account. The user must log in to the external email account and retrieve the one-time password, then type or paste it into the appropriate field in the Secure Mobile Access login interface. Any user requests prior to entering the correct one-time password re-directs the user to the login page.

The one-time password is automatically deleted after a successful login and can also be deleted by the user by clicking Cancel in the Secure Mobile Access interface, or it is automatically deleted when the user fails to login within that user’s timeout policy period.

Configuring One Time Passwords for SMS-Capable Phones

Secure Mobile Access One Time Passwords can be configured to be sent by email directly to SMS-capable phones. Contact your cell phone service provider for further information about enabling SMS (Short Message Service).

The following is a list of SMS email formats for selected major carriers, where 4085551212 represents a 10-digit telephone number and area code.

Verizon: 4085551212@vtext.com
Sprint: 4085551212@messaging.sprintpcs.com
AT&T PCS: 4085551212@text.att.net
Cingular: 4085551212@mobile.mycingular.com
T-Mobile: 4085551212@tmomail.net
Nextel: 4085551212@messaging.nextel.com
Virgin Mobile: 4085551212@vmobl.com
Qwest: 4085551212@qwestmp.com
* 
TIP: Refer to the Using SMS Email Formats for a more detailed list of SMS email formats.
* 
NOTE: These SMS email formats are for reference only. These email formats are subject to change and can vary. You might need additional service or information from your provider before using SMS. Contact the SMS provider directly to verify these formats and for further information on SMS services, options, and capabilities.

To configure the SMA/SRA appliance to send one-time passwords to an SMS email address, follow the procedure described in Editing User Settings, and enter the user’s SMS address in the E-mail address field.

Verifying Administrator One Time Password Configuration

To verify that an individual user account has been enabled to use the One Time Password feature, log in to the Secure Mobile Access Virtual Office user interface using the credentials for that account.

If you are able to successfully log in to Virtual Office, you have correctly used the One Time Password feature.

If you cannot login using One Time Password, verify the following:

Are you able to login without being prompted to check your email for One-time Password? The user account has not been enabled to use the One-time Password feature.
Is the email address correct? If the email address for the user account has been entered incorrectly, log in to the management interface to correct the email address.
Is there no email with a one-time password? Wait a few minutes and refresh your email inbox. Check your spam filter. If there is no email after several minutes, try to login again to generate a new one-time password.
Have you accurately typed the one-time password in the correct field? Re-type or copy and paste the one-time password within the time allotted by the user’s timeout policy as set in the Log > Settings page.

End Point Control Overview

This section provides an introduction to the End Point Control feature. This section contains the following topics:

What is End Point Control?

In traditional VPN solutions, accessing your network from an untrusted site like an employee-owned computer or a kiosk at an airport or hotel increases the risk to your network resources. EPC provides secure access from any Web-enabled system, including devices in untrusted environments.

Benefits of End Point Control

The SMA/SRA appliance supports End Point Control (EPC) that provides the following benefits:

Verifies that the user’s environment is secure before establishing a connection.
Protects sensitive data and
Ensures that your network is not compromised when accessed from devices in untrusted environments.
Protects the network from threats originating from client devices participating in the SMA/SRA.

How Does End Point Control Work?

The SMA/SRA appliance provides end point security controls by completing host integrity checking and security protection mechanisms before a tunnel session is begun. Host integrity checks help ensure that the client system is in compliance with your organization’s security policy. SonicWall end point security controls are tightly integrated with access control to analyze the Windows client system and apply access controls based on the results.

End Point Control is supported on Mac iOS and Android mobile devices using Mobile Connect, allowing device profiles to be created for these devices. This provides security protection from threats against client devices and protection to the SMA/SRA appliance from threats originating from client devices logged in to the appliance. For more information on Mobile Connect, refer to the Mobile Connect User Guides.

Configuring End Point Control

To configure End Point Control (EPC), complete the following tasks:

1
Configure Device Profiles that allow or deny user authentication based on various global, group, or user attributes. See End Point Control > Device Profiles.
2
Add and configure groups and users to allow or deny End Point Control profiles. See Edit EPC Settings.
3
Configure users to inherit their group profiles. See Edit EPC Settings.
4
Enable End Point Control. See End Point Control > Status.
5
Connect to NetExtender and monitor the End Point Control log. See End Point Control > Log.

Secure Virtual Assist Overview

* 
NOTE: Secure Virtual Assist is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

This section provides an introduction to the Secure Virtual Assist feature. This section contains the following topics:

What is Secure Virtual Assist?

* 
NOTE: Secure Virtual Assist is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

Secure Virtual Assist is an easy to use tool that allows Secure Mobile Access users to remotely support customers by taking control of their computers while the customer observes. Providing support to customers is traditionally a costly and time consuming aspect of business. Secure Virtual Assist creates a simple to deploy, easy to use remote support solution.

Benefits of Secure Virtual Assist

* 
NOTE: Secure Virtual Assist is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

Secure Virtual Assist provides the following benefits:

Simplified and effective customer support - Support staff can use Secure Virtual Assist to directly access customers computers to troubleshoot and fix problems. This eliminates the need for customers to try to explain their problems and their computer’s behavior over the phone.
Time and cost savings - Secure Virtual Assist eliminates the need for support staff to visit customers to troubleshoot problems and reduces the average time-to-resolution of support calls.
Educational tool - Trainers and support staff can use Secure Virtual Assist to remotely show customers how to use programs and tools.
Seamless integration with existing authentication system - Ensures that the customers are who they say they are. Alternatively, the local database of the SMA/SRA appliance and tokenless two-factor authentication can be utilized.
Secure connections - 256-bit AES SSL encryption of the data by the SMA/SRA appliance provides a secure environment for the data and assists in the effort to be compliant with regulations like Sarbanes-Oxley and HIPAA.
Greater flexibility for remote access - Using the Secure Virtual Access functionality, support staff can access their personal systems located outside the LAN of the SMA/SRA appliance.

How Does Secure Virtual Assist Work?

* 
NOTE: Secure Virtual Assist is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

The following sections describe how the Secure Virtual Assist feature works:

Basic Operation
* 
NOTE: Secure Virtual Assist is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

Secure Virtual Assist is a lightweight, thin client that installs automatically using Java from the Secure Mobile Access Virtual Office without requiring the installation of any external software. For computers that do not support Java, Secure Virtual Assist can be manually installed by downloading an executable file from the Virtual Office.

For basic screen sharing support, administrative privileges are not required to run Secure Virtual Assist. For full installation of the client, administrative rights might be necessary, but full installation is not necessary to use the service.

When a user requests service as a customer, Secure Virtual Assist should not be run while connected to the system through RDP for Windows 7 and Windows Vista platforms. Secure Virtual Assist runs as a service for proper access to the customer’s system, so correct permissions cannot be set if it is run from an RDP connection.

There are two sides to a Secure Virtual Assist session: the customer view and the technician view. The customer is the person requesting assistance on their computer. The technician is the person providing assistance. A Secure Virtual Assist session consists of the following sequence of events:

1
The technician launches Secure Virtual Assist from the Secure Mobile Access Virtual Office.
2
The technician monitors the Assistance Queue for customers requesting assistance.
3
The customer requests assistance by one of the following methods:
Logs into the Secure Mobile Access Virtual Office and clicks on the Secure Virtual Assist link.
Receives an email invitation from the technician and clicks on the link to launch Secure Virtual Assist.
Navigate directly to the URL of the Secure Virtual Assist home page that is provided by the technician.
4
The Secure Virtual Assist application installs and runs on the customer’s browser.
5
The customer appears in the Secure Virtual Assist Assistance Queue.
6
The technician clicks on the customer’s name and launches a Secure Virtual Assist session.
7
The customer clicks on a warning pop-up window that gives the technician control over the customer’s computer.
8
The technician’s Secure Virtual Assist window now displays the customer’s entire display. The technician has complete control of the customer computer’s mouse and keyboard. The customer sees all of the actions that the technician does.
9
If at anytime the customer wants to end the session, they can take control and click End Virtual Assist in the bottom right corner of the screen.
10
When the session ends, the customer resumes sole control of the computer.
Remote File Transfer
* 
NOTE: Secure Virtual Assist is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

Secure Virtual Assist includes a Remote File Transfer feature that enables the technician to transfer files directly to and from the customer’s computer. The technician launches the File Transfer process by clicking a button in the Virtual Assist taskbar in the top left corner of the Secure Virtual Assist window. The File Transfer feature supports the upload and download of multiple files.

Chat Feature
* 
NOTE: Secure Virtual Assist is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

Secure Virtual Assist includes a chat feature that allows the technician and customer to communicate using an instant message-style chat function. Either the technician or the customer can initiate a chat session by clicking Chat in the Secure Virtual Assist taskbar.

Email Invitation
* 
NOTE: Secure Virtual Assist is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

From the technician view of Secure Virtual Assist, technicians can send email invitations to customers that contain a direct URL link to initiate a Secure Virtual Assist session. The technician can optionally include a unique message to the customer. When the customer clicks on the email link to Secure Virtual Assist, only the technician who sent the invitation can assist that customer.

Secure Virtual Access
* 
NOTE: Secure Virtual Assist is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

Secure Virtual Access, as part of the larger Secure Virtual Assist feature, allows technicians to gain access to systems outside the LAN of the SMA/SRA appliance, such as their personal systems. After downloading and installing a client from the portal page for Secure Virtual Access mode, the personal system appears only on that technician’s Secure Virtual Assist support queue, within the Secure Mobile Access management interface. While Secure Virtual Access must be enabled per-portal, this functionality provides greater remote access flexibility for support technicians.

Installing and using Secure Virtual Access requires administrative privileges.

Launching a Secure Virtual Assist Technician Session

* 
NOTE: Secure Virtual Assist is being deprecated. For legacy support, call SonicWall Customer Support for assistance.
To launch a Secure Virtual Assist session as a technician:
1
Log in to the Secure Mobile Access Virtual Office. If you are already logged in to the Secure Mobile Access management interface, click Virtual Office.
2
Click on Secure Virtual Assist.

3
If the Virtual Assist plug-in is not installed, the File Download window displays, and Secure Virtual Assist attempts to automatically install. Click Run to launch the program directly, or click Save to save the installer file to your computer, and then manually launch it.

When downloading through IPv6, the File Download window displays IPv6 information.

4
A pop-up wizard asks if you would like to install Secure Virtual Assist as a standalone client. Click Next to begin the installation.

5
Enter an SSLVPN Server Name or IP in the space provided and click Next.

6
When you see the confirmation screen, the installer is ready to install SonicWall Inc. Secure Virtual Assist on your computer. Click Next to begin the installation.

7
When Secure Virtual Assist launches for the first time, you might see a security warning pop-up window. De-select Always ask before opening this file to avoid this window in the future. Click Run.

8
The Secure Virtual Assist standalone application launches.

9
The technician is now ready to assist customers.

Performing Secure Virtual Assist Technician Tasks

* 
NOTE: Secure Virtual Assist is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

To get started, the technician logs into the SMA/SRA appliance and launches the Secure Virtual Assist application.

* 
NOTE: Each technician can only assist one customer at a time.

After the technician has launched the Secure Virtual Assist application, the technician can assist customers by completing the following tasks:

Inviting Customers by Email

To invite a customer to a Secure Virtual Assist session by email:

1
To invite a customer to Secure Virtual Assist, use the email invitation form on the left of the Secure Virtual Assist window.
 
* 
NOTE: Customers who launch Secure Virtual Assist from an email invitation can only be assisted by the technician who sent the invitation. Customers who manually launch Secure Virtual Assist can be assisted by any technician.
2
Enter the customer’s email address in the Customer E-mail field.
3
Optionally, enter Technician E-mail to use a different return email address than the default technician email.
4
Optionally, enter an Additional Message to the customer.
5
Click Invite. The customer receives an email with an HTML link to launch Secure Virtual Assist.
6
Customers requesting assistance appears in the Assistance Queue, and the duration of time they have been waiting is displayed.
Assisting Customers
1
A pop-up window in the lower right task bar alerts the technician when a customer is in the assistance queue.
2
Double-click on a customer’s user name to begin assisting the customer.

3
The customer’s entire desktop is displayed in the bottom right window of the Secure Virtual Assist application.

The technician now has complete control of the customer’s keyboard and mouse. The customer can see all of the actions that the technician does.

During a Secure Virtual Assist session, the customer is not locked out of their computer. Both the technician and customer can control the computer, although this might cause confusion and consternation if they both attempt “to drive” at the same time.

The customer has a small tool bar in the bottom right of their screen, with three options.

The customer has the following options during a Secure Virtual Assist session, each enabled after clicking the corresponding button.

Active - Toggles to the View Only mode, where the technician can view the customer’s computer but cannot control the computer.
Chat - Initiates a chat window with the technician.
End Virtual Assist - Terminates the session.
Using the Secure Virtual Assist Taskbar

The Technician’s view of Secure Virtual Assist includes a taskbar with a number of options.

In Windows, the taskbar contains the following buttons:

Full Screen - Adjusts the screen to fill the entire window.
Auto Scaling - Adjusts the screen to fit the window size.
Zoom - Zooms the display to one of several presets or allows you enter a specific value.
True Size - Zooms to 100 percent.
Refresh - Refreshes the display of the customer’s computer.
File Transfer - Launches a window to transfer files to and from the customer’s computer. see Using the Secure Virtual Assist File Transfer for more information.
Chat - Launches the chat window to communicate with the customer. The technician can also use the dedicated chat window in the bottom left window of the Secure Virtual Assist application.
System Info -Displays detailed information about the customer’s computer.

Reboot Customer - Reboot the customer’s computer. Unless you have Requested full control, the customer is warned about and given the opportunity to deny the reboot.
Active Screens - Switches to a second monitor if the customer’s computer has more than one monitor configured.

In MacOS, the taskbar contains the following buttons:

Refresh - Refreshes the display of the customer’s computer.
System Info -Displays detailed information about the customer’s computer similar to that shown for a Windows computer.
Reboot - Reboot the customer’s computer. Unless you have Requested full control, the customer is warned about and given the opportunity to deny the reboot.
Chat - Launches the text chat window to communicate with the customer. The technician can also use the dedicated chat window in the bottom left window of the Secure Virtual Assist application.
File Transfer - Launches a window to transfer files to and from the customer’s computer. see Using the Secure Virtual Assist File Transfer for more information.
Hide Toolbar - Hides the taskbar from view.
Gray Color - Displays everything in grey monochrome
Controlling the Secure Virtual Assist Display
Full Screen - Hides all of the Secure Virtual Assist toolbars and displays the customer’s desktop on the technician’s entire screen with the Secure Virtual Assist taskbar in the top left corner.

If the Secure Virtual Assist taskbar does not display, move your mouse to the top middle of the screen. Right-click on the taskbar and click Restore to exit full-screen mode.

Auto Scaling - Zooms the display to fill the entire Secure Virtual Assist window.
Zoom - Zooms the display to one of several presets or allows you enter a specific value.
True Size - Zooms to 100 percent.
* 
NOTE: A number of these options can be configured from the drop-down menus at the top of the Secure Virtual Assist application.
Request Full Control

Technicians can request full control of a customer’s desktop, allowing them to reboot the system, delete files, or over-write files on the customer’s computer without the customer being repeatedly prompted for permission. Select Request Full Control under the Commands menu to issue a request that appears on the customer’s desktop.

Using the Secure Virtual Assist File Transfer

The File Transfer window is used to transfer files to and from the customer’s computer. The file directory of the technician’s computer is shown on the left and the customer’s computer on the right.

The File Transfer window functions in much the same manner as Windows Explorer or an FTP program. Navigate the File Transfer window by double-clicking on folders and selecting files. The File Transfer window includes the following controls:

Desktop jumps to the desktop of the technician’s or customer’s computer.
Up navigates up one directory on either the technician’s or customer’s computer.
Download transfers the selected file or files from the technician’s computer to the customer’s computer.
Upload transfers the selected file or files from the customer’s computer to the technician’s computer.
Delete deletes the selected file or files.
* 
NOTE: When deleting or over-writing files, the customer is warned and must give the technician permission unless the technician has elected Request Full Control and the customer has confirmed.
New folder creates a new folder in the selected directory.
Rename renames the selected file or directory.

When a file is transferring, the transfer progress is displayed at the bottom of the File Transfer window. Click Exit to cancel a transfer in progress.

* 
NOTE: File Transfer supports the transfer of single or multiple files. It does not currently support the transfer of directories. To select multiple files, hold down Ctrl while clicking on the files.

Enabling a System for Secure Virtual Access

* 
NOTE: Secure Virtual Access is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

If Secure Virtual Access has been enabled on the Virtual Assist tab on the Portals > Portals page of the Secure Mobile Access management interface, users should see a link on the portal to set-up a system for Secure Virtual Access. To enable Secure Virtual Access within the Secure Mobile Access management interface, see Configuring Per-Portal Virtual Assist Settings.

To configure Secure Virtual Access on a system:
1
Log in to the portal through the system you wish to configure for Secure Virtual Access and click the Virtual Access link.

2
A file should download with parameters to install the VASAC.exe file that provides the needed client for Secure Virtual Access mode. Save and run the file.
* 
NOTE: Running the file directly from this dialog box might not work on some systems. Save the file to the system and then run the application.
3
Fill in the necessary information in the provided fields to configure the system in Secure Virtual Access mode and click OK.
Server: This should be the name or IP address of the appliance the technician normally accesses the Virtual Office from outside the management interface (Do not include “https://”).
Portal: The name of the portal the technician would normally log in to.
Computer Name: This is an identifier for the system to help differentiate between other systems that might be waiting for support in the queue.
Password: This is a password the technician must enter prior to accessing the system through the support queue.

4
After installation, the VASAC client should be left running in the desktop tray.

This system’s identifier name should now appear in the technician’s support queue displayed on the Secure Virtual Assist > Status page within the management interface. Upon double-clicking the system listing, the technician is prompted to provide the password established during system set-up to gain Secure Virtual Access to the system.

Ending Secure Virtual Access Mode

Disconnecting from a Secure Virtual Access session places the system back in the support queue for later access by the technician. From the personal system-side, the user/technician might uninstall or terminate the application from the tray option icons.

An administrator can forcibly remove a system from the queue. If this occurs, the Secure Virtual Access system should no longer attempt to connect to the support queue and should display an error message.

* 
NOTE: For tasks and information on using Secure Virtual Assist as an end-user, refer to the Secure Mobile Access User’s Guide.

Secure Virtual Meeting Overview

* 
NOTE: Secure Virtual Meeting is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

This section provides an introduction to the Secure Virtual Meeting feature. This section contains the following topics:

What is Secure Virtual Meeting?

* 
NOTE: Secure Virtual Meeting is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

Secure Virtual Meeting is a web-based management interface for the SMA 400, SRA 4600, and SMA 500v Virtual Appliance. Secure Virtual Meeting allows multiple users to view a desktop and interactively participate in a meeting from virtually anywhere with an Internet connection. Secure Virtual Meeting is similar to the one-to-one desktop sharing provided by Virtual Assist except multiple users can share a desktop.

Benefits of Secure Virtual Meeting

* 
NOTE: Secure Virtual Meeting is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

Secure Virtual Meeting provides the following benefits:

Secure connections - 256-bit AES SSL encryption of the data by the SMA/SRA appliance provides a secure environment for the data and assists in the effort to be compliant with regulations like Sarbanes-Oxley and HIPAA.
Time and cost savings - Secure Virtual Meeting eliminates the need to visit customer sites and reduces the average time-to-resolution of support calls.
Educational tool - Trainers and support staff can use Secure Virtual Meeting to remotely show customers how to use programs and tools.
Configurable environment with multiple functions - Meeting parameters can be configured for specific meetings, in addition to meeting configurations that apply to all virtual meetings.
Meeting functions - Meeting attendees can complete several functions, such as polling meeting attendees, text chatting, and switching who shares their desktop or controls the meeting.

User Roles

* 
NOTE: Secure Virtual Meeting is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

Secure Virtual Meeting has several user roles:

Coordinator (Owner of the meeting) - The Coordinator must be a Secure Mobile Access user on the appliance. The Coordinator schedules, sets up, and controls the meeting. In addition, the Coordinator has the sole power to promote a Participant to the Assistant.
Assistant (Coordinator-designated Assistant) - The Coordinator selects an Assistant from the list of available Participants and assigns the Assistant privileges. When the Coordinator exits the meeting, the Assistant automatically becomes the Coordinator. A meeting can have multiple Assistants, each with the same or a different set of privileges. An Assistant need not be a user of the SMA/SRA appliance. Possible Assistant privileges are:
Start/End Meeting
Set Host
Open Polling
Set/Unset View Only
Invite Participants
Kick out Participants
Reschedule Meeting
Host - The Host is a Participant who shares their desktop with all Participants in the meeting. When a meeting begins, the Host’s desktop is shown to all Participants. The Host can be changed by the Coordinator during the meeting by selecting any available Participant. If a Host is not explicitly set when the meeting starts, the Coordinator becomes the Host. Only one Participant is designated as the Host at any one time.

Only the Host can control the Host System, unless the Host grants permission when a Participant requests control. The Host can also give control to any Participant by selecting the Participant from the Meeting Members list. Only one Participant can control the Host System at any one time. When a Participant takes control of the Host System, he loses control as soon as the Host moves his mouse pointer on the screen. The meeting control permission state is visible to all Participants while in the lobby.

Participant (User with credentials to join the meeting) - A Participant must enter a meeting code before they can join a meeting. The code required to join the meeting is determined by the Coordinator prior to the meeting. After joining a meeting, the Participant can view the shared desktop and chat with another attendee privately or type a message in the Chat window that is visible to all attendees. A Participant becomes the Assistant if selected by the Coordinator or by an Assistant who has the required privilege.
View-only Participant (User with limited meeting capabilities) - The Coordinator can designate any Participant as a View-only Participant. A View-only Participant cannot be assigned any privileges nor become an Assistant or Host.

Roles are switched before or during a meeting. A Coordinator or Assistant with necessary privileges can change the roles of any Participant during the meeting. A Participant wishing to become the Host must request permission from the Coordinator.

How Does a Secure Virtual Meeting Work?

* 
NOTE: Secure Virtual Meeting is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

See the following sections:

Configuring Secure Virtual Meeting
* 
NOTE: Secure Virtual Meeting is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

Secure Virtual Meeting configuration and management tasks are done through the Secure Mobile Access web-based management interface and consist of the following:

Status
Settings
Log
Licensing

These tasks are explained in detail in Secure Virtual Meeting Overview and the Secure Virtual Meeting Feature Module.

Performing Coordinator Tasks
* 
NOTE: Secure Virtual Meeting is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

The Virtual Meeting Coordinator completes the following tasks:

 

Virtual Meeting Coordinator tasks 

Coordinator Tasks

Description

Logging In

Log in from a Virtual Meeting client using Secure Mobile Access credentials.

Setting Up a Meeting

Set up a meeting by scheduling a time and creating a meeting code that allows meeting members to join the meeting.

Performing Lobby Functions

Access various meeting functions in the lobby before or during a meeting. See Performing Lobby Functions.

Controlling Roles

Control what meeting members can do and appoint an Assistant to help facilitate the meeting.

Revising Meeting Settings

Set up a proxy or modify login profiles for meetings.

Logging Actions and Messages

Review a log of actions that occurred and view any warning or error message details that might require attention.

Using the Control Menu During a Meeting

Access functions available while a meeting is active. See Using the Control Menu during a Meeting.

Creating Email Invites

Invite meeting members through email before or during a meeting.

Polling

Create a poll for attendees to participate in.

Viewing Polling Feedback

View the feedback submitted for a poll.

Text Chatting

Chat with everyone or specific individuals in a meeting.

Performing Lobby Functions

The following functions can be completed from the lobby by clicking buttons:

Clicking Start Meeting starts the meeting. Only the Coordinator and Assistant can start a meeting.

Clicking Stop Meeting stops the meeting. Only the Coordinator and Assistant can end the meeting.

Clicking Polling opens the polling window where you can load, edit, and start a poll for Participants currently in the meeting. Only the Coordinator and Assistant can initiate polling.

Clicking Invite sends an email invitation to Participants. Only the Coordinator and Assistant can invite Participants.

Clicking Reschedule Meeting reschedules the meeting start and end times. Only the Coordinator and Assistant can reschedule a meeting.

Clicking Request Host informs the Host that you want to become the Host and share your desktop. Only Participants who are not currently the Host can request to become the Host.

Clicking Quit exits the meeting and return to the meeting selection window. Anyone in the meeting can quit the meeting.

Clicking Start Sharing shares the Host desktop with all Participants in the meeting. Sharing is only available during a meeting.

Clicking Stop Sharing stops sharing the Host System desktop. Only the Host can stop sharing and only while in the sharing state (after Start Sharing has been selected).

Clicking Request Control requests that the Host give you control of the keyboard and mouse. Only Participants who are not the Host can request control.

Using the Control Menu during a Meeting

The Control Menu is available at the top of a shared desktop when the Host shares the desktop during an active meeting.

Invite is available for the Coordinator or Assistants with invite permission. It opens the invite dialog if the lobby is not open.

Polling is available for the Coordinator or Assistants with polling permission. It opens the polling dialog.

Chat is available for all Participants, including View-only Participants. It opens a chat dialog if the lobby is not open.

Lobby is available for all meeting members, including View-only Participants. If the lobby is hidden during a meeting, it displays the lobby window when the Host is sharing the screen.

Options opens the Meeting Settings window and is available for all Participants.

Viewer is available for all Participants except the Host. It toggles the window between the Participant’s window and the Host’s desktop.

About opens the About dialog that identifies the Secure Virtual Meeting client and version. About is available for all meeting members, including View-only Participants.

Performing Participant Tasks
* 
NOTE: Secure Virtual Meeting is being deprecated. For legacy support, call SonicWall Customer Support for assistance.

Participants can be designated as View-only Participants or regular Participants. View-only Participants enter and exit meetings like other Participants, but cannot do most functions. However, they can be kicked out of meetings like other regular Participants. Regular Participants can also:

Respond to polls
Text chat
Request control of the Host keyboard and mouse
Request to become the Host and share the Participant’s desktop
Become the Assistant
Become a View-only Assistant

Web Application Firewall Overview

This section provides an introduction to the Web Application Firewall feature. This section contains the following topics:

What is Web Application Firewall?

Web Application Firewall is subscription-based software that runs on the SMA/SRA appliance and protects Web applications running on servers behind the appliance. Web Application Firewall also provides real-time protection for resources such as HTTP(S) bookmarks, Citrix bookmarks, offloaded Web applications, and the Secure Mobile Access management interface and user portal that run on the SMA/SRA appliance itself.

Web Application Firewall provides real-time protection against a whole suite of Web attacks such as Cross-site scripting, SQL Injection, OS Command Injection, and many more. The top ten vulnerabilities for Web applications are tracked by OWASP, an open source community that focuses its efforts on improving the security of Web applications. Secure Mobile Access Web Application Firewall protects against these top ten, defined as follows:

 

OWASP Top Ten Vulnerabilities 

Name

Description

A1 - Cross Site Scripting (XSS)

XSS flaws occur whenever an application takes user supplied data and sends it to a Web browser without first validating or encoding that content. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface Web sites, and possibly introduce worms.

A2 - Injection Flaws

Injection flaws, particularly SQL injection, are common in Web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data.

A3 - Malicious File Execution

Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.

A4 - Insecure Direct Object Reference

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

A5 - Cross Site Request Forgery (CSRF)

A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable Web application that then forces the victim's browser to do a hostile action to the benefit of the attacker. CSRF can be as powerful as the Web application that it attacks.

A6 - Information Leakage and Improper Error Handling

Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks.

A7 - Broken Authentication and Session Management

Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.

A8 - Insecure Cryptographic Storage

Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.

A9 - Insecure Communications

Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.

A10 - Failure to Restrict URL Access

Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and complete unauthorized operations by accessing those URLs directly.

Slowloris Protection

In addition to the top ten threats listed previously, Web Application Firewall protects against Slowloris HTTP Denial of Service attacks. This means that Web Application Firewall also protects all the backend Web servers against this attack. Many Web servers, including Apache, are vulnerable to Slowloris. Slowloris is especially effective against Web servers that use threaded processes and limit the amount of threading allowed.

Slowloris is a stealthy, slow-acting attack that sends partial HTTP requests at regular intervals to hold connections open to the Web server. It gradually ties up all the sockets, consuming sockets as they are freed up when other connections are closed. Slowloris can send different host headers, and can send GET, HEAD, and POST requests. The string of partial requests makes Slowloris comparable to a SYN flood, except that it uses HTTP rather than TCP. Only the targeted Web server is affected, while other services and ports on the same server are still available. When the attack is terminated, the Web server can return to normal within as little as 5 seconds, making Slowloris useful for causing a brief downtime or distraction while other attacks are initiated. After the attack stops or the session is closed, the Web server logs can show several hundred 400 errors.

For more information about how Web Application Firewall protects against the OWASP top ten and Slowloris types of attacks, see How Does Web Application Firewall Work?.

Offloaded Web Application Protection

Web Application Firewall can also protect an offloaded Web application that is a special purpose portal created to provide seamless access to a Web application running on a server behind the SMA/SRA appliance. The portal must be configured as a virtual host. It is possible to disable authentication and access policy enforcement for such an offloaded host. If authentication is enabled, a suitable domain needs to be associated with this portal and all SonicWall Inc. advanced authentication features such as One Time Password, Two-factor Authentication, and Single Sign-On apply to the offloaded host.

Application Profiling

Application Profiling (Phase 1) allows the administrator to generate custom rules in an automated manner based on a trusted set of inputs. This is a highly effective method of providing security to Web applications because it develops a profile of what inputs are acceptable by the application. Everything else is denied, providing positive security enforcement. This results in fewer false positives than generic signatures that adopt a negative security model. When the administrator places the device in learning mode in a staging environment, the SMA/SRA appliance learns valid inputs for each URL accessed by the trusted users. At any point during or after the learning process, the custom rules can be generated based on the “learned” profiles.

Rate Limiting for Custom Rules

You can track the rate at which a custom rule, or rule chain, is being matched. This is extremely useful to block dictionary attacks or brute force attacks. The action for the rule chain is triggered only if the rule chain is matched as many times as configured.

Cookie Tampering Protection

Cookie Tampering Protection is an important item in the Payment Card Industry Data Security Standard (PCI DSS) section 6.6 requirements and part of the Web Application Firewall evaluation criteria that offers strict security for cookies set by the backend Web servers. Various techniques such as encryption and message digest are used to prevent cookie tampering. See Configuring Cookie Tampering Protection Settings for additional information.

Credit Card and Social Security Number Protection

Credit Card/SSN protection is a Data Loss Prevention technique that ensures that sensitive information, such as credit card numbers and Social Security numbers are not leaked within Web pages. After such leakage is detected, the administrator can choose to mask these numbers partially or wholly, present a configurable error page, or simply log the event. See Configuring Information Disclosure Protection for additional information.

Web Site Cloaking

Web Site Cloaking prevents guessing the Web server implementation and exploiting its vulnerabilities. See Configuring Web Site Cloaking for additional information.

PDF Reporting for WAF Monitoring and PCI DSS 6.5 and 6.6 Compliance

PDF reporting is introduced for Web Application Firewall Monitoring and PCI DSS 6.5 and 6.6 Compliance. You can generate the reports on the Web Application Firewall > Status page. The time line for generating the data published in the reports is configurable on the Web Application Firewall > Monitoring page.

Benefits of Web Application Firewall

Web Application Firewall is secure and can be used in various areas, including financial services, healthcare, application service providers, and e-commerce. Secure Mobile Access uses SSL encryption to encrypt data between the Web Application Firewall and the client. Secure Mobile Access also satisfies OWASP cryptographic storage requirements by encrypting keys and passwords wherever necessary.

Companies using Web Application Firewall can reduce the development cost required to create secure applications and also cut out the huge turnaround time involved in deploying a newly found vulnerability fix in every Web application by signing up for Web Application Firewall signature updates.

Resources accessed over Application Offloaded portals and HTTP(S) bookmarks can be vulnerable because of a variety of reasons ranging from badly designed architecture to programming errors. Web Application Firewall provides an effective way to prevent a hacker from exploiting these vulnerabilities by providing real-time protection to Web applications deployed behind the SMA/SRA appliance.

Deploying Web Application Firewall at the SMA/SRA appliance lets network administrators use application offloading even when it exposes Web applications needing security to internal and remote users. Application offloading avoids URL rewriting that improves the proxy performance and functionality.

There are several benefits of integrating Web Application Firewall with SMA/SRA appliances. Firstly, identity-based policy controls are core to Web Application Firewall and this is easily achievable using Secure Mobile Access technology. Secondly, there are lower latencies because of the existing hardware-based SSL offloading. Most importantly, SMA/SRA appliances run Web applications and must be protected from such attacks.

As small businesses adopt hosted services to facilitate supplier collaboration, inventory management, online sales, and customer account management, they face the same strict compliance requirements as large enterprises. Web Application Firewall on an SMA/SRA appliance provides a convenient, cost-effective solution.

Web Application Firewall is easy to configure in the Secure Mobile Access management interface. The administrator can configure Web Application Firewall settings globally, by attack priority, and on a per-signature basis. After custom configuration settings or exclusions are in place, you can disable Web Application Firewall without losing the configuration, allowing you to complete maintenance or testing and then easily re-enable it.

How Does Web Application Firewall Work?

To use the Web Application Firewall feature, the administrator must first license the software or start a free trial. Web Application Firewall must then be enabled on the Web Application Firewall > Settings page of the Secure Mobile Access management interface. Web Application Firewall can be configured to log or block detected attacks arriving from the Internet.

The following sections describe how Web Application Firewall and SMA/SRA appliances prevent attacks such as Slowloris or those listed in the OWASP top ten, how Web Application Firewall protects against information disclosure, and how other features work:

How are Signatures Used to Prevent Attacks?

For Cross Site Scripting, Injection Flaws, Malicious File Execution, and Insecure Direct Object Reference vulnerabilities, the Web Application Firewall feature uses a black list of signatures that are known to make Web applications vulnerable. New updates to these signatures are periodically downloaded from a SonicWall Inc. signature database server, providing protection from recently introduced attacks.

How signatures are used to prevent attacks

When input arrives from the Internet, Web Application Firewall inspects HTTP/HTTPS request headers, cookies, POST data, query strings, response headers, and content. It compares the input to both a black list and a white list of signatures. If pattern matching succeeds for any signature, the event is logged and/or the input is blocked if so configured. If blocked, an error page is returned to the client and access to the resource is prevented. If blocked, an error page is returned to the client and access to the resource is prevented. The threat details are not exposed in the URL of the error page. If configured for detection only, the attack is logged but the client can still access the resource. If no signature is matched, the request is forwarded to the Web server for handling.

What happens when no signature is matched

The Web Application Firewall process is outlined in the following flowchart.

Web Application Firewall process

In the case of a blocked request, the following error page is returned to the client:

This page is customizable under Web Application Firewall > Settings in the Secure Mobile Access management interface. Some administrators might want to customize the HTML contents of this page. Others might not want to present a user friendly page for security reasons. Instead, they might prefer the option to present an HTTP error code such as 404 (Not found) or 403 (Access Denied).

How is Cross-Site Request Forgery Prevented?

CSRF attacks are not detected with signature matching. Using this vulnerability, a hacker disguised as the victim can gain unauthorized access to application even without stealing the session cookie of a user. While a victim user is authenticated to a Web site under attack, the user can unwittingly load a malicious Web page from a different site within the same browser process context, for instance, by launching it in a new tab part of the same browser window. If this malicious page makes a hidden request to the victim Web server, the session cookies in the browser memory are made part of this request making this an authenticated request. The Web server serves the requested Web page as it assumes that the request was a result of a user action on its site. To maximize the benefits, typically, hackers targets actionable requests, such as data updates to carry out this attack.

To prevent CSRF attacks, every HTTP request within a browser session needs to carry a token based on the user session. To ensure that every request carries this token, the Web Application Firewall feature rewrites all URLs contained in a Web page similarly to how they are rewritten by the Reverse Proxy for HTTP(S) Bookmarks feature. If CSRF protection is enabled, this is also done for Application Offloading.

If authentication is enforced for the portal, then the user is redirected to the login page for the portal.

How is Information Disclosure Prevented?

Web Application Firewall prevents Information Disclosure and Improper Error Handling by providing a way for the administrator to configure text containing confidential and sensitive information so that no Web site accessed through the Web Application Firewall reveals this text. These text strings are entered on the Web Application Firewall > Settings page.

Beside the ability to pattern match custom text, signatures pertaining to information disclosure are also used to prevent these types of attacks.

Web Application Firewall protects against inadvertent disclosure of credit card and Social Security numbers (SSN) in HTML Web pages.

* 
NOTE: Only text or HTML pages, and only the first 512K bytes are inspected for credit card or SSN disclosure.

Web Application Firewall can identify credit card and SSN numbers in various formats. For example, a SSN can be specified as XXX XX XXXX or XXX-XX-XXXX. Web Application Firewall attempts to eliminate false-positives by filtering out formats that do not conform to the credit card or SSN specification. For example, credit cards follow the Luhn’s algorithm to determine if an n-digit number could be a credit card number or not.

The administrator can set an appropriate action, such as detect (log), prevent, or just mask the digits that can reveal the user identity. Masking can be done fully or partially, and you can select any of the following characters for masking: #, *, -, x, X, ., !, $, and ?. The resulting masked number is similar to the appearance of credit card numbers printed on an invoice.

How are Broken Authentication Attacks Prevented?

The requirement for Broken Authentication and Session Management requires Web Application Firewall to support strong session management to enhance the authorization requirements for Web sites. Secure Mobile Access already has strong authentication capabilities with the ability to support One Time Password, Two-factor Authentication, Single Sign-On, and client certificate authentication.

For Session Management, Web Application Firewall pops up a session logout dialog box when the user portal is launched or when a user logs in to an application offloaded portal. This feature is enabled by default when Web Application Firewall is licensed and can be disabled from the Web Application Firewall > Settings page.

How are Insecure Storage and Communications Prevented?

Insecure Cryptographic Storage and Insecure Communications are prevented by encrypting keys and passwords wherever necessary, and by using SSL encryption to encrypt data between the Web Application Firewall and the client. Secure Mobile Access also supports HTTPS with the backend Web server.

How is Access to Restricted URLs Prevented?

Secure Mobile Access supports access policies based on host, subnet, protocol, URL path, and port to allow or deny access to Web sites. These policies can be configured globally or for users and groups.

How are Slowloris Attacks Prevented?

Slowloris attacks can be prevented if there is an upstream device, such as an SMA/SRA security appliance, that limits, buffers, or proxies HTTP requests. Web Application Firewall uses a rate-limiter to thwart Slowloris HTTP Denial of Service attacks.

What Type of PCI Compliance Reports Are Available?

Payment Card Industry Data Security Standard (PCI DSS) 6.5 (Version 2.0) and PCI DSS 6.6 (Version 1.2) are covered in PCI reporting. The administrator can configure Web Application Firewall to satisfy these PCI requirements.

You can generate and download the PCI report file on the Web Application Firewall > Status page.

* 
NOTE: This is not an official PCI Compliance report. It is for your self-assessment only.

In the report cover, the following information is displayed:

The model, serial number, and firmware version of the appliance
The user name of the person who downloaded the report, displayed as the author of the report
Time when the report was generated

The following is an example:

Two tables are dynamically generated in the PCI compliance report to display the status of each PCI requirement. The format of the table is shown in the example that follows:

The first column describes the PCI requirement.

The second column displays the status of the PCI requirement under current Web Application Firewall settings. There are four possible values for the status, distinguished by color.

Satisfied (Green)
Partially Satisfied (Orange)
Unsatisfied (Red)
Unable to determine (Black)

The third column provides comments and details explaining the status rating. If the status is Satisfied, no comments are provided.

How Does Cookie Tampering Protection Work?

SMA/SRA appliances protect important server-side cookies from tampering.

There are two kinds of cookies:

Server-Side Cookies – These cookies are generated by backend Web servers. They are important and have to be protected. They have optional attributes like Path, Domain, Secure, and HttpOnly.
Client-Side Cookies – These cookies are created by client side scripts in user browsers. They are not safe, and can be easily tampered with.

This feature is found on the Web Application Firewall > Settings page.

This page contains the following options:

Portals – A list of all application offloading portals. Each portal has its own settings. The item Global is the default setting for all portals.

Tamper Protection Mode – Three modes are available:

Prevent – Strip all the tampered cookies and log them.
Detect only – Log the tampered cookies only.
Inherit Global – Use the global setting for this portal.

Encrypt Server Cookies – Choose to encrypt name and value separately. This affects client-side script behavior because it makes cookie names or values unreadable. Only server-side cookies are encrypted by these options.

Cookie Attributes – The attributes HttpOnly and Secure are appended to server-side cookies if they are enabled.

The attribute HttpOnly prevents the client-side scripts from accessing the cookies that is important in mitigating attacks such as Cross Site Scripting and session hijacking. The attribute Secure ensures that the cookies are transported only in HTTPS connections. Both together add a strong layer of security for the server-side cookies.

* 
NOTE: By default, the attribute Secure is always appended to an HTTP connection even if Cookie Tampering Protection is disabled. This behavior is a configurable option, and can be turned off.

Allow Client Cookies – The Allow Client Cookies option is enabled by default. In Strict mode, the Allow Client Cookies option is disabled. When disabled, client-side cookies are not allowed to be sent to the backend systems. This option does not affect server-side cookies.

Exclusion List – If the Exclusion List is enabled and contains a cookie, the cookie is passed as usual and is not protected. You can exclude server-side cookies and client-side cookies.

Exclusion list items are case sensitive, and in the format ‘CookieName@CookiePath.’ Cookies with the same name and different paths are treated as different cookies. ‘CookiePath’ can be left empty to represent any path.

Import Global – Application Offloading portals can import the Global exclusion list.

How Does Application Profiling Work?

The administrator can configure application profiling on the Web Application Firewall > Rules page. Application profiling is completed independently for each portal and can profile multiple applications simultaneously.

After selecting the portal, you can select the type of application content that you want to profile. You can choose HTML/XML, JavaScript, CSS, or All that includes all content types such as images, HTML, and CSS. HTML/XML content is the most important from a security standpoint, because it typically covers the more sensitive Web transactions. This content type is selected by default.

Then the SMA/SRA appliance is placed in learning mode by clicking Begin Profiling (the button then changes to End Profiling). The profiling should be done while trusted users are using applications in an appropriate way. The Secure Mobile Access records inputs and stores them as URL profiles. The URL profiles are listed as a tree structure on the Web Application Firewall > Rules page in the Application Profiling section.

Only the URLs presented as hyperlinks are accessible URLs on the backend server. You can click on the hyperlink to edit the learned values for that URL if the values are not accurate. You can then generate rules to use the modified URL profile.

The SMA/SRA appliance learns the following HTTP Parameters:

Response Status Code
Post Data Length – The Post Data Length is estimated by learning the value in the Content-Length header. The maximum size is set to the power of two that is closest to and higher than this value. This accommodates the amount of memory that could have been allocated by the backend application. For example, for a Content Length of 65, the next power of two greater than 65 is 128. This is the limit configured in the URL profile. If the administrator determines that this is not accurate, the value can be modified appropriately.
Request Parameters – This is the list of parameters that a particular URL can accept.

When an adequate amount of input has been learned, you can click End Profiling and are ready to generate the rules from the learned input. You can set one of the following as a default action for the generated rule chains:

Disabled – The generated rules are disabled rather than active.
Detect Only – Content triggering the generated rule are detected and logged.
Prevent – Content triggering the generated rule are blocked and logged.

If a rule chain has already been generated from a URL profile in the past, then the rule chain are overwritten only when Overwrite existing Rule Chains for URL Profiles is selected. When you click Generate Rules, the rules are generated from the URL profiles. If a URL profile has been modified, those changes are incorporated.

How Does Rate Limiting for Custom Rules Work?

The administrator can configure rate limiting when adding or editing a rule chain from the Web Application Firewall > Rules page. When rate limiting is enabled for a rule chain, the action for the rule chain is triggered only when the number of matches within a configured time period is above the configured threshold.

This type of protection is useful in preventing Brute Force and Dictionary attacks. An example rule chain with a Rule Chain ID of 15002 is available in the Secure Mobile Access management interface for administrators to use as reference.

The associated fields are exposed when Enable Hit Counters is selected at the bottom of the New Rule Chain or Edit Rule Chain screen.

After a rule chain is matched, Web Application Firewall keeps an internal counter to track how many times the rule chain is matched. The Max Allowed Hits field contains the number of matches that must occur before the rule chain action is triggered. If the rule chain is not matched for the number of seconds configured in the Reset Hit Counter Period field, then the counter is reset to zero.

Rate limiting can be enforced per remote IP address or per user session or both. Track Per Remote Address enables rate limiting based on the attacker’s remote IP address.

Track Per Session enables rate limiting based on the attacker’s browser session. This method sets a cookie for each browser session. Tracking by user session is not as effective as tracking by remote IP if the attacker initiates a new user session for each attack.

The Track Per Remote Address option uses the remote address as seen by the SMA/SRA appliance. In the case where the attack uses multiple clients from behind a firewall that is configured with NAT, the different clients effectively send packets with the same source IP address and is counted together.

Navigating the Management Interface

The following sections describe how to navigate the Secure Mobile Access management interface:

Browser Requirements

The following sections describe the browser requirements for the Secure Mobile Access management interface.

Topics:

Browser Requirements for the Administrator

The following Web browsers and operating systems support the Secure Mobile Access web-based management interface and the user portal, Virtual Office.

Secure Mobile Access Administrator Browser Requirements 

Browser

Operating System

 

Internet Explorer 9

Windows 7

 

Internet Explorer 10

Windows 10

 

Internet Explorer 11

Windows 10

 

Mozilla Firefox
(latest version)

Windows Vista
Windows 10
Windows 7
Linux
MacOS X

Google Chrome

Windows Vista
Windows 10
Windows 7
Linux
MacOS X

To configure an SMA/SRA appliance using the Secure Mobile Access web-based management interface, an administrator must use a Web browser with Java, JavaScript, ActiveX, cookies, pop-ups, TLS 1.0, TLS 1.1, and TLS 1.2 enabled. Java is only required for various aspects of the Secure Mobile Access Virtual Office, not the Secure Mobile Access management interface.

Browser Requirements for the End User

The following is a list of Web browser and operating system support for various Secure Mobile Access protocols including NetExtender and various Application Proxy elements. Minimum browser version requirements are shown for Windows, Windows Vista, Windows 7, Linux, and MacOS.

The following table provides specific browser requirements for the Secure Mobile Access End User Interface:

Browser

Operating System

 

Internet Explorer 11

Windows 10

 

Mozilla Firefox
(latest version)

Windows Vista
Windows 10
Windows 7
Linux
MacOS X

Google Chrome
(latest version)

Windows Vista
Windows 10
Windows 7
Linux
MacOS X

Apple Safari
(latest version)

MacOS X

 

Management Interface Introduction

The following is an overview of basic setup tasks that connect you to the Secure Mobile Access web-based management interface of the SMA/SRA appliance. For more detailed information on establishing a management session and basic setup tasks, refer to the Getting Started Guide for your platform. To access the Secure Mobile Access web-based management interface of the SonicWall SMA/SRA appliance:

1
Connect one end of a CAT-6 cable into the X0 port of your SMA/SRA appliance. Connect the other end of the cable into the computer you are using to manage the SMA/SRA appliance.

2
Set the computer you use to manage your SMA/SRA appliance to have a static IP address in the 192.168.200.x/24 subnet, such as 192.168.200.20. For help with setting up a static IP address on your computer, refer to the Getting Started Guide for your model.
* 
NOTE: For configuring the SMA/SRA appliance using the Secure Mobile Access web-based management interface, a Web browser supporting Java and HTTP uploads, such as Internet Explorer 9 or higher, Firefox 16.0 or higher, or Chrome 22.0 or higher is recommended. Users need to use IE 9 or higher, supporting JavaScript, Java, cookies, SSL and ActiveX in order to take advantage of the full suite of Secure Mobile Access applications.
3
Open a Web browser and enter https://192.168.200.1 (the default LAN management IP address) in the Location or Address field.
4
A security warning can appear. Click Yes to continue.
5
The Secure Mobile Access management interface is displayed and prompts you to enter your user name and password. Enter admin in the User Name field, password in the Password field, select LocalDomain from the Domain drop-down list and click Login.
* 
NOTE: The number and duration of login attempts can be controlled by the use of the Secure Mobile Access auto-lockout feature. For information on configuring the auto-lockout feature, refer to Configuring Login Security.

When you have successfully logged in, you see the default page, System > Status.

* 
NOTE: If the default page after logging in is the Virtual Office user portal, you have selected a domain with user-only privileges. Administration can only be done from the LocalDomain authentication domain. If you wish to log in as an administrator, make sure you select LocalDomain from the Domain drop-down list in the Login screen.

The System, Network, Portals, NetExtender, Secure Virtual Assist, Web Application Firewall, Users and Log menu headings on the left side of the browser window configure administrative settings. When you click one of the headings, its submenu options are displayed below it. Click on submenu links to view the corresponding management pages.

The Virtual Office option in the navigation menu opens a separate browser window that displays the login page for the user portal, Virtual Office.

Help in the upper right corner of the management interface opens a separate browser window that displays Secure Mobile Access Help.

Logout in the upper right corner of the management interface terminates the management session and closes the browser window.

Navigating the Management Interface

The Secure Mobile Access web-based management interface allows the administrator to configure the SMA/SRA appliance. The Secure Mobile Access management interface contains top level, read-only windows and configuration windows:

Windows - Displays information in a read-only format.
Configuration windows - Enables administrator interaction to add and change values that characterize objects. For example, IP addresses, names, and authentication types.

The following figures show sample windows in the Secure Mobile Access web-based management interface. Note the various elements of a standard Secure Mobile Access interface window.

System > Status Page

The following is a sample configuration window:

For descriptions of the elements in the Secure Mobile Access management interface, see the following sections:

Status Bar

The Status bar at the bottom of the management interface window displays the status of actions executed in the Secure Mobile Access management interface.

Accepting Changes

Click Accept at the top right corner of the main window to save any configuration changes you made on the page.

If the settings are contained in a secondary window within the Secure Mobile Access management interface, Accept is still available at the top right corner of the window.

Navigating Tables

Navigating tables with large number of entries is simplified by navigation buttons located above the table. For example, the Log > View page contains an elaborate bank of navigation buttons:

Log > View

 

Navigation Buttons in the Log View Page 

Navigation Button

Description

Find

Allows the administrator to search for a log entry containing the content specified in the Search field. The search is applied to the element of the log entry specified by the selection in the drop-down list. The selections in the drop-down list correspond to the elements of a log entry as designated by the column headings of the Log > View table. You can search in the Time, Priority, Source, Destination, User, and Message elements of log entries.

Exclude

Allows the administrator to display log entries excluding the type specified in the drop-down list.

Reset

Resets the listing of log entries to their default sequence.

Export Log

Allows the administrator to export a log.

Clear Log

Allows the administrators clear the log entries.

Restarting

The System > Restart page provides a Restart button for restarting the SMA/SRA appliance.

* 
NOTE: Restarting takes approximately two minutes and causes all users to be disconnected.

Common Icons in the Management Interface

The following icons are used throughout the Secure Mobile Access management interface:

Clicking on the configure icon displays a window for editing the settings.
Clicking on the delete icon deletes a table entry.
Moving the pointer over the comment icon displays text from a Comment field entry.

Tooltips in the Management Interface

Many pages throughout the Secure Mobile Access management interface display popup tooltips with configuration information when the mouse cursor hovers over a check box, text field, or radio button. Some fields have a Help icon that provides a tooltip stating related requirements.

Getting Help

Help in the upper right corner of the Secure Mobile Access management interface opens a separate Web browser that displays the main Secure Mobile Access Help.

SMA/SRA appliances also include online context-sensitive Help, available from the management interface by clicking the question mark button on the top-right corner of most pages. Clicking on the question mark button opens a new browser window that displays management page or feature-specific Help.

* 
NOTE: Accessing the SMA/SRA appliance online Help requires an active Internet connection.

Logging Out

Logout in the upper right corner of the management interface terminates the management session.

When you click Logout, you are logged out of the Secure Mobile Access management interface and the Web browser is closed.

Navigation Bar

The Secure Mobile Access navigation bar is located on the left side of the Secure Mobile Access management interface and is comprised of a hierarchy of menu headings. Most menu headings expand to a submenu of related management functions, and the first submenu item page is automatically displayed. For example, when you click the System heading, the System > Status page is displayed. The navigation menu headings are: System, Network, Portals, Services, NetExtender, End Point Control, Secure Virtual Assist, Secure Virtual Meeting, Web Application Firewall, High Availability, Users, Log, and Virtual Office.

Deployment Guidelines

This sections provides information about deployment guidelines for the SMA/SRA appliance. This section contains the following subsections:

Support for Numbers of User Connections

The following table lists the maximum and recommended numbers of concurrent tunnels supported for each appliance.

 

Concurrent tunnels supported based on appliance 

Appliance Model

Maximum Concurrent Tunnels Supported

Recommended Number of Concurrent Tunnels

SMA 400

250

125

SMA 200

50

50

SRA 4600

500

100

SRA 1600

50

25

SMA 500v Virtual Appliance

50

50

Factors such as the complexity of applications in use and the sharing of large files can impact performance.

Resource Type Support

The following table describes the types of applications or resources you can access for each method of connecting to the SMA/SRA appliance.

 

Supported application and resource types 

Access Mechanism

Access Types

Standard Web browser

Files and file systems, including support for FTP and Windows Network File Sharing
Web-based applications
Microsoft Outlook Web Access and other Web-enabled applications
HTTP and HTTPS intranets

NetExtender

Any TCP/IP based application including:
Email access through native clients residing on the user’s laptop (Microsoft Outlook, Lotus Notes, and so on.)
Commercial and home-grown applications
Flexible network access as granted by the network administrator

Downloadable ActiveX or Java Client

An application installed on desktop machines or hosted on an application server, remote control of remote desktop or server platforms
Terminal services, RDP, VNC, Telnet, SSH, and Citrix

Integration with other SonicWall Inc. Products

The SMA/SRA appliance integrates with other SonicWall Inc. products, complementing the SonicWall Inc. NSA, SuperMassive (9000 Series) and TZ Series product lines. Incoming HTTPS traffic is redirected by a SonicWall Inc. firewall appliance to the SMA/SRA appliance. The SMA/SRA appliance then decrypts and passes the traffic back to the firewall where it can be inspected on its way to internal network resources.

Typical Deployment

The SMA/SRA appliance is commonly deployed in tandem in one-armed mode over the DMZ or Opt interface on an accompanying gateway appliance, for example, a SonicWall Inc. network security appliance, such as a NSA 4600.

This method of deployment offers additional layers of security control plus the ability to use SonicWall Inc.’s Unified Threat Management (UTM) services, including Gateway Anti-Virus, Anti-Spyware, Content Filtering and Intrusion Prevention, to scan all incoming and outgoing NetExtender traffic. SonicWall Inc. recommends one-armed mode deployments over two-armed for the ease-of-deployment and for use in conjunction with UTM GAV/IPS for clean VPN.

As shown in the following figure, in one-armed mode the primary interface (X0) on the SMA/SRA appliance connects to an available segment on the gateway device. The encrypted user session is passed through the gateway to the SMA/SRA appliance (step 1). The SMA/SRA appliance decrypts the session and determines the requested resource. The Secure Mobile Access session traffic then traverses the gateway appliance (step 2) to reach the internal network resources. While traversing the gateway, security services, such as Intrusion Prevention, Gateway Anti-Virus and Anti-Spyware inspection can be applied by appropriately equipped gateway appliances. The internal network resource then returns the requested content to the SMA/SRA appliance through the gateway (step 3) where it is encrypted and returned to the client.

Sequence of Events in Initial Connection

For information about configuring the SMA/SRA appliance to work with third-party gateways, refer to Configuring the SMA/SRA Appliance with a Third-Party Gateway.

Two-armed Deployment

The SMA/SRA appliances also support two-armed deployment scenarios, using one external (DMZ or WAN side) interface and one internal (LAN) interface. However, two-armed mode introduces routing issues that need to be considered before deployment. The SMA/SRA appliance does not route packets across interfaces, as there are IP tables rules preventing that, and therefore cannot be used as a router or default gateway. Any other machines connected to an internal interface of the SMA/SRA appliance in two-armed mode would need to access the Internet or other network resources (DNS, NTP) through a different gateway.

If you have an internal router as well as an Internet router, you can use a two-armed deployment to leverage your internal router to access your internal resources.

Sample Scenario: Company A has resources and a number of subnets on their internal network, and they already have a robust routing system in place. With two-armed deployment of the SMA/SRA appliance, client requests destined for internal resources on the corporate network can be delivered to an internal router.