FirePass Controller Administrator Guide, Version 7.0.0

FirePass® Controller Administrator Guide
version 7.0
MAN-0211-03
Product Version
This manual applies to product version 7.0 of the FirePass® product.
Publication Date
This manual was published on May 26, 2010.
Legal Notices
Copyright
Copyright 1999-2010, F5 Networks, Inc. All rights reserved.
F5 Networks, Inc. (F5) believes the information it furnishes to be accurate and reliable. However, F5
assumes no responsibility for the use of this information, nor any infringement of patents or other rights of
third parties which may result from its use. No license is granted by implication or otherwise under any
patent, copyright, or other intellectual property right of F5 except as specifically described by applicable
user licenses. F5 reserves the right to change specifications at any time without notice.
Trademarks
F5, F5 Networks, the F5 logo, BIG-IP, 3-DNS, Acopia, Acopia Networks, Application Accelerator, Ask
F5, Application Security Manager, ASM, ARX, Data Guard, Enterprise Manager, EM, FirePass,
FreedomFabric, Global Traffic Manager, GTM, iControl, Intelligent Browser Referencing, Internet
Control Architecture, IP Application Switch, iRules, Link Controller, LC, Local Traffic Manager, LTM,
Message Security Module, MSM, NetCelera, OneConnect, Packet Velocity, SSL Accelerator, SYN Check,
Traffic Management Operating System, TMOS, TrafficShield, Transparent Data Reduction, uRoam,
VIPRION, WANJet, WebAccelerator, and ZoneRunner are trademarks or service marks of F5 Networks,
Inc., in the U.S. and other countries, and may not be used without F5's express written consent.
Export Regulation Notice

This product may include cryptographic software. Under the Export Administration Act, the United States
government may consider it a criminal offense to export this product from the United States.
RF Interference Warning
This is a Class A product. In a domestic environment this product may cause radio interference, in which
case the user may be required to take adequate measures.
FCC Compliance
This equipment has been tested and found to comply with the limits for a Class A digital device pursuant
to Part 15 of FCC rules. These limits are designed to provide reasonable protection against harmful
interference when the equipment is operated in a commercial environment. This unit generates, uses, and
can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual,
may cause harmful interference to radio communications. Operation of this equipment in a residential area
is likely to cause harmful interference, in which case the user, at his own expense, will be required to take
whatever measures may be required to correct the interference.
Any modifications to this device, unless expressly approved by the manufacturer, can void the user's
authority to operate this equipment under part 15 of the FCC rules.
Canadian Regulatory Compliance

This Class A digital apparatus complies with Canadian ICES-003.
Standards Compliance
This product conforms to the IEC, European Union, ANSI/UL and Canadian CSA standards applicable to
Information Technology products at the time of manufacture.
FirePass® Controller Administrator Guide i

Acknowledgments
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit.
(http://www.openssl.org/).
This product includes cryptographic software written by Eric Young (eay@cryptsoft.com)
This product contains software licensed and copyrighted by OPSWAT, Inc. For more information see
OPSWAT on the World Wide Web (http://www.opswat.com).
This product contains software developed by Daniel Kouril <kouril@users.sourceforge.net>. Source and
Documentation can be found at: http://modauthkerb.sourceforge.net/. It is based on work by James E.
Robinson, III <james@ncstate.net>, Daniel Henninger <daniel@ncsu.edu>, and Ludek Sulak
<xsulak@fi.muni.cz>. Copyright (c) 2004-2006 Masarykova universita (Masaryk University, Brno, Czech
Republic) All rights reserved.
ii
Table of Contents
Table of Contents
1
Introducing the FirePass Controller
Introducing the FirePass controller ............................................................................................1-1
Introducing FirePass controller features ..........................................................................1-1
Reviewing the FirePass controller models .......................................................................1-3
Finding the FirePass controller software version number ...........................................1-4
Understanding the FirePass controller .............................................................................1-5
Getting started with the FirePass controller ............................................................................1-9
The recommended path .......................................................................................................1-9
Possible configuration scenarios ...................................................................................... 1-10
Using this guide ............................................................................................................................. 1-12
Audience ............................................................................................................................... 1-12
Stylistic conventions in this document ........................................................................... 1-12
Finding help and technical support resources ....................................................................... 1-15
2
Managing Users and Configuring Groups
Introducing master groups and resource groups ....................................................................2-1
Understanding master groups .............................................................................................2-1
Understanding resource groups .........................................................................................2-1
Understanding how master groups and resource groups work together ...............2-2
Understanding user account management options ........................................................2-3
Configuring authentication for users .................................................................................2-4
Creating internal users on the FirePass controller ........................................................2-4
Managing user information in an external data store .............................................................2-6
Managing users in the FirePass controller data store .............................................................2-8
Setting up master groups and users ...........................................................................................2-9
Configuring a master group .............................................................................................. 2-11
Populating master groups with users ............................................................................. 2-13
Understanding entries in the User Management list .................................................. 2-15
Setting up dynamic group mapping .......................................................................................... 2-16
Finding procedures for dynamic group mapping ......................................................... 2-16
Understanding dynamic master group mapping ........................................................... 2-17
Understanding how a user is authenticated ................................................................. 2-17
Understanding dynamic resource group mapping ....................................................... 2-18
Understanding how resource groups are assigned ..................................................... 2-19
Using dynamic group mapping ......................................................................................... 2-22
Using enhanced session variables created from RADIUS attributes ...................... 2-48
Customizing landing URI or virtual host logon ............................................................ 2-48
Customizing domain and password order .................................................................... 2-51
Setting and changing mapping priority ........................................................................... 2-52
Customizing virtual host and URI ................................................................................... 2-52
Using WebDAV for advanced customization .............................................................. 2-53
Using dynamic resource group mapping in master groups ....................................... 2-64
Setting up authentication ............................................................................................................ 2-67
Choosing an authentication method .............................................................................. 2-67
Setting up internal authentication ................................................................................... 2-72
Setting up RADIUS server authentication ..................................................................... 2-72
Setting up LDAP server authentication ........................................................................ 2-74
Setting up two-factor authentication with a Client Certificate and LDAP ........... 2-76
Setting up HTTP basic authentication to external server ......................................... 2-81
Setting up initial signup on LDAP with subsequent strong internal password ..... 2-81
Setting up Windows domain server authentication ................................................... 2-82
Setting up Active Directory authentication (Kerberos authentication) ................. 2-82
FirePass® Controller Administrator Guide v

Table of Contents
Configuring a flexible query for a client certificate with Active Directory ........... 2-83
Setting up HTTP form-based authentication ................................................................ 2-85
Setting up client-certificate-based authentication ....................................................... 2-85
Understanding VHOST client certificate request ....................................................... 2-91
Setting up RSA SecurID authentication ......................................................................... 2-92
Working with resource groups ................................................................................................ 2-94
Creating favorites in resource groups ........................................................................... 2-94
Associating resource groups with users ........................................................................ 2-96
Configuring resource group favorites ............................................................................ 2-97
Impersonating a user .......................................................................................................... 2-98
3
Configuring Endpoint Security
Understanding endpoint security ................................................................................................3-1
Collecting information ..........................................................................................................3-1
Using the inspectors ..............................................................................................................3-2
Using session variables ..........................................................................................................3-5
Performing remediation .......................................................................................................3-6
Protecting resources .............................................................................................................3-7
Understanding protection options .....................................................................................3-8
Understanding protection limitations ...............................................................................3-9
Using pre-logon sequences ........................................................................................................ 3-10
Understanding pre-logon sequence flow ................................................................................ 3-11
Understanding the visual policy editor .......................................................................... 3-11
Understanding pre-logon sequence elements .............................................................. 3-12
Implementing client system checking ...................................................................................... 3-14
Creating pre-logon sequences to protect resources .......................................................... 3-15
Understanding protected workspace ............................................................................. 3-15
Creating a pre-logon sequence ........................................................................................ 3-15
Using data gathered by pre-logon sequences ............................................................... 3-17
Assigning a protected configuration ............................................................................... 3-18
Using actions in pre-logon sequences ............................................................................ 3-19
Defining rules for actions in pre-logon sequences ...................................................... 3-23
Browser requirements for endpoint security .............................................................. 3-25
User rights requirements for protected workspace and pre-logon inspectors ... 3-26
Creating protected configurations ........................................................................................... 3-27
Protecting resources ................................................................................................................... 3-31
Configuring endpoint protection for a resource group ............................................. 3-32
Understanding protection assignment ........................................................................... 3-32
Configuring post-logon protection .......................................................................................... 3-33
Using other kinds of protection ............................................................................................... 3-34
4
Using Server Certificates
Understanding SSL server certificates ........................................................................................4-1
Using server certificates on the FirePass controller ....................................................4-1
Using Certificate Authority-signed SSL server certificates ..........................................4-2
Using self-signed SSL server certificates ...........................................................................4-2
Understanding reverse proxy backend server certificate verification ......................4-2
Managing certificates on the FirePass controller .....................................................................4-5
Displaying information on installed certificates ..............................................................4-5
Generating a Certificate Signing Request or self-signed certificate ....................................4-6
Submitting the CSR ...............................................................................................................4-7
Understanding the files generated for the self-signed certificate ...............................4-8
vi
Table of Contents
Installing a server certificate ................................................................................................4-8

Associating an SSL server certificate with a web service .......................................... 4-10
Installing a self-signed certificate on client computers ............................................... 4-10
Updating installed server certificates ............................................................................. 4-11
Deleting installed certificates ........................................................................................... 4-12
Installing and configuring client root certificates .................................................................. 4-13
Using CRLs and OSCP ...................................................................................................... 4-13
Using OCSP to validate client certificates .............................................................................. 4-15
5
Configuring Network Access
Introducing Network Access .......................................................................................................5-1
Understanding Network Access features ........................................................................5-1
Understanding FirePass controller Network Access ....................................................5-3
Using client applications with Network Access .............................................................5-4
Configuring global Network Access settings ............................................................................5-6
Using NAPT or a virtual subnet .........................................................................................5-6
Understanding routing ..........................................................................................................5-9
Keeping connections open when the webtop is closed ............................................ 5-10
Configuring global packet filter rules ............................................................................. 5-10
Using overlapping IP address pools ................................................................................ 5-12
Configuring bitrate evaluator parameters ..................................................................... 5-18
Configuring Network Access resource group settings ....................................................... 5-19
Understanding Client Settings options .......................................................................... 5-19
Understanding DNS options ............................................................................................ 5-23
Understanding Hosts options .......................................................................................... 5-24
Understanding Drive Mappings options ........................................................................ 5-24
Understanding Launch Application options .................................................................. 5-25
Understanding IP Group Filters options ....................................................................... 5-26
Understanding Policy Checks options ........................................................................... 5-28
Understanding Customization options .......................................................................... 5-31
Configuring Network Access master group settings .......................................................... 5-39
Customizing the user experience for Network Access connections ..................... 5-39
Auto-launching web applications ..................................................................................... 5-40
6
Configuring Application Access
Introducing Application Access ...................................................................................................6-1
Understanding App Tunnels .........................................................................................................6-2
Choosing a static or dynamic App Tunnel .......................................................................6-3
Defining a web application tunnel ......................................................................................6-5
Understanding access restrictions for App Tunnels ......................................................6-6
Defining App Tunnel favorites .....................................................................................................6-7
Creating web application App Tunnel favorites .......................................................... 6-12
Configuring remote host and local host settings: important considerations ........ 6-15
Creating custom App Tunnels ......................................................................................... 6-16
Configuring App Tunnels that open automatically ...................................................... 6-17
Creating static App Tunnels to network file shares ................................................... 6-18
Restricting access to App Tunnels .................................................................................. 6-19
Configuring master group settings for App Tunnels ........................................................... 6-23
Understanding common master group settings for all App Tunnels ...................... 6-23
Understanding master group settings for dynamic and web application tunnels . 6-24
Understanding Legacy Host connections ............................................................................... 6-26
Defining legacy host favorites .......................................................................................... 6-27
FirePass® Controller Administrator Guide vii

Table of Contents
Starting preconfigured legacy host favorites from a Web application page or webtop
6-29
Configuring legacy hosts keyboard mapping ................................................................ 6-30
Configuring master group settings for legacy hosts connections ............................ 6-31
Configuring terminal server favorites ..................................................................................... 6-33
Configuring master group settings for terminal server connections ...................... 6-36
Using Citrix session reliability .......................................................................................... 6-39
Using terminal servers screen resolution ..................................................................... 6-40
Configuring global settings for Application Access .............................................................. 6-43
Handling Windows power-management events .......................................................... 6-43
Configuring client messages for Windows loopback ................................................. 6-43
7
Configuring Portal Access
Introducing Portal Access .............................................................................................................7-1
Introducing Portal Access features and operation .........................................................7-1
Introducing Portal Access application support ...............................................................7-2
Configuring web applications on the FirePass controller ......................................................7-4
Understanding proxy and cache functionality .................................................................7-4
Defining favorites for Portal Access Web Applications access ...................................7-6
Configuring web applications for minimal rewriting ................................................... 7-10
Configuring NTLM and basic authentication proxy .................................................... 7-14
Using NTLM version 2 ...................................................................................................... 7-15
Configuring split tunneling for Portal Access ............................................................... 7-15
Understanding access control lists for Portal Access ................................................ 7-16
Understanding Java sockets support .............................................................................. 7-18
Preserving host names ....................................................................................................... 7-18
Configuring content processing for web applications ................................................ 7-19
Configuring caching and compression ............................................................................ 7-31
Configuring intranet webtop options ............................................................................. 7-33
Preserving page content .................................................................................................... 7-34
Configuring proxy options ................................................................................................ 7-34
Configuring Windows files ......................................................................................................... 7-36
Configuring Windows Files favorites ............................................................................. 7-36
Configuring Windows Files master group settings ..................................................... 7-37
Configuring Mobile E-Mail .......................................................................................................... 7-39
Configuring the LDAP query ............................................................................................ 7-40
Configuring LDAP as the email address source .......................................................... 7-41
Disabling email attachments ............................................................................................. 7-42
Changing where Mobile E-Mail links appear on the webtop .................................... 7-42
Configuring content inspection ................................................................................................ 7-43
Configuring cross site scripting security ....................................................................... 7-43
Configuring SQL injection scanning ................................................................................ 7-45
Configuring buffer overflow protection ........................................................................ 7-47
Configuring anti-virus scanning of uploaded files ........................................................ 7-48
Using the FirePass controller reverse proxy ......................................................................... 7-51
Understanding client-server implementations ............................................................. 7-51
Understanding the reverse proxy ................................................................................... 7-52
Understanding the reverse proxy and Flash ................................................................. 7-53
Configuring the reverse proxy dynamic cache ............................................................ 7-53
Troubleshooting reverse proxy issues .......................................................................... 7-54
Using the reverse proxy and SED script support ....................................................... 7-59
viii
Table of Contents
8
Managing and Monitoring the FirePass Controller
Maintaining the FirePass Controller ...........................................................................................8-1
Configuring global FirePass controller settings ........................................................................8-2
Maintaining the network configuration settings .....................................................................8-3
Understanding the finalization process .............................................................................8-4
Understanding the Interfaces tab settings ........................................................................8-6
Configuring VLAN settings ..................................................................................................8-9
Configuring IP addresses and subnets ...............................................................................8-9
Configuring routing tables and rules .............................................................................. 8-11
Configuring DNS ................................................................................................................. 8-18
Configuring host names ..................................................................................................... 8-19
Configuring web services .................................................................................................. 8-20
Configuring other network settings ............................................................................... 8-25
Configuring access scope .................................................................................................. 8-26
Using realms .................................................................................................................................. 8-29
Configuring the Full Access realm .................................................................................. 8-29
Configuring the FirePass controller for realms ........................................................... 8-30
Assigning administrative privileges to a user account ................................................ 8-32
Upgrading with administrators configured in versions previous to FirePass software
version 5.4 ............................................................................................................................ 8-33
Using reports inside realms .............................................................................................. 8-33
Completing other configuration activities .............................................................................. 8-34
Configuring Admin E-mail ................................................................................................. 8-34
Adding definitions for other types of browsers .......................................................... 8-35
Configuring a new RSA SecurID authentication server (for native RSA authentication)
8-36
Specifying the SMTP email server ................................................................................... 8-40
Configuring an SNMP agent .............................................................................................. 8-41
Specifying HTTP and SSL proxies ................................................................................... 8-42
Specifying the time, time zone, and NTP server ........................................................ 8-43
Performing maintenance ............................................................................................................. 8-45
Managing FirePass controller licenses ............................................................................ 8-45
Backing up and restoring the FirePass controller ....................................................... 8-47
Cavium RoHS FIPS card support .................................................................................... 8-48
Upgrading controller software ........................................................................................ 8-48
Managing log files ................................................................................................................ 8-51
Configuring for RADIUS accounting .............................................................................. 8-58
Shutting down and restarting the FirePass controller ................................................ 8-59
Using the troubleshooting tools ...................................................................................... 8-61
Monitoring the FirePass controller ......................................................................................... 8-66
Displaying FirePass controller statistics ......................................................................... 8-66
Displaying FirePass controller system health ............................................................... 8-67
Monitoring the load on a FirePass controller .............................................................. 8-67
Using load statistics ............................................................................................................ 8-69
Customizing the user’s webtop ................................................................................................ 8-70
Configuring for multiple languages ........................................................................................... 8-71
9
Using FirePass Controller Client Components
Downloading client components .................................................................................................9-1
Using Windows clients with the FirePass controller .............................................................9-2
Installing client components on Windows systems .......................................................9-2
Using MSI to preinstall client components ......................................................................9-4
FirePass® Controller Administrator Guide ix

Table of Contents
Using the Component Installer ..........................................................................................9-4

Installing Component Installer Service ..............................................................................9-5
Installing Windows CE (Pocket PC) ..................................................................................9-6
Introducing BIG-IP Edge Client features ..........................................................................9-7
Installing the BIG-IP Edge Client for Windows ...............................................................9-7
Connecting with the BIG-IP Edge Client ..........................................................................9-7
Viewing standalone client traffic and statistics ................................................................9-8
Installing the FirePass legacy client for Windows ........................................................ 9-11
Understanding Windows XP and Vista 64-Bit VPN driver support ....................... 9-12
Installing the F5 Networks Client API ........................................................................... 9-12
Using standalone client web logon ................................................................................. 9-13
Using proxy settings ........................................................................................................... 9-13
Understanding the ICAP client ........................................................................................ 9-15
Using Macintosh and Linux clients with the FirePass controller ...................................... 9-16
Introducing supported Network Access features ....................................................... 9-16
Configuring the starting of applications on Macintosh or Linux clients ................. 9-17
Installing the client on Macintosh and Linux systems ................................................. 9-18
Establishing client connections .................................................................................................. 9-19
Understanding Network Access error messages on Macintosh or Linux clients ........ 9-20
Controlling the client using the command line interface .................................................... 9-22
Using the -start command ................................................................................................ 9-22
Using the -stop command ................................................................................................. 9-25
Using the -info command .................................................................................................. 9-27
Using the -profile command ............................................................................................. 9-31
Using the -help command ................................................................................................. 9-32
Using the command line interface on the client ................................................................... 9-34
Troubleshooting client components .............................................................................. 9-36
10
Using FirePass Controller Reports
Overview of FirePass controller reports ............................................................................... 10-1
Using the App Logs report ........................................................................................................ 10-2
Working with the App Logs report ............................................................................... 10-2
Understanding entries in the App Logs report ............................................................ 10-2
Using the Group report ............................................................................................................. 10-4
Working with the Group report .................................................................................... 10-4
Understanding entries in the Group report ................................................................. 10-4
Using HTTP Logs reports .......................................................................................................... 10-6
Working with the HTTP Logs report ............................................................................ 10-6
Understanding entries in the HTTP Logs report ........................................................ 10-7
Using the Logons report .......................................................................................................... 10-10
Working with the Logons report ................................................................................. 10-10
Understanding entries in the Logons report .............................................................. 10-10
Using the Sessions report ........................................................................................................ 10-12
Working with the Sessions report ............................................................................... 10-12
Understanding entries in the Sessions report ............................................................ 10-13
Using the Summary report ...................................................................................................... 10-16
Working with the Summary report .............................................................................. 10-16
Understanding entries in the Summary report .......................................................... 10-16
Using the System Logs report ................................................................................................. 10-18
Working with the System Logs report ........................................................................ 10-18
Understanding entries in the System Logs report .................................................... 10-18
Understanding logging options ................................................................................................ 10-20
x
Table of Contents
11
Using FirePass Controllers for Failover
Understanding FirePass controller high availability .............................................................. 11-1
Introducing failover configuration ................................................................................... 11-1
Reviewing the configuration process ............................................................................. 11-2
Introducing a failover member into a production environment .............................. 11-5
Configuring the active FirePass controller ............................................................................. 11-7
Enabling failover on the active controller ..................................................................... 11-7
Configuring the active controller with a self IP address ............................................ 11-9
Configuring the active controller with a shared IP address .................................... 11-10
Configuring web services for the IP addresses of the active controller .............. 11-10
Configuring the active controller’s heartbeat, synchronization, and miscellaneous
settings ................................................................................................................................. 11-13
Configuring the standby FirePass controller ....................................................................... 11-15
Synchronizing re-signed client components between cluster/failover nodes ..... 11-16
Enabling failover on the standby controller ................................................................ 11-16
Configuring the standby controller with a self IP address ...................................... 11-17
Configuring a shared IP address .................................................................................... 11-17
Checking the FQDN ........................................................................................................ 11-17
Configuring DNS server entries .................................................................................... 11-17
Adding and configuring web services, and specify a synchronization service ..... 11-18
Configuring the heartbeat ............................................................................................... 11-18
Finalizing and restarting the active controller ............................................................ 11-18
Accessing a standby controller ...................................................................................... 11-18
Configuring multiple external addresses for availability testing ............................. 11-19
Post-configuration tasks ........................................................................................................... 11-20
Starting failover controllers ............................................................................................ 11-20
Verifying the failover configuration ............................................................................... 11-20
Verifying controller identity ........................................................................................... 11-21
Triggering manual failover ............................................................................................... 11-21
12
Using FirePass Controllers in Clusters
Understanding FirePass controller clusters ........................................................................... 12-1
Understanding synchronization in clusters ................................................................... 12-1
Installing FirePass controllers as a cluster ..................................................................... 12-2
Configuring FirePass controller clusters ................................................................................ 12-3
Making configuration changes in clusters ...................................................................... 12-3
Understanding the configuration process ..................................................................... 12-4
Consolidating logs ............................................................................................................... 12-5
Enabling clustering ........................................................................................................................ 12-6
Configuring the primary node .......................................................................................... 12-6
Configuring the secondary nodes ................................................................................... 12-7
Configuring clustering synchronization ................................................................................... 12-8
Configuring a synchronization service ........................................................................... 12-8
Configuring load balancing ....................................................................................................... 12-12
Configuring load balancing on the primary node ...................................................... 12-12
Configuring load balancing on the secondary node .................................................. 12-13
Activating load balancing ................................................................................................. 12-13
Verifying the cluster configuration ................................................................................ 12-14
Verifying the load balancing configuration ............................................................................ 12-15
Managing a cluster configuration ............................................................................................ 12-16
Accessing a secondary controller’s configuration ..................................................... 12-16
Displaying statistics for a FirePass controller cluster ............................................... 12-16
FirePass® Controller Administrator Guide xi

Table of Contents
13
Using Web Applications Engine Trace
Understanding Web Applications engine trace .................................................................... 13-1
Using the Web Applications engine trace feature ............................................................... 13-2
Understanding trace files .................................................................................................. 13-3
Analyzing Web Applications engine traces ............................................................................ 13-5
Fixing common problems .................................................................................................. 13-6
A
How-To Examples
Introducing how-to scenarios .....................................................................................................A-1
Denying access to users running Google Desktop Search ..................................................A-2
Creating the Google Desktop Check pre-logon sequence ........................................A-2
Adding the Google Desktop Check action to the pre-logon sequence ..................A-5
Customizing the Google Desktop Check logon-denied message .............................A-8
Denying and allowing logons from specific operating systems and requiring certificates ....
A-11
Rule 1: Deny Windows 95, Windows 98, and Windows Me connections ...........A-11
Rule 2: Require Windows NT and Windows 2000 clients to log on using the virtual
keyboard ...............................................................................................................................A-15
Rule 3: Allow logons only from Windows XP, Linux, Pocket PC, and Macintosh
computers that have a valid certificate ..........................................................................A-17
Glossary
Index
xii
1
• Introducing the FirePass controller
• Getting started with the FirePass controller
• Using this guide
• Finding help and technical support resources

Introducing the FirePass controller

The F5 Networks FirePass® controller is a network appliance that provides
remote users with secure access to corporate networks, using most standard
Web browsers. The FirePass controller is easy to set up with proper
planning, and installation requires no modification to existing corporate
applications. No configuration or set up is required at the user’s remote
location. If the user’s Web browser can connect to Web sites on the Internet,
then that browser can connect to the FirePass controller.
The FirePass controller provides a web-based alternative to traditional
remote-access technologies such as modem pools, RAS servers, and
IPsec-layer Virtual Private Networks (VPNs). By leveraging the browser as
a standard thin client, the FirePass controller enables your corporation or
organization to extend secure remote access easily and cost-effectively to
anyone connected to the Internet with no special software or configuration
on the remote device. You do not need to make any additions or changes to
the back-end resources being accessed. This approach eliminates the IPsec
VPN support burden, and adds application functionality well beyond mere
connectivity.
The FirePass controller enables full access to network resources, and
provides broad application support, including:
• File servers
• Email
• Intranet and Web applications
• Terminal servers
• Legacy mainframe, AS/400, and Telnet applications
• Proprietary corporate applications
• Client/server applications
Introducing FirePass controller features

All FirePass controller models include the following features:
◆ Standard Web browser support
FirePass controllers can be used with most standard browsers supporting
secure HTTP (also known as HTTPS). These include Internet Explorer®,
Netscape Navigator®, Mozilla®, Safari™, and Firefox®.
◆ WAN security
The FirePass controller supports common encryption technologies,
including RC4, Triple DES, and AES. It uses standard SSL encryption
from the client browser to the FirePass controller.
◆ Authentication
The FirePass controller can perform authentication using your own
authentication method, including LDAP directories, Active Directory
and Microsoft® Windows® Domain servers, RADIUS servers, to support
two-factor (token-based) authentication, support for RSA SecurID, and
FirePass® Controller Administrator Guide 1-1

Chapter 1
integration with single sign-on (SSO) systems such as Oracle® COREid®,

eTrust™ SiteMinder®, and others. The FirePass controller can also
perform basic authentication using its internal data base. In addition, the
controller uses signed digital certificates to authenticate devices.
◆ Broad application support
The FirePass controller provides access to virtually all corporate and
desktop applications, including email applications such as Outlook Web
Access (OWA) and iNotes, file and intranet server access, client-server
application access, legacy host application access (mainframe, AS/400,
and Telnet), and Terminal Services/Citrix® application access.
◆ Mobile device access
The FirePass controller provides email, file, and intranet server access
from mini-browsers on mobile devices, including Internet-enabled (WAP
and iMode) telephones, and PDAs.
◆ Endpoint security
The FirePass controller provides a broad set of endpoint security features
such as a protected workspace, client integrity checking, browser cache
cleaner, secure virtual keyboard, and support for 100+ versions of
antivirus and firewall software.
◆ Visual policy editor
To facilitate policy definition, the FirePass controller provides a built-in
policy editor that is graphically based, which eases management and
supports a visual audit of endpoint security policies.
◆ Administration
The FirePass controller provides a web-based Administrative Console.
The console includes tools for installing and managing the FirePass
controller, managing user and group enrollment, configuring clustering
and failover, certificate generation and installation, and customization of
the remote client pages.
◆ Audit trail
The FirePass controller provides audit tools including full-session audit
trails, drill-down session queries, and customizable reports and queries.
◆ Client/Server application support
The FirePass controller provides application-specific tunnels for
client-server applications like Microsoft® Outlook®, ERP package
applications, and custom TCP/IP applications. The FirePass controller
also includes Network Access which gives remote clients full network
access comparable to that offered by a traditional IPsec VPN connection.
◆ High availability
You can configure FirePass controllers to fail over to standby controllers,
ensuring availability for users.
◆ Scalability
FirePass controller cluster nodes support up to 20,000 users with built-in
load balancing support (4100 and 4300 controllers only). In addition, the
FirePass controller integrates with BIG-IP system to support large-scale,
high-performance clustering, which offers universal, secure access for
remote, wireless, and internal network users.
1-2
◆ Integration with BIG-IP system

Integration between the FirePass controller and BIG-IP system provides
a uniform framework; an architecture that provides remote, WLAN, and
LAN access control as a unified solution, rather than requiring you to
manage access control and security policies in three different places. For
information about the BIG-IP system, see the F5 Networks web site at
http://www.f5.com.
◆ MacOS and Linux support
The FirePass controller includes Network Access support for MacOS and
Linux remote clients.
◆ Standalone VPN client and APIs
FirePass controller includes a standalone VPN client and APIs for
building FirePass controller remote access services into applications.
Reviewing the FirePass controller models

The FirePass controller is available in the following models:
◆ FirePass 1000
The FirePass 1000 (Figure 1.1) is a 1U rack-mounted controller designed
for small to medium enterprises, supporting up to 100 concurrent users.
◆ FirePass 1200
The FirePass 1200 (Figure 1.2) is a 1U rack-mounted controller designed
for small to medium enterprises, supporting up to 100 concurrent users.
◆ FirePass 4100 and 4300
The FirePass 4100 and 4300 (Figure 1.3) are 2U rack-mounted
controllers designed for large enterprises, supporting up to 2000
concurrent users, with clustering expanding support to 20,000.
The 1000, 1200, 4100, and 4300 models support failover configuration for
high availability. For more information, see Chapter 11, Using FirePass
Controllers for Failover.

Chapter 1
The FirePass 4100 and 4300 controllers also support clustering, which
provides increased numbers of connections and load balancing. For more
information, see Chapter 12, Using FirePass Controllers in Clusters.
Figure 1.1 The FirePass 1000
Figure 1.2 The FirePass 1200
Figure 1.3 The FirePass 4100 and 4300
Finding the FirePass controller software version number

When you work with F5 Networks technical support, you might need to
have the version number of the software running on your FirePass
controller. You can find the software version number on the Welcome
screen, available from the navigation pane by clicking Device Management
and then clicking Welcome. The screen presents the version numbers below
the introductory graphic. Following is an example of the version numbers.
Version - FirePass 6.0.3
Tue, 22 Jul 2008 23:58 PST
URM-6.03-20080722
1-4
Understanding the FirePass controller

The FirePass controller offers remote connection support for Windows®,
Macintosh®, and Linux® clients. The controller supports IP applications on
all three platforms, and includes an open API that third-party application
vendors can use to build secure remote access solutions into their client
applications.
Availability
Unlike IPsec VPNs, the web-based remote access of the FirePass controller
works over all ISP connections, and from behind other firewalls. ISPs
cannot detect and block FirePass controller conversations as they might with
detected IPsec traffic. Failover and clustering options provide high
availability and high capacity. You can cluster FirePass controllers to
support up to 20,000 concurrent connections on a single logical URL
without performance degradation.
Security
The FirePass controller adheres to the highest standards of security.
◆ Endpoint security
The FirePass controller provides a broad set of endpoint security features
such as a protected workspace, client integrity checking, browser cache
cleaner, secure virtual keyboard, and support for 100+ versions of
antivirus and firewall software. Configurable remediation helps
end-users that fail compliance checks to automatically download the
needed client software to meet endpoint security requirements, for
example, the latest antivirus signature files, operating system updates,
and others. The FirePass controller can display a custom message
containing a download link, so end-users can perform their own
remediation, meet compliance requirements, and get access without
requiring having to call the IT help desk.
◆ Encryption
You can get several levels of encryption, depending on the capability of
the client browser and the configuration of FirePass controller security
settings. The controller supports high encryption standards such as Triple
DES and AES, as well as FIPS and hardware encryption accelerator
options.
◆ Authentication
The FirePass controller supports a number of authentication methods.
• An internal user database for user name and password authentication
• Basic HTTP and forms-based authentication methods
• Authentication based on client certificates
• Authentication based on your existing Active Directory, RADIUS,
LDAP, and Windows domain servers

Chapter 1
As an administrator, you can choose to require different authentication

methods for different groups. Because the FirePass controller supports
RSA SecurID® token-based authentication, you can configure two-factor
authentication.
◆ Access Control
You can use the FirePass controller to grant users access to specific
applications on an individual level or on a group level, enabling
role-based access. With FirePass controller’s access controls, you can
restrict individuals and groups to particular internal resources. For
example, partners can have access restricted to an extranet server, while
sales staff are allowed to connect to email, the company intranet, and the
internal customer-tracking system. The FirePass controller administrative
realms allow you to configure administrators access by restricting access
to different features.
◆ Application security
The FirePass controller provides web application protection that guards
against targeted web application attacks such as SQL injection, cross site
scripting (CSS), and cookie manipulation. Built-in antivirus protection
scans email attachments and files uploaded to the FirePass controller.
Accessibility
The FirePass controller provides a range of accessibility options.
◆ Full network access
Full network access provides a connection that is always available,
assuming the client machine supports it. Full network access virtually
puts the client machine inside the company network, so that clients
perform operations exactly as if they sat at their corporate computers.
Typically, an administrator would choose full network access as the
deployment method for client computers that are from a well-known or
trusted source, such as company-provided laptops.
◆ Application tunnel access
Application tunnel access (also called App Tunnels) provides access to
TCP applications that support fixed ports or a range of ports. The client
experience is similar to full network access, but it exposes only specific
functionality available on the local machine.
Typically, an administrator would choose application tunnel access as the
deployment method for client computers that are from a somewhat
trusted source, such as employee-owned equipment.
◆ Specialized application access
Specialized application access provides browser-based interaction with a
set of commonly used functions:
• Mobile email
• Legacy hosts
• Windows files
• Terminal Servers
1-6
Each application was specifically developed for use on the FirePass

controller.
Typically, an administrator would choose specialized application access
as the deployment method for client computers that are from a public or
untrusted source, such as computers that are publicly accessible (for
example, systems in public libraries, at internet cafes, and from other
public portals).
◆ Web application access
Web application access enables interaction to proprietary and custom
applications using the reverse-proxy technology. Essentially, you can use
web application access to create a specialized application, similar to the
ones listed in the Specialized application access list. Because there is no
overarching protocol for web applications, the degree of support
available for any given application varies based on its content and
method of implementation.
For example, applications that use HTML over HTTP integrate relatively
seamlessly. However, if your application contains a lot of customized
script or applets, you may have to work with your interim application to
support web application access.
Ease of use, deployment, maintenance, and management

You can install and configure the FirePass controller quickly. An intuitive,
browser-based client interface means you do not have to train remote access
users. You can upgrade the FirePass controller remotely, over the Internet,
using browser-based administration. Automatic notifications about release
updates prompt you to download new versions when they become available.
You can also add FirePass controller features and capacity over the Internet.
Determining security requirements for users

Whether you maintain users externally or internally, you can specify several
levels of security, as determined by the governing master group and the
resources you want the users to access. Specifying security requirements
ensures that unauthorized users do not have access while authorized users
do. For example, you can:
◆ Require that the clients logging on have a specific certificate. If the
certificate you define is not present, you can prevent or provide access to
a restricted set of resources. For more information about certificates, see
Setting up client-certificate-based authentication, on page 2-85.
◆ Gather information about the client environment and grant or restrict
access based on the antivirus software type and update time, the presence
of a firewall, the operating system and browser version, and other factors.
For more information about pre-logon inspection of client systems, see
Implementing client system checking, on page 3-14.
◆ Define protected configurations, a set of safety checks to protect
resources. Protected configurations focus on a specific aspect of
protection, such as unauthorized access, information leaks, virus attacks,

Chapter 1
and keystroke loggers. For each criterion, the FirePass controller

provides specific safety measures. For example, to prevent information
leaks, you might specify that the user run inside the protected workspace
or download the cache cleaner to remove cached files when the user logs
off. For more information about protected configurations, see Creating
protected configurations, on page 3-27. At the resource level, you can
apply a definition in one of the following ways:
• To the entire feature
Users must meet certain requirements to use the functionality.
• To one or more resources
Users must meet certain requirements to access a specific resource.
• To the master group
Users must belong to a specific master group to get access to certain
resources.
• To applications and files
Users must meet certain requirements to have access to specific
applications or files.
1-8
Getting started with the FirePass controller

The FirePass controller is a multi-featured appliance that you can configure
from any location. You can follow guidelines in The recommended path,
following, to set up your FirePass controller, or you can elect to travel your
own path, choosing from the options described in Possible configuration
scenarios, on page 1-10.
The recommended path

If you are new to the FirePass controller, you can follow the path outlined in
this section. This recommended path is designed to guide you through the
most common operations, and includes descriptions to help you complete
the task, as well as links to other sections with related functionality.
1. Determine client-system security requirements.
For more information, see Understanding endpoint security, on
page 3-1.
2. Identify authentication mechanism.
The FirePass controller supports two types of authentication:
external and internal. For each type, you can select from a number
of authentication methods, depending on your security setup. These
include Active Directory, RADIUS, LDAP, and others.
• If you are not sure which type of authentication you want, review
topics in Choosing an authentication method, on page 2-67.
• If you already have an authentication mechanism in place and
you want to use it for verifying user identity, you can read more
at Managing user information in an external data store, on page
2-6.
• If you want to use the FirePass controller database to authenticate
users, you can read more at Managing users in the FirePass
controller data store, on page 2-8.
3. Assign users to groups and map master groups to users.
For more information, see Setting up master groups and users, on
page 2-9 and Setting up dynamic group mapping, on page 2-16.
4. Test user connectivity.
This is a good place to stop and test to make sure that users can
connect to the FirePass controller. To do so, open a new browser
window and log on using a logon account that you know exists.
5. Create certificates for user groups.
For more information, see Using client certificates to authenticate
users, on page 2-88.
6. Configure resource groups with the applications and functionality
you want to provide.
For more information, you can review content in several sections:

Chapter 1
• Configuring global Network Access settings, on page 5-6

• Defining favorites for Portal Access Web Applications access, on
page 7-6
• Configuring terminal server favorites, on page 6-33
• Defining a web application tunnel, on page 6-5
• Defining legacy host favorites, on page 6-27
7. Map resource groups to master groups and users.
For more information, see Working with resource groups, on page
2-94.
8. Test connectivity and access.
For more information, see various sections in Chapter 8, Managing
and Monitoring the FirePass Controller.
9. Ensure availability by configuring failover systems.
For more information, see Understanding FirePass controller high
availability, on page 11-1.
10. Expand capacity by configuring clustering.
For more information, see Understanding FirePass controller
clusters, on page 12-1.
11. Learn about monitoring and maintaining the FirePass controller.
For more information, see Chapter 8, Managing and Monitoring the
FirePass Controller.
12. Read sample how-to scenarios.
For more information, see Introducing how-to scenarios, on page
A-1.
Possible configuration scenarios

There are several ways you can begin the configuration process. You can
start with existing groups, even if you want to manage user authentication
internally.
◆ To authenticate users from an external server
If you already have an authentication mechanism in place and you want
to use it for verifying user identity, you can read more at Managing user
information in an external data store, on page 2-6.
◆ To authenticate users from a database on the FirePass controller
If you want to use the FirePass controller database to authenticate users,
you can read more at Managing users in the FirePass controller data
store, on page 2-8.
◆ To gather information from client systems
If you want to specify requirements for client systems to determine
authentication (whether to grant user access) and authorization (which
resources to grant access to), you can read more at Implementing client
system checking, on page 3-14.
1 - 10
◆ To configure the resources, applications, and functionality you want

to provide
If you prefer to start with the resources, applications, and functionality
that you want to provide to your users, you can read more at the
access-type specific sections:
• Configuring global Network Access settings, on page 5-6
• Defining favorites for Portal Access Web Applications access, on
page 7-6
• Configuring terminal server favorites, on page 6-33
• Defining a web application tunnel, on page 6-5
• Defining legacy host favorites, on page 6-27
◆ To configure the internal networking parameters
If you want to prepare the FirePass controller for all of the network
interaction and availability required, such as specifying IP addresses for
web services and setting up failover and clustering members, you can
read more at Maintaining the network configuration settings, on page
8-3, Introducing failover configuration, on page 11-1, and Configuring
FirePass controller clusters, on page 12-3.
◆ To learn about monitoring and maintaining the FirePass controller
If you want to get a head start on understanding the ongoing operations
and logging functionality provided with the FirePass controller, review
content in Monitoring the FirePass controller, on page 8-66, and
Backing up and restoring the FirePass controller, on page 8-47.
◆ To set up certificates on the server
If you are ready to set up and install server certificates for the FirePass
controller, read more in Chapter 4, Using Server Certificates.
◆ To see how-to information on various subjects
If you want exposure to sample configurations that use step-by-step
examples, see Appendix A, How-To Examples.
FirePass® Controller Administrator Guide 1 - 11

Chapter 1
Using this guide

This guide provides overview information about the FirePass controller, and
step-by-step instructions for key features.
This guide is available as an Adobe Acrobat file (.pdf) and as an HTML file
on the F5 Networks Technical Support Web site, https://support.f5.com.
Audience
This guide is intended for system and network administrators who configure
and maintain IT equipment and software. This guide assumes that
administrators have experience working with network configurations.
Stylistic conventions in this document

To help you easily identify and understand certain types of information, this
documentation uses the following stylistic conventions.
Using the solution examples

All examples in this documentation use only private class IP addresses.
When you set up the solutions we describe, you must use valid IP addresses
suitable to your own network in place of our sample addresses.
Identifying new terms

When we first define a new term, the term is shown in bold italic text. For
example, HTTPS is HyperText Transport Protocol (Secure), or secure
HTTP.
Identifying references to objects, names, and commands

We apply bold text to a variety of items to help you easily pick them out of a
block of text. These items include web addresses, IP addresses, utility
names, and portions of commands such as variables and keywords. For
example, the ping command requires that you include at least one
<ip_address> or <fully qualified domain name> variable.
Identifying references to other documents

We use italic text to denote a reference to a specific section or another
document. In references where we provide the name of a book as well as a
specific chapter or section in the book, we show the book name in bold,
italic text, and the chapter/section name in italic text to help quickly
differentiate the two.
1 - 12
For example, you can find information about various FirePass controller
models in the FirePass Controller Getting Started Guide, Chapter 1,
Getting Started with the FirePass Controller.
Identifying command syntax

We show actual, complete commands in bold Courier text. Note that we do
not include the corresponding screen prompt, unless the command is shown
in a figure that depicts an entire command line screen. For example, to log
on to the Maintenance Console, type the user name:
maintenance
Table 1.1 explains additional special conventions used in command line
syntax.
Item in text Description
\
Continue to the next line without typing a line break.
< >
You enter text for the enclosed item. For example, if the command
has <your name>, type your name.
|
Separates parts of a command.
[ ]
Syntax inside the brackets is optional.
...
Indicates that you can type a series of items.
Table 1.1 Command line conventions used in this manual
Additional conventions
We use a conspicuous note format for a variety of information, ranging from
supplemental to critical.
A Tip suggests ways to make administration easier or faster. For example:
Tip
An easy way to enter a user agent string is to copy and paste the string from
the Logons report.
A Note provides supplemental, helpful information. For example:
Note
If you want users to be able to define their own personal webtop favorites or
preferences, then you must use internal user management.

Chapter 1
An Important note contains important information. For example:
Important
If you are starting up a controller cluster, always start the primary
controller first, and then the remaining secondary cluster controllers
thereafter. Otherwise, the controllers will not start properly.
A Warning describes actions that can cause data loss or problems. For
example:
WARNING
If you are configuring failover in a production environment, the order in
which the pair of controllers restart is very important, and can result in data
loss if the two controllers do not restart in the correct order. For more
information, see Introducing failover configuration, on page 11-1.
1 - 14
Finding help and technical support resources

You can find additional technical documentation about the FirePass
controller using the following resources:
◆ Getting Started Guide
The FirePass® Controller Getting Started Guide is provided as a printed
document in the box with the FirePass controller. The Getting Started
Guide contains all of the information you need to set up and install a new
FirePass controller. You can find a copy of the guide (in PDF and HTML
formats) on the F5 Networks Technical Support Web site,
https://support.f5.com.
◆ Release notes
Release notes containing the latest information for the current version of
the FirePass controller are available from the Administrative Console. In
the navigation pane, click Device Management, expand Maintenance,
and then click Online Update. A link to Release notes for the current
release is at the top of the screen. Release notes include a list of new
features and enhancements, a list of fixes, and a list of known issues.
You can also find release notes for the FirePass controller in HTML
format on the F5 Networks Technical Support web site,
http://tech.f5.com/home/firepass/. This site includes release notes for
the current, and all previous versions of the FirePass controller.
◆ Online help for FirePass features
You can find help online for virtually all screens on the Administrative
Console. To open the context-sensitive online help, click the Help
button in the upper right of the screen.
◆ Technical support through the World Wide Web
The F5® Networks Technical Support web site, https://support.f5.com,
provides the latest technical notes, answers to frequently asked questions,
release notes and release note updates, and the Ask F5SM database. You
can also find Release notes there, and all the guides in PDF format. To
navigate to the Ask F5 site, click the Ask button in the upper right of
any screen on the FirePass controller Administrative Console.

Chapter 1
1 - 16
2
• Introducing master groups and resource groups
• Managing user information in an external data store
• Managing users in the FirePass controller data store
• Setting up master groups and users
• Setting up dynamic group mapping
• Setting up authentication
• Working with resource groups

Introducing master groups and resource groups

The FirePass controller uses groups to authenticate users and enable access
to resources, applications, and files. Using multiple groups, you can
configure different authentication methods and define different access rules
to fit different sets of users. FirePass controller supports two types of
groups: master groups, and resource groups.
Understanding master groups

A master group is a collection of users. It contains authentication settings,
overall security configuration settings for groups of users, network access
filtering policies, user experience (appearance and sequence of the user’s
home screen), and, if you are maintaining users on the FirePass controller,
user accounts. Using master groups, you can define sets of users, and to
enforce different authentication requirements and security settings for
different groups. Each user who connects to the FirePass controller is
associated with one master group, and the master group provides the
authentication that defines what the user can access.
You can also configure different user experience settings for users in
different master groups. For example, you can divide users into two groups:
employees who are authenticated against your Active Directory server and
can access almost all resources on your intranet, and partners who are
authenticated against a RADIUS server and can access only a few resources.
Understanding resource groups

A resource group is a collection of resources, access control lists, and
protection criteria, which includes your company intranet servers,
applications, and network shares. Using resource groups, you can define sets
of resources and control access to these resources discretely.
Each resource in a resource group is represented using a special
configuration construct called a favorite. A favorite has all of the
information needed for the client computer to connect to an resource.You
can define several kinds of favorites:
◆ Intranet server favorites
• Network Access connections
• App Tunnel connections
◆ Favorites for various applications
• Terminal Servers connections
• Web applications connections
• Legacy Hosts connections
◆ Network share favorites for Windows files access

Chapter 2
When a user attempts to log on to the FirePass controller, if the user is

authorized to access a resource, the corresponding favorite appears as a link
on the user’s browser-based home screen. The user can click the link to
access the resource.
Understanding how master groups and resource groups work

together
A master group is associated with one or more resource groups. Once the
master group authenticates the user, the user is allowed to access the
resources configured for that master group. You can associate a resource
group with one or more master groups or with individual users. Using
resource groups, you can ensure that only the users who meet the
authentication criteria and security settings requirements configured for the
master group have access to the resource group. This way, you can restrict
access to certain resources based on which master group a user belongs to.
Fundamentally, master groups deal with authentication of users who want
access, while resource groups deal with the functionality and locations that
users can access. Figure 2.1, following, illustrates the relationship between
master groups, resource groups, and favorites categories.
Figure 2.1 Association between users, master groups, resource groups, and favorites categories
2-2
Understanding user account management options

When determining the user-management structure of master groups, you
have a choice between managing users externally or internally.
◆ Manage users externally on your corporate servers
This is the recommended method. Using this method, you keep your
user’s information on an external server. The FirePass controller
retrieves the user’s group information from the external server at logon
time. The FirePass controller supports the following methods for
externally managing users:
• RADIUS server
• LDAP server
• Windows® Domain server
• Windows Active Directory® server
• RSA SecurID® technology
For more information, see Managing user information in an external
data store, on page 2-6.
◆ Manage users internally on the FirePass controller
Using this method, you add users to the internal FirePass controller
database. You populate internal master groups with users and user
information manually, using signup-templates, or by user-import
functions. For more information, see Managing users in the FirePass
Note
If you want users to be able to define their own personal webtop favorites or
preferences, you must manage users internally on the FirePass controller.
Understanding the best practice for managing users

F5 Networks highly recommends managing users externally using your own
network group structure. First, the user-administration task is much simpler.
Second, managing users externally results in increased FirePass controller
performance because the controller does not have to create as many files on
the system. This is especially important with sites that have large numbers
of users and failover configured, since in such cases synchronizing the user
database can reduce performance. Finally, although the FirePass controller
has limited capability to automate user database synchronization (using the
master group features signup templates and the LDAP/Active Directory
synchronize options), there are no such issues with externally managed
users.

Chapter 2
Configuring authentication for users

When determining the authentication method for users in master groups,
you have a choice between external and internal authentication.
• External authentication
Authenticates users with information retrieved from an external source.
You can elect to authenticate users from an external server whether you
manage the users internally on the FirePass controller, or externally on
your network server.
• Internal authentication
Authenticates users with information from local user accounts. You
cannot configure internal authentication for externally managed users.
The FirePass controller authenticates a user based on the authentication

method configured for that user’s master group. The FirePass controller
supports the following authentication methods:
• LDAP server query
• RADIUS server query
• Windows domain server query
• Windows Active Directory server query
• Specified settings from a client certificate: Organization (O),
Organization Unit (OU), or a string match against the Distinguished
Name (DN).
• HTTP form-based authentication
• RSA SecurID® technology
• HTTP basic authentication
Creating internal users on the FirePass controller

If you want to use the FirePass controller to manage users, you can add user
accounts to master groups by using any of the following methods.
◆ Manually add users
You can add a single user at a time. This is the least efficient, yet most
controlled method. If you have more than about 100 users, manually
adding users can be extremely time consuming, and can result in
extensive administrative requirements. See Understanding user account
management options, on page 2-3.
◆ Import users from an Active Directory or Windows domain server
In some environments, the administrator might prefer to add users to the
FirePass controller, but already has an Active Directory or Windows
domain server structure in place. In this case, you can use your existing
user base as an import source for FirePass controller master groups.
2-4
◆ Import users from an LDAP server

Similarly, in an environment that has an LDAP server structure in place,
administrators can use their existing user base as an import source for
FirePass controller master groups.
◆ Import users from a text file
In cases where there is no existing server structure, you can populate the
internal FirePass controller database with user accounts from a text file.
The advantage of using a file is that you can add many users
simultaneously, simplifying the add-user process.
◆ Use signup templates to automatically add users
For setups using locally managed users, you can use signup templates to
automatically add external users to the local database. See Using signup
templates to add user accounts, on page 2-14.
All of these methods create user accounts in the FirePass controller internal
database. For specific procedures for each of these operations, see the online
help,

Chapter 2
Managing user information in an external data store

You can use existing user accounts that you have defined on an external
server in your own network environment to authenticate FirePass controller
users. External user management is the recommended user-management
method. The advantage of using an external data store is that you can use the
same server to authenticate FirePass controller users as you use to
authenticate your local network users. Using an external data store for
authentication greatly reduces the administrative effort needed to maintain
user accounts on the FirePass controller, as well as on your internal network
servers. In addition, using an external data store for authentication improves
FirePass controller performance because user accounts are not maintained
on the FirePass controller.
Tip
If you already have an authentication mechanism in place (for example, you
are using the Active Directory service), you can use that mechanism to
manage users of the FirePass controller. Using external user authentication
reduces administration time, and is the simplest client-authentication
method.
For example, if your network uses the Active Directory service, you can
configure the FirePass controller to map to that structure. In this case, the
FirePass controller queries the directory to get user information, and uses
the results to associate each user with a master group as they log on.
To configure master groups for external users

1. In the navigation pane, click Users, expand Groups, and click
Master Groups.
The Master Groups screen opens.
2. Click the Create new group button.
The Group Management screen opens.
3. In New group name, specify a name for the group.
4. From the Users in group list, select External.
5. From the Authentication method list, select the authentication
method you want to use.
You cannot select Internal database or Initial signup on LDAP
with Subsequence Strong Internal Password as the authentication
method for master groups of external users.
6. Click the Create button.
The master group configuration screen opens with the General tab
selected.
7. To use dynamic group mapping in master groups, check Allow
users to be assigned to this master group using dynamic master
group mapping.
If you do not enable this option, the FirePass controller gives the
user access to the master group only if the master group is in the list
2-6
of fallback groups, and Determine the user's master group by

attempting to authenticate the user in each of the fallback
master groups is enabled. To access this option, you must enable
the option Determine the user’s master group dynamically using
the master group mapping table on the Dynamic Group Mapping
screen.
8. To use dynamic group mapping in resource groups, enable the
option Allow resource groups to be assigned to this master group
using dynamic resource group mapping.
If you do not enable this option, the FirePass controller gives the
user access only to resource groups that are statically assigned to the
user. To access this option, you must enable the option Determine
the user's resource group dynamically using the resource group
mapping table on the Dynamic Group Mapping screen.
9. Click the Resource Groups tab, and select the resource groups you
want this master group to access.
You can select one or more resource groups and click Add to make
them accessible to the master group’s users.
10. Finally, click the User Experience tab to customize the look and feel
of the screen for users in this master group.
Tip
You can create new master groups that use settings from existing master
groups by selecting the group from the Copy settings from list when you
create a new group.

Chapter 2
Managing users in the FirePass controller data store

If you prefer, you can create users in the FirePass controller data store. The
process involves first creating the master groups, and then adding users. You
can add users manually, by importing them from existing external sources,
or by configuring signup templates.
Managing users internally is not the recommended method. However, there
are several circumstances in which you might want to use this method.
• Administrators who have no existing user management and
authentication source in place might want to use the FirePass controller
to manage users.
• An administrator might want a single location that lists which users have
access to which resources.
This is an easy way to determine who has individual access to various
devices.
• Some administrators might want to create an administrators-only group
that exists only on the FirePass controller.
This might be effective when the external authentication source is not
available.
• Those administrators who want users to create their own favorites or
change personal preferences must maintain users locally.
To configure master groups for local users, follow the same steps as needed
for configuring a master group with external users, as described in the
procedure To configure master groups for external users, on page 2-6.
Note
The FirePass controller has a default master group called Default. You can
use this master group without creating any other master groups, or you can
create master groups to use instead of, or in addition to, the default group.
2-8
Setting up master groups and users

For each master group, you can separately manage users and set up
authentication methods, resources, and other features. This is the
recommended process for setting up groups, user accounts, authentication,
and certificates on the FirePass controller.
◆ Determine the requirements you want for different sets of users.
The FirePass controller uses groups to determine authentication, resource
assignment, and many other features. This is the task at which you should
determine how much access each set of users has. The guidelines defined
in your company’s security policy might help you answer some of these
questions:
• Where will the FirePass controller reside physically and logically in
your network structure?
• What are your company’s authentication requirements? That is, do
you use Active Directory, RADIUS, LDAP, or something else? Will
you use the company’s authentication requirements or develop
something else?
For more information, see Choosing an authentication method, on
page 2-67.
• What are the requirements for password length and content?
For more information, see Setting up initial signup on LDAP with
subsequent strong internal password, on page 2-81.
• Who gets access to which resources and who does not?
For more information, see Determining security requirements for
users, on page 1-7.
• What are the endpoint security procedures and penalties for dealing
with information leaks, unauthorized access, and security breaches?
For more information, see Creating protected configurations, on page
3-27.
◆ Create the FirePass controller master groups to correspond to the
requirements you define.
For more information, see Populating master groups with users, on page
2-13.
◆ Configure authentication for each group on the FirePass controller.
For more information, see Setting up authentication, on page 2-67.
◆ Map external groups to internal FirePass controller groups.
For more information, see Setting up dynamic group mapping, on page
2-16.
You use group mapping under either of the following circumstances:
• You plan to manage users externally. For more information, see
Managing user information in an external data store, on page 2-6.
• You plan to have locally managed users, but you want to control their
master group membership dynamically each time they log on to the
FirePass controller. For more information, see Managing users in the
FirePass controller data store, on page 2-8.
You can configure group mapping using any of the following sources.

Chapter 2
• Windows Active Directory server

For more information, see Setting up Active Directory
authentication (Kerberos authentication), on page 2-82.
• Windows Domain server (pre-Windows 2000 compatibility)
For more information, see Setting up Windows domain server
authentication, on page 2-82.
• LDAP server
For more information, see Setting up LDAP server
• RADIUS server (including RSA SecurID RADIUS)
For more information, see Setting up RADIUS server
• Client certificate (passwordless)
For more information, see Setting up client-certificate-based
• URI landing page
For more information, see Mapping based on landing URI, on
page 2-43.
Note: Mapping by URI landing page on its own does not verify
users. F5 Networks recommends mapping using external groups
instead.
◆ Add user accounts directly to the FirePass controller database.
If you plan to manage users internally, you can add them manually by
creating accounts individually, by importing them into the database, or
by adding them automatically using the signup-by-template feature.
For more information, see Managing users in the FirePass controller
data store, on page 2-8, and Using signup templates to add user
accounts, on page 2-14.
◆ Set up server certificates specifically for your site.
If you plan to use client certificate authentication, set up server
certificates specifically for your site, and set up client certificates to
validate clients.
For more information, see Managing certificates on the FirePass
controller, on page 4-5.
◆ Install a client root certificate and certificate revocation list (CRL).
If you plan to configure the FirePass controller to validate client
certificates installed on each user’s computer, you can use client
certificates for authentication and to control access to specific resources.
For more information on setting up server and client certificates, see
Managing certificates on the FirePass controller, on page 4-5.
2 - 10
Configuring a master group

After creating a master group, your next task is to configure the group. You
use the Master Groups screen for this task. The Master Groups screen lists
all the master groups, including the default master group. To access the
screen, in the navigation pane, click Users, expand Groups, and click
Master Groups.
The Master Groups screen contains several tabs that provide specific
configuration options. For more information about the options on each tab,
see the online help for the Master Groups screen.
◆ General
Presents options that govern how to assign users and resources to the
master group.
◆ Authentication
Presents options for the authentication method the group requires.
◆ Resource Groups
Presents options for assigning resource groups to master groups.
◆ Signup Templates
Presents options for automatically adding users to external groups.
◆ User Experience
Presents options that govern the appearance of the user’s FirePass
controller webtop.
Tip
On many configuration screens, you can switch to a different master group
by selecting a group from the Group list box at the upper left. This is an
easy way to change the master group you are configuring, without returning
to the Master Groups list screen.
Navigating the Master Groups list screen

The Master Groups list screen displays all the master groups, along with
some configuration information. To access the screen, in the navigation
pane, click Users, expand Groups, and click Master Groups. By default,
the master groups list is sorted by group name, but you can sort by
authentication method by clicking the Authentication column heading. You
can click a column entry to open the tabbed Master Group configuration
screen or a user or group management screen.
The columns of the Master Groups list screen provide information about
each master group.
◆ Group Name
Lists the name of each group. You can click a group name to open its
Master Group configuration screen containing options such as how users
and resources are assigned to the group.

Chapter 2
◆ Authentication
Lists the type of authentication the group uses. You can click the
authentication method to open the Master Group configuration screen
containing options such as authentication-specific settings
(Authentication tab).
◆ Resource Groups
Lists the number of resource groups assigned to the master group, and
whether dynamic resource assignment is enabled. You can click an entry
to open the Master Group configuration screen containing options for
adding or removing resource groups for the associated master group.
◆ Signup Template
Shows whether signup templates are enabled (options are: N/A, No, and
Yes). The N/A entry indicates master groups of externally managed
users. You can click a No or Yes entry to open the Master Group
configuration screen containing options such as whether to allow
automatic sign-up by template and others.
Note: You can specify signup template as an optional parameter only for
master groups of externally managed users.
◆ Max concurrent sessions
Contains the number representing the maximum number of sessions
configured for that master group. The default varies depending on the
number of licenses you have for the FirePass controller. You can specify
a different number on the General tab by clicking the associated link,
checking Limit the number of concurrent sessions for this group, and
specifying the number you want. In no case can you specify a number
greater than the number of licenses you have.
◆ Users
Contains an indication of whether the group’s users are maintained
internally (Local) or externally (External). In any group containing
locally managed users, you can click the Local link to display the users.
Note: You cannot view the list of users from master groups with
externally managed users.
◆ Routing Table
Contains an indication of which routing table governs the associated
master group. You can click the link in the column to open the Select
Routing Table screen to select a different table to associate with a master
group. The FirePass controller routes the traffic from users in the master
group according to the routes in the associated routing table.
◆ Delete
Provides links for deleting the associated master group. You cannot
delete the Default master group.
You can use the Back to Users : Groups : Master Groups page link at the
top of the screen to return to the Master Groups list screen. You can also
return to the Master Groups list screen by clicking Master Groups in the
navigation pane.
2 - 12
Managing master groups

Once you have set up the master groups you want, you can manipulate them
in various ways so that they meet the requirements you have.
◆ Use the Master Groups list screen
To access the Master Groups list screen, click Users, expand Groups,
and click Dynamic Group Mapping. The Master Groups list screen is
where you accomplish all of the tasks described in this section.
◆ Create a new master group
You can create a new master group by clicking the Create new group
button at the upper right.
◆ Configure a master group
You can configure a master group by clicking the group name, or by
clicking any link in the following columns: Authentication, Resource
Groups, Signup Template, Max concurrent sessions, Users, or Routing
Table.
◆ View the group’s users
You can list the users by clicking the Local link in the Users column.
You can view group members for locally maintained users only.
◆ Delete a master group
You can delete a master group by clicking the associated Delete link.
When you click Delete, the FirePass controller presents a confirmation
prompt in which you can move users to a different master group or to
delete the group’s members. You cannot delete the Default master
group.
Important
If you move internal users from externally authenticated groups to internally
authenticated groups, you must manually specify each user’s password and
any other user information requested on the User Management screen.
Populating master groups with users

You can populate master groups with users in the following ways.
◆ Mapping external groups to FirePass controller groups.
You can map your external groups to the FirePass controller’s master
groups.
◆ Importing users from external sources.
You can import users from the following sources:
• LDAP directory
• Windows Domain (NTLM)
• Text files
• Active Directory
You can then use synchronization options to make sure the group
membership stays current.

Chapter 2
If you want different settings for sets of users, you can either manage this
through use of multiple master groups (with resource groups statically
assigned to each master group), or with a single master group (and enabling
dynamic group mapping to map individual resource groups to users).
Note
F5 Networks recommends authenticating users externally.
Tip
If you plan to use the same authentication and settings for all users, you can
simply add all users to the existing default master group and just change the
authentication type.
Using signup templates to add user accounts

If you use an external server to authenticate users, you can configure a
signup template to automatically add users to the group when they log in to
the FirePass controller for the first time. The FirePass controller displays a
form where first-time users type their user name, password, and other
information.
To set up signup templates

Master Groups.
The Master group list screen opens.
2. Click one of the existing master group names, or click Create new
group to create a new master group.
3. Click the Signup Templates tab, and check Allow Authenticated
Signup by Template.
You can also check Bypass signup by template form and enter
user information later to allow the user to log on using only the
user name and password. That is, the FirePass controller does not
present a signup template to users, but adds users to the group.
Using this option, you can specify content for the user account at
any time after creation.
Tip
You can switch to a different master group by selecting the group from the
Master Group list at the upper left of any Master Group configuration
screen. This is an easy way to change the master group you are configuring.
If you also use group mapping, the FirePass controller retrieves the user’s
group information and adds the user to the corresponding internal mapped
group, and then presents the signup template as needed. If a user is a
2 - 14
member of several groups on the external server and you have set up
mapping for each group, the FirePass controller adds the user to the first
group it finds that matches a group specified for signup templates.
For more information about group mapping, see Setting up dynamic group
mapping, on page 2-16.
Understanding entries in the User Management list

If you manage users locally, you can use options on the User Management
screen to create and delete individual users, import groups of users, activate
and deactivate user accounts, export user information to a file, configure
user access to resources, and move users to another group. To access the
screen, in the navigation pane, click Users, and click User Management.
You can use links at the top of the list of users to sort users by logon, name,
email, and group. You can specify search-by criteria and strings to find
users and limit the scope and the size of the list of results.

Chapter 2
Setting up dynamic group mapping

Using dynamic group mapping, you can associate a user with a master group
and with resource groups dynamically at user logon time. This functionality
allows the FirePass controller to use your user’s group-based and role-based
policies that you maintain on your existing corporate policy server. If you
are using dynamic group mapping, you only need to change the group-based
policy or roles at your corporate server. During the logon attempt, the
FirePass controller retrieves the user’s current group information and
dynamically associates it with a master group or resource groups.
Note
We recommend that you optimize your mapping table using the fewest
number of mappings to accomplish what you want. The trade-off is
performance-based. Because the FirePass controller retrieves group
mapping information at logon time for every user, a large number of groups
and mappings might slow logon times.
Finding procedures for dynamic group mapping

The FirePass controller dynamic group mapping feature provides support
for several types of mapping operations. You can find a general example as
well as specific procedures for each of the group mapping methods.
For more information, see one or more of the following sections.
• Configuring dynamic master group mapping: an example, on page 2-20
• Configuring dynamic resource group mapping: an example, on page
2-21
• Enabling dynamic group mapping, on page 2-23
• Specifying fallback master groups, on page 2-24
• Completing group mapping configuration, on page 2-25
• Specifying a group mapping method, on page 2-26
For information about one of the specific group mapping methods, see one
or more of the following sections.
• Mapping based on Active Directory or Windows domain controllers,
on page 2-27
• Mapping based on LDAP information, on page 2-32
• Mapping based on client certificates, on page 2-38
• Mapping based on RADIUS groups, on page 2-40
• Mapping based on landing URI, on page 2-43
• Mapping based on virtual hosts, on page 2-45
• Mapping based on session variables, on page 2-47
2 - 16
Understanding dynamic master group mapping

During dynamic master group mapping, the FirePass controller queries the
external group mapping servers, and matches the value of the external
groups with the entries in the master group mapping table. If a user matches
more than one entry in the master group mapping table, the FirePass
controller uses the first match it encounters. If the mapping succeeds, then
the FirePass controller authenticates the user by the authentication methods
configured for that master group.
Understanding how a user is authenticated

The FirePass controller goes through a series of activities when it uses
master group mapping to determine to which master group a user belongs.
Then the FirePass controller authenticates the user by whatever
authentication method is configured for that master group. The FirePass
controller steps through the master group mapping process in the following
order.
◆ First, the FirePass controller queries any external servers that are
configured with mapping methods and attempts to match the user to a
master group based on entries in the master mapping table. For example,
if LDAP is the configured mapping method, the FirePass controller sends
a query to the LDAP server to gather the information requested.
◆ Next, the FirePass controller compares the results of the query with each
entry you have specified in the master group mapping table, looking for a
match. At this point, if the system has not identified a master group, the
FirePass controller searches its internal database to determine the user’s
master group information.
◆ When the FirePass controller finds a match, it associates the user with the
master group and prepares for authentication. If a single user matches
more than one master group, as determined by entries in the master
mapping table, the FirePass controller uses the first match it encounters.
You can set the order in which the FirePass controller should perform
group mapping operations by specifying the mapping’s priority number
in the master group mapping table.
◆ If the system has not yet found a match, it searches through the fallback
master groups specified.
Figure 2.2 illustrates the dynamic master group mapping process. You can
find sample mapping procedures in Specifying a group mapping method, on
page 2-26.

Chapter 2
Figure 2.2 The FirePass controller master group mapping process
The Dynamic Group Mapping screen contains text that describes the process
illustrated in Figure 2.2. To access the Dynamic Group Mapping screen, in
the navigation pane, click Users, expand Groups, and click Dynamic
Group Mapping.
Understanding dynamic resource group mapping

During dynamic resource group mapping, the FirePass controller queries the
external group mapping servers and matches the value of the external groups
against the entries in the resource group mapping table. The user gets an
association for each resource mapping table entry whose resource group
configuration matches. When the FirePass controller finds a match, it
provides the user access to the resource groups associated with the mapped
entries. The FirePass controller then permits the user access to all resources
in all resource groups returned by any of the configured methods, and
presents the resources as favorites on the user’s webtop. If dynamic resource
group mapping fails, the following actions occur:
• If the user belongs to a group whose users are maintained externally, the
FirePass controller does not provide the user access to the resource.
2 - 18
• If the user belongs to a group whose users are maintained in a FirePass

controller resource group, the FirePass controller provides the user
access to only those resource groups that are statically assigned to the
master group and individually assigned to the user.
Understanding how resource groups are assigned

The FirePass controller makes resources available in the following ways:
• From dynamically assigned resource groups
• From resource groups that are statically assigned to the user’s master
group
• From resource groups that are statically assigned to a user
When you enable dynamic resource group mapping, and the user logs on to
the FirePass controller, the FirePass controller completes the following
sequence of events to map a user to available resources:
◆ First, the FirePass controller attempts to use dynamic resource group
mapping to determine which resource groups are assigned to the user. If
the system finds assigned resource groups, the FirePass controller
presents to the user the resources from those groups.
◆ Next, the FirePass controller attempts to determine which resource
groups are statically assigned to a user’s master group. If the system
finds resource groups, the FirePass controller allows the user access to
the resources associated with that master group.
◆ The FirePass controller then attempts to determine which static resource
groups are statically assigned to the user. If the system finds resource
groups, the FirePass controller permits the user access to those statically
assigned resources as well.
◆ Finally, the FirePass controller presents to the user all resource groups
received from this sequence.
Figure 2.2 illustrates the dynamic master group mapping process. You can
find sample mapping procedures in Specifying a group mapping method, on
page 2-26.

Chapter 2
Figure 2.3 The FirePass controller resource group mapping process
Configuring dynamic master group mapping: an example

You define two groups on your corporate policy server: employees and
consultants. You want to authenticate the users in these two groups using
different authentication servers: employees through your own authentication
server, and consultants through a third-party authentication server.
On the FirePass controller, you have two master groups: Employees and
Consultants. You specify an authentication method for the Employees
master group that matches your internal network servers. You configure
resource groups with resources that are appropriate for access only by
company employees, and map those resource groups to the Employees
master group.
Similarly, for the Consultants master group, you specify a third-party
authentication method, and you configure resource groups with access only
to resources that corporate consultants should access, that is, resources that
2 - 20
are isolated from the corporate network or prevent access to confidential

information. You configure map those resource groups to the Consultants
master group.
Next, you configure mapping entries that associate your external group
Employees with the FirePass controller master group employees, and
Consultants with consultants.
Here is what happens for two users: Maria, an employee, and George, a
consultant.
Whenever Maria tries to log on to the FirePass controller, the FirePass
controller retrieves the group information from your corporate policy server,
maps Maria to the FirePass controller master group Employee, and
authenticates Maria against your authentication server. The FirePass
controller then allows Maria to access all of the resource groups associated
with the master group Employee.
When George tries to log on to the FirePass controller, the FirePass
controller retrieves group information from a third-party source, maps
George to the FirePass controller master group Consultant, and limits
George to only those resource groups that are associated with the master
group Consultant.
If, in the future, George becomes an employee, you do not have to make any
changes on the FirePass controller. You just have to update group
information for George on your corporate policy server, changing it from
consultant to employee.
When George next tries to log on to the FirePass controller, the FirePass
retrieves the group information from your corporate policy server instead of
the third-party source, maps George to the FirePass controller master group
Employee, and authenticates George against your authentication server. The
FirePass controller then allows George to access all of the resource groups
that are associated with the master group Employee.
This example shows that dynamic master group mapping allows you to
dynamically control the authentication, security, and resource assignment
for a user.
Configuring dynamic resource group mapping: an example

Dynamic resource mapping allows you to assign resources dynamically to a
user, based on roles. At logon time, the FirePass controller retrieves
role-based policies (groups) information from your corporate policy server.
The FirePass controller then assigns resources to the user dynamically,
based on the user’s groups.
In this scenario, you have two kinds of users in your marketing division:
staff and managers. Staff can access most of your marketing resources, but
the confidential information on some servers is only accessible to managers.
To use dynamic resource group mapping, you define two resource groups on
the FirePass controller: Staff and Managers. In Staff, you create favorites
that represent the resources appropriate for those users to access. In
Managers, you create favorites that represent all resources.

Chapter 2
Next, you configure the dynamic resource group mapping table to map your
staff group to the FirePass controller Staff group, and your managers group
to the FirePass controller Managers group.
Here is what happens for Joe, a new staff member at your company.
When Joe starts at your company, you create user account information for
him in the staff group. When Joe tries to log on to the FirePass controller,
the FirePass controller retrieves the group value staff from your corporate
policy server. Based on the configured dynamic resource group mapping
entries, the FirePass controller maps the value staff to the FirePass controller
Staff resource group.
Now, Joe can access all of the resources configured for the Staff resource
group.
In this scenario, 12 months later, Joe is doing such good work that he is
promoted to a managerial position. To provide Joe access to the resources
that all managers see, the only thing you need to do is to change Joe’s group
from Staff to Managers on your corporate policy server.
The next time Joe tries to log on, the FirePass controller retrieves the group
value managers from your corporate policy server. Based on the configured
dynamic resource group mapping entries, the FirePass controller maps the
value managers to the FirePass controller Managers resource group, and
gives Joe access to all of the resources available to the Managers resource
group.
This example shows that dynamic resource group mapping allows you to
keep your group-based or role-based policies on your corporate policy
server. You can then configure the FirePass controller to apply these
policies dynamically when the user logs on. If a policy changes, you do not
have to reconfigure the FirePass controller, you can just move the user to a
different group on your corporate server. Because you have defined the
mapping entries, the FirePass controller automatically provides access
correctly, based on the user’s changing role.
Using dynamic group mapping

Dynamic group mapping is accomplished by configuring associations in a
mapping table. The group mapping table serves as a framework to ensure
that the FirePass controller correctly authenticates external users or local
users authenticated externally, and that those users get access to the
appropriate resources.
The FirePass controller maintains a table of associations between external
groups and users and a table of internal master groups and resource groups.
The master mapping table controls the association between users and
master groups, and the resource mapping table controls the association
between users and resource groups.
You can configure dynamic group mapping by completing these tasks.
◆ Enable master group mapping and resource group mapping.
For more information, see Enabling dynamic group mapping, following.
2 - 22
◆ Specify fallback master groups.

For more information, see Specifying fallback master groups, on page
2-24.
◆ Add one or more mapping methods.
For more information, see Specifying a group mapping method, on page
2-26.
◆ Specify the mapping configuration.
For more information, see Completing group mapping configuration, on
page 2-25.
◆ Configure entries in the master mapping table.
For more information, see Completing group mapping configuration, on
page 2-25.
◆ Configure entries in the resource mapping table.
For more information, see Associating resource groups with users, on
page 2-96.
You can use signup templates to have the group mapping functionality
automatically add new users to master groups at logon time. For more
information, see Using signup templates to add user accounts, on page 2-14.
Enabling dynamic group mapping

Dynamic master group mapping is automatically selected for master groups
with external users. By default, group mapping is not selected when you
create master groups with local users. You can specify group mapping when
you create a group, or at any time after the group has been created. Until you
enable dynamic group mapping, you can add users manually, or by
importing them from an external source.
Users that you maintain locally on the FirePass controller can have both
dynamically and statically assigned resource groups.
For dynamic group mapping to succeed, you must specifically enable it for
each master group.
To enable dynamic mapping

Master Groups.
2. Click the group name of the group you want to use in group
mapping.
The screen changes, and you see the General screen for this master
group.
3. Select the option appropriate to the type of group you are mapping.
• For master groups, select the option Allow users to be assigned
to this master group using dynamic master group mapping.
Selecting this option uses settings on the master group mapping
table to map users to master groups.

Chapter 2
• For resource groups, select the option Allow resource groups to

be assigned to this master group using dynamic resource
group mapping.
Selecting this option uses settings on the resource group mapping
table to map users to resource groups.
4. Click the Update button.
Specifying fallback master groups

Since most users belong to several groups in a network structure, using
fallback groups can help direct the FirePass controller to identify a user as
part of a specific master group. In this case, if the FirePass controller cannot
identify the user as part of the first master group in the mapping, it tries the
master groups listed in the fallback master group list, in the order the group
appears in the list.
By default, the FirePass controller adds newly created master groups to the
list of fallback master groups. You can add and remove master groups, and
you can rearrange the order of master groups in the list. Specifying fallback
master groups is part of configuring for dynamic group mapping.
To add a fallback master group

Dynamic Group Mapping.
The Dynamic Group Mapping screen opens.
2. Check the box following Step 3, Determine the user's master
group by attempting to authenticate the user in each of the
fallback master groups.
3. In the Available master groups list, select any master groups you
want to affect.
You can use the Shift and Ctrl keys to add items to your selection.
4. To add a master group as a fallback master group, click Add.
The selected group or groups appear in the Fallback master groups
list.
5. In the Fallback master groups list, select any master groups you
want to affect.
You can use the Shift and Ctrl keys to add items to your selection.
6. Perform an action. Possible actions include:
• To prevent the FirePass controller from using the master group
selected as fallback master group, click Remove.
• To position the selected master group so that the FirePass
controller uses it earlier in the dynamic group mapping process,
click Move Up.
• To position the selected master group so that the FirePass
controller uses it later in the dynamic group mapping process,
click Move Down.
2 - 24
Completing group mapping configuration

Once you enable dynamic group mapping, you can proceed to select the
mapping method you plan to use (see Specifying a group mapping method,
on page 2-26), configure the request for user information (see To configure
dynamic group mapping, following), and add entries to the master group
mapping table and the resource group mapping table (see the section relating
to the type of mapping you are configuring). When you complete these
tasks, the FirePass controller can perform dynamic group mapping.
To configure dynamic group mapping

The Group mapping sequence screen opens.
2. Check or clear the options you want to create the mapping sequence.
3. If you plan to have fallback groups for mapping users, in the Step 3
area of the screen, add and order master groups to the Fallback
master groups list.
4. If you plan to have dynamic resource group mapping, check the
option in the Resource Groups Mapping Sequence section.
5. Click the Group mapping methods tab.
The Group mapping methods screen opens.
6. From the mapping methods list, select the method you want, and
click Add mapping method.
The new method is added to the list. If the method is already added,
it is not present in the list. For more information, see Specifying a
group mapping method, on page 2-26.
7. Click the Request configuration tab.
The Request configuration screen opens.
8. From the Select method to configure request list, select the
method you plan to use for group mapping, and then click Switch.
The screen refreshes to reveal options that are relevant to the
method you selected.
9. Configure the settings that reflect your external group and network
structure, and then click the Update button.
You must configure settings so that the FirePass controller can send
the request for user information to the appropriate server on your
network. For more information, see Completing group mapping
configuration, on page 2-25.
10. Click the Master mapping table tab.
The Master mapping table screen opens.
11. From the Mapping Method list, select the type of mapping table
entry you want to create, and click Add.
The master mapping table screen opens for the mapping method you
added.

Chapter 2
12. Specify the mappings you want, and then click Add.
The Master mapping table screen opens, showing the mapping you
added.
This is where you add master mapping entries. For more
information, see the section that describes configuring mappings
based on the method you are using. For example, if you are mapping
using the LDAP (user object) method, see To add the LDAP user
object mapping method, on page 2-33.
13. Click the Resource mapping table tab.
The Resource mapping table screen opens.
14. From Mapping Method, select the type of mapping table you want
to create, and then click Add.
The Resource mapping table screen opens for the mapping method
you added.
15. Specify the mappings you want, and then click Add.
The Resource mapping table screen opens, showing the mapping
you added.
This is where you add resource mapping entries. For more
information, see the section that describes mappings based on the
method you are using.
Specifying a group mapping method

You can define how the FirePass controller gets authentication information
from the associated server by specifying options and choosing settings when
configuring the mapping method.
The options and settings you configure depend on your external network
setup. The FirePass controller supports the following types of group
mapping configurations:
• Active Directory or Windows domain group mapping
For more information, see Mapping based on Active Directory or
Windows domain controllers, following.
• LDAP information mapping (user object, group object, or filter mapping)
For more information, see Mapping based on LDAP information, on
page 2-32.
• Client Certificate mapping
For more information, see Mapping based on client certificates, on page
2-38.
• RADIUS group mapping
For more information, see Mapping based on RADIUS groups, on page
2-40.
• Landing URI mapping
For more information, see Mapping based on landing URI, on page 2-43.
• Virtual Host mapping
For more information, see Mapping based on virtual hosts, on page 2-45.
2 - 26
• Session Variable mapping

For more information, see Mapping based on session variables, on page
2-47.
When you add a Windows Domain or Active Directory mapping, or any of
the three LDAP-based mappings, the system provides a link for configuring
the mapping method. You can read more about configuring mapping
methods in the procedure for each mapping type.
Note
A group’s authentication method and group mapping type do not have to

match, although they can and probably do.
Mapping based on Active Directory or Windows domain controllers

If your external network structure uses Active Directory or Windows
domain groups, you can use the FirePass controller group mapping function
to take advantage of that structure. The system provides a method for
mapping groups within an Active Directory to the FirePass controller master
groups. Use the Active Directory method with Windows 2000 and later
domain controllers. Use the Windows domain controllers method against
pre-Windows 2000 servers, or when you have a mix of Windows platforms
in your environment.
Within an Active Directory or Windows domain, there are usually a number
of groups defined, with users belonging to one or more of these groups. You
can map existing master and resource groups directly to these Active
Directory or Windows domain groups. When a user attempts to log on to the
FirePass controller, the domain queries your external Active Directory or
Windows domain groups to determine what groups contain the user. The
FirePass controller looks for matches in its dynamic group mapping
framework. When it finds a match, the FirePass controller authenticates the
user and allows access to the appropriate resources.
When mapping a user to one or more resource groups, the FirePass
controller attempts to match all domain groups against the configured
resource group mapping, and the user is assigned one or more resource
groups based on any matches.
Configuring Active Directory-based mapping

If you use Active Directory for your user database, you can configure the
FirePass controller to map users based on Active Directory groups.
Configuring Active Directory-based mapping involves three procedures:
adding the Active Directory mapping method, mapping the Active Directory
to the FirePass controller master groups in the master group mapping table,
and mapping the Active Directory to the FirePass controller resource groups
in the resource group mapping table.
To add the Active Directory mapping method


Chapter 2
master groups list.
6. From the mapping methods list, select Active Directory, and click
Add mapping method.
The new method is added to the table. If the table already contains a
mapping method of this type, the list contains no Active Directory
item.
7. Click the Configure link to the right of the entry in the Mapping
methods table.
The Mapping methods configuration screen opens.
8. In Domain name, type the domain name for the Active Directory to
use for mapping users.
You must use the Fully Qualified Domain Name (FQDN) in
Domain name. Domain name is a required parameter.
9. In Kerberos server name, type the Kerberos server name or IP
address.
Kerberos server name is an optional parameter.
10. In WINS server IP address, type the WINS server IP address.
WINS server IP address is an optional parameter.
11. In Domain admin name and Domain admin password, type a user
name and password that has Active Directory administrative
permissions.
Domain admin name and Domain admin password are required
parameters.
12. To use a second Active Directory server, check Use a secondary
AD server.
The screen changes to reveal additional options.
address.
15. To use a third Active Directory server, check Use a tertiary AD
server.
address.
2 - 28
18. To limit Active Directory group mapping to the user’s primary

domain, check Only use Active Directory primary group for
mapping.
19. To configure options for synchronizing the FirePass controller
database with the external Active Directory, check Synchronize
FirePass user database with Active Directory.
• From the Action list, select an option:
Deactivate FirePass account if user is not in Active Directory
or
Delete FirePass account if user is not in Active Directory
• Check Notify by e-mail to have the system inform the user of the
deactivation or deletion operation.
• In Check interval, specify the number of minutes to wait
between synchronization operations.
20. To update user information in internal FirePass controller database
records, check Update user information from Active Directory.
• Check Map first name to update the first name.
• Check Map last name to update the last name.
• Check Map e-mail to update the e-mail address.
• Check Allow user to edit personal information obtained from
Active Directory to allow the user edit access to Active
Directory information.
21. Click Update to save your settings.
Continue with the following procedure.
To configure the Active Directory mapping table

Complete the previous procedure before you start this one.
1. Click the Master group mapping table tab.
The Master group mapping table screen opens.
2. From the Mapping Methods list, select Active Directory, and click
Add.
Note: If there is no Active Directory item, click the Group mapping
methods tab, and add the Active Directory mapping method first.
3. In the box in the Active Directory Group column, specify the Active
Directory group you want to map.
4. From the list in the FirePass group column, select the group you
want to map to.
5. Click Add to save your mappings.

Chapter 2
Configure resource group mapping. You configure resource group mapping

on the Resource group mapping tab using the same procedures you followed
to configure master group mapping. See To add the Active Directory
mapping method, on page 2-27, and To configure the Active Directory
mapping table, preceding.
Note
Instead of specifying each Active Directory group individually, you can

have the system retrieve the external groups, but this method is
recommended if you have fewer than several hundred groups.
Configuring Windows domain-based mapping

You can use Windows domain-based authentication in two ways.
◆ Native NTLM
If you provide domain administrative credentials when configuring
Windows domain authentication, then the FirePass controller performs
authentication using native NTLM. You can use this method to add a
machine account for itself, join the domain, and create a one-way,
Windows NT 4.0-style, trust relationship with the Primary Domain
Controller (PDC).
◆ Basic
If you do not provide domain administrative credentials when
configuring Windows domain authentication, then the FirePass controller
authentication mechanism connects to the PDC’s netlogon share using
the user’s credentials, to determine whether the user has a valid account
within the domain.
If you use Windows domain for your user database, you can configure the
FirePass controller to map users based on Windows domain groups.
Configuring Windows domain-based mapping involves three procedures:
adding the Windows domain mapping method, mapping the Windows
domain groups to FirePass controller master groups in the master group
mapping table, and mapping the Windows domain groups to FirePass
controller resource groups in the resource group mapping table.
To add the Windows domain mapping method

master groups list.
2 - 30

6. From the mapping methods list, select Windows Domain, and click
Add mapping method.
mapping method of this type, the list contains no Windows Domain
item.
methods table.
8. In Domain name, type the domain name for the Windows domain
to use for mapping users.
You must use the Fully Qualified Domain Name (FQDN) in
Domain name. Domain name is a required parameter.
9. In PDC server name, type the name of the Primary Domain
Controller (PDC).
PDC server name is an optional parameter.
WINS server IP address is an optional parameter.
11. To have the FirePass controller join the Windows domain, check
Join Windows domain.
12. In Domain admin name and Domain admin password, type a user
name and password that has Windows domain administrative
permissions.
Domain admin name and Domain admin password are required
parameters.
To configure the Windows domain mapping table

2. From the Mapping Methods list, select Windows Domain, and
click Add.
Note: If there is no Windows Domain item, click the Group
mapping methods tab, and add the Windows Domain mapping
method first.
3. In the box within the Windows Domain Group column, specify the
Windows domain group you want to map.
want to map to.

Chapter 2

to configure master group mapping. See To add the Windows domain
mapping method, on page 2-30, and To configure the Windows domain
Note
Instead of specifying each Windows domain group individually, you can

have the system retrieve the external groups, but this method is
recommended if you have fewer than several hundred groups.
Mapping based on LDAP information

If your external network structure uses LDAP to store user information, you
can use the FirePass controller group mapping function to take advantage of
that structure. LDAP-based group mapping automatically synchronizes
changes on the LDAP server with group functionality on the FirePass
controller. For example, if you move a user to a different group on the
LDAP server, the FirePass controller automatically provides the user with
access to the new set of resources the next time the user logs on.
If you use a signup template for new FirePass controller users, group
mapping can also have the FirePass controller query the external server for
each user’s group membership, and automatically associate the user to the
mapped master and resource groups on the FirePass controller.
You can use LDAP in several ways.
• Mapping based on an LDAP user object attribute
For more information, see Mapping based on LDAP information from a
user object, following.
• Mapping based on the LDAP group object that describes the user's group
For more information, see Mapping based on LDAP information from a
group object, on page 2-34
• Mapping based on a filter you specify
For more information, see Mapping based on an LDAP filter, on page
2-36
You can use one, two, or all three modes simultaneously.
Important
In the request configuration, you can specify an LDAP port and configure
the FirePass controller to use SSL for the query operation. If you use LDAP
authentication over SSL, be sure that the host name you specify exactly
matches the host name on your LDAP server's certificate.
When you specify a query template for the request to use when searching for
a user, it must be a valid LDAP query expression.
2 - 32
Mapping based on LDAP information from a user object

If you have LDAP configurations that use a specific attribute as the unique
identifier for the user, you can configure group mapping based on that
attribute. For example, if your LDAP server uses an LDAP attribute called
userPrincipalName, you could specify that when you configure the
request.
Configuring LDAP user object-based mapping involves three procedures:
adding the LDAP user object mapping method, mapping the LDAP user
object to a FirePass controller master group in the master group mapping
table, and mapping the LDAP user object to a FirePass controller resource
group in the resource group mapping table.
To add the LDAP user object mapping method

master groups list.
6. From the mapping methods list, select LDAP (user object), and
mapping method of this type, the list contains no LDAP (user
object) item.
methods table.
8. In the LDAP server box, specify the user distinguished name (DN).
For example:
CN=Administrator,CN=Users,dc=eng,dc=net,dc=com
9. In the Query LDAP user object area, select the method you want the
FirePass controller to use to query the external LDAP server.
• If you select the Get user DN using template option, click
Update, and type the user’s entry in Template. For example,
cn=%logon%,dc=eng,dc=net,dc=com
• If you select the Get user DN using query option, click Update,
and specify the base DN in Search Base DN. For example:
CN=Users,dc=eng,dc=net,dc=com
And specify the search string in Query template. For example:
&(sAMAccountName=%logon%)

Chapter 2
You can use %logon% in the template to have the FirePass

controller insert the user’s logon name into the query. For example,
if you specify as the template
&(objectclass=person)(cn=%logon%), and the user’s name is
"george", at logon time the FirePass controller sends the actual
query: &(objectclass=person)(cn=george).
10. In the Fetch group information from LDAP user object area, define
the attributes to use to map the group. For example, memberOf.
You can use multiple attributes, each one on a separate line.
To configure the LDAP user object mapping table

2. From the Mapping Methods list, select LDAP (user object), and
click Add.
Note: If there is no LDAP (user object) item, click the Group
mapping methods tab, and add the LDAP mapping method first.
3. From Attribute, select the attribute you want to map to.
4. In the Attribute value column, specify the string for the FirePass
controller to use for mapping.
Note: You can instead map the LDAP user attribute directly to a
FirePass controller master group name by checking the Map
verbatim box. In this case, the group names must match exactly. In
this case, the FirePass controller removes the settings in the
Attribute value and FirePass Group columns.
want to map to the users returned by the filter expression.
Configuring resource group mapping.

You configure resource group mapping on the Resource group mapping tab
using the same procedures you followed to configure master group
mapping. See To add the LDAP user object mapping method, on page 2-33,
and To configure the LDAP user object mapping table, preceding.
Mapping based on LDAP information from a group object

If you have an LDAP configuration that uses a group object to organize
users, you can configure group mapping based on that structure. For
example, you can use the Administrative console to create new groups, or
you can use existing groups. Your configuration mechanism must have a
group object in your LDAP schema to use for mapping groups. The group
should have at least two multi-valued attributes for its members.
2 - 34
Configuring LDAP group object-based mapping involves three procedures:

adding the LDAP group object mapping method, mapping the LDAP group
object to a FirePass controller master group in the master group mapping
table, and mapping the LDAP group object to a FirePass controller resource
group in the resource group mapping table.
To add the LDAP group object mapping method

master groups list.
6. From the mapping methods list, select LDAP (group object), and
mapping method of this type, the list contains no LDAP (group
object) item.
methods table.
8. In the LDAP server box, specify the user DN. For example,
9. In the Fetch group information from LDAP group object area,
specify the attributes in the appropriate box.
• The Static members attribute relates to objects with
multi-valued membership attributes such as the attribute that
contains the list of the user’s DNs, for example, groupofNames,
groupofUniqueNames.
• The Dynamic members attribute determines membership by
executing an LDAP URL, for example, groupOfURLs, or an
LDAP query that specifies criteria for a group’s membership.
Note: There is no group object, as such. That is, the LDAP URL
exists only in the application that is using it.

Chapter 2
To configure the LDAP group object master group

mapping table
2. From the Mapping Methods list, select LDAP (group object), and
click Add.
Note: If there is no LDAP (group object) item, click the Group
mapping methods tab, and add the LDAP mapping method first.
3. In the LDAP group object DN column, type the group object
Distinguished Name (DN) you want to map from the LDAP group
to the FirePass controller group.
4. From FirePass group, select the group you want to map to the
specified LDAP group.

to configure master group mapping. See To add the LDAP group object
mapping method, on page 2-35, and To configure the LDAP group object
master group mapping table, preceding.
Mapping based on an LDAP filter

If you have discrete groups of users that you have configured with an
attribute other than the user attributes and you do not use a group object
implementation of LDAP, the LDAP filter option is the option to configure.
You can configure the mapping of LDAP groups based on results returned
by sending a query containing an LDAP filter.
Within a set of defined Windows domain groups, there are usually logical
divisions. For example, you may have a group whose users consist of
regular employees and consultants. The type and breadth of access allowed
for each division within the group usually varies. For example, you might
give regular employees access to internal human resources services, and
prevent consultants from having the same access. If your LDAP structure
matches this organization, you can accomplish this access division using
filters. In this case, you define the filter to map to a specific master group.
Configuring LDAP filter-based mapping involves three procedures: adding
the LDAP filter mapping method, mapping the LDAP filter to a FirePass
controller master group in the master group mapping table, and mapping the
LDAP filter to a FirePass controller resource group in the resource group
mapping table.
2 - 36
To add the LDAP filter mapping method

master groups list.
4. If you plan to use dynamic resource group mapping, check that
6. From the mapping methods list, select LDAP (filter), and click Add
mapping method.
mapping method of this type, the list contains no LDAP (filter)
item.
methods table.
8. In the LDAP server box, specify the fully qualified domain name
(FQDN) of the LDAP server.
9. In the LDAP port box, specify the port you want to use.
The default is 389 for an LDAP connection, and 636 for a secure
LDAP connection.
10. In the User DN box, specify the user DN. For example
To configure the LDAP filter master group mapping table

2. From the Mapping Methods list, select LDAP (filter), and click
Add.
Note: If there is no LDAP (filter) item, click the Group mapping
methods tab, and add the LDAP mapping method first.
3. In the first box in the LDAP filter column, type the filter you want
to use to define FirePass controller group membership.
You can use %logon% in the filter expression to have the FirePass
controller insert the user’s logon name into the query. For example,
if you specify as the template

Chapter 2
&(objectclass=person)(cn=%logon%), and the user’s name is

“george”, at logon time the FirePass controller sends the actual
query: &(objectclass=person)(cn=george).
4. From the list in the FirePass group column, select the FirePass
group you want to map to the users that the filter expression returns.
to configure master group mapping. See To add the LDAP filter mapping
method, on page 2-37, and To configure the LDAP filter master group
Most Active Directory objects use the cn property as their naming attribute.
Some objects, however, use a naming attribute other than cn. For example, a
domain controller uses the domainDNS property for the naming attribute,
and an organizational unit uses the organizationalUnit property for the
naming attribute. To avoid having to use a different naming attribute for
different object types, you should use the name property, which contains the
relative distinguished name of the object, to search for objects by name.
For example:
&(&(objectClass=user)(objectCategory=person))(|(name=Sales*)(name
=Marketing*))
Mapping based on client certificates

For users with client certificates, you can use the Organization (O) or
Organizational Unit (OU) attribute from the certificate’s issuer or subject
Distinguished Name (DN) to map the user to a FirePass controller master
group or to one or more resource groups.
It is also possible to use a substring of the issuer or subject DN to map the
user to a FirePass controller group. For example, a typical subject DN might
appear as follows:
/C=US/ST=CA/L=MyCity/O=MyCompany/OU=MyDept/CN=user/ema
ilAddress=user@company.xyz
For this case, you can specify L=MyCity to map MyCity to a particular
FirePass controller master or resource group.
Configuring client certificate-based mapping involves three procedures:
adding the Client Certificate mapping method, mapping a client certificate
attribute to a FirePass controller master group in the master group mapping
table, and mapping the client certificate attribute to a FirePass controller
resource group in the resource group mapping table.
Client certificate Organizational Unit group mapping

For client certificates that contain multiple organization unit (OU) attributes
in the subject or issuer Distinguished Name (DN), the FirePass controller
uses all OU attributes for client certificate dynamic group mapping in the
session. Additionally, the FirePass controller creates pre-logon session
variables for every OU attribute. For example, session.ssl.cert.ou0,
session.ssl.cert.ou1, and so on.
2 - 38
OU attributes are tested in order, from left to right, based on the order of
their appearance in the certificate subject or issuer DN field, from left to
right in the subject or issuer DN using normal group mapping prioritization.
All matches are used to select master group or resource groups.
To add the client certificate mapping method

master groups list.
6. From the mapping methods list, select Client Certificate, and click
Add mapping method.
mapping method of this type, the list contains no Client Certificate
item.
To configure the client certificate master group mapping

table
2. From the Mapping methods list, select Client Certificate, and then
click Add.
The associated Master group mapping table opens.
Note: If there is no Client Certificate item, click the Group mapping
methods tab, and add the client certificate mapping method first.
3. From the list in the Attribute column, select the certificate attribute
you want to use for mapping.
4. In the box in the Value column, specify the string for the FirePass
controller to map to.
Note: You can also map the user’s client certificate attribute
directly to a FirePass controller master group by checking the box
in the Map verbatim column. In this case, the FirePass controller
removes the Value and FirePass Group columns. For example, if
the box in Map verbatim is checked, and you select Subject

Chapter 2
Organizational Unit (OU), then the FirePass controller maps all

client certificates configured as OU=MyDept to the master group
named MyDept.
want to map to the associated users.
Next, configure resource group mapping. You configure resource group
mapping on the Resource group mapping tab using the same procedures you
followed to configure master group mapping. See To add the client
certificate mapping method, on page 2-39, and To configure the client
certificate master group mapping table, preceding.
Mapping based on RADIUS groups

You can map external RADIUS groups directly to existing master and
resource groups. Then, when a user logs on to the FirePass controller, the
FirePass controller queries the external RADIUS server to retrieve the list of
groups to which the user belongs. The FirePass controller attempts to match
the retrieved external RADIUS groups against the configured mapping.
The FirePass controller retrieves the external RADIUS group information
from an attribute returned from the RADIUS user profile. This attribute
contains the external RADIUS group list. The FirePass controller parses the
return value to retrieve the external group information in various formats.
If a match is found with a FirePass controller master group, the user is
dynamically moved to the corresponding FirePass controller master group.
The FirePass controller then authenticates the user according to the
authentication method configured for this dynamically assigned master
group.
If a match is found within a FirePass controller resource group, the user is
allowed access to its resources after being successfully authenticated in a
FirePass controller master group.
To configure group mapping based on RADIUS lookups

The Group mapping sequence screen appears.
3. From the Add mapping method list, select RADIUS and click the
Add mapping method button.
4. Click the Configure link to configure the RADIUS mapping
method.
The RADIUS settings screen appears.
5. In the RADIUS settings area, in the Timeout interval box, type the
number of seconds.
6. In the Retries box, type the number of retry attempts.
2 - 40
7. In the optional Service Type box, specify a service type.

The FirePass controller uses the Service Type value for the
RADIUS attribute Service Type (Attribute Number 6). This value
is inserted as the Service Type for all requests the FirePass
controller makes to the RADIUS Server. Service Type is an optional
setting and the default value for Service Type is Authenticate Only.
8. In the Primary RADIUS server area, in the Server box, type the
Server IP address.
9. In the UDP Port box, specify the UDP port.
10. In the Change Shared Secret box, specify the shared secret.
11. In the Group Information box, specify the attributes you want to
search for, and specify whether the attributes apply to a Single
Group or Multiple Groups. You can also create and test a regular
expression to gather the attributes you want.
12. If you wish, select the Use a backup RADIUS server check box
and enter the associated server, port, and shared secret information
to configure the backup RADIUS server.
13. If you wish, select the Use a tertiary RADIUS server check box
and enter the associated server, port, and shared secret information
to configure a tertiary RADIUS server.
14. Click Update to save your configuration.
Additional procedures for RADIUS group information

The FirePass controller retrieves the external RADIUS group information
from an attribute returned from the RADIUS user profile. This attribute
contains the external RADIUS group list, which the administrator maps to a
FirePass controller group. The FirePass controller then parses the return
value to retrieve the external group information in various formats. Options
in the Group Information section enable an administrator to specify any of
the RADIUS attributes to extract the external group information.
To parse for RADIUS-attribute-specific information

The Mapping Methods screen opens.
3. Next to RADIUS, click the Configure link to configure the
RADIUS mapping method.
The RADIUS settings screen opens.
4. To extract external group information, in the Radius attribute box,
type the IETF-assigned attribute number for the RADIUS attribute.
For example, type 25 for the Class attribute, 26 for the Vendor
Specific attribute (Vendor code for FirePass is 12276), or 11 for the
Filter-id attribute.

Chapter 2
5. Under Attribute contains, several options are available. Select the

option that best fits your configuration:
• Single group. Select this option to extract single group
information from the RADIUS attribute. In this case, the FirePass
controller extracts external group information from the attribute
value when the attribute does not contain KEY values.
• Single group. Format: KEY=VALUE1: Select this option to
extract group information from one RADIUS group. In this case,
the FirePass controller parses the value of selected RADIUS
attribute as KEY=VALUE; and considers VALUE as the external
group.
• Multiple groups. Format: KEY=VALUE1;KEY=VALUE2;:
Select this option to extract group information from multiple
RADIUS groups that are formatted in RADIUS as
Group1=eng;Group2=sales;Group3=acct, and so on.
In the Delimiter box, you can specify a delimiter other than the
default semi-colon ( ; ) to separate RADIUS attribute values.
• Multiple groups. Format: KEY=VALUE1;VALUE2;: Select
this option to extract group information from multiple RADIUS
groups that are formatted in RADIUS as Groups=eng;sales;acct,
and so on.
In the Delimiter box, you can specify a delimiter other than the
default semi-colon ( ; ) to separate RADIUS attribute values.
• Multiple groups,use regular expression to extract groups:
Select this option to extract group information from multiple
RADIUS groups using the Perl-style regular expression you
specify.
For example, if you have the value Group1;Group2;Group3; in
attribute 11, type 11 in RADIUS attribute and type /(.*)/ as the
regular expression.
To test a regular expression

The Mapping Methods screen opens.
3. Next to RADIUS, click the Configure link to configure the
RADIUS mapping method.
The RADIUS settings screen opens.
4. Click the Test regular expression link.
The test screen opens.
5. In the Regular expression box, type the string you want to test.
6. Click the Test button.
2 - 42
7. When the results are what you want, click the Finish button to
return to the Group Information section.
Mapping based on landing URI

A URI is a Uniform Resource Identifier. In the FirePass controller context,
URI means the fully-qualified domain name, followed by
/<uri-specific_path>. For URI-based customization, URIs are defined
inside of the FirePass controller. You can create customized FirePass
controller screens for different URIs. By configuring URI-based
customization, you can present a different look and feel depending on the
URI the user specifies when logging on. This is similar to mapping based on
virtual hosts.
Important
You cannot simultaneously use virtual-host based dynamic group mapping
and landing URI-based dynamic group mapping.
From a user standpoint, URI-based customization is maintained by a cookie.

Once a user establishes a session using a URI that gets customized, then all
subsequent FirePass controller sessions started in that browser use the same
customization, even if the user specifies the domain name alone (for
example, www.siterequest.com), or the domain name qualified by a
redirect site (for example, www.siterequest.com/my.logon.php3). To end
URI customization, the user must start a new browser session.
If you configure URI-based customization, you can use it as a basis for the
group mapping. In URI-based mapping, you map a customized URI to a
specific master group. Using URI-based mapping, you can map users to
different master groups or assign them to different resource groups based on
the landing URI used by the users to log on to the FirePass controller.
For example, a FirePass controller might have two landing URIs configured:
outlook and CRM. To support URI-based master group mapping, the
administrator creates two mappings in the Master group mapping table. To
support URI-based resource group mapping, the administrator creates two
mappings in the Resource group mapping table. Users who log on to
www.sitrerequest.com/outlook receive access to one set of master and
resource groups, which includes access to outlook. Users who log on to
www.siterequest.com/crm receive another set of master and resource
groups, which includes access to CRM.
To configure landing URI-based mapping, you complete four tasks:
• Adding the landing URI mapping method
• Specifying the landing URI
• Mapping the landing URI to a FirePass controller master group
• Mapping the landing URI to a FirePass controller resource group in the
resource group mapping table

Chapter 2
To add the landing URI mapping method

master groups list.
4. If you plan to have dynamic resource group mapping, check that
option in the Resource Groups Mapping Sequence area.
6. From the list, select Landing URI, and click Add mapping
method.
The Landing URI method is added to the table. Landing URI is not
an available selection in the list if this mapping method has already
been added.
To specify the landing URI

1. On the Group mapping methods screen, click the link Click to
configure landing URIs.
The Device Management : Customization screen opens with the
URI-based Customization tab active.
2. In the Create Landing URI box, type the URI you want to map.
The URI you specify must be alphanumeric and cannot contain
spaces. Type only the portion of the URI that follows the domain
name in the URL. For example, to create a URI consisting of
www.siterequest.com/partners, type partners in the box.
3. Click Apply.
The Configuring URIs screen opens.
4. Select and specify the settings you want, and click the Update
button corresponding to each configuration change that you make.
5. When you have finished, click the link Back to Users : Groups :
Dynamic Group Mapping page.
The Dynamic Group Mapping screen opens with the Group
mapping methods tab active.
2 - 44
To map the URI to a FirePass controller group

2. From the Mapping Methods list, select Landing URI, and click
Add.
Note: If there is no Landing URI item, click the Group mapping
methods tab, and add the Landing URI mapping method first.
3. From each list in the FirePass group column, select a group for
mapping to the URI.
Mapping the landing URI to a FirePass controller resource group

to configure master group mapping. See To add the landing URI mapping
method, on page 2-44, To specify the landing URI, preceding, and To map
the URI to a FirePass controller group, preceding.
Mapping based on virtual hosts

In the FirePass controller context, a virtual host means the domain name or
IP address that users specify when logging on to a web service you create on
a virtual IP address. When you want to organize users based on the virtual
host they are requesting, you can use virtual host information to dynamically
map users to a master group or resource group.
You can create customized screens for different virtual servers. By
configuring virtual host-based customization, you can present a different
look and feel depending on the virtual host address the user specifies when
logging on. This is similar to URI-based mapping.
Important
You cannot simultaneously use virtual-host based dynamic group mapping
and landing URI-based dynamic group mapping.
A virtual server can be one of the following things.

• An additional IP address that resolves to the FirePass controller, plus a
user web service within the FirePass controller, configured on that IP
address
• A distinct host name, configured on your DNS to resolve to the same IP
address
For virtual servers, you can define one customization for a single IP address.
URI-based customization takes precedence over virtual host customization.
Virtual host customization takes precedence over the default, global
customization.

Chapter 2
Configuring virtual host-based mapping involves three tasks: adding the

Virtual Host mapping method, mapping the virtual host to a FirePass
controller master group in the master group mapping table, and mapping the
URI to a FirePass controller resource group in the resource group mapping
table.
To add the virtual host mapping method

master groups list.
4. If you plan to have dynamic resource group mapping, check that
6. From the mapping methods list, select Virtual Host, and click Add
mapping method.
mapping method of this type, the list contains no Virtual Host item.
To map the virtual host to a FirePass controller group

2. From the Mapping Methods list, select Virtual Host, and click
Add.
Note: If there is no Virtual Host item, click the Group mapping
methods tab, and add the Virtual Host mapping method first.
mapping to the virtual host.

to configure master group mapping. See To add the virtual host mapping
method, on page 2-46, and To map the virtual host to a FirePass controller
group, preceding.
2 - 46
Mapping based on session variables

Creating dynamic group mapping with session variables is particularly
useful for mapping based on user information. You can use the following
types of the session variables for dynamic group mapping:
• System-provided and custom session variables defined during a
pre-logon sequence.
• Session variables defined by attributes received from external Active
Directory and LDAP servers during dynamic group mapping. The system
converts these attributes to session variables.
Because some session variables are defined after the FirePass controller
performs group mapping, you cannot use them. These include the following
types of session variables:
• Session variables defined by post-logon operations
• Session variables defined by attributes received from external Active
Directory and LDAP servers during the user-authentication process
Configuring session variable-based mapping involves three tasks: adding
the Session Variable mapping method, mapping the session variable to a
FirePass controller group in the master group mapping table, and mapping
the session variable to a FirePass controller resource group in the resource
group mapping table.
To add the Session Variable mapping method

master groups list.
6. From the mapping methods list, select Session Variable, and click
Add mapping method.
mapping method of this type, the list contains no Session Variable
item.
To map the session variable to a FirePass controller group


Chapter 2
2. From the Mapping Methods list, select Session Variable, and click
Add.
Note: If there is no Session Variable item, click the Group mapping
methods tab, and add the Session Variable mapping method first.
3. In the Session variable column, define the session variable you want
to map to, making sure to enclose the session variable within
percent ( % ) characters.
4. In the Value column, specify the string for the FirePass controller to
use for mapping.
Note: You can instead map the Session Variable value directly to a
FirePass controller master group name by checking the Map
verbatim box. In this case, the FirePass controller removes the
settings in the Value and FirePass Group columns.
mapping to the session variable.

to configure master group mapping. See To add the Session Variable
mapping method, on page 2-47, and To map the session variable to a
FirePass controller group, preceding.
Using enhanced session variables created from RADIUS attributes

Session variables can include storage of all RADIUS attributes, so that only
a single RADIUS request is made during authentication, and stored
attributes are efficiently reused for group resource mapping against the same
RADIUS server. To use this feature, from the FirePass Administrative
Console, click Users, click Session Variables, and click Add New Session
Variable.
Customizing landing URI or virtual host logon

In network environments that use multiple authentication realms, some of
them require an additional domain password. Associating each realm
(master group) with a particular landing URI allows selective display of an
additional domain password prompt.
Logon customization provides an extra domain password option for landing
URI or virtual host configurations, and a custom domain password prompt
for each landing URI or virtual host.
To configure this feature on the Global Settings screen, in the navigation
pane click Users and click Global Settings. Select the options for the
landing URI or virtual host in the Additional Domain Password area.
2 - 48
From the For Landing URI or Virtual Host list, you can select the URI or
virtual host to configure. The list contains all the configured landing URIs
and virtual hosts, and the default URI value (which applies when no landing
URI or virtual host is selected during the logon process). To appear on the
list, a landing URI must first be created on the Device Management :
Customization screen, with the option Virtual Host must have host based
customization enabled.
Note
When no landing URIs exist and no Virtual Hosts are enabled, only the
default URI selector is available.
The available customization options are as follows:

• Select Use extra domain password for single sign on to enable the
password for the selected URI or virtual host. When this option is
disabled, no other options appear in this section.
• Select Cache the password between sessions to enable the password
to be cached between settings. This option appears only if the option
Use extra domain password for single sign on is selected.
• In the Extra domain password prompt box, type the password
prompt for the extra domain password. For example, type Domain
Password? This option appears only if the option Use extra domain
password for single sign on is selected.
Note
When an administrator upgrades the FirePass controller from a previous

FirePass software version that has only global options available, the new
FirePass software copies those global options into all the landing URIs and
virtual hosts, including those that were deleted or disabled. After the
upgrade, an administrator can enable or disable and change the prompt for
each URI or virtual host individually.
Using URI landing and VHOST settings during logon

The system uses URI landing and VHOST settings during logon in different
ways:
• If the user logs on through the landing URI, the FirePass controller uses
the settings for the landing URI.
• If the user logs on through a virtual host, the FirePass controller uses the
settings for the virtual host.
• If the user logs on in another way, the FirePass controller uses the default
URI settings.

Chapter 2
For example, when a user logs on to https://vhost/uri, the FirePass

controller uses the URI settings.
Tip
If the administrator does not specify an extra domain password, the logon
screen displays the domain password prompt.
When a user fails to authenticate during logon through any URI or virtual
host, the FirePass controller returns the user to the initial Landing URI or
virtual host logon screen.
On the Master Group authentication tab, the screen displays the Verify
domain password against Active Directory server option only when
Extra domain password is enabled for the default URI, or another enabled
landing URI or virtual host.
When a user accesses the logon screen without the domain password prompt
and is mapped to a group where verification of that password is required,
authentication fails. This also happens when domain password is disabled
everywhere, but a group has the Verification option enabled. In this case,
you can find the reason for the authentication failure in the Logon Report
details.
For logon screen customization on a per URI/VHOST basis, the
configuration setting is stored in the file
/usr/local/uroam/firepass/images/custom/$subdir/uroam.conf
where $subdir is either the landing URI name or the virtual host IP address.
Default URI settings are stored in the file
/usr/local/uroam/etc/uroam.conf
Using global settings

You can specify global settings for certain user options. You can find these
global options on the Users : Global Settings screen.
◆ Allow to login with e-mail address as substitute of user name
Indicates that the system accepts an email address instead of a user name.
This is useful when your existing infrastructure relies on email addresses
as the primary user identifier.
◆ Treat user’s logon name as case-sensitive
This option applies to users who are configured in the local FirePass
database. When the FirePass controller performs external authentication
or dynamic group mapping based on external servers, the FirePass
controller sends the user names to the servers in the exact case that is
stored in the local user database. When the option Treat user’s logon
name as case-sensitive is enabled, the FirePass controller sends user
names to external servers in the case in which they are entered by the
user on the logon screen.
This case-sensitive option has no effect on External users because the
FirePass controller does not store their user names in the local database;
external user names are always sent to external servers in the case
entered by the user on the logon screen.
2 - 50
◆ Display extra input field at logon for user defined session variable
On the logon screen, presents the user with a box in which to type text.
This value is then converted to a session variable named
%session.userdef.logon_extra_field%. You can specify a label to help
the user know what to type in the box.
For example, you can map users to different master groups by specifying
the label Type your master group name in the following box, and then
mapping the session variable %session.userdef.logon_extra_field% to
that master group in the master mapping table. For a procedure to guide
you through this process, see the online help for the Users : Global
Settings screen.
◆ Specifying an additional domain password
Indicates that the system provides a second password prompt on the
logon screen. The FirePass controller passes the content of this prompt to
the functions that enable access to Windows Files, Web Applications,
Terminal Servers, and so on. If this option is disabled, the system
presents only one password prompt on the logon screen.
Customizing domain and password order

In addition to standard credential entry prompts (Username and Password),
the FirePass controller logon screen can also display an additional file
prompt, and a user-defined session variable prompt (also known as Domain,
although the prompt is customizable). One or both of these prompts can be
enabled.
Users normally enter credentials in this order:
Username
Password
Domain Password
Domain
In configurations using a primary authentication method for the Password
setting, there is also a time-sensitive, token-based, one-time password (OTP)
condition, such as RSA or RADIUS. The situation frequently arises where
the one time OTP entered by the user expires by the time the user types the
domain password, and the domain, if required, and then clicks the logon
button. In this case, you can specify a revised order for credentials:
Username
Domain
Domain Password
Password
When a user enters the password last, the chance of OTP expiration is
reduced.
Use the Users : Global Settings screen’s password option Display password
input field last on logon page to change the logon password order.

Chapter 2
Setting and changing mapping priority

The group mapping functionality maps users to one master group. If you
have users who belong to more than one group in your network structure,
the mapping functionality can map to only the first match it finds, as
determined by the order of mappings in the master mapping table.
Therefore, the order of mappings might impact the authentication and access
that the user receives.
For example, OneUser belongs to two groups: Sales and Marketing, both of
which are configured for dynamic group mapping. In the master mapping
table, the mapping for Marketing occupies the top slot, Priority 1, and Sales
occupies Priority 2. In this case, at logon time, the FirePass controller maps
OneUser to Marketing because that group’s priority is higher.
Initially, the order in which you create mappings determines the order in
which the FirePass controller checks for matches. That is, the FirePass
controller compares users with the first mapping you create, then the second,
and so on.
However, you can also specify the order on the master mapping table,
available from the Users : Groups : Dynamic Group Mapping screen. You
can set priority on the Master group mapping table screen to change the
order of the mappings in the group mapping process.
Customizing virtual host and URI

For virtual host and URI-based customization, you can customize the
FirePass controller’s screens separately for different virtual servers and
different URIs.
A URI is a Universal Resource Indicator. In this context, it means the
fully-qualified domain name, followed by /<uriname>. For URI-based
customization, URIs are defined inside the FirePass controller.
For both virtual servers and URIs, you can separately customize images,
colors, and the company name.
For virtual servers, you can define one distinct customization for a single IP
address. All virtual hosts sharing that IP will also share the same
customization.
Understanding precedence
URI-based customization takes precedence over virtual host customization.
Virtual host customization takes precedence over the default, global
customization.
From a user standpoint, URI-based customization is sticky. It is maintained
by a cookie. This means that once a user has established a session using
URI-based customization, then all subsequent FirePass controller sessions
started from within the same browser session use the URI-based
customization, even if the user later enters either the domain name alone (for
example, www.siterequest.com), or even the domain name qualified by the
usual redirect screen (for example, www.siterequest.com/my.logon.php3).
2 - 52
Once the user has established a URI-based custom session, then the user
must start a new browser session to switch back to the global customization
(or a virtual host-based customization, if there is one). This is by design.
To create a new URI

1. In the navigation pane, click Device Management, and click
Customization.
2. Click the URI-Based Customization tab.
The Landing URIs screen opens.
3. In the Create Landing URI box, type the name you want to use.
This name must be alphanumeric, with no spaces. Type only the
portion of the URI that follows the domain name in the URL.
For example, to create the URI www.siterequest.com/partners,
type partners in the box.
4. Click Apply.
To customize the appearance of user screens based on a

distinct URI
1. In the navigation pane, click Device Management, and click
Customization.
2. Click the URI-Based Customization tab.
The Landing URIs screen appears.
3. Next to the landing URI you want to edit, click Edit.
4. Click the Enable host-based customization check box.
The customization boxes appear.
5. Click the Update button corresponding to each change you make.
Using WebDAV for advanced customization

You can customize some aspects of the FirePass controller’s user screens
using a WebDAV-based client.
To enable WebDAV based customization

1. Navigate to the Device Management : Configuration : Network
Configuration : Web Services screen and create an HTTP web
service.
2. On the Device Management : Security : User Access Security
screen, select the Allow insecure access option.
3. Navigate to the Device Management : Customization screen, check
Allow WebDAV sandbox customization, and type a WebDAV
password in the text box that appears.

Chapter 2
You access the WebDAV sandbox using HTTP at the URI /sandbox as the
user webdav. For example, if you configured the FirePass controller with a
HTTP web service at 192.168.0.99, you access the WebDAV sandbox at the
URL http://192.168.0.99/sandbox/.
Using sandbox files

You can place any content in the sandbox directory. The FirePass controller
uses specific files to override or supplement stock system behavior.
index.htm: Represents content that appears when a user requests the root
URI (/). Typically the user is redirected to /my.logon.php3, to which the
customized screen may provide a link.
blocked_popups_warning.htm: This screen presents a warning to a user
when a popup window is blocked by the browser. The content should
describe how to disable the popup blocker, or allow the popup. For example,
“Follow your browser’s instructions to allow the popup window.” To
improve the user experience, we recommend that you add the following
HTML code:
<a href="#" onclick="retry(false);"><B>Click here to restart the
pop-up window.</B></a>
This code allows the user to retry the popup window after taking action to
allow the popup.
customfoot.inc: Represents content that serves as the common footer
information that appears at the bottom of the user logon screen.
exception.inc: This screen provides a custom error message to a user when
a web page is denied, or when a web portal cannot load. You can use the
following variables in the exception.inc file:
• %F5_MSG_TITLE% - replaces this variable with the title of the error
message
• %F5_MSG% - replaces this variable with the text of the error message
• %F5_URL% - replaces this variable with the URL that caused the error
For example, here is a simple HTML file for exception.inc:
<HTML>
<BODY>
<H1>Custom error page</H1>
<H3> %F5_MSG_TITLE% </H3>
<P>Error message: %F5_MSG%</P>
<P>URL: %F5_URL%</P>
</BODY>
</HTML>
right.inc: Represents content that appears to the right of the user logon
prompt on the logon screen.
links.inc: Represents content that appears immediately below the user logon
prompt and replaces the set of default links displayed under the title Need
Help.
2 - 54
links.pocket.inc: Represents content that is the same as the links.inc file,

but appears for PocketPC clients.
lockoutmsg.inc: Represents content that is displayed to users attempting to
log on while the administrator has the Lockout New User Sessions option
enabled under the Device Management : Maintenance : User Session
Lockout screen.
logon.denied.inc: Directs the user to the logon denied screen when he fails
a pre-logon sequence check; for example, the user does not have the
required antivirus software or firewall.
logon.failed.inc: Directs the user to a failed logon screen when the user
enters incorrect credentials or cannot authenticate on the external server.
This screen can contain a logon form that allows the user to log on again.
logout.inc: Represents content that is displayed to users upon log off or
session termination.
resetpass.inc: Represents content that appears in response to a click on the
Forgot Password? link when the user’s password is not maintained in the
FirePass controller database (for example, on an external LDAP server
instead). The presence of the Forgot Password? link is governed by
settings in User Password Recovery under Security in the Device
Management section.
The FirePass controller maps all content in the sandbox directory to a virtual
folder, /sandbox, that the FirePass controller can access from all web
services. Content added to the files listed above can reference other files in
the sandbox directory. For example, the FirePass controller sandbox
directory may store a necessary security download, that may then be
referenced from other customized content. For sample implementation text
that provides portal access, see Creating a portal access sample screen, on
page 2-58.
Managing multiple destinations

In addition to customizing portal screens, you can present unique content for
multiple virtual hosts or URIs by creating corresponding folders containing
the custom content you want to use. For example, to customize the password
recovery screen for a previously configured landing URI company1, create
the file company1/resetpass.inc in the sandbox directory. The presence of a
virtual host or URI customization overrides any corresponding global
sandbox customization.
Note
To customize virtual hosts, you must create subdirectories of the WebDAV

directories named the same as the virtual host's IP addresses.

Chapter 2
Understanding how to use logon screen customization

You can use logon screen customization to create logon screens that provide
several different features.
Customize the user logon page: You can customize the logon screen with
several customization files, to provide the FirePass controller users with a
richer experience. You can add content to provide instructions for logging
in, links to external content, and so on.
Provide a portal page: You can make a customized portal screen using the
sandbox that is directly accessible. The system can direct users to a screen
containing instructions, external links, JavaScript for launching FirePass
controller favorites, and so on.
Provide a default webtop: Users see the webtop screen once they log in,
and you can configure this screen in the sandbox. You should reference
screens in this manner, using absolute URLs. For example, you can direct
users to a screen at https://firepass.company.xyz/sandbox/portal.htm.
The content you place on a default webtop screen can offer instructions or
an SSL VPN start link (using JavaScript), or automatically start an SSL
VPN connection (again using JavaScript). For sample implementation text
that provides portal access, see Creating a portal access sample screen, on
page 2-58.
Creating an index.htm file

You should include specific tags when you create the index.htm screen. For
example, the FirePass controller detects JavaScript support in a client
browser using a POST parameter called tzoffsetmin. If the index does not
include this code, the open in new window button in web applications and
for the network access screens does not appear.
Remember to check the following parameters.
• Vhost input should be specified just once.
• uRoamTestCookie should be specified as a form input parameter.
If the parameter uRoamTestCookie is missing in POST, this omission
forces the webtop to act as if the client is in cookieless mode. In this
mode, the webtop displays the system warnings Your browser has
disabled cookies, and the session ID is visible in the browser’s URL
navigation bar.
Example index.htm file

The following example is a simple logon screen for the FirePass controller:
<pre>
<html>
<head>
<script type="text/javascript">
function OnLoad() {
var form = document.forms[0];
if (form == null) return;
2 - 56
try
{
// URI and IP-host customization support
var allcookies = document.cookie;
var pos = allcookies.indexOf("VHOST=");
if (pos != -1)
{
var start = pos + 6; // Start of cookie
value, 6 = length of 'VHOST='
var end = allcookies.indexOf(";", start); // End of cookie value
if (end == -1) end = allcookies.length;
var vhostvalue = allcookies.substring(start, end); // Extract the value
vhostvalue = unescape(vhostvalue); // Decode it
document.forms[0].vhost.value = vhostvalue; // Assign VHOST cookie
value to coresponding form field
}
// Client JavaScript support

form.tzoffsetmin.value = 1;
}
catch (e)
{
}
}
</script>
</head>
<body onload="OnLoad();">
<form name="e1" method="post" action="/my.activation.php3">
Customized logon form<BR>

<input type=hidden name="vhost" value="standard">
Username:<br>
<input type=text size="13" name="username" value="" autocomplete="off">
<br>
Password:<br>
<input type="password" size="13" name="password"
autocomplete="off"><br>
<input name="login" type="submit" value="Logon">
<input type="hidden" name="mrhlogonform" value="1">

<input type="hidden" name="tzoffsetmin" value="">
<input type="hidden" name="uRoamTestCookie" value="TEST">

Chapter 2
</form>
</body>
</html>
</pre>
Creating a portal access sample screen

You can present your users with a customized portal access screen by
providing a file in the /sandbox directory. To read more about the /sandbox
directory, Using sandbox files, on page 2-54.
To prepare the portal access screen for deployment

1. Copy the text sample following, including the beginning and ending
<html> tags, and paste it into a text editor.
2. Save it as text-only with .html as the file extension.
3. Replace NAME_OF_RESOURCE_GROUP with the name of a
resource group you have defined.
4. Replace FAVORITE_NAME with the text you want the user to
click.
5. Replace parameters in the box createDirectAppTunnelConnection
with appropriate values.
After the content matches what you want the user to see, you must make it
available in the /sandbox directory, as described in Using sandbox files, on
page 2-54, and Managing multiple destinations, on page 2-55.
This sample content may also be hosted on an internal intranet web server.
You must then access the screen through Web Applications or set the screen
with this content as your Intranet Webtop. It will then be possible to start
FirePass controller favorites directly from your Intranet server. It is also
possible for you to have the system dynamically insert portions of the
following code into intranet screens through use of Web Applications
Content Processing Scripts. For example, you could use this capability to
dynamically start an App Tunnel to support a difficult intranet ActiveX
control which might not normally work through Web Applications.
Use the special tags <FP_DO_NOT_TOUCH> and
</FP_DO_NOT_TOUCH>, as shown in the example below, to prevent the
FirePass controller Web Applications engine from re-writing the links and
JavaScript between the tags. You control the processing of these tags using
the option Process content of the FP_DO_NOT_TOUCH element. To
view this option, navigate to the Portal Access : Web Applications : Content
Processing screen, and select the Global Settings tab. Scroll to the Web
Applications Global Settings area.
In the following sample text, the lines preceded by two slashes (//) indicate
comments in which descriptive text occurs.
<html>
<head>
<title>An example for launching FirePass controller favorites</title>
</head>
2 - 58
<body>
<FP_DO_NOT_TOUCH>
<script>
// Replace NAME_OF_RESOURCE_GROUP with name from one of your configured resource groups.
// Replace FAVORITE_NAME with the text you want your user to see.
// support function that creates a new window

function createNewWindow(url,params,bNewWindow) {
dimension= "WIDTH=802, HEIGHT=626";
if(dimension > 10 && dimension <= 100) { //screen percentage
perc = dimension;
dimension = "WIDTH=802,HEIGHT=626";
if (parseInt(navigator.appVersion)>3) {
screenW = screen.width;
screenH = screen.height;
screenW = Math.round(screenW/100*perc);
screenH = Math.round(screenH/100*perc);
dimension = "WIDTH="+(screenW+2)+",HEIGHT="+(screenH+26);
params = params+"&width="+(screenW+2)+"&height="+screenH;
}
}
if(bNewWindow) {
params = params+"&bNewWindow=1";
window.open(url+params,"_blank",dimension+",status=no,toolbar=no,menubar=no,location=n
o");
} else {
window.open(url+params,"_self");
}
}
// create the AppTunnel Connection

// params:
// res_group: Represents the resource group.
// fav_name: Represents the name of the favorite in the resource group.
function createAppTunnelConnection(res_group, fav_name) {
var w_name = name+(Math.random()).toString().substring(2,16);
var params = "res_group="+res_group+"&res_name="+fav_name;
childWindow = window.open('/vdesk/geekster/connection.php3?'+params, w_name,

Chapter 2
'name='+w_name+',resizable=0,scrollbars=0,statusbar=0,menubar=0,width=320,height=240')
;
}
// create a direct AppTunnel Connection

// rhost0: Represents remote host to connect to (name or IP address)
// rport0: Represents remote port to connect to (port number)
// lhost0: Represents a local 127.x address for the AppTunnel connection
// lport0: Represents local port to connect o (port number)
// cmd0: Optional command to be run when AppTunnel starts
// dont_warn: Set to 1 if you do not want a warning dialog show about starting the
optional command
function createDirectAppTunnelConnection(rhost0, rport0, lhost0, lport0, cmd0, dont_warn)
{
var w_name = (Math.random()).toString().substring(2,16);
var params =
"rhost0="+rhost0+"&rport0="+rport0+"&lhost0="+lhost0+"&lport0="+lport0+"&cmd0="+cmd0+"
&dont_warn="+dont_warn;
childWindow = window.open('/vdesk/geekster/connection.php3?'+params, w_name,
;
}
//create Dynamic Web Application Tunnel Connection

//paras:
//res_group: Represents the resource group.
//fav_name: Represents the name of the favorite in the resource group.
function createDYNConnection(res_group, fav_name)
{
var w_name = 'DYNAMIC_TUNNELS'+(Math.random()).toString().substring(2,16);
childWindow = window.open('/vdesk/portfw/connection.php3?'+params, w_name,
'name='+w_name+',resizable=1,scrollbars=1,statusbar=1,menubar=1,width=1320,hei
ght=1240');
}
// create SSL VPN Connection

// params:
function createVPNConnection(res_group, fav_name) {
var w_name = 'VPN_CONNECTION'+(Math.random()).toString().substring(2,16);
childWindow = window.open('/vdesk/vpn/connect.php3?'+params, w_name,
2 - 60
;
childWindow.focus();
}
// create Terminal Services Connection

// params:
function createTSConnection(res_group, fav_name, bNewWindow) {
createNewWindow("/vdesk/terminal/index.php3?",params,bNewWindow);
}
</script>
<table border="0" width="100%">

<tbody>
<tr>
<td>
<div align="center"><small><font size="5">An example for launching FirePass
controller favorites</font></div><br>
</td>
</tr>
<tr>
<td>
<table style="width: 100%;" border="0" cellpadding="4" cellspacing="4">
<tbody>
<tr>
<td>
<p style="text-align: center;"><strong><font size="3">
<a
href='javascript:createVPNConnection("NAME_OF_RESOURCE_GROUP","FAVORITE_NAME")'>SSL
VPN</a>
</font></strong></p>
<p>This connection is for use from company-issued laptops and home
computers. This link connects you to the corporate network. You
will have access to all of the resources you would typically have
available when you are connected to the company network.</p>
</td>
</tr>
<tr>
<td>

Chapter 2
<a
href='javascript:createAppTunnelConnection("NAME_OF_RESOURCE_GROUP","FAVORITE_NAME")'>
App Tunnel</a>
<p>This link connects you to office resources from a computer on an external
site
such as at an internet cafe or a client location. You will not need to
download
or install any software.</p>
</td>
</tr>
<tr>
<td>
<a
href='javascript:createTSConnection("NAME_OF_RESOURCE_GROUP","FAVORITE_NAME",false)'>T
erminal Services</a>
<p>This link connects you to your terminal services applications.</p>
</td>
</tr>
<tr>
<td>
<a
href=/vdesk/intranets/provision.php3?res_group=NAME_OF_RESOURCE_GROUP&res_name=FAVORIT
E_NAME>Web Applications</a>
<p>This link opens a portal page through Web Applications.</p>
</td>
</tr>
<tr>
<td>
<a
href='javascript:createDirectAppTunnelConnection("telnetserver.company.xyz", 23,
"127.173.191.252", 23, "telnet 127.173.191.252", 1)'>Direct App Tunnel</a>
<p>This link opens a direct AppTunnel connection (by passing parameters). The
<b>Limit AppTunnels Access
to Favorites only</b> option must be disabled.</p>
</td>
</tr>
<tr>
</tbody>
</table>
2 - 62
</td>
</tr>
</tbody>
</table>
</FP_DO_NOT_TOUCH>
</body>
</html>
<html>



<FP_DO_NOT_TOUCH>
<frameset cols="200,*">
<frame name="contents" target="main"
src="/vdesk/filemanager/directory.php3?dir=%5C%5Ccompany_server%5Cpublic%5C"
marginwidth=10 marginheight=10>
<frame name="main" src="/vdesk/filemanager/view.php3" marginwidth=10 marginheight=10>
</frameset>
</FP_DO_NOT_TOUCH>
Customizing error screens with WebDAV

Using WebDAV you can customize the error screens that are displayed
when a user would normally see an access denied screen through the Portal
Access setup for virtual and URI-based hosts.
The file exception.inc can be added using WebDAV.
Before FirePass controller loads the exception.inc screen, it replaces the
following variables with the actual strings from the FirePass controller:
• The variable %F5_MSG_TITLE% is replaced with the title of the error
message.
• The variable %F5_MSG% is replaced with the text of the error
message.
• The variable %F5_URL% is replaced with the referring URL of the
error message.
To create a customized error message, you upload a customized version of
the file exception.inc to the FirePass controller’s WebDAV sandbox. A user
who is denied access to a site then sees the customized error screen when the
error occurs.
Note
You can use any software that supports the WebDAV protocol.

Chapter 2
Using dynamic resource group mapping in master groups

You can enhance the flexibility of user authorization by implementing
dynamic resource group mapping on the master group level in the FirePass
controller. In addition to global dynamic master and resource group
mapping, you can also configure dynamic resource mapping separately for
each master group. This configuration is an additional phase that follows
authentication and allows you to authorize users against multiple sources of
the same type. In this way, each master group can dynamically map
resources using its own combination of Active Directory, LDAP, Windows
Domain, or RADIUS mapping methods.
You configure Resource Group Mapping from the Users : Groups :
Dynamic Group Mapping screen, as shown in Figure 2.4.
Figure 2.4 Dynamic resource group mapping
You can enable the option Determine the user’s master groups
dynamically using resource group mapping table in user’s master
group to globally enable or disable resource group mapping that is
configured individually in the master groups. When this option is disabled,
this resource group mapping step is not performed even if it is configured in
master groups.
Additionally, on the Users : Groups : Master Groups screen for a selected
master group, you can enable the option Allow resource groups to be
assigned using dynamic group mapping configured in this master
group, as shown in Figure 2.5.
2 - 64
Figure 2.5 Dynamic resource group mapping in a master groups
This option allows you to enable or disable resource group mapping

configured in this master group. When the global option described in the
previous section is disabled, this option is likewise disabled, and cannot be
enabled from this screen.
Understanding dynamic resource group mapping methods

You can use the Mapping methods screen on the Users : Groups : Master
Groups screen, on the Mapping methods tab, to access options for adding
and configuring dynamic group mapping methods for a selected master
group. The same mapping methods are available for master group mapping
as are available for global resource mapping. You can assign multiple
mapping methods to a master group, although only one method of each type
is allowed for each group. For example, you can assign only one Active
Directory mapping method to a single group, but you can assign an
additional mapping methods, such as Windows Domain, RADIUS, and
Client Certificate methods, in addition to the Active Directory method.
After you add mapping methods, you click Configure to display the
configuration screen for the selected mapping method. The options available
on the configuration screen are method-specific, and consistent with most of
the options available from the global group mapping configuration screen.
The exceptions are options related to user database synchronization and
options related to updating of user information. These options are not
available from the Resource group mapping methods screen.
You can select the option Use settings from Active Directory
authentication to allow the resource group and the Active Directory
authentication method to share configuration settings. You can enable this
option to duplicate the settings from the authentication tab, and disable
editing. If you enable this option, any previous settings for this mapping
method are overwritten when this option is enabled. Any subsequent
updates to the Active Directory authentication configuration also updates
the related group mapping method settings.

Chapter 2
Using the dynamic resource group mapping table

You can access the Resource Group Mapping Table screen on the Users :
Groups : Master Groups screen, on the Mapping Table tab. The mapping
table provides options for configuring dynamic resource group mapping for
a selected master group. This screen provides the same capabilities as the
global group mapping table configuration screen.
On the Resource Group Mapping Table screen, you can select and add
mapping methods from a list that includes all resource groups that are
configured for the selected master group on the Resource Group Mapping
Methods screen for the user.
Using session variables with master group mapping

The FirePass controller creates session variables during master group-based
dynamic resource group mapping. These session variables are similar to the
session variables created during global group mapping based on user record
attributes retrieved from Active Directory or LDAP.
This is an example of the session variables created during global mapping:
%session.ad.groupmapping.cn%
%session.ad.groupmapping.displayname%
...
%session.ldap.groupmapping.cn%
%session.ldap.groupmapping.employeeid%
new session variables created during master group based mapping:
%session.ad.groupresourcemapping.cn%
%session.ad.groupresourcemapping.displayname%
...
%session.ldap.groupresourcemapping.cn%
%session.ldap.groupresourcemapping.employeeid%
2 - 66
Setting up authentication
Authentication is the process of verifying the identity of a user logging on
to a network. In a typical authentication process, a system requires that users
provide logon information such as user name and password. The system
then checks those credentials against information maintained remotely or
locally on a server or in a database.
Note
The stringent nature of the authentication mechanism you use for the
FirePass controller should match your local network. That is, you should
use equally high standards for the FirePass controller authentication as you
do for your local network.
The FirePass controller uses master groups to determine authentication

parameters, so you set up authentication when you create master groups.
You can authenticate users using FirePass controller internal groups, or you
can use an external server. To determine which authentication method is
right for your setup, see Managing user information in an external data
store, on page 2-6 or Managing users in the FirePass controller data store,
on page 2-8.
Authentication (tasks that ensure that users are who they claim to be), and
authorization (tasks that enable access to resources, applications, and
network shares) are two separate processes on the FirePass controller.
Choosing an authentication method

You specify an authentication method when you create your master groups.
You can also change an authentication method from one type to another.
You can select from several structures for maintaining users for
authentication.
◆ If you plan to use local authentication using the same method for all
users, you can simply add all users to the FirePass controller default
master group and set up the authentication you want for the default
group.
◆ If you plan to use external authentication using the same method for all
users, F5 Networks recommends that you create a new master group with
external user maintenance. In this case, you do not need to add users to
the FirePass controller at all. Because the default master group is
configured for internal users, you must create a new master group in
order to maintain users externally.
◆ If you want to use different authentication for different users, you must
create separate master groups on the FirePass controller.

Chapter 2
To specify the authentication method for a group

1. In the navigation pane, click Users, expand Groups, and then click
Master Groups.
3. In New group name, type the name you want for the group.
You can use up to 48 alphanumeric characters, as well as underscore
( _ ), hyphen ( - ), and period ( . ), and the first character must be
alphanumeric.
4. From Users in group, select Local to maintain users in the FirePass
controller database, or External, to have the users authenticated
from your external network server.
5. From Authentication method, select the authentication method you
want. For more information on the available authentication
methods, see Determining the authentication method, following.
6. Click Create after selecting any other options you want for the
group.
For more information on creating master groups, see Configuring a master

group, on page 2-11.
Determining the authentication method

You can set up FirePass controller authentication using any combination of
the following methods for different master groups. Each master group uses
one authentication method.
Important
To use a specific authentication method, you must have a server at your site
that supports the method.
The FirePass controller supports these authentication methods.

◆ FirePass controller’s internal authentication
Uses the internal FirePass controller authentication method for storing
the logon credentials, email, group, and mail server. Internal
authentication does not require any other configuration. You must assign
each user a password, which the users can then change from their
webtops. The FirePass controller stores a hash of user passwords. For
more information on this method, see Managing users in the FirePass
◆ RADIUS server
Uses the server at your site that supports authentication using the
RADIUS protocol. If you want to use RSA SecurID over RADIUS
protocol, use this method. If you want to use RSA SecurID over its
2 - 68
native protocol, use the RSA SecurID method instead. For more
information on this method, see Setting up RADIUS server
◆ LDAP server
Uses the server at your site that supports authentication using LDAP. For
more information on this method, see Setting up LDAP server
◆ Basic HTTP authentication to external server
Uses external, web-based authentication servers such as Oracle®
COREid®, eTrust™ SiteMinder®, and others to validate user logons and
passwords, and to control user access to specific network resources. For
more information on this method, see Setting up HTTP basic
authentication to external server, on page 2-81.
◆ Initial signup on LDAP with subsequent strong password
Authenticates first-time users against an LDAP directory, but at the first
use also presents a form to require them to entry a strong password.
Subsequently, the user is authenticated using the internal FirePass
controller database. This method allows you to use strong passwords not
supported by your LDAP directory, while providing most of the
convenience of LDAP authentication. For more information on this
method, see Setting up initial signup on LDAP with subsequent strong
internal password, on page 2-81.
◆ Windows domain server
Uses the Windows domain server at your site that supports NTLM
authentication against a pre-Windows 2000 domain controller. For more
information on this method, see Setting up Windows domain server
◆ Windows Active Directory
Uses the server at your site that supports Kerberos authentication against
a Windows 2000 or later server. For more information on this method,
see Setting up Active Directory authentication (Kerberos authentication),
on page 2-82.
◆ HTTP form-based
Integrates with single sign-on systems such as Oracle COREid, and
eTrust SiteMinder. For more information on this method, see Setting up
HTTP form-based authentication, on page 2-85.
◆ Client certificate passwordless
Requires no name or password at logon for users who have the installed
client certificate. For more information on this method, see Setting up
client-certificate-based authentication, on page 2-85.
◆ RSA SecurID
Uses the server at your site that supports RSA’s SecurID technology over
its native protocol. RSA SecurID represents a two-factor authentication
method that uses a combination of a known password and a digitally
generated string to grant access to the FirePass controller. The FirePass

Chapter 2
controller is RSA-certified. If you want to use RSA SecurID over

RADIUS, select RADIUS instead. For more information on this method,
see Setting up RSA SecurID authentication, on page 2-92.
Understanding support for extended variables with Single Sign-On (SSO)

values
The FirePass controller provides support for variables that allow for the
real-time setting of a user’s Single Sign-On (SSO) values in a session.
Pre-logon, AD, LDAP, and RADIUS group mapping or authentication
variables may be used directly in the FirePass controller administrative
console. For example, administrators may perform an LDAP or AD query
using dynamic group mapping or authentication, which returns key
attributes that can then be configured as variables that override the session's
SSO (single-sign-on) user name and password.
To use this feature, navigate to the Users: User Management screen.
In order to use session variables created from external directory attributes,
you must configure an appropriate group mapping or authentication method.
Entering variables on the screen does not automatically generate a query to
external directories.
The FirePass controller determines the user name and password values
configured on the User Management screen after a user logs in. These
values are assigned to the %username% and %password% variables that
you can use when configuring the following resources:
• URL variables in Web Applications and intranet webtops
• Drive mapping paths and Launch Application paths and parameters in
network access
• Application parameters in Application Tunnels
• Paths in Windows files
• Mobile email corporate account templates for external users
Additionally, you can use the SSO user name and password to log the user
on automatically to Terminal Services, App Tunnel file shares, Network
Access drive mappings, Web Applications, Windows file shares, and
Mobile email corporate accounts. To extend the use of the SSO user name
and password, enable the auto logon option in the Master Group settings for
the corresponding resource type.
Important
The SSO settings on the User Management screen do not affect the Single
Sign On mechanism based on cookies received from an external web server
during HTTP Basic or Form-Based authentication methods.
2 - 70
Tip
An SSO password defined on the User Management screen overrides an
SSO password configured in a RADIUS authentication method. To use the
SSO password configured in a RADIUS authentication method, leave the
SSO password and regular expression boxes blank on the User Management
screen.
Changing authentication methods

You can convert from any authentication method to another.
To convert the authentication method for a master group

Master Groups.
2. In the Authentication column, click the link associated with the
master group you want to affect.
The master-group-specific authentication screen opens.
3. Click the Convert authentication method link.
The convert-authentication screen opens.
4. From the list of authentication methods available for conversion,
click the method you want to convert to. For more information on
the available authentication methods, see Determining the
authentication method, on page 2-68.
5. On the convert-confirmation screen, click the Continue button.
The associated Authentication screen opens.
6. Specify the settings and options you want, and then click the Save
Settings button.
Important
Depending on the conversion, you might be required to configure additional
settings. For example, if you convert to the internal authentication method,
you must make sure to specify passwords as well as add any missing data so
all of the boxes are filled on the associated user information screen. For
more information on converting to an authentication type, see the section
associated with the specific method. For example, if you are converting to
the RADIUS authentication method, see Setting up RADIUS server

Chapter 2
Setting up internal authentication

The internal authentication method uses an internal database storing
FirePass controller user data for name, logon designation, password (stored
as cryptographically strong hashes), email address, group name, mail server,
and NFS logon and password. Initially, you must assign each user a
password. Later, a user can change his password from the webtop.
Setting up RADIUS server authentication

The FirePass controller can authenticate users using a RADIUS server. On
the RADIUS server, you must set up the FirePass controller as a client of the
RADIUS server. Then, establish a shared secret and add it to both the
RADIUS server and the FirePass controller so the RADIUS server can trust
the FirePass controller.
Important
Be sure that the RADIUS server is configured to recognize the FirePass
controller as a client. Use the same shared secret in both the RADIUS
server configuration, and in the FirePass controller configuration.
Tip
You can specify up to three RADIUS servers for redundancy. The FirePass
controller tries to authenticate using the first configured server. If there is
no response, it falls back to the secondary server. If the secondary server
does not respond, the FirePass controller tries with the tertiary server.
Configuring RSA SecurID using RADIUS

FirePass controller fully supports RSA extensions for RADIUS and is
RSA-certified. You have one of the following options.
• If you plan to use RSA SecurID over RADIUS, select RADIUS as the
authentication method.
• If you plan to use RSA SecurID over its native protocol, select RSA
SecurID as the authentication method.
For more information, see Setting up RSA SecurID authentication, on page

2-92.
Troubleshooting RSA SecurID on Windows using RADIUS configuration

If you are having difficulty authenticating using RSA SecurID over
RADIUS, check on the authentication server that is running RSA SecurID
server to make sure these settings are correct:
◆ The RADIUS service is active.
Even if the RADIUS service has been started from the SecurID options
window on the Windows SecurID server, the service may not be active.
2 - 72
In the Windows Services Manager, make sure that the service is set to
start each time the server starts, and is currently running. RSA SecurID
authentication using RADIUS takes place on a different port than does
native SecurID authentication.
◆ The SecurID server is configured correctly for RADIUS
authentication.
While using RSA SecurID over RADIUS, the SecurID server is a client
of itself. The RADIUS service functions as a standalone process, and if
the SecurID server is not set up as a client of itself, it rejects the FirePass
controller authentication request and does not store anything in the logs.
In this case, the FirePass controller reports that authentication has failed,
and with no log information, the failure is difficult to diagnose. To
troubleshoot, check that:
• You have enabled support for the RADIUS protocol for the RSA
SecurID server.
• You have configured the FirePass controller as a client of the RSA
SecurID server.
Configuring Single Sign-On using a RADIUS attribute

You can configure the FirePass controller to retrieve the Single Sign-On
(SSO) password information from an attribute returned from the RADIUS
user profile. The FirePass controller parses the return value to retrieve the
SSO password information in various formats.
To configure SSO using the RADIUS attribute

Master Groups.
2. Click the group name of the RADIUS group for which you want to
enable SSO.
Alternatively, you can click the Create new group button to create
a new group, and select RADIUS from the Authentication method
list.
3. Click the Authentication tab.
The RADIUS Authentication screen opens.
4. Select the check box Retrieve Single Sign On Password from
RADIUS attribute.
A new screen area labeled RADIUS Attribute value and format
settings for SSO password appears.
5. In the RADIUS attribute box, type the IETF-assigned attribute
number for the RADIUS attribute to use to extract the SSO
password information. For example, type 25 for the Class attribute,
26 for the Vendor Specific attribute, or 11 for the Filter-ID
attribute.
6. For the Attribute contains setting, select one of the following
options:

Chapter 2
• SSO Password. Format: Value. The FirePass controller parses

the value of the selected RADIUS attribute and uses Value as the
SSO password.
• SSO Password. Format: KEY=VALUE. The FirePass
controller parses the value of the selected RADIUS attribute as
KEY=VALUE and uses VALUE as the SSO password.
Note
SSO configuration is applicable for simple RADIUS as well as RSA SecurID

over RADIUS.
Setting up LDAP server authentication

The FirePass controller can authenticate using any LDAP database,
including a Windows Active Directory.
You can use an LDAP-protocol-based directory, including an Active
Directory, to authenticate users dynamically. In this case, you do not store
user information on the FirePass controller. Instead, you obtain it from the
LDAP entry.
Using the Template option for LDAP authentication

If the FirePass controller logon matches the naming attribute that your
LDAP directory uses as part of the bind DN, you can look for the user’s
entry directly by configuring the option described in the following
procedure.
To specify the template option for LDAP authentication

Master Groups.
2. In the Authentication column, click the link representing the master
group you want to configure.
The screen changes, and you see the authentication screen for the
corresponding master group.
3. In Host, specify the FQDN or the IP address of the LDAP server.
If you use the LDAP authentication over SSL method, be sure that
the Host name you specify exactly matches the host name on your
LDAP server certificate.
4. In Port, specify the port on which the LDAP server listens.
The default values are 389, which represents LDAP, and 636, which
represents secure LDAP.
5. From the Protocol version list, select 2, if yours is an LDAPv2
configuration, or 3, if yours is an LDAPv3 configuration.
2 - 74
6. In User DN Template, type the following string, substituting the

appropriate value for YourCo.
cn=%logon%,o=YourCo
During logon, the authentication mechanism substitutes the user’s FirePass
controller logon as part of the bind DN, and supplies the entered password
as the bind password. If the bind operation succeeds, the user is validated.
Using the Query option for LDAP authentication

If the user name and password are not the same as the LDAP logon (for
example, if the LDAP user ID contains characters that the FirePass
controller does not support), then you cannot use the FirePass controller
logon to bind to the LDAP directory. Instead, you must query to find the
correct DN to use in a second attempt to bind.
Query the appropriate part of the directory tree structure (specified by the
search base, or container, DN) to find a user within that branch.
Your LDAP directory might allow anonymous queries. If so, you do not
need to specify an account and password. Otherwise, either specify
credentials of any LDAP account that is allowed to query this part of LDAP
directory, or create a new LDAP account for FirePass controller.
Note
Your schema may vary considerably from the examples presented in the
following list. The user object class user is different on some LDAP servers,
and your structure might have more layers of names defined between the
root and the leaves.
To specify certain parameters, you must have the following information,

which you can get from your LDAP server administrator:
• User DN for query: The fully qualified DN of the user with rights to run
the query. We recommend specifying this value in lowercase and without
spaces for compatibility with some specific LDAP servers.
The specific content of this string depends on your directory layout.
For example, in an Active Directory structure, a typical User DN for
query is similar to the following string:
cn=administrator,cn=users,dc=eng,dc=net,dc=com
• Password: The password associated with the DN you specified in User
DN for query. You can leave this box blank if your LDAP server allows
anonymous queries.
• Search base DN (Container DN): Determine the appropriate values
from your specific directory layout.
The specific content of this string depends on your directory layout.
For example, in an Active Directory structure, a typical Search base DN
is similar to the following string:
cn=users,dc=eng,dc=net,dc=com
• Query template: For example, (&(sAMAccountName=%logon%))

Chapter 2
After the FirePass controller runs the query, if it finds a matching user entry,
it uses the returned DN value and the user-entered password to bind to the
LDAP directory. If the second bind succeeds, the authentication succeeds
(that is, the user is validated). If either bind fails, the authentication fails.
Setting up two-factor authentication with a Client Certificate and

LDAP
FirePass controller provides a two-factor authentication method that
requires users to present a valid client certificate, which is then verified
against the LDAP database using information extracted from certificate
values.
This method supports customers who have client root certificate authority
linked to the LDAP database from which certificates are generated based on
information stored in those directories.
Note
To use this feature, a client root CA certificate must be installed on the

FirePass controller, and you must configure the FirePass controller to
extract fields from the client certificate to use in the two-factor
authentication process.
To use two-factor authentication, you must first install a client root

certificate. Then, you configure a master group with the LDAP
authentication method, and then select the option Require client certificate
for user logon.
Two-factor authentication is a secondary authentication and it is performed
only if primary authentication (specifically, certificate validation against a
selected client root CA certificate) is successful. The user record is retrieved
from the LDAP database based on the configured settings, and optionally
matched against data extracted from the client certificate.
You must select one of the following options:
• Client certificate subject field used for comparison
Select one of the following choices. The data extracted from the
certificate according to this setting can be used to compare against the
LDAP or Active Directory attribute. It is also assigned to local variable
%certfield% that can be used in defining a LDAP user Distinguished
Name (DN) template or query template.
• Client certificate common name (CN)
• Client certificate e-mail address
• Client certificate serial number (SN)
• Client certificate distinguished name (DN)
• Client certificate field (regex extraction)
• Client certificate next subjectAltName field (regex extraction)
2 - 76
• Regular expression
This option appears only when one of the last two settings (regex
extraction) is selected for the previous option and defines a regular
expression used to extract certificate data for comparison and to fill the
%certfield% variable.
• Verification method
This option defines the criteria for successful secondary authentication,
that is, what is considered a successful verification of certificate data
against LDAP. The following choices are available:
• User DN found in LDAP
Specifies that the authentication attempt is successful when the user
record is retrieved from the LDAP database using the configuration
defined in the Configure LDAP settings section; no attribute check is
performed.
• Direct match of client certificate field to LDAP attribute
Specifies that the user record must be retrieved from LDAP, and
LDAP attribute value must match extracted certificate data exactly.
• Match client certificate field within LDAP attribute (substring)
Specifies that the user record must be found, and extracted certificate
data must be a substring of LDAP attribute value.
• Match LDAP attribute within client certificate field (substring)
Specifies that the user record must be found, and LDAP attribute
value must be a substring of the extracted certificate data.
• Match LDAP attribute within client certificate field (substring)
Specifies that the user record must be found, and LDAP attribute
value must be a substring of extracted certificate data.
• Configure LDAP Settings
This section specifies the LDAP server configuration, and the criteria
used to retrieve the user record from the LDAP database.
• LDAP server
Specifies the IP address or host name of the LDAP server
• LDAP port
Specifies the TCP port number for connecting to the LDAP server.
• Use SSL connection
Specifies whether the connection must use SSL.
• Protocol version
Specifies the LDAP protocol version. The default values is 3, and the
FirePass controller supports version 2 and 3.
• Bind DN
Specifies the DN for binding to the LDAP server. This is usually the
DN of the administrative account, or another account with LDAP read
access.
• Bind password
Specifies the password for the Bind DN.
• Get user DN using
Specifies the method the FirePass controller uses to retrieve the user
record from the LDAP database. Options are template or query. The

Chapter 2
following variables are supported:
o%user%, %username%, %s, %logon% - the user name extracted

from the client certificate based on configuration options defined
globally from the Device Management : Security : Certificates screen.
o%certfield% - the data extracted from the client certificate based on

the Client certificate subject field used for verification option.
o%certdn% - the certificate subject DN converted from certificate

format to LDAP DN format. This variable is a special case. Use this
only when the certificate subject DN is identical to the user object DN
in the LDAP directory. This value is specified in the User DN
template box by itself, only when you use the template method. This
setting is independent of the selections you make for the Client
certificate subject field used for verification option.
The difference between using %certdn% and using %certfield%
together with the Client certificate distinguished name (DN) value
for the Client certificate subject field used for verification option is
that %certdn% causes a DN format conversion (from certificate to
LDAP format), where %certfield% does not.
• When template method is selected the following options appear:
User DN template - this specifies template for user record DN, for
example: CN=%certfield%,CN=Users,DC=domain,DC=com or
CN=%logon%,OU=Sales,O=Company.
Variables in the template are replaced with their values at the time of
user authentication and object, and the resulting DN is retrieved from
LDAP. The FirePass controller performs the LDAP search using this
variable as the base DN, and the search filter objectClass=*, which
returns the object with this base DN, if it exists.
• When query method is selected the following boxes appear:
Base DN - the base DN used for an LDAP search
Query template - the template for an LDAP search filter; except for
%certdn%, all other variables described are supported
All configuration options are split into three sections:

• The data that is specified to be extracted from the certificate for
subsequent verification against LDAP.
• The verification method that is specified to compare the data from the
certificate to the LDAP directory.
• The LDAP server access information, and the method used to retrieve
user records.
2 - 78
LDAP Verification
The FirePass controller performs LDAP verification in a specific order:
• Prerequisites are checked.
• If the User DN found in LDAP verification method is selected, there
are no prerequisites.
• Otherwise, if you use an attribute check, the Client certificate
subject setting used for verification must be configured, and the
LDAP attribute used for verification must not be empty.
• If prerequisites are not met, LDAP verification fails.
• The FirePass controller extracts certificate data according to the
configuration options in the first section, and places them in a temporary
%certfield% variable. This field is automatically used in the user DN
template or query template when the FirePass controller retrieves the
user from the LDAP directory in the next step.
• When you select the User DN found in LDAP verification method:
• The user record is retrieved from the LDAP directory, according to
the configuration options specified.
• If the FirePass controller has a communication problem with the
LDAP directory, an error is reported (Connect Failed, Bind Failed,
or Request to LDAP server Failed) and verification fails.
• If the FirePass controller does not find the user record, errors are
logged (LDAP search result - User not found, Client certificate
match against LDAP - Failed, Client certificate validation -
Failed) and verification fails.
• If the FirePass controller finds the user in the database, a message is
logged (LDAP search result - User found, and Client certificate
validation - Succeeded) and verification succeeds.
• If you have selected an attribute check method:
• If no data was extracted by the FirePass controller from the certificate
in the previous step, so the %certfield% value is empty, errors are
logged (LDAP query results - No client cert setting and Client
certificate validation - Failed) and verification fails.
• If there is no error, the FirePass controller retrieves the user from the
LDAP directory according to the configuration.
• If the FirePass controller has a communication problem with the
LDAP directory, an error is reported (Connect Failed, Bind Failed,
or Request to LDAP server Failed) and verification fails.
• If the FirePass controller does not find the user record, errors are
logged (Client certificate match against LDAP attribute - Failed,
Client certificate validation - Failed) and verification fails.
• If the FirePass controller finds the user record, the extracted
certificate data is matched against LDAP attribute. If the FirePass
controller matches the fields successfully, a message is logged (Client
certificate setting match within LDAP attribute - Succeeded, or
LDAP attribute match within certificate setting - Succeeded, or

Chapter 2
Client certificate match against LDAP attribute - Succeeded, and

Client certificate validation - Succeeded), and verification succeeds.
If the FirePass controller cannot match the data successfully, an error
is logged (LDAP search result - User not found, Client certificate
match against LDAP - Failed, Client certificate validation -
Failed) and verification fails.
• If the FirePass controller verifies the LDAP and certificate settings, the
LDAP attributes are recorded in the session variables
%session.ldap.auth.attributeX%. The FirePass controller combines
multiple attributes with the same name into a single session variable,
with their values concatenated as a space-separated string.
To configure client certificate passwordless two-factor

authentication with LDAP
Master Groups.
2. Click the name of a group that is authenticated with the client
certificate method, or create a new one.
3. On the Master Groups screen, check the box Automatically log-in
when client certificate is present.
4. If you require a specific certificate issuer for the client certificate,
select it from the Required client certificate issuer list.
5. From the list Perform additional client check using, select LDAP.
6. From the corresponding lists, select the client certificate subject
field to use for comparison, and the verification method.
7. If you select Direct match client certificate field to an LDAP
attribute, Match contents of client certificate field within LDAP
attribute (substring), or Match contents of LDAP attribute
within client certificate field (substring), you must type the LDAP
attribute to use for verification in the box provided.
8. Configure the LDAP settings.
These settings include the LDAP server and port, whether to use an
SSL connection, the protocol version (2 or 3), whether to follow
referrals, the Bind DN and password, and whether to get the user's
DN using a template or a query.
9. Click Update to update the authentication method.
10. Once you have configured the passwordless two-factor
authentication for a user, you can get details of the configuration.
Type a user name into the Username field, and click Details. The
results of the two-factor authentication queries for this user name
are displayed.
2 - 80
Setting up HTTP basic authentication to external server

Basic authentication requires a valid URL resource. This resource must
respond with a challenge to a non-authenticated request. This method
supports authentication over both HTTP and HTTPS protocols. Redirects
are not supported.
Note
F5 Networks strongly recommends using HTTPS because basic

authentication passes user credentials as clear text.
You can test the URL by logging on with valid and invalid credentials, to
make sure your external authentication server issues a challenge when
invalid credentials are tendered, and that it does not send a redirect.
Setting up initial signup on LDAP with subsequent strong internal

password
This option authenticates new users against an LDAP directory. At logon,
the FirePass controller presents a form requiring the new user to enter a
strong password. Subsequently, the user is authenticated using the FirePass
controller internal method.
With this method, you can use strong passwords not supported by LDAP
directory, while providing most of the convenience of LDAP authentication.
To use Initial Signup on LDAP with Subsequent Strong Internal Password
authentication, you also must use template-based signup for the group. To
enable signup by templates, use the Users : Signup Templates screen.
A strong password is one that is difficult to detect by both humans and
computer programs, which effectively protects data from unauthorized
access.
On the FirePass controller, a strong password must:
• Contain at least eight characters
• Have not been used in the previous 24 password instances
• Start with an alphabetical character
• Contain at least one numeric character from the set 0, 1, 2, 3, 4, 5, 6, 7, 8,
9.
• Contain at least one special character from the set ` ~ | . , : ; ? / ' " \ { } <
>!@#$%^&*()+=_-
• Not contain more than three consecutive occurrences of the same
character
• Not contain the employee name or logon

Chapter 2
• Not contain 5 consecutive numeric characters (for example: test@12345)
Note
In a strong password, neither the number nor the special character may be
in the last character position.
Setting up Windows domain server authentication

Within a Windows domain there are usually a number of groups defined,
with users belonging to one or more of these groups. You can map existing
Windows domain groups directly to existing FirePass controller master
groups. When a user attempts to log on to the FirePass controller, the
Windows domain groups that the user belongs to are retrieved from the
domain. The FirePass controller attempts to match one of the domain groups
against the FirePass controller-configured mapping, and the user is
dynamically moved to the new FirePass controller master group based on a
match. For more information on group mapping, see Setting up dynamic
group mapping, on page 2-16.
Windows domain server supports the following authentication modes:
◆ Native NTLM authentication
Uses Native Windows NT LAN Manager (NTLM) authentication if you
specify domain administrative credentials when you set up Windows
domain authentication on the FirePass controller. This allows FirePass
controller to add a machine account for itself, join the domain, and create
a trust relationship with the Primary Domain Controller (PDC). FirePass
controller can then authenticate users using native NTLM services.
◆ Netlogon Share
If you do not specify domain administrative credentials when you set up
Windows domain authentication on the FirePass controller, then the
FirePass controller uses a more basic method for authenticating users.
The FirePass controller connects to the Netlogon share on the configured
PDC using the user’s credentials to determine whether the user has a
valid account within the domain. If binding to Netlogon succeeds, the
FirePass controller authenticates the user.
Setting up Active Directory authentication (Kerberos

authentication)
Computers using Windows 9x or Windows NT typically use the NTLM
protocol for network authentication in Windows 2000 domains. Computers
running Windows 2000 and later might use NTLM when authenticating to
servers with Windows NT 4.0 and when accessing resources in Windows
NT 4.0 domains, but the more commonly used protocol is Kerberos,
generally referred to as Active Directory. If you are running Windows 2000
2 - 82
or later servers, F5 Networks recommends that you use Active Directory

authentication instead of Windows domain authentication. The FirePass
controller can also authenticate users with UPN names in Active Directory.
For specific procedures for setting up Active Directory authentication, see
Configuring Active Directory-based mapping, on page 2-27.
Using nested groups during Active Directory authentication

If you have nested groups in your Windows Active Directory configuration,
you can use those nested groups during authentication. Nested groups are
created in a Windows Active Directory domain, and allow you to raise and
lower the level of domain functions within the Active Directory hierarchy.
To use nested groups in the FirePass controller, in the navigation pane, click
Users, expand Groups, and click Master Groups. and assign the user to a
series of nested groups. You may optionally select the options Check
nested groups and User must belong to Domain group.
For more information about nested group checking during Active Directory
authentication, refer to the Ask F5 Technical Support web site.
Configuring a flexible query for a client certificate with Active

Directory
You can retrieve user records from Active Directory with an arbitrary
Active Directory attribute and value, using a flexible filter expression of the
form:
attribute=value
where value can contain variables such as %username%, %logon% or
%certfield%.
You use this method when a user’s sAMAccountName in Active Directory
is not a substring of the client certificate subject DN. For example:
Client certificate subject DN: /C=US/O=U.S.
Government/OU=DoD/OU=PKI/OU=CONTRACTOR/CN=FERRY.JA
COB.M.1278033593
sAMAccountName: Jacob.ferry
employeeID: 1278033593
In this case, the FirePass controller can verify the client certificate using the
employeeID attribute, because it is unique, and it is a substring of the
subject DN. You can use this filter expression to extract the employeeID
attribute:
employeeID=%username%
or
employeeID=%certfield%

Chapter 2
Use the variable (certfield or username) that is most appropriate for your
configuration.
Note
To use this feature, you must install the client root CA certificate on the
FirePass controller, and configure user name extraction from the client
certificate. Additionally, you must configure the master group with the client
certificate authentication method. And the option Perform additional client
certificate check using must be set to Active Directory.
Understanding Active Directory search filters

You can optionally use a search filter with Active Directory authentication
to extract an attribute that you can then use in an expression. The format of
the Active Directory search filter is:
attribute=value
where attribute can be any Active Directory attribute, such as
sAMAccountName, employeeID, cn, and so on. Except for Regular
expression, all text boxes and comparisons are not case-sensitive.
The value can be configured to contain one of the following variables:
• %username%, %user%, %logon%, %s - substituted with the user
name extracted from the client certificate according to settings on the
Device Management : Security : Certificates screen. This is the user
name logged on the Reports : Logons screen.
• %certfield% - substituted with the value extracted from the client
certificate according to the settings on this screen. The Client certificate
subject box is used for comparison and (optionally) with a Regular
expression.
Note
An empty filter value is the same as specifying

sAMAccountName=%username%. Either attribute or value can be
omitted, in which case, the defaults are sAMAccountName and
%username% .
The system retrieves the user’s sAMAccountName attribute from the

Active Directory using the configured search filter. Then the full user record
is retrieved based on the retrieved sAMAccountName, and the Active
Directory attribute used for verification is matched (if configured). All
Active Directory attributes are then stored in session variables.
You can use the verification option User found in Active Directory, if the
only verification you require is that a user record based on the search filter
exists, and there is no need to do an attribute match, as is the case with an
employeeID attribute. When you select this verification method, the Active
Directory attribute used for verification entry box is not displayed.
Active Directory attributes are stored in session variables when
authentication is successful.
2 - 84
You select the secondary Active Directory authentication option from the
list Perform additional client certificate check using, then specify the
secondary authentication option.
Setting up HTTP form-based authentication

You can configure the FirePass controller to use external, web-based
authentication servers such as Oracle COREid, eTrust SiteMinder, and
others, to validate user logons and passwords and to control user access to
specific network resources. The FirePass controller can detect any of the
following response types from an external server:
• A valid redirect URL in the external server’s response
• A specific, configurable substring in the external server's response
• The presence of a specific cookie in the external server's response to the
FirePass controller request for user validation
From the standpoint of the authentication server, the FirePass controller

appears as a proxy browser. The FirePass controller itself is transparent to
the authentication application. You do not need to make any configuration
changes to the authentication server to integrate it with the FirePass
controller.
Setting up client-certificate-based authentication

To use client certificates, you must have a server configured as a Certificate
Authority (CA) that can generate a client root certificate and the client
certificates based on the client root certificate. Or, you can purchase the
client root certificate and client certificates from an external CA. For more
information about installing client certificates, see Installing and
configuring client root certificates, on page 4-13.
Using client certificates

When the FirePass controller is serving as the client certificate CA, you can
generate and download client certificates on the User’s details screen. To
access the screen, click Users, click User Management, and click the edit
button associated with a specific user.
The issued client certificates are based on the subject boxes of the issuing
client root CA certificate. The common name (CN) is set to the logon name,
and the Organization Unit (OU) might be set to the user’s group name on the
FirePass controller (for use with dynamic group mapping functions).
You can enable the setting to request the client certificate during logon only
after installing a valid client root certificate. This instructs the FirePass
controller to request the client certificate as part of the SSL session
negotiation, which occurs before the client attempts to log on to the FirePass
controller. It also validates and logs the client certificate, but it does not
restrict access to the FirePass controller.

Chapter 2
You can determine whether content from client certificate boxes

automatically populates the user name box at logon time. When you request
a client certificate during logon, you use one of several options.
◆ Do not use certificate field for logon username
Select this option if you do not want any client certificate box to map to
the FirePass controller logon name. When you select this option, the
FirePass controller does not support client certificate passwordless
auto-logon authentication, and other client certificate functions do not
check to ensure that the user name matches any client certificate box.
However, the FirePass controller does check the client certificate the user
provides against the installed root CA certificate, and against any
configured CRL checking mechanisms.
◆ Use certificate common name (CN) for logon username
Select this option if your PKI infrastructure issues client certificates that
use the common name (CN) as the FirePass controller logon user name
or when the certificate is generated on the FirePass controller. When the
FirePass controller is configured to serve as the client root CA and issues
client certificates directly, it issues certificates that use the client
certificate CN as the logon name. When you select this option, the
FirePass controller populates the logon name prompt with this value, and
other client certificate functions check to make sure the logon name
matches the CN box in the client certificate.
◆ Use certificate e-mail address for logon username
Select this option to use the email address of the user as the FirePass
controller logon user name. When you select this option, the FirePass
controller populates the logon prompt with this value, and other client
certificate functions check to make sure the logon name matches the
email address in the client certificate. the FirePass controller checks
against the first user account found with the specified email address.
◆ Use certificate serial number (SN) for logon username
Select this option to use the certificate serial number (SN) as the FirePass
controller logon name. When you select this option, the FirePass
controller populates the logon name prompt with this value, and other
client certificate functions check to make sure the logon name matches
the SN box in the client certificate.
◆ Use certificate subject DN field (regex extraction) for logon
username
Select this option to use a different value from the client certificate
distinguished name (DN) as the FirePass controller logon name. You can
then specify a Perl-style regular expression to extract the user name from
the DN. The following example shows a sample DN:
/C=US/ST=CA/L=MyCity/O=MyCompany/OU=MyDept/CN=user/e
mailAddress=user@company.xyz
You can use an expression such as |CN=(.*)/| to extract the CN for use as
the logon name. When you select this option, the FirePass controller
populates the logon prompt with the value extracted, and other client
certificate functions check to make sure the logon name matches the
extracted box from the client certificate.
2 - 86
◆ Use certificate ext subjectAltName field (regex extraction) for logon

username
Select this option to use the X509v3 extension’s Subject Alternative
Name attribute. You can then specify a Perl-style regular expression to
extract the subjectAlternativeName from the certificate. For example, if
the certificate has the SubjectAltName extension attribute as
X509v3 Subject Alternative Name:
email:joeuser@siterequesta.com, email:joeuser@siterequestb.com
to extract the second e-mail address from this attribute using a regular
expression, you can use the following expression
|email:.*, email:(.*)|
Configuring client certificate authentication

Client certificates serve as a security mechanism that allows the FirePass
controller to verify that the client computer is a valid computer. You can use
client certificates in the following ways:
◆ Two-factor authentication
In the two-factor authentication system, users must have a valid client
certificate installed in addition to specifying a user name and password.
After installing a client root certificate and enabling the option to request
client certificate during logon, the Client Certificate Two-Factor
Authentication section becomes available on the Authentication tab for
each master group. To access the screen, click Users, expand Groups,
click Master Groups, and click the link in the Authentication column
for the master group you want to configure. For information about this
feature, see Configuring client-certificate two-factor authentication, on
page 2-90.
◆ Extra policy layer of protection
You can specify use of client certificates for individual access functions
or individual resource protection. For example, you can limit access to
the FirePass controller Network Access service only to corporate laptops
with valid client certificates installed. In that case, users do not have
access to the Network Access service from untrusted locations, such as
public access kiosks. But you still can give them access to Web
Applications, even from untrusted locations.
You can use client certificates to control access to resources by creating a
named endpoint configuration on the Protected Configuration screen. To
access the screen, click Users, expand Endpoint Security, click
Protected Configurations, and then click the New Protected
Configuration link. You can assign the endpoint protection you created
on the Protect Resources screen. To access the screen, click Users,
expand Endpoint Security, and click Protect Resources. Then click the
Select link for each service (for example, all Web Applications or
webtops), an individual resource group, or several favorites you want to
protect, and select the protected configuration you want to use. For
information about protected configurations, see Creating protected
configurations, on page 3-27, and for information about protecting
resources, see Protecting resources, on page 3-31.

Chapter 2
◆ Passwordless auto-logon
The presentation of a valid user client certificate, where the common
name (CN) matches the user logon name, enables either a zero-click or
one-click automatic logon. You can configure a passwordless automatic
logon mechanism on the Authentication screen. To access the screen,
click Users, expand Groups, click Master Groups, and click the link in
the Authentication column for the master group you want to configure.
For information about this feature, see Configuring passwordless
◆ Dynamic group mapping
The existence of a valid user client certificate allows use of options
within the client certificate to enable dynamic mapping of users into
particular FirePass controller master authentication groups or to
particular resource groups. This allows use of extensive resource policy
management based on the existence of settings within a client certificate.
You can configure the dynamic group mapping mechanism on the
Dynamic Group Mapping screen. To access the screen, click Users,
expand Endpoint Security, and click Dynamic Group Mapping. For
information about dynamic group mapping, see Setting up dynamic
group mapping, on page 2-16.
◆ Pre-logon sequence processing
The existence or nonexistence of a valid user client certificate controls
whether the FirePass controller performs the defined pre-logon actions,
such as loading the protected workspace or denying access to the
FirePass controller logon screen. You can configure a pre-logon
sequence that require client certificates on the Pre-Logon Sequence
screen. To access the screen, click Users, expand Endpoint Security,
and click Pre-Logon Sequence. For information about pre-logon
sequences and inspectors, see Creating pre-logon sequences to protect
resources, on page 3-15.
◆ Resource protection
You can use client certificates to control access to resources by assigning
a previously defined and named endpoint configuration (created using
the New Protected Configuration link on the Users : Endpoint Security
: Protected Configurations screen) to a resource on the Protect Resources
screen. To access the screen, click Users, expand Endpoint Security,
and click Protect Resources, and then click the Select link for each
service you want to protect. For information about protected
configurations, see Creating protected configurations, on page 3-27.
Using client certificates to authenticate users

To use client certificates, you must have a server configured as a Certificate
Authority (CA) that can generate a client root certificate and the client
certificates based on the client root certificate. Or, you can purchase the
client root certificate and client certificates from an external CA.
Here is an overview of the tasks required for using client certificates to
authenticate a user’s computer:
2 - 88
◆ Install the client root certificate on the FirePass controller. You can
install a client root certificate using the Certificates screen. To access the
screen, click Device Management, expand Security, and click
Certificates.
◆ Enable the validation of client certificates.
◆ Configure client certificate validation as part of the authentication for a
group.
◆ Instruct users how to download and install the client certificate on their
computers. You can also email the client certificates to users.
◆ Install a certificate revocation list (CRL) that contains a list of client
certificates for users who you want to deny access to the FirePass
controller, for example, the revoked client certificates of users who have
left your company.
The FirePass controller can then request and validate the computer’s
client certificate against its installed client root certificate as part of the
authentication process.
Configuring passwordless authentication

If you select the Client certificate passwordless authentication method for
any group, the FirePass controller requests a client certificate from the user
machine. This client certificate can be one issued by your company’s PKI
infrastructure, one made available from a SmartCard solution, or one created
and distributed to the user by the FirePass controller itself.
If the client machine has a trusted certificate, the FirePass controller follows
this process when authenticating.
◆ The FirePass controller hides the password prompt, and populates the
User name fields on the logon screen with the client certificate setting
that you configured on the Certificates screen. The user cannot edit this
logon user name.
◆ The FirePass controller validates the certificate against the installed
client root certificate. It also checks the certificate against any configured
CRL methods enabled.
◆ The FirePass controller validates the user name against the internal
authentication database. If you specify use of sign-up by templates for
the group (along with dynamic group mapping, to make sure the user is
mapped to a group supporting client certificate authentication), then the
FirePass controller automatically adds the user based on the client
certificate.
Users who are validated need only click the Logon button to log on to
the FirePass controller webtop (one-click logon). If you have enabled
automatic logon when the client certificate is present, the FirePass
controller logs the user directly on to the FirePass controller webtop
(zero-click logon). In this case, the FirePass controller verifies the client
certificate common name (CN) setting against the logon user name.

Chapter 2
◆ If there is no client certificate on the remote machine, the FirePass

controller provides the regular logon screen, and attempts to authenticate
the users using the methods specified for other authorized groups.
If you have more than one client root certificate installed, you can select a
client certificate issuer to restrict authentication to certificates issued by that
specific client root certificate. For more information on functionality with
more than one client root certificate installed, see Installing and configuring
client root certificates, on page 4-13.
Using Windows Mobile client certificate passwordless authentication

The FirePass controller supports Windows Mobile client certificate
passwordless authentication. With this authentication type, you can
configure the FirePass controller to authenticate users with only a
certificate, and no requirement for a user name and password. This is the
most common form of authentication for personal devices.
Configuring client-certificate two-factor authentication

You can require the existence of a valid client certificate as a secondary
authentication factor, that is, a method requiring two authentication
methods. You can configure client certificates as part of a two-factor
authentication system, in which users must have a valid client certificate
installed on their computer in addition to entering their user name and
password at logon time.
A server certificate verifies the server’s identity to a user’s computer. In
addition to using server certificates, you can require client certificates that
enable the FirePass controller to verify the identity of a user’s computer, and
to control access to specific resources, applications, and files. For more
information about server certificates, see Using server certificates on the
FirePass controller, on page 4-1.
You can require valid client certificates to gain access to specific
applications. For example, you might provide access to the FirePass
controller Network Access service only for users who present valid client
certificates. That user could access the Network Access service from the
laptop, but not from other locations, such as public access kiosks, where the
certificate might not be installed.
Note
To use this feature, you must install the client root CA certificate on the
FirePass controller, and configure user name extraction from the client
certificate. Additionally, you must configure the master group with the client
certificate authentication method, and configure the option Perform
additional client certificate check using to use Active Directory.
2 - 90
To configure two-factor authentication

Master Groups.
2. In the Authentication column, click the link representing the master
group you want to configure.
The screen changes, and you see the authentication screen for the
corresponding master group.
3. In the Client Certificate Two-Factor Authentication area, check the
Require client certificate for user logon check box.
The screen refreshes to reveal certificate-specific options, and a
message indicating which client certificate setting the FirePass
controller uses to populate the logon box, depending on the option
you selected on the Device Management : Security : Certificates
screen.
4. From the Required client certificate issuer list, select a client
certificate that you want the client computer to present.
The client certificate can be one issued by your company PKI, one
made available by a SmartCard solution, or one created and
distributed to the user by the FirePass controller itself.
If you have not installed a client certificate, you do not see the Request
client certificate during logon check box on the Device Management :
Security : Certificates screen, or the Require client certificate for user
logon check box on the Users : Groups : Master Groups screen. In that case,
install a client root certificate first, using the Client Root Certificate or
Self-Signed Certificate option on the Device Management : Security :
Certificates screen. For more information, see Installing and configuring
client root certificates, on page 4-13.
If you have more than one client root certificate installed, you can select a
client certificate issuer to restrict authentication to certificates issued by that
specific client root certificate. For more information on functionality with
more than one client root certificate installed, see the online help for the
Device Management : Security : Certificates screen.
Understanding VHOST client certificate request

The VHOST client certificate request feature allows you to disable or enable
the requesting of a client certificate for each individual web service. The
global setting on the Security : Certificates screen still controls this
functionality for all web services, and no web service requests a certificate
when this option is disabled.
When enabled, it is possible to disable a requesting certificate for any
selected web service. This is useful in environments in which only a certain
group of users are logging on using client certificates, and other users are
logging on without them. The group of users can be instructed to log on to a
specified host name and port from which the client certificate is requested.

Chapter 2
To configure a client certificate to be requested

1. In the navigation pane, click Device Management, expand
Configuration, and click Network Configuration.
2. Click the Web Services tab.
The Web Server Configuration screen appears.
3. In the certificate list, find the certificate you want to configure, and
click Configure.
4. Select Request Client Certificate.
5. Click Update.
The user is asked to submit the client certificate when connecting to
this web service. However, when this option is not checked, the
certificate is not requested.
Setting up RSA SecurID authentication

If you are using an RSA SecurID server using its native protocol (that is, not
over RADIUS), you must configure the authentication server so that the
FirePass controller can communicate with it.
You can enable support on the server by adding the FirePass controller as a
UNIX Agent Host to the RSA server configuration.
When you configure the UNIX Agent Host, make sure to use the virtual IP
address of the FirePass controller as the primary IP address. If your
configuration uses failover units, configure each failover unit as a secondary
node, using the actual (not virtual) IP address. You can find more
information on configuring secondary nodes in the administrator’s guide for
your RSA SecurID server.
Next, you must configure a new RSA SecurID server on the FirePass
controller. To do so, navigate to the Device Management : Configuration :
RSA SecurID screen. Because the FirePass controller is a multihome
appliance with multiple IP addresses, the source IP address setting that the
FirePass controller uses for communicating with the RSA SecurID server is
very important. It must be the same address as the IP address you specified
in the network address setting when you configured the FirePass controller
as an agent host on the RSA SecurID server. Once configured, the
Authentication screen for any master group shows the name, configuration
file upload time, and source IP address it will use for communicating with
the RSA SecurID server.
When you specify the source IP on the FirePass controller, if there is a NAT
device in the network path between the FirePass controller and the RSA
SecurID server, use as the source IP the address as translated by the NAT
device. Otherwise, specify the IP address from among those configured on
Important
In all cases, the source IP address must match the SourceIP address in the
IP packets received by the RSA SecurID server.
2 - 92
For specific procedures for each of these operations, see the online help for
the Device Management : Configuration : RSA SecurID screen.
If you have already configured one or more RSA SecurID servers on the
FirePass controller, you can select from the list of RSA SecurID servers on
the Users : Groups : Master Groups screen, using the Authentication tab.

Chapter 2
Working with resource groups

When you are ready to configure the resources for users to access, you use
the options on the Resource Groups screens. Using theses options, you can
configure favorites that link to intranet resources, web applications, network
shares, application tunnels and legacy host applications.
To create a resource group

Resource Groups.
The Resource Groups list screen opens.
The Group Management screen opens.
3. In the New group name box, type the name you want for the group.
You can specify up to 48 alphanumeric characters, as well as
underscore ( _ ), hyphen ( - ), and period ( . ), and the first character
must be alphanumeric.
4. From Copy settings from, select Do not copy to configure all
settings for the new resource group, or select an existing resource
group to copy settings from.
This gives you a fast way to reuse settings you have already
specified.
5. If you select a resource group to copy settings from, you can also
check Assign the new resource group to the same set of master
groups to associate master groups from the based-on resource group
to the new resource group. This gives you a fast way to associate
master groups to resource groups.
The FirePass controller provides a default resource group called
Default_resource that by default has no associated master group. You can
create your own resource groups to use instead, or you can modify the
default group.
The Resource Groups list screen lists all the resource groups, including the
default group. From this screen, you can navigate to the other screens you
need for creating favorites. You can also delete any group by clicking the
associated Delete link.
Creating favorites in resource groups

You can create three basic categories of favorites for resource groups: those
that provide portal access, those that enable network access, and those that
support application access. Figure 2.6, on page 2-95, illustrates resource
groups and favorite association.
2 - 94
◆ Portal Access
Provides a web-based application that gives users access to POP or
IMAP email, network shares, and proprietary corporate applications. For
more information about portal access, see Introducing Portal Access, on
page 7-1.
◆ Network Access
Connects users to the network just as if they were using a traditional
IPsec Virtual Private Network connection. Then users can access any
applications that use IP networking between their remote computer and
the corporate intranet structure, enabling full network access through an
SSL-VPN tunnel. For more information about network access, see
Introducing Network Access, on page 5-1.
◆ Application Access
Provides users access in the following ways:
• App Tunnels, connections to a server on a corporate LAN that uses an
HTTPS-based, encrypted tunnel through the FirePass controller.
• Terminal Servers, connections to Microsoft Terminal Servers,
Windows XP® desktops, MetaFrame® servers, and VNC servers.
• Legacy Hosts, connections to legacy greenscreen systems (for
example, Vt100, Vt320, TN3270, and others) on mainframes,
AS/400s, and UNIX hosts).
For more information about application access, see Introducing

Application Access, on page 6-1.
Figure 2.6 Visual representation of favorites categories
Note
Portal access, network access, and application access all have master group
settings. When you configure favorites for a resource group, you should also
check the master group settings. Master group settings apply to all favorites
in a category. To find a category’s master group setting, from the
navigation pane, click Network Access, Portal Access, or Application
Access, and then click Master Group Settings. You can find more
information about master group settings in the online help for the associated
screen.

Chapter 2
Associating resource groups with users

Resource groups can be static or mapped.
A resource group is considered a static resource group when it is explicitly
assigned to a master group or to an internally managed user. All users in the
associated master group are granted access to the statically assigned
resource groups. In this case, the mapping becomes associated with the user,
irrespective of the user’s associated master group, so the user can move to
any master group and still keep the same resource group assignment. You
can assign a static resource group to a user when you create the user
account, or at any time after the user account has been created.
A resource group is considered a dynamically mapped resource group
when the FirePass controller grants access based on the resource mapping
table. Any user who belongs to the external group is granted access to the
resource groups. Users who move to a different external group are
automatically granted access to any resource groups mapped to the new
external group. When you add a new favorite or reconfigure an existing one,
the change applies to users in all mapped groups.
When a user logs on and is successfully authenticated in a master group, the
FirePass controller grants the user access to the associated master group’s
assigned resource groups. You can also directly assign resource groups to
local users from the User : User Management screen.
To assign a resource group statically

1. In the navigation pane, click Users and click User Management.
The User Management list screen opens.
2. Click the edit button associated with the user you want to have
access to the resource group.
The User’s details screen opens
3. In Available individual resource groups, along the right side of the
screen, check the resource groups you want the user to access.
4. Click the Change button.
The groups now appear in Assigned resource groups.
To assign a resource group dynamically

Master Groups.
The Master groups list screen opens.
2. Click one of the existing master group names.
The master group’s screen opens, with the General tab selected.
3. In the Resource Groups column click the link associated with the
master group you want to configure with resources.
The Resource Groups configuration screen opens.
2 - 96
4. From the Available list, select the resource group or groups you
want to make accessible to users in the master group.
You can use the Shift and Ctrl keys to select multiple resource
groups.
5. Click the Add button to add the resource groups to the Selected list.
See Figure 2.1, on page 2-2, for a visual representation of the relationship
between users, master groups, resource groups, and favorites categories.
To edit a resource group association

Resource Groups.
The Resource groups list screen opens.
2. In the Network access, Portal access, or Application access column
for any resource group, click the Edit link.
The category’s favorites screen opens.
3. Configure the favorites you want.
For more information about favorites, see Configuring resource
group favorites, following.
Tip
You can switch to a different resource group by selecting a group from the
Resource Group list. This is an easy way to switch from one resource group
to another, without returning to the Resource groups list screen.
Configuring resource group favorites

Once you have created resource groups, the next step is to configure
favorites for the resource group. Any user who belongs to a resource group
automatically gets the configured favorites of that resource group. Favorites
include web applications, Windows files, App Tunnels, Legacy Hosts,
Terminal Servers, Portal Access, and Network Access. You configure the
favorites for resource groups based on which users have the resource groups
assigned to them. or their master group
• Web Application favorite
Provides remote users with secure access to Web servers on your
organization intranet. For more information, see Defining favorites for
Portal Access Web Applications access, on page 7-6.
• Windows Files favorite
Provides remote users with the ability to browse and view files stored on
Windows servers on your LAN. For more information, see Configuring
Windows files, on page 7-36.

Chapter 2
• App Tunnels favorite

Gives a remote FirePass controller user to access a TCP/IP client/server
application on your LAN. For more information, see Configuring master
group settings for App Tunnels, on page 6-23.
• Legacy Host favorite
Provides remote FirePass controller users access to legacy applications
on your organization’s hosts. For more information, see Defining legacy
host favorites, on page 6-27.
• Terminal Server favorite
Gives remote users access to computers running Terminal services,
Citrix MetaFrame servers, and VNC servers. For more information, see
Configuring terminal server favorites, on page 6-33.
• Network Access favorite
Provides remote FirePass controller users with SSL VPN access to
applications and network resources on your LAN. For more information,
see Chapter 5, Configuring Network Access.
Impersonating a user
You can use the Impersonate User feature to log on as if you were a user.
This feature can help you troubleshoot configuration once everything is
configured. You can find Impersonate User on the Users item in the
navigation pane. This feature is useful for checking favorites that you create
and for troubleshooting other connection issues.
Important
When you impersonate a user, the system ends your administrative session.
The impersonation process skips the step of authenticating the user. In order
to skip authentication, the FirePass controller must have sufficient
information about those users to treat them appropriately. Therefore, you
can impersonate only those users whose information is maintained in
FirePass controller data store.
When you log on using the Impersonate User feature, the system behaves as
if users were authenticated, even if those users can not pass the normal log
on procedure. While impersonating a user, you do not have access to any
network resources that require logging on.
While you are impersonating a user, the system records the actions of the
impersonated user in the Sessions report, available in Reports : Sessions.
Because the user did not actually log on, the system does not record an entry
in the Logon report.
Note
Although you can impersonate deactivated users, you do not have access to
any of the users’ assigned resources.
2 - 98
3
• Understanding endpoint security
• Using pre-logon sequences
• Understanding pre-logon sequence flow
• Implementing client system checking
• Creating pre-logon sequences to protect resources
• Creating protected configurations
• Protecting resources
• Configuring post-logon protection
• Using other kinds of protection

Understanding endpoint security

Endpoint security is a centrally managed method of monitoring and
maintaining client-system security. The FirePass controller provides three
mechanisms for accomplishing endpoint security:
• A pre-logon sequence, which defines a set of actions that need to be
taken in order to evaluate the client system or device.
• A protected configuration, which takes information gathered by the
pre-logon sequence and instructs the system to respond based on the
result.
• Resource protection, which uses a protected configuration to protect a
set of resources you have defined.
Endpoint security performs three basic tasks:
◆ Collects information about the client system
For example, whether the user is operating from a company-issued
computer, what antivirus software is present on the machine, what
operating system the computer is running, and others. This is
accomplished by the pre-logon sequence.
◆ Performs remediation, if possible
For example, puts the system into the protected workspace, prompts the
user to download antivirus software, and provides other solutions.
Remediation information is based on information gathered by the
pre-logon sequence.
◆ Protects resources based on the collected information
For example, prevents access to a resource until the user downloads and
installs the antivirus software requested, and others. This is accomplished
by creating protected configurations and assigning them to protect
resources.
Collecting information
The FirePass controller collects various types of information about the client
system using browser add-ons. In clientless mode, that is, when the
inspection process does not download any controls or plug-ins, the endpoint
security process inspects the HTTP headers to gather the information.
The FirePass controller provides checking primarily for Windows-based
systems, and some of the checking is not supported on Mac OS X or Linux
systems. The FirePass controller does support file checking on Mac OS X
and Linux systems. Table 3.1, following, shows the complete list of
inspectors.

Chapter 3
Using the inspectors

Inspectors are the basic working functionality for sequences. An inspector is
a browser add-on that gathers information about the user’s computer,
evaluating factors such as the presence of viruses or antivirus software,
operating system version, running processes, and others. The pre-logon
sequence determines which inspectors to activate, and the inspectors
evaluate the system of the user logging on. Depending on the outcome of
evaluation, the FirePass controller permits the to continue, initiates an
action, presents a message, or rejects the attempt. The FirePass controller
supports the following inspectors.
Table 3.1 contains information about each inspector. You can find more
information about session variable usage and operating system requirements
for each inspector in the online help.
Inspector Description
Decision The decision box allows you to present a user options to select from a list. You
can use a rule containing the variable session.user_decision.last.check==1
to match the first option selected by user. Default options are Yes and No, but
you can modify these options, and you can add other options from which the
user can select.
Define custom variable Defines a new variable and assigns a value to an existing one. For more
information about the custom variable, see the section Using variables
generated by inspectors for Action Rule expressions in the online help for the
Pre-Logon Sequence screen.
Extended Windows information Gets version information about the Windows operating system, such as version
and hotfix information from the remote system. This inspector uses the
session.win_info.os_version, session.win_info.hotfixes.count, and
session.win_info.hotfixes.hf_<hotfixname>, which you can then use to
define a rule for a specific action in a sequence.
Far-End Security Integration Provides integration with third-party endpoint security products using the
session.external_security_check.result session variable. A match to
session.external_security_check.result == 1 indicates that the check
completed successfully.
You can use this inspector to detect WholeSecurity’s Confidence Online™
Server, which automatically identifies and eliminates both known and unknown
threats without requiring users to install or update signatures. For more
information about how to use this feature, see the deployment guides for
FirePass controller integration with Whole Security, available on the F5
Networks Solution Center at http://www.f5.com/solutions/.
Google Desktop Search Inspector Checks for the presence of Google Desktop Search software using the
session.google_desktop_check.result session variable. A match to
session.google_desktop_check.result != 1 indicates that Google Desktop
Search is running.
Table 3.1 Pre-logon inspectors
3-2
Internet Explorer information Collects version information about the Internet Explorer software, such as
version and hotfix information, from the remote system. This inspector
generates the variables session.ie_info.version,
session.ie_info.hotfixes.count, and
session.ie_info.hotfixes.hf_<hotfixname>, which you can then use to define
a rule for a specific action in a sequence.
Linux file checker Checks for the presence of certain Linux files and uses MD5 to authenticate
files. This inspector uses the session.file_check_linux.<filename>.result
session variable. A match to
session.file_check_linux.<filename>.result ==1 indicates the presence of the
file with all associated parameters.
Logger Writes user-defined information to the logon and system logs. For the string,
you can use a session variable name enclosed in percent symbols (%) to have
the system substitute the appropriate information. For example, typing Logon
from %session.network.client.ip% creates an entry containing the IP address
for the client system where the logon operation originated.
Mac OS X file checker Checks for the presence of certain Mac OS X files and uses MD5 to
authenticate files. This inspector uses the
session.file_check_macosx.<filename>.result session variable. A match to
session.file_check_macosx.<filename>.result ==1 indicates the presence of
the file with all associated parameters.
Mailer (Sending email action) Sends email to the specified address during the pre-logon operation. For the
string, you can use a session variable name enclosed in percent symbols (%) to
have the system substitute the appropriate information.
For example, you can type the following message text:
Antivirus: %session.detected_av.av_1.name%,
%session.detected_av.av_1.engine_version%,
%session.detected_av.av_1.monitor%,
%session.detected_av.av_1.database_time%,
%session.detected_av.av_1.last_scan%
The following is a sample message constructed using these session variables.
pre-logon: Antivirus: McAfeeAV, 4400, enabled, 2005.08.01.00.00,
2005.07.29.00.00
For a list of session variables, see Using variables generated by inspectors for
Action Rule expressions in the online help for the Pre-Logon Sequence screen.
Important: A busy or incorrectly configured email server can cause an
extended delay in a pre-logon process. You can configure the email server on
the Device Management : Configuration : SMTP Server screen.
Message Presents a message to the user during the pre-logon check and prompts the
user to click the Continue button to continue with the pre-logon check. This
inspector does not return any session variables.
You can use the Endpoint Inspector Details screen to create the message you
want to present. In addition to the content you enter, you can select left
alignment, center alignment, or right alignment of the message text.

Chapter 3
Protected Workspace inspector Controls various aspects of switching Windows 2000 and Windows XP users to
run inside the F5 Networks protected workspace (PWS). Running inside the
PWS, you can restrict users from printing, saving files, or storing information on
a Windows file share. Placing users inside the PWS is especially useful when
your users are working on devices that are outside of company control.
Running inside the PWS only reduces the risk of unintentional or accidental
information leaks, but does not eliminate that risk.
Virtual keyboard enabler Toggles use of the virtual keyboard for client logon operations. Activating this
inspector presents a graphical representation of a keyboard and requires users
to type their password using mouse clicking on the graphical keyboard. This
helps prevent keyboard loggers from harvesting users logon names and
passwords. In addition to presenting the virtual keyboard, you can elect to have
the keyboard graphic reposition itself randomly with each mouse click.
Randomly repositioning prevents captured mouse movements from revealing
password information.
Windows antivirus checker Enforces antivirus protection and performs endpoint checks for viruses.
Using one instance of this inspector, you can check for up to three antivirus
packages. To find the list of supported antivirus packages, see the online help
for the Windows antivirus checker.
Windows file checker Checks for the presence of certain Windows files using the
session.file_check.<filename>.result session variable. A match to
session.file_check.<filename>.result ==1 indicates the presence of the file
with all associated parameters.
Windows firewall checker Checks for the presence of a firewall on the remote system. This inspector uses
the following rules:
running
session.fw.summary.enabled == 1
installed
session.fw.summary.count>0
You can enable the Windows firewall if other firewalls are not enabled. To find
the list of supported firewalls, see the online help for the Windows firewall
checker.
Windows machine certificate Checks for the presence of a machine certificate on Windows clients.
checker
Windows process checker Collects information about running Windows processes using the
session.process_check.<process>.result session variable. A match to
session.process_check.<process>.result == 1 indicates that the process is
running.
Windows registry checker Collects information about Windows registry keys using the
session.process_check.<registry_check_ID>.result session variable. A
match to session.process_check.<registry_check_ID>.result == 1 indicates
the presence of the registry item specified on the details page for this inspector.
Windows Group Policy Inspector Delivers and applies Group Policy settings to endpoint systems.
3-4
Using session variables

You can use session variables to directly control various aspects of a user’s
session. FirePass controller session variables consist of two main sets:
• Session variables defined during pre-logon sequence
The FirePass controller defines these variables while the system performs
pre-logon checking. These variables contain information about the client,
or information that you define for custom variables.
You can find a complete list of these variables in the online help for the
Users : Endpoint Security : Pre-Logon Sequence screen and in the online
help for the Define custom variable inspector.
• Session variables defined during group mapping and user authentication
During dynamic group mapping and user authentication, the FirePass
controller retrieves user attributes from the external Active Directory and
LDAP servers. The system then converts these attributes to session
variables.
Note
The FirePass controller does not convert to session variables attributes

received from external RADIUS servers.
The FirePass controller names the session variables in the following

manner:
session.ad.groupmapping.attribute_name = attribute_value
session.ldap.groupmapping.attribute_name = attribute_value
session.ad.auth.attribute_name = attribute_value
session.ldap.auth.attribute_name = attribute_value
If the attribute contains multiple values, the FirePass controller forms a
space-separated string containing all values, and uses that as the attribute
value.
session.ad.groupmapping.attribute_name = "attribute_value1
attribute_value2…"
session.ldap.groupmapping.attribute_name = "attribute_value1
session.ad.auth.attribute_name = "attribute_value1
session.ldap.auth.attribute_name = "attribute_value1
You can use session variables in the following ways:
• To configure Network Access favorites. For example, you might specify
session.ldap.auth.SubNetAddress in the LAN address space box for a
Network Access favorite. Then, when a user is authenticated, the
FirePass controller substitutes the user’s SubNetAddress value. You can
configure this option in a favorite definition, available on the Network
Access : Resources screen.

Chapter 3
• To configure protection criteria when defining a protected configuration.

For example, in the Custom check expression box you might specify
(session.ldap.auth.NetworkAccessAllowed==”Yes”) AND
(session.ldap.auth.OU==”Sales”)
Then, when the user matching these specifications logs on, the FirePass
controller allows access to the resources protected by that configuration.
You can configure this option in a protected configuration definition,
available on the Users : Endpoint Security : Protected Configuration
screen.
• To configure various rules in pre-logon sequences, which you can then
use for defining protected configuration. You can configure this option in
a pre-logon sequence, available on the Users : Endpoint Security :
Pre-Logon Sequence screen.
• To direct different users to different webtops based on the landing URI
they request. For example, you can use the session variable
%session.userdef.my-dynamic-webtop% for different master groups
on the Portal Access : Web Applications : Intranet Webtop screen. Then,
you create a pre-logon sequence to initialize this custom variable to
appropriate values based on landing URI information.
You can enable the Save user’s session variables to Logon Report option
on the Device Management : Maintenance : Troubleshooting screen to have
the system write a user’s session variables to the Logon report for that user.
Then you can view the variables on the Reports : Logon screen.
WARNING
If logging is enabled on the FirePass controller, you can expect to
experience reduction in performance as a result.
Performing remediation
When the endpoint security process is inspecting the client systems, it can
take several actions to correct the state or condition of the client computer.
◆ Present information to the user
If the inspection process requires the download of certain controls or
plug-ins, and the user does not have sufficient privileges for the
download operation, the system can inform the user and present
recommendations for making the changes necessary, or prompt the user
to download and install a security update. You can present information to
the user using the Information box inspector.
◆ Perform the action needed
If the protection configuration needs a specific condition to be met, and it
is possible to perform the action, the system takes the remediative action
necessary. The following items describe some actions that the system can
take to remediate the situation.
3-6
• If the protection configured requires that the computer run in the

protected workspace, the system can place the running processes into
the protected workspace. The Protected Workspace inspector
performs this action automatically.
• Depending on the action needed, the system can present a list of
options from which the user can select. You can write rules tailored to
the options that you provide. For example, you can write a set of rules
that redirect users to various external logon pages, by defining a
Decision box inspector with different External Logon Page endings.
• If the protection configured requires that a specific process not be
running, the system can prompt the user to halt the process.
• Depending on the protection configured, the system can locate
installed antivirus and firewall software, and configure actions based
on the results returned.
• If the protection configured requires a scan for viruses, the system can
run virus-scanning operations, using actions associated with the
Windows Antivirus Checker Inspector.
• If the protection configured requires an updated version of an
antivirus software package, the system can prompt the user to
download and update the package. You can use the External Logon
Page ending to send the user to a custom page you create on an
external server, or to a page you create in the FirePass controller
sandbox. For more information, search for WebDAV in the FirePass
controller online help.
◆ Request action from the user
If the protection configured requires any action that the system cannot
complete, you can configure a request that the user perform the action
instead. For example, if the protection configured requires an updated
version of an antivirus software package, and the system cannot
automatically download and update the package, you can configure a
request that the user download and update the package before continuing.
Protecting resources
The final task of the pre-logon sequence is to protect resources. Protected
configurations use information that the inspectors gather to protect the
resource you assign them to. Protected configurations use the values that the
pre-logon sequence returns in its session variables to determine how to
respond to requests for resource access.
Important
If you plan to use protected configurations to grant or deny access to
resources, you must construct and activate a pre-logon sequence that
collects all necessary information. If you assign protected configurations to
your resources, but you do not activate a sequence, users receive the
following message: Endpoint check is not activated or pre-logon inspection
failed.

Chapter 3
You can read more about protected configurations in Creating protected

configurations, on page 3-27. You can read more about protecting resources
in Protecting resources, on page 3-31.
Understanding protection options

You can configure protection options based on a number of factors,
including operating system, type of browser used, presence of a specific file
or process, and others. You can also define custom session variables in
pre-logon sequences so that a protected configuration can check whether the
user has passed a particular point in the pre-logon sequence. For more
information about custom session variables, see the online help for the
Endpoint Inspector Details screen for the Define custom variable inspector.
You can select from a wide range of antivirus and firewall software the
FirePass controller supports, such as Symantec® (Norton AntiVirusTM),
Networks Associates (McAfee®), and Microsoft®. The software supported
changes frequently, so the current list is maintained in the FirePass
controller release notes that accompany a specific release. In addition to
antivirus and firewall detection, inspectors provide information about
operating system, file versions, running processes, and others. You can use
this information to configure protection options.
The inspectors you set up on the FirePass controller evaluate or operate on
client systems in several areas:
◆ Antivirus and firewall detection
Detects multiple antivirus and firewall installations on a client computer.
You can use the Windows antivirus checker to determine whether the
user has antivirus software installed, and to scan processes for the
presence of viruses.
Note
You must have an Anti-Virus/Firewall/Inspector license on the FirePass

controller to inspect the client system for antivirus and firewall software. If
you do not have a license, contact your sales representative to get one.
◆ Operating system detection

Discovers the version of the operating system running the client
computer, so that protected configurations can use the version
information.
◆ File version checking
Evaluates the versions of antivirus binaries, DLLs, signature files, and
scan engines to determine whether they match the criteria you configure.
◆ MD5 signature validation
Inspects the MD5 signature of a file on a client system to ensure that the
file has not been tampered with or corrupted.
◆ Scan performance
Performs scans for viruses on the client machine. You can specify several
values to use when scanning for antivirus software:
3-8
• Antivirus vendor
Represents the maker of the antivirus software.
• Engine version
Represents the number assigned to a specific release of the software.
• Database signature
Represents an electronic, encryption-based, secure stamp of
authentication provided by the antivirus vendor by which you can
determine the authenticity of the software.
You can find database signature information by searching the Internet
or checking for the value on a specific product's web site.
• Database update time
Represents the timestamp on the antivirus software on the user’s
computer.
◆ Custom inspector usage
Gathers data related to the custom variable defined.
For more information, see the Endpoint Inspector Details online help for
the Define custom variable inspector.
Understanding protection limitations

For Windows clients, the FirePass controller downloads and installs browser
plug-ins to gather some information on the client device. To install the
controls or plug-ins, the logged on user must have power user rights on the
device. You can also preinstall the controls on the client machine using an
administrator account, or an account that has power user rights. For more
information about installing client components, see Using MSI to preinstall
client components, on page 9-4 and Using the Component Installer, on page
9-4.
In addition, the client’s browser must be configured to allow the running of
browser add-ons and JavaScript, otherwise, the inspection operation might
not collect all of the information needed.
Pre-logon inspection switches to clientless mode automatically if
installation of the required browser add-on failed due to insufficient rights,
or the operating system does not support the control or plug-in. In clientless
mode, information collection and actions that require client components are
not performed. The following actions do not require any client components
to be downloaded to the client system.
• Show virtual keyboard
• Send email
• Check the time on the system
• Check the type of device
• Check the operating system
• Check the client certificate
• Write content to the log

Chapter 3
Using pre-logon sequences

The FirePass controller collects information from the client system by using
inspectors. The various inspectors consist of ActiveX controls or Java
plug-ins that collect information about the client system. When a user first
accesses the FirePass controller, the browser downloads the inspector
control or plug-in needed to check for a specific condition, process, or piece
of data.
You can configure inspectors in pre-logon sequences, a named set of
inspectors, rules, and actions, which evaluates each endpoint system
presented for log on to the FirePass-controlled network.
Protected configurations use information that the inspectors gather. If the
system meets the requirements configured in the protected configuration, the
user is granted access to the resource requested.
You use the visual policy editor to create pre-logon sequences. The visual
policy editor consists of a graphical area in which you click to add and
delete actions and rules to use when inspecting the client system to
determine whether it meets certain conditions.
You can configure pre-logon sequences using options on the Pre-Logon
Sequence screen. To access the screen, click Users, expand Endpoint
Security, and click Pre-Logon Sequence.
For step-by-step procedures for creating a pre-logon sequence, see Creating
the Google Desktop Check pre-logon sequence, on page A-2.
3 - 10
Understanding pre-logon sequence flow

When a pre-logon sequence is active and a user logs on, a series of
operations occur based on the content of the sequence. Figure 3.1 describes
the basic flow.
Figure 3.1 Pre-logon sequence flow
Understanding the visual policy editor

You use the visual policy editor to create and modify the pre-logon
sequences you want to use in checking client systems. The layout of the
sequence in the visual policy editor window provides visual clues to indicate
the flow of the action as it occurs on the client system.
Figure 3.2, following, contains the Corporate Access Check pre-logon
sequence, which you can create by following steps in Denying and allowing
logons from specific operating systems and requiring certificates, on page
A-11.

Chapter 3
Figure 3.2 Corporate Access Check pre-logon sequence with open CHANGE SEQUENCE pane
Note
The Corporate Access Check pre-logon sequence contains an action named

Show virtual keyboard, which is attached to the rule Windows NT and 2000.
This action presents a visual representation for Windows NT and Windows
2000 users to protect against key-logger software. For more information
about the Show virtual keyboard action, see the online help for the Virtual
Keyboard enabler Endpoint Inspector Details screen.
Understanding pre-logon sequence elements

When you construct a pre-logon sequence, you use the visual policy editor
to add actions, which are made up of rules. You can use one of the
predefined actions, or you can construct one of your own. You can add
inspectors to existing or custom actions, and you can build rules for the
inspectors to use.
3 - 12
As you construct pre-logon sequences, you can use the elements described
in Table 3.2.
Element Description
Action Represents one or more inspectors associated with one or more rules. Actions provide the
context for the inspectors. In the visual policy editor, actions appear inside a rectangle.
Rule Contains one or more Boolean expressions that describe a specific condition. Rules
evaluate what information the inspector collects. Each action has a fallback rule that
evaluates to true so you can specify the action to take if the result is not acceptable. For
example, the predefined action Check client certificate contains two rules: yes and
fallback. The yes rule defines the action to take if the result returned is acceptable. The
fallback rule defines the action to take if the result is not acceptable. In the visual policy
editor, rules appear along connecting lines as underlined words.
Ending Indicates the final outcome of the pre-logon inspection. The FirePass controller provides the
following endings: Logon Allowed, Logon Denied, External Logon Page (Client data
posted), Redirect (No client data posted), and Subsequence. In the visual policy editor,
endings appear in a rectangle with a cut-out right edge.
External Logon Page and Redirect perform essentially the same function, except that
Redirect uses the GET command for redirecting and does not send any data to the external
server.
Subsequence Represents a collection of actions, rules, and endings that branch off from the main
sequence path. In the visual policy editor, subsequences appear in the lower portion of the
screen, under the heading Subsequences. In the visual policy editor, a subsequence
appears in a rectangle with a pointed-out right edge when it occurs in the sequence
The subsequence appears in a shaded rectangle with a pointed-out right edge when it
occurs in the subsequence.
Table 3.2 Pre-logon sequence elements
For an example of a subsequence, see Figure 3.2, on page 3-12.

Chapter 3
Implementing client system checking

You want to make sure that all users accessing your resources are running
on computers that meet your security requirements.
The pre-logon sequences you construct gather the information about the
client system. The protected configurations you define use the information
gathered, and associate safety measures to respond to potential threats. Once
you have constructed the pre-logon sequences that gather the client-system
information and defined protected configurations that use safety measures to
address security risks, you assign the protected configurations to your
resources.
In summary, when you implement endpoint security to check client systems,
you must complete several tasks.
◆ Construct the pre-logon sequence
For more information, see Creating pre-logon sequences to protect
resources, on page 3-15.
◆ Create a protected configuration
For more information, see Creating protected configurations, on page
3-27.
◆ Assign the protected configuration
For more information, see Protecting resources, on page 3-31.
Important
You must create the pre-logon sequence to gather the information that the
protected configurations needs. Otherwise, protected configurations block
access.
3 - 14
Creating pre-logon sequences to protect resources

The first task of implementing endpoint security is to create a pre-logon
sequence. In a pre-logon sequence, you configure inspectors to gather the
information you want to have about the client. The inspectors create session
variables containing the detected information. The FirePass controller
passes the information to the protected configuration to determine access to
protected resources. You create and configure pre-logon sequences on the
Users : Endpoint Security : Pre-Logon Sequence screen.
The controller ships with several pre-logon defined sequence templates (for
example, Google Desktop Search block, Collect information with no
pre-logon actions, and Empty), which you can use or modify. You also can
create new sequences, using any of these as your starting point, or an empty
sequence with just a starting and ending point, if you prefer.
Once you create the sequence, you must use the data it gathers by creating a
protected configuration. A protected configuration is a collection of safety
measures or checks that guard the connection and client system against
various kinds of attacks or threats.
Understanding protected workspace

You can create a protected workspace for users, by adding the Switch to
PWS inspector to a pre-logon sequence. Protected workspace is a temporary
user environment, containing a new temporary folder, Desktop folder, My
documents folder, and some temporary registry keys. All requests to real
user folders and certain registry keys are redirected to this temporary
environment, where full access is allowed.
When the user returns from Protected Workspace, the system deletes all
temporary files and keys as part of the clean up process.
FirePass controller provides Protected Workspace to solve the potential
problems that can occur when users access their connection from a public
PC. The Protected Workspace deletes proprietary files, and protects users
from attacks, like keyloggers and screen sniffers.
Note
One of the limitations of Protected Workspace is that only Windows 32-bit

processes can be started. Starting older 16-bit Windows and DOS processes
is not allowed.
Creating a pre-logon sequence

Creating pre-logon sequences basically consists of adding actions in the
visual policy editor. Each action is followed by one or more rules that
specify the criteria that you plan to evaluate, and an ending that follows
depending on the outcome of the evaluation. For more information about

Chapter 3
actions, see Using actions in pre-logon sequences, on page 3-19, and for
more information about rules, see Defining rules for actions in pre-logon
sequences, on page 3-23.
For example, you might want to require that all users operate inside a
protected workspace while they access a specific resource. To do so, you
create a new sequence, and add the action that switches the user to the
protected workspace.
To create a pre-logon sequence that checks whether the

user is in the protected workspace
1. In the navigation pane, click Users, expand Endpoint Security, and
click Pre-Logon Sequence.
The Pre-Logon Sequence screen opens.
2. In the Create new sequence box in the New Sequence area, type a
name for the sequence.
3. From the Based on list, select template : Empty.
4. Click Create.
The new sequence appears in list of sequences in the upper portion
of the screen.
5. Click the edit link next to the sequence you created.
The visual policy editor screen opens.
6. Position the cursor along the connecting line between Sequence
Start and Logon Allowed Page, until you see the Add Action button
.
7. Click the Add Action button .
The screen refreshes to show the change sequence pane.
8. In the list of Predefined actions, select Switch to PWS.
9. Click the Apply changes button.
The screen refreshes to show the Switch to PWS action, along with
two rules: inside PWS, which continues to the Logon Allowed Page
ending, and fallback, which continues to the Logon Denied Page
ending. Figure 3.3 shows the completed pre-logon sequence.
Figure 3.3 The completed sequence containing the Switch to PWS action
3 - 16
Next, you use the data the pre-logon sequence gathered in a protected
configuration. For more information, see Using data gathered by pre-logon
sequences, following.
The active pre-logon sequence runs when a user tries to log on to the
FirePass controller. Only one pre-logon sequence is active at any one time.
A selected button next to the sequence name on the Users : Endpoint
Security : Pre-Logon Sequence screen indicates the active pre-logon
sequence.
Importing and exporting pre-logon sequences

You can import or export pre-logon sequences between FirePass controllers.
This option allows for the efficient configuration of multiple FirePass
controllers.
To use this feature, from the navigation pane, click Users, expand Endpoint
Security, and click Pre-Logon Sequence. You can find import and export
options listed in the Import/Export Sequence(s) area.
Using data gathered by pre-logon sequences

In Creating a pre-logon sequence, on page 3-15, you created a pre-logon
sequence that inspects client systems for the protected workspace. Now, you
can put that data to use in a protected configuration and assign the
configuration to a resource favorite.
To create a protected configuration that uses the data

collected by the protected workspace pre-logon sequence
click Protected Configurations.
The Protected Configurations screen opens, showing a list of
predefined protected configurations.
2. Click the New Protected Configuration link.
The Protected Endpoint Configuration definition screen opens.
3. In the Protected configuration ID box, type a name of up to 30
characters for the protected configuration.
4. In the Description box, type a description, if you wish.
5. From Mode, select the type of access you want.
Check endpoint protection, grant access if check passed is the
default. This is the recommended setting for using protected
configurations. The Temporary bypass check, grant access
always and Temporary bypass check, do not grant access
settings are for temporarily troubleshooting configurations and
logon problems.
You do not need to click Cancel or Save at this point.

Chapter 3
6. Click the Protection Criteria tab along the top of the table.
The Protected Configurations screen opens with the Protection
Criteria tab selected.
7. Click the Information Leaks link.
The screen refreshes to reveal the safety measures or checks
associated with information leaks.
8. From the list, select Protected Workspace, and then click Add.
The Required safety measures or checks area refreshes to contain
the Protected Workspace criterion.
9. Click Save.
The Protected Configurations screen opens, with the protected
configuration you created shown at the bottom of the list.
10. Next, you assign the protected configuration to a resource. For more
information, see Assigning a protected configuration, following.
For more information about creating protected configurations, see Creating

protected configurations, on page 3-27.
Assigning a protected configuration

In Using data gathered by pre-logon sequences, preceding, you created a
protected configuration that uses the protected workspace information the
pre-logon sequence gathers. Now, you can put that protected configuration
to work, by assigning the configuration to the webtop, an entire resource
group, a resource type, or an individual favorite.
To assign a protected configuration to a favorite

1. In the navigation pane, click Portal Access, or Application Access,
and click an existing favorite or the Add New Favorite link.
The favorite definition screen opens.
2. From the Endpoint protection required list, select the protected
configuration you just created.
3. Click Update.
The favorite appears in the list with the protected configuration
assigned. Now, users clicking the favorite are switched to the
protected workspace before being granted access to the associated
resource.
You can also use settings on the Users : Endpoint Security : Protect
Resources screen to assign a protected configuration to a favorite. For more
information, see Protecting resources, on page 3-31.
For more information about creating favorites, see Defining favorites for
Portal Access Web Applications access, on page 7-6, Configuring Windows
files, on page 7-36, Defining legacy host favorites, on page 6-27, or
Configuring terminal server favorites, on page 6-33.
3 - 18
Using actions in pre-logon sequences

An action, depicted by a rectangle in the pre-logon sequence editor (see
Table 3.2, on page 3-13), is an ordered set of active rules for evaluating a
remote system. Each action invokes one or more inspectors. The action then
uses rules to test the inspectors’ findings.
An action invokes rules in the order they appear in the sequence. To change
the order, delete the rule you want to move, and recreate it in the desired
position. If the inspectors’ findings satisfy a rule’s conditions, the sequence
passes to the element in the sequence specified by the rule. Otherwise, the
process moves on to the next rule in the action.
The FirePass controller includes a number of predefined actions. You can
see the available actions in the visual policy editor when you click the Add
Action button , which is activated by positioning the cursor along the
action’s connector line. The action pane appears to the right of the visual
sequence editor, as shown in Figure 3.2, on page 3-12. You can create your
own custom rules in the action pane of the visual policy editor. To follow a
step-by-step lesson in creating your own pre-logon sequence, see Appendix
A, How-To Examples. When you create a new action, the sequence editor
automatically creates a default rule, called fallback. The fallback rule is
always the last rule in the ordered set of rules. It cannot be moved. It
governs all cases that do not satisfy a preceding rule. The default next action
for the fallback rule is the Logon Denied Page ending. You can change this
by editing the ending, inserting additional actions, or adding other rules.
Figure 3.4, following, shows the internal structure of an action.

Chapter 3
Figure 3.4 The flow of control in a pre-logon sequence action
You can see an example of the action pane for the Check for Antiviruses
action in Figure 3.5, on page 3-22, available when you have a license for the
Anti-Virus / FireWall Checker inspector. Table 3.3 shows the rules and
definitions for the Check for Antiviruses action.
3 - 20
Rule Definition
Monitor is running (session.av.summary.monitor >= 1) AND

(NOT(EXIST(session.av_scan.infected) AND
(session.av_scan.infected != 0)))
AV installed (session.av.summary.count>0)AND
(NOT(EXIST(session.av_scan.infected) AND
(session.av_scan.infected != 0)))
Virus detected EXIST(session.av_scan.infected) AND

(session.av_scan.infected != 0)
fallback The default rule for every action
Table 3.3 Rules and definitions for the Check for Antiviruses action
The action pane is where you can type a description for the action, add and
modify the action’s inspectors, and define rules for the action to use. Figure
3.5 contains the Check for Antiviruses’s action pane with the rules shown.

Chapter 3
Figure 3.5 The action pane for the Check for Antiviruses action
For additional information, see the help for each inspector, and review the
rules of the predefined actions shipped with the FirePass controller.
3 - 22
Defining rules for actions in pre-logon sequences

A rule tests the inspectors’ findings about a client system. The outcome of
the evaluation in a rule grants or denies access or sends the flow to the next
action. The order of rules in a pre-logon sequence determines the flow of
action.
In a pre-logon sequence, you use predefined actions with already defined
rules. You can modify these rules or create new rules to test for a specific
condition. You can create custom actions and add your own rules to them.
The ending is the last rule applied. Figure 3.4, on page 3-20, shows the flow
of a rule-checking operation.
A rule uses data from variables returned by inspectors to determine user
access criteria. For more information about variables, see Using session
variables in sequence rules, on page 3-24.
By default, if the system does not meet the requirements, the FirePass
controller denies the user access. You can change the outcome by changing
the sequence ending, and by modifying rules to check for different criteria.
Using rule syntax

You can include the following syntax elements in rules:
◆ Boolean operators: AND, OR, NOT
◆ Operators:
• less than <
• less than or equal to <=
• greater than >
• greater than or equal to >=
• equal to =
• equal to ==
• not equal to !=
◆ Functions: EXIST()
◆ Other symbols: (, ), “
Viewing rule examples

Following are some examples of rules. The first rule defines the criterion
that a user’s system be in the protected workspace.
session.pws.active == 1
The session variable session.pws.active has two possible values: 1, which
indicates that the user’s computer is operating inside the protected
workspace, and 0, which indicates that it is not.
The second example represents a rule that searches for the presence of the
McAfee antivirus software that has an engine version greater than or equal
to 4.3.20, and checks to make sure that the most recent antivirus scan
occurred on or after December 12, 2004, at midnight.

Chapter 3
(EXIST(session.av.McAfeeAV))AND(session.av.McAfeeAV.engine_version >= “4.3.20”)AND(

session.av.McAfeeAV.last_scan >= “2004.12.10 00:00”)
You can see an example of the not running rule included with the
predefined action Google Desktop Search Checker in Figure A.6, on page
A-7. In this case, the rule description is
session.google_desktop_check.result !=1, which indicates that when the
session variable is not equal to 1, then the Google Desktop Search
application is not running.
You can edit a rule by clicking the rule’s link in the visual policy editor. The
rules pane appears to the right of the visual sequence editor, as shown in
Figure A.15, on page A-16.
For additional information, see the help for each inspector and review the
rules of the predefined actions shipped with the FirePass controller.
Using session variables in sequence rules

The rules in pre-logon sequences use the values that the inspectors return in
session variables. A session variable contains a number or string that
represents a specific piece of information. You can specify another action or
an ending in response to the information returned. To understand how rules
operate in sequences, you can view the sequence flow defined in the
predefined actions provided with the FirePass controller.
You can use session variables to create your own rules to use in the custom
actions you define.
To create a rule
click Pre-Logon Sequence.
2. Open an existing sequence, or create a new one.
The visual policy editor opens.
3. Add an action as described in Creating a pre-logon sequence, on
page 3-15.
The action pane opens in the visual policy editor.
4. From the Using list in the action pane, select New action.
5. Click Apply changes.
The sequence refreshes to contain the action New action.
6. In the Name box in the action pane, change the name to a
meaningful title for the action, and add some descriptive text in
Description, if you like.
7. Click Update details.
The visual policy editor refreshes to show the title you specified.
8. Position the cursor along the connecting line between the action you
added and the fallback rule, until you see the Add Action button .
3 - 24

The screen refreshes to show the insert rule pane.
10. In Name, type a name for the rule.
11. In the larger box, type the session variable and the other text you
want to use for the rule.
For information about the expression syntax for rules, see Defining
rules for actions in pre-logon sequences, on page 3-23.
For a list of the session information returned by specific inspectors, see the
online help for the Pre-Logon Inspection screen.
Creating subsequences for pre-logon sequences

Subsequences are defined sequences that run when processing encounters a
branch in the sequence. Subsequences do not pass control back to the parent
sequence from a subsequence; the flow continues through to the
subsequence ending, or to another subsequence. However, when you are
creating sequences, having subsequences can eliminate duplication in
sequences. Using subsequences is particularly useful when you have a
number of actions that all run the same series of rules, actions, and endings.
For example, the Corporate Access Check sequence, which you can create
by following steps in Appendix A, How-To Examples, contains a
subsequence named Subsequence: certificate check that runs at the end of
the Windows XP, Linux, PocketPC, and Mac OS rules.
The subsequences section of the visual policy editor appears below the main
sequence section. You can create and use as many subsequences as you like
to support the sequence you want to apply. Figure 3.6 contains an example
of a subsequence.
Figure 3.6 The subsequence certificate check from the Corporate Access
Check sequence
Browser requirements for endpoint security

The FirePass controller supports only specific browser versions and
functionality. The browser enables communication with the client systems
so that the inspectors can access information and perform scans and other
operations. You can find the most current browser support list in the release
notes. For information about user rights requirements for endpoint inspector
support. see Installing client components on Windows systems, on page 9-2.

Chapter 3
User rights requirements for protected workspace and pre-logon

inspectors
Because of how the FirePass controller supports protected workspace and
pre-logon inspectors, the user must have certain rights for the process to
complete successfully. In most cases, this means the user must have Power
User or Admin rights, or you must preinstall the components using an
account with such rights. For more information, see Installing client
components on Windows systems, on page 9-2.
3 - 26
Creating protected configurations

Once you have determined the client information you plan to gather, you
create protected configurations, named sets of safety checks and security
measures, to assign to resources, applications, and files.
Protected configurations represent the conditions that control access to
resources under their protection. Controlled conditions include what
antivirus software the endpoint system is running, whether a logon comes
from a company-issued computer, what time of day the logon occurs, which
certificate the client is using, and others. Protected configurations provide a
way for you to collect a set of safety requirements, store it under a name of
up to 30 characters, and assign it to a resource to define a very restrictive set
of configurations that govern access to the resources presented to end users.
Security measures help guard against factors that put network resources at
risk. These are described in the risk-factor/safety-feature associations table
on the Protected Configurations configuration screen. To access the screen,
click Users, expand Endpoint Security, click Protected Configurations,
and click the New Protected Configuration link, or click the name of an
existing protected configuration.
In order to use a protected configuration, a pre-logon sequence inspector
must gather the necessary information. For information about pre-logon
sequences and inspectors, see Using pre-logon sequences, on page 3-10.
Important
Protected configurations use the result of the pre-logon and post-logon
operations to determine how to respond to requests for resource access. To
take advantage of protected configurations, you must define and activate a
pre-logon sequence. If you assign a protected configuration without
properly configuring a pre-logon sequence, you lock out all access to that
resource.
You can assign protected configurations at a very granular level by

exempting specific master groups from safety checks configured for a
resource. For a very refined accessibility/protection trade-off, you can
combine safety checks using Boolean logic, as described in the Defining
rules for actions in pre-logon sequences, on page 3-23.
Table 3.4, following, provides a summary of risk factors and associated
protection criteria available for protected configuration definitions.

Chapter 3
Risk factor Available protection
Unauthorized Access The following protection criteria are available for preventing unauthorized access:
Client Certificate
Requires that the client certificate meet criteria specified in properties. For this type of
protection, you must enable a pre-logon sequence.
Trusted Network
Specifies that logon is restricted to traffic arriving from the networks specified in properties.
Time Interval
Restricts access to the days and hours specified in properties. This protection requires no
pre-logon sequence.
Custom Check
Checks variables collected by the pre-logon sequences (or a variable set by the define
custom variable inspector). For this type of protection, you must enable a pre-logon
sequence.
Note: Only the Custom Check protection can use the data returned by the user-defined
variable in a pre-logon sequence. For more information, see the online help for the Endpoint
Inspector Details screen for the Define custom variable inspector.
SSL Encryption Control

Provides options for requiring specific SSL cipher security and SSL protocol versions. You
can read more about SSL cipher and protocol settings in the online help for the Device
Management : Security : User Access Security screen. For this type of protection, you must
enable a pre-logon sequence.
Note: F5 Networks recommends that customers use TLS only protocol option to ensure
maximum FIPS cipher compliance. In addition, to ensure maximum FIPS compliance, F5
recommends that SSL certificates that administrators import into the FirePass controller use
FIPS-approved SHA1 instead of MD5 as their signing algorithm.
To maximize FIPS compliance, configure FirePass systems to allow only TLS (that is, select
the Accept only TLS protocol option), and verify that all RSA private keys for Web Services
have been imported into the FIPS card. On systems with imported keys, the Security box
lists FIPS instead of Normal in the online help for the Configure SSL Certificates screen,
available as a link on the Web Services tab on the Device Management : Configuration :
Network Configuration screen.
No Measure or Check Required

Indicates that no protection is configured for the risk factor. For this type of protection, you
must enable a pre-logon sequence.
Logon Allowed
Checks that pre inspection was done and that logon was allowed. For this type of protection,
you must enable a pre-logon sequence.
Table 3.4 Protected configuration protection criteria
3 - 28
Information Leaks In addition to Client Certificate, No Measure or Check Required, and Trusted Network,
described above, the following protection criteria are available for preventing information
leaks:
Protected Workspace
Requires a user workspace that prevents external access, and deletes any files created
before leaving the protected area. When you add the Protected Workspace protection, the
user is placed into the protected workspace after logging on successfully. Operating inside
the protected workspace restricts access to specific folders, and deletes all files created
when the user logs out. You can read more about using the protected workspace inspector
in the Endpoint Security : Pre-Logon Sequence online help. For this type of protection, you
must use the Protected Workspace inspector in an enabled pre-logon sequence.
Trusted Windows Version

Restricts access to users running specific Windows versions or hot-fixes, as specified in
properties. For this type of protection, you must use the Extended Windows information
inspector in an enabled pre-logon sequence.
Cache Cleaner
Removes content from the cache when users log out. For this type of protection, you must
enable Inject ActiveX/Plugin to clean-up client browser web cache on the Users :
Endpoint Security : Post-Logon Actions screen.
Trusted Browser
Requires use of a browser specified in properties. If you specify Trusted Browser, make sure
also to configure the browsers you want to accept in properties. For this type of protection,
you must use the Internet Explorer information inspector in an enabled pre-logon sequence.
Loggers In addition to Protected Workspace, Trusted Network, Client Certificate, and No

Measure or Check Required, described above, the following protection criteria are
available for preventing access by key-logging programs:
Virtual Keyboard
Specifies that passwords be entered using mouse clicks on a screen representation of a
keyboard. For this type of protection, you must use the Virtual Keyboard Enabler inspector in
an enabled pre-logon sequence.
Registry Control
Associates a result with a specific name generated by a Pre-logon add Windows registry
checker operation. For this type of protection, you must use the Windows registry checker
Process Control
Associates a result with a specific name generated by a Pre-logon add Windows process
checker operation. For this type of protection, you must use the Windows process checker
File Control
Associates a result with a specific name generated by a Pre-logon add Windows file checker
operation. For this type of protection, you must use the Windows file checker inspector in an
enabled pre-logon sequence.

Chapter 3
Virus Attack Antivirus

Requires the presence of specific antivirus software. You specify the antivirus software in the
properties for this type of protection. For this type of protection, you must use the Windows
antivirus checker inspector in an enabled pre-logon sequence.
Firewall
Requires the presence of specific firewall software. You specify the antivirus software in the
properties for this type of protection. For this type of protection, you must use the Windows
firewall checker inspector in an enabled pre-logon sequence.
Note: You must have an Anti-Virus/Firewall/Inspector license on the FirePass controller to
inspect the client system for antivirus and firewall software. If you do not have a license,
contact your sales representative to get one.
3 - 30
Protecting resources
Once you have created the protected configurations you want, you protect
resources, a process of assigning protected configurations to resources,
applications, and file stores. The FirePass controller uses protected
configurations to control access to network resources.
For example, you may have a general configuration for all Network Access
favorites, which require only that the logon arrive from a computer with
installed and running antivirus software. In this case, you would create a
pre-logon sequence that requires company-provided antivirus software,
define a protected configuration that uses the information from the
pre-logon sequence, and assign the protected configuration to all Network
Access favorites. This prevents access to network resources from computers
that are possibly infected, thus protecting your corporate intranet.
The FirePass controller uses protected configurations to control access to
network resources. A protected configuration is a definition of criteria that
users’ systems must meet in order to be granted access to specific resources.
Once you define a protected configuration, you must assign it. You can
assign resource protection at the following levels:
• Webtop
Protects all types of resource favorites.
• Resource type
Protects a class of resource favorites (for example, Web Applications or
Network Access favorites).
• Resource group
Protects all elements defined in resource group including favorites and
access control lists.
• Individual
Protects a single resource (for example, the Sales Intranet).
Protection is cumulative. That is, each type of protection is combined, so

that the effect is additive, affecting all resources at all levels.
Important
Protected configurations use the result of pre-logon and post-logon
operations to determine how to respond to requests for resource access. To
take advantage of protected configurations, you must define and activate a
pre-logon sequence. If you assign a protected configuration without
properly configuring a pre-logon sequence, you lock out all access to that
resource.
You can define custom session variables in a pre-logon sequence, so

protected configurations can check whether a user has passed a particular
point in the logon sequence. For more information, see the online help for
pre-logon sequences. For information about protected configurations, see
Creating protected configurations, on page 3-27. For information about
pre-logon sequences, see Using pre-logon sequences, on page 3-10.

Chapter 3
Configuring endpoint protection for a resource group

You can define protected configurations for a resource group from the
Users : Endpoint security : Protected configurations screen. For information
about protected resources, navigate to the Users : Endpoint security : Protect
resources screen.
To apply endpoint protection to a resource group:

1. In the navigation pane, click Application Access and expand
Legacy Hosts.
The Resource screen opens.
2. From the Resource Group list, select a resource group to which
endpoint security is to be applied.
3. Scroll to the Endpoint Protection Required for this Resource Group
area.
4. From the Endpoint protection list, select a protected configuration.
5. Click the Update button to save your changes.
Understanding protection assignment

This is an example of how to implement access control using protected
configurations.
The sample company has a general configuration for all Network Access
resource favorites, most of which require only that the logon arrive from a
computer running antivirus software. In this case, you create a pre-logon
sequence that requires company-provided antivirus software. In addition, for
the Sales Intranet, the company wants to further require that the employee
use a company-issued laptop authenticated with a client certificate, and that
only members of the Executive and Sales groups are eligible.
For this configuration, the FirePass controller administrator creates and uses
two protected configurations: a general configuration (which allows access
to all Network Access resources not otherwise secured) that requires that the
user’s computer has antivirus protection, and a second configuration (which
grants access to Sales and Executive users with certificate-bearing company
laptops) that allows certain users also to access the Sales Intranet.
3 - 32
Configuring post-logon protection

For additional security, you can configure protection that runs only after the
user logs on to the FirePass controller. You can define a configuration that
downloads browser add-ons to support the following kinds of post-logon
protection.
• Activate cache cleanup to allow attachment downloads in Mobile E-Mail
and downloads from Web Applications.
• Activate cache cleanup to allow file downloads in Windows Files. If this
option is not enabled, the user can only download .zip archives.
• End the FirePass controller session if the user closes the browser or
webtop.
• Uninstall downloaded FirePass controller components.
• Remove dial-up entries that Network Access clients use.
• Uninstall ActiveX components downloaded during the session.
• Empty the Windows Recycle Bin.
• Clean forms and passwords autocomplete data.
• Close Google Desktop Search.
• Inherit caching policy settings from Portal Access Web Applications
configuration.
Note
The Terminates user session option ends the FirePass controller

connection when the user does not input data from his keyboard or mouse
within a specified period of time (1 minute to 4 hours). By default, this
option is disabled.
You can specify different post-logon protection for each master group.
For more information on each of these options, see the help for the
Post-Logon Actions screen, available under Users : EndPoint Security.

Chapter 3
Using other kinds of protection

In addition to the protected configurations described in Table 3.4, on page
3-28, there are other protections such as:
• Two-factor authentication
For information, see Configuring client-certificate two-factor
• Using certificates
For information, see Setting up client-certificate-based authentication,
on page 2-85.
• Pre-logon inspection
For information, see Using pre-logon sequences, on page 3-10.
• Requiring strong passwords
For information, see Setting up initial signup on LDAP with subsequent
strong internal password, on page 2-81.
• Configuring other authentication features for groups
For information, see Setting up authentication, on page 2-67.
3 - 34
4
• Understanding SSL server certificates
• Managing certificates on the FirePass controller
• Generating a Certificate Signing Request or

self-signed certificate
• Installing and configuring client root certificates
• Using OCSP to validate client certificates

Understanding SSL server certificates

The SSL (Secure Sockets Layer) protocol uses the certificate to establish a
secure connection. A valid SSL server certificate, also known as a security
certificate, is necessary for establishing secure HTTPS connections. An SSL
server certificate identifies your server to any connecting client browser.
The certificate contains information identifying the server, the organization
it was issued to, as well as an expiration date. Most browsers that support
SSL connections have internal lists of Certificate Authorities (CAs), and
automatically accept certificates issued by these organizations. If there is an
error, some browsers display security warnings; other browsers, notably
those found on wireless devices such as PDAs or smart phones, might refuse
a connection.
Note
When a signed certificate expires and you do not plan to update it, you
should delete it from the FirePass controller. For information on how to
delete a certificate, see Deleting installed certificates, on page 4-12.
Using server certificates on the FirePass controller

When a user connects to the FirePass controller, the FirePass controller
presents a server certificate to the client browser. The browser validates the
certificate based on its internal list of trusted certificates from CAs, and, if it
finds a match, allows the connection. The browser displays a warning if:
• There is no corresponding CA certificate to validate against.
• The name of the server certificate does not match the name of the server
(the FirePass controller) in the URL.
• The certificate is expired.
The FirePass controller includes a preconfigured, default SSL server

certificate for firepass.company.xyz. You can use this certificate while
configuring and testing a FirePass controller, but the certificate is not
unique, and the certificate’s server name will not match the name you give
to the FirePass controller, so anyone connecting to the FirePass controller
sees warning messages from their web browser.
Important
Before you make the FirePass controller available to external users, you
should replace the default server certificate with a permanent certificate
that is appropriate for your environment.

Chapter 4
Using Certificate Authority-signed SSL server certificates

Most organizations should purchase and install a server certificate signed by
a known, trusted CA. A CA-signed certificate provides a high level of trust
by verifying that the server is actually what it claims to be. Most web
browsers automatically recognize server certificates issues by known,
trusted CAs, and FirePass controller users can log on without seeing
warning or error messages.
To obtain a trusted server certificate, submit a Certificate Signing Request
(CSR) to a trusted CA such as Thawte or Verisign. The CA verifies your
organization’s identity before issuing a signed certificate.
You can generate a CSR from the FirePass controller Administrative
Console. For more information, see Generating a Certificate Signing
Request or self-signed certificate, on page 4-6.
Using self-signed SSL server certificates

An alternative to a CA-signed server certificate is a self-signed certificate. A
self-signed server certificate is a digital certificate signed by its owner. The
self-signed certificate that the FirePass controller generates provides a
greater level of trust than the default certificate, but it is not as secure as a
CA-signed certificate.
Note
All production-level FirePass controllers should have a server certificate

signed by a known, trusted CA.
A self-signed certificate is automatically recognized by client browsers, so

users connecting to a FirePass controller that has a self-signed certificate
installed may see warnings posted by the browser. The user can add the
certificate to the browser’s accepted list to eliminate the warnings. For
details on self-signed certificates, see Generating a Certificate Signing
Request or self-signed certificate, on page 4-6.
A CA-signed server certificate provides the highest level of trust, but a
self-signed certificate may provide an acceptable level of trust for some
production environments. A self-signed certificate has not been validated by
a trusted organization, but it is unique (the default FirePass controller server
certificate is not).
Understanding reverse proxy backend server certificate

verification
FirePass controller supports validation of SSL server certificates for any
intranet servers accessed using the reverse proxy. Use this feature to validate
all HTTPS servers’ certificates. The General Certificate Authority (CA)
4-2
bundle is used for verification if a backend SSL certificate is not installed

from this screen. Otherwise only an installed certificate (without general CA
bundle) is verified.
The certificate verification policy includes the following standard checks:
• Date/expiration check for all certificates in chain
• Matching Common Name field to site name for the end-user certificate
• Validate all certificates in chain
• Matching Basic Constraints field to true for root and intermediate
certificates. This feature must have rights for signing and corresponding
appointment (Basic Constraints: CA:TRUE)
The system carries out verification at the handshake stage, but the
connection with the backend server breaks if any errors are detected in the
certificate chain. In this case an error notification screen is generated for the
user.
The certificate must begin and end as shown below:
‘-----BEGIN CERTIFICATE-----’
‘-----END CERTIFICATE-----’
Backend SSL certificate options

The backend server certificate screen has two configuration options.
• Check server certificate for SSL connection (Web Applications)
Select this option to improve security for your intranet applications. The
server certificate installed from this page allows you to support security
policies on the backend SSL.
• Check server certificate for LDAP SSL connection
Select this option to enforce the certificate check when the system makes
LDAP queries over SSL. Clear this checkbox if you are using secure
LDAP servers with unrecognized certificates. This option is useful when
the certificates on the backend SSL servers are issued by non-standard
Certificate Authorities.
To install a backend SSL certificate

Security, and click Back End SSL.
The Install Backend SSL Certificate screen opens.
2. Click the Browse button.
3. Navigate to the certificate in PEM format and click Open, or paste
the certificate text into the box provided.
4. Click the Update button to install the new server certificate.
5. Check the box Check server certificate for SSL connection (Web
Applications) to activate verification certificates on the SSL
backend.

Chapter 4
6. Check the box Check server certificate for LDAP SSL

connection to enforce the certificate check when making LDAP
queries over SSL.
A service restart is required following configuration of the server
certificate for SSL or LDAP SSL.
4-4
Managing certificates on the FirePass controller

A pre-installed, default server certificate (for firepass.company.xyz) is
included on each FirePass controller. This certificate is intended only for
testing and initial configuration. It should not be used for any other purpose.
Before you make secure connections using the FirePass controller, you
should install at least one signed SSL server certificate.
When you want to manage server certificates, you can use options on the
Device Management : Security : Certificates screen.
• Display and review information about installed certificates
• Generate Certificate Signing Requests (CSRs) to submit to trusted
Certificate Authorities
• Install server certificates issued by known, trusted CAs
• Generate and install self-signed server certificates
• Update installed certificates
• Delete installed certificates
• Configure certificate revocation lists (CRLs) and Online Certificate
Status Protocol (OCSP)
Displaying information on installed certificates

You can determine what server certificates the FirePass controller has
installed, and view basic information about each certificate. The SSL Server
Certificate screen displays the following information:
• Status of the certificate (Valid or Fake. A status of Fake means the
certificate is invalid or has expired.)
• Names of the certificate and private key files
• Common name on the certificate
• The issuer of the certificate
• The certificate’s expiration date
To access the server certificates information

The IP Configuration screen opens.
The Web Server Configuration screen opens.
3. Click the Configure SSL Certificates link.
The SSL Server Certificate screen opens.
The SSL Server Certificate screen lists all the server certificates that
you have installed on FirePass controller. If you have not installed
any certificates, the SSL Server Certificate screen lists only the
default certificate for firepass.company.xyz.

Chapter 4
Generating a Certificate Signing Request or

self-signed certificate
To install a server certificate, you first send a Certificate Signing Request
(CSR) to a trusted CA or create a self-signed certificate on the FirePass
controller. The FirePass controller provides functionality that automates the
process of getting a CA-signed certificate. When the CSR is generated, you
can save it, and submit it to a trusted CA. The CA verifies the identity of the
FirePass controller and sends you a signed digital certificate.
The self-signed certificate does not need to be sent to a CA. You can do one
or both of the following actions.
• Install the certificate on the FirePass controller using the process
described in To generate a certificate request or a self-signed certificate,
following.
• Install the certificate on the client computers using the procedures
described in Installing a self-signed certificate on client computers, on
page 4-10.
To generate a certificate request or a self-signed certificate

Security, and click Certificates.
The Certificates screen opens.
2. In the Renew/Replace SSL Server Certificate section, click
Generate to generate a CSR, or click Self-Sign to generate a
self-signed certificate.
The SSL Server Certificate screen opens, containing the Generate
New Certificate Request or Generate New Self-Signed Certificate
options, depending on what you clicked.
3. In the Server Name box type the fully qualified domain name
(FQDN) of the FirePass controller.
The following characters are not accepted in any certificate request
box: < > ~ ! @ # $ % ^ * / \ ( ) ?.,&
Note: Make sure the name you specify matches the name to be used
to access the FirePass controller on the web service using this
certificate.
4. In the Country Name box, type the two-letter country code, US for
the United States of America, JP for Japan, and so on.
5. In the State box, type the state or province in which your
organization is located.
6. In the City box, type the city in which your organization is located.
7. In the Company box, type your organization name.
8. In the Organizational Unit box, type the name or title of your
organizational unit.
4-6
9. In the Contact Email box, type your email address.

The CA uses this address for verification purposes, and for
notification at certificate-renewal time. If this is your first certificate
request, the CA may require additional information to verify your
identity and the validity of the data.
10. If you are generating a self-signed certificate, select an interval from
the Expiration list.
The default time limit is 1 month. If you plan to use the self-signed
certificate instead of a CA-signed certificate, select a time limit of
two years or longer.
If you are generating a CSR, the CA specifies the time interval
during which the signed certificate is valid, based on the time
interval purchased.
11. In the Encryption Password and Confirm Password boxes, type
the password for the FirePass controller to use to encrypt the
generated private key. A password must be at least four characters
long.
Note: Make a note of the password you specify; you will need this
password when you install the signed certificate.
12. Click the Generate Request button to generate a CSR, or click the
Generate Certificate button to generate a self-signed certificate.
The SSL Server Certificate screen opens, with a message saying
your CSR or self-signed certificate has been generated.
Note: If you skipped or mis-typed any required value, the screen
displays an error message when you click the generate button.
Correct the problem and click the appropriate generate button
again.
13. Review the information for accuracy.
14. Click the here link to download the CSR or self-signed certificate to
your local hard drive.
To avoid certificate warnings, users can add this self-signed
certificate to their browser’s list of acceptable certificates.
15. When prompted, download the CertRequest.zip or Cert.zip file to
your computer.
The .zip file contains three files, which differ depending on what
you generated.
Important
The FirePass controller does not save the CSR. You need to click the here
link to download the ZIP file to a safe location.
Submitting the CSR

For CSRs, the CertRequest.zip file contains the following files:

Chapter 4
• README.html
Contains instructions for submitting the CSR to a known CA. You can
view this file using any browser.
• newcert.csr
Contains the content for the CSR.
• new.key
Contains the private key that corresponds to the certificate (encrypted
with the password you specified). Keep this file in a safe place. You need
it when you install your CA-signed certificate.
Submit your CSR to a known, trusted CA. Typically, certificate vendors
provide a web form in which you can paste the contents of the CSR file.
Alternatively, you can submit your CSR as an email attachment. If the
vendor requests a certificate type, specify mod_ssl (Apache). As part of the
verification process, the CA might contact you to verify details you
submitted in the CSR.
Understanding the files generated for the self-signed certificate

For self-signed certificates, the cert.zip file contains the following files:
• README.html
Describes the contents of the newcert.crt and newcert.key files.
• newcert.crt
Contains your newly generated self-signed SSL server certificate.
• newcert.key
Contains the private key that corresponds to the certificate (encrypted
with the password you specified).
Self-signed certificates are automatically available for use on the FirePass

controller, once the certificate had been generated and saved. Self-signed
certificates do not require installation.
Installing a server certificate

Install a signed server certificate on the FirePass controller before you allow
any user to log on. You can install any of the following types of certificates.
◆ A CA-signed certificate
If you install a CA-signed certificate, users should not see warning
messages from their browsers.
◆ A self-signed certificate
If you install a self-signed certificate, users might see warning messages
from their browsers unless you also install the self-signed certificate in
the browser’s certificate store on the user computers. Self-signed
certificates provide a limited level of security, but may be appropriate for
a pre-production environment, for example. For information on installing
a self-signed certificate on user browsers, see Installing a self-signed
certificate on client computers, on page 4-10.
4-8
◆ An intermediate certificate
If you are using a CA-signed intermediate certificate (also known as a
chaining certificate), install the intermediate certificate when you install
your signed certificate.
You need the private key associated with the certificate, as well as the
encryption password. If you are generating a CSR using the FirePass
controller, the key (new.key) is in the zipped file that you saved.
To install a server certificate

Security, and click Certificates.
The Certificates screen opens.
2. Click Install.
3. Open the certificate file using a text editor, and copy the entire
content of the file to the system clipboard.
If you are installing a self-signed certificate, this is the newcert.crt
file.
4. Paste the certificate text into the box labeled Paste the new
certificate in PEM format (for Apache + mod_ssl) here.
PEM-formatted content is denoted by the presence of
----begin cert and end cert---------- tags.
5. Open the private key file (newcert.key) in a text editor, and copy its
entire contents to your system clipboard.
6. Paste the private key text in the box labeled Paste the
corresponding cryptographic key in PEM format here.
7. In the Enter password here box, type the password you used when
you generated the CSR or self-signed certificate.
8. If you are using an intermediate certificate, paste that in the box
labeled Optionally, put your intermediate certificate chain here
(in the PEM format).
9. To complete the installation process, click the Go button.
Note
If the FirePass controller is configured with FIPS 140-encryption hardware,

the certificates and private keys are automatically stored in the FIPS
hardware. You do not need to perform any additional steps when installing
certificates on FirePass controllers equipped with FIPS hardware.
The certificate is installed on the FirePass controller. You must now

configure a Web service to use the certificate. For details on configuring a
web service, see the online help for the Web Services tab of the Device
Management : Configuration : Network Configuration screen.

Chapter 4
Associating an SSL server certificate with a web service

After you have installed the CA-signed or self-signed certificate, you
associate it with a web service.
To associate an SSL server certificate with a web service

3. In the Web Server Configuration table, click the Configure link for
a service that has SSL enabled.
The web services that are SSL-enabled contain the text SSL in the
Use SSL column of the table.
4. From the Certificate list, select your newly installed certificate and
key.
Note: You can view details about each certificate on the SSL Server
Certificate screen. To access the screen, from the Web Services
screen, click the Configure SSL Certificates link.
5. Click Update.
6. When you are finished, click the Finalize tab at the top of the screen
and follow the instructions to put the changes into effect.
Installing a self-signed certificate on client computers

Client browsers do not recognize a self-signed certificate unless you install
it in the browser’s certificate store.
For example, when a user uses Internet Explorer to connect to a FirePass
controller that is using a self-signed certificate, the browser presents a
security alert that states that the certificate was issued by a company you
have not chosen to trust. To eliminate browser warning messages when
using a self-signed certificate, install the certificate on each client browser.
You can pre-install the certificate on each browser, or you can have each
user install the certificate when the browser displays a warning.
To install a self-signed certificate in the Internet Explorer

browser store
1. Connect to the FirePass controller using the URL associated with
the certificate.
A warning should appear.
2. Click the View Certificate button on the browser warning.
Most browsers display a warning that includes an option to view the
certificate.
4 - 10
3. Follow the prompts to install a certificate on the local browser.

For details on installing a signed certificate on other browsers, see the
browser’s documentation.
Updating installed server certificates

It is important to keep your server certificate valid by renewing it as
necessary, usually every year. You can use the FirePass controller
Administrative Console to update a CA-signed certificate that is going to
expire. The issuing CA warns you when a certificate that they signed is
about to expire, and you have the option of renewing it.
You can check the expiration date of the server certificate on the Device
SSL Certificates screen. For steps that show you how to access the SSL
Certificates screen, see the following procedure.
When you update the expiring certificate with the new certificate that the
CA sends, you will also need the private key that was created when you first
generated the CSR.
Note
If you update an existing CA-signed certificate, you do not need to

reconfigure the web services that are using that certificate. If you install a
new certificate, you must configure the web services to use that certificate.
To update an installed certificate

4. Click the Edit link in the right column of the certificate you want to
update.
The SSL Server Certificate screen opens, displaying details of the
certificate you selected.
5. Copy the new CA-signed certificate, and paste it into the Paste the
new certificate in the PEM format (for Apache + mod_ssl) here
box.
6. Copy the private key (from newcert.key in the CertRequest.zip
file you saved when you generated the original CSR) and paste it in
the Paste the corresponding cryptographic key in PEM format
here box.
7. In the Enter password here box, type the password you created
when you generated the original CSR.

Chapter 4
8. To update the CA-signed certificate, click the Go button.
Deleting installed certificates

You may need to delete an installed server certificate, for example, if you
have been using a self-signed certificate while waiting for a CA-signed
certificate to be issued, for example.
To delete an installed certificate

Note: If you have not installed any certificates, the SSL Server
Certificate screen only lists the default, internal certificate for
firepass.company.xyz. You cannot delete the default FirePass
certificate.
4. Check the box to the left of one or more certificates, and click the
Delete Selected button.
5. When you are finished, click the Finalize tab at the top of the
screen, and follow the instructions to put the changes into effect.
4 - 12
Installing and configuring client root certificates

You can use one of the following methods to install a client root certificate
and issue client certificates to users.
◆ If your company already has a PKI (Public Key Infrastructure) in place
for deploying client certificates to users, you can leverage it for use with
the FirePass controller. To do so, complete these tasks:
• Install on the FirePass controller the client root certificate only (no
private key) from your PKI server, along with a certificate revocation
list (CRL).
• Enable the client certificate two-factor authentication, passwordless
authentication, policy checking, or dynamic group mapping functions.
The FirePass controller then uses your existing PKI for deploying client
certificates to users.
◆ If your company does not have a PKI in place, then you can use the
FirePass controller’s built-in client certificate PKI capabilities. The
FirePass controller can generate a self-signed client root CA certificate,
generate and issue client certificates for users, and manage an internal
CRL. After generating a self-signed client root CA certificate, you can
generate and email or download PKCS#12 certificate packages for
individual users (on the Users : User Management screen, by editing
each user’s details). Then, you can install them on the client computers.
◆ If your company does not have a PKI in place, but has purchased or
generated an appropriate root CA certificate for issuing client
certificates, you can install it on the FirePass controller (including the
private key), and the FirePass controller can perform the same functions
as those described for the self-signed client root CA certificate.
Note
Use of smart card-based security solutions is fully supported with the

FirePass controller. With these solutions, a client certificate is made
available to the user’s web browser, and this certificate is then provided to
the FirePass controller as part of initial SSL session negotiation. You must
install the issuing client root certificate on the FirePass controller which
corresponds to the client certificate provided by the user’s smart card.
Using CRLs and OSCP

A certificate revocation list (CRL) is a list of revoked certificates. The CRL
describes the reason for the revoked status of the certificate, and provides
the certificate’s issue date and originator. The list also notes its next update.
When a user with a revoked client certificate attempts to log on to the
FirePass controller, the FirePass controller allows or denies access based on
the user’s CRL entry.

Chapter 4
A CRL is one of two common methods for maintaining valid,

certificate-based access to servers in a network. The other method is Online
Certificate Status Protocol (OCSP), and it has superseded CRL in some
instances. The main limitation of CRL is that the current state of the CRL
requires frequent updates. On the other hand, OCSP checks certificate status
in real time. You can read more about OCSP in Using OCSP to validate
client certificates, following.
On the Device Management : Security : Certificates screen, you can
configure the FirePass controller to periodically retrieve CRLs from
specified URLs using HTTP or HTTPS. The FirePass controller provides
options for specifying the hour to retrieve CRL updates, as well as retrieval
frequency options ranging from every five minutes to every twelve months.
Note
You should not configure CRL updates if you are using the FirePass
controller to generate and issue client certificates to users (using either a
self-signed client root CA certificate, or a client root CA certificate from a
trusted CA). In this case the FirePass controller manages CRLs internally.
On the FirePass controller, you must specify CRLs in PEM format,

beginning with '-----BEGIN X509 CRL-----' and ending with
'-----END X509 CRL-----'.
4 - 14
Using OCSP to validate client certificates

The Online Certificate Status Protocol (OCSP) enables applications to
determine the revocation status of a certificate. OCSP provides more timely
revocation information than is possible using CRLs, and may also be used to
obtain additional status information. An OCSP client issues a status request
to an OCSP responder and suspends acceptance of that certificate until the
responder provides a response.
The FirePass controller supports OCSP validation of client certificates. For
a step-by-step procedure, see the online help for the Device Management :
Security : Certificates screen.
Note
Do not use Client Certificate OCSP if you are using the FirePass controller
to generate/issue client certificates to users (using either a self-signed client
root CA certificate, or a client root CA certificate issued by a trusted CA). In
this case, the FirePass controller is managing CRLs internally.

Chapter 4
4 - 16
5
• Introducing Network Access
• Configuring global Network Access settings
• Configuring Network Access resource group

settings
• Configuring Network Access master group settings

Introducing Network Access

The FirePass controller Network Access feature provides secure access to
corporate applications and data using a standard web browser. Using
network access, employees, partners, and customers can have access to
corporate resources when they are working from home and traveling outside
the company. Sending connections through the FirePass controller helps
keep them secure.
The FirePass controller’s Network Access feature provides users with the
functionality of a traditional IPsec VPN client. Unlike IPsec, however,
Network Access does not require any pre-installed software or configuration
on the remote user’s computer. It is also much more robust than IPsec VPN
against router and firewall incompatibilities. For more information about
client component downloads, see Downloading client components, on page
9-1.
Users connected through Network Access have equivalent functionality to
those users directly connected to the LAN. You can use pre-logon checks
and protected configurations to control access to Network Access. For
information about pre-logon checks, see Using pre-logon sequences, on
page 3-10, and for information about protected configurations, see Creating
Understanding Network Access features

FirePass controller enables automated, secure access for applications by
providing secure system-to-system or application-to-application
communication. Using Network Access, applications can automatically start
and stop network connections without requiring users to log on again. This
enables faster connections for end users while reducing client application
installation.
Network Access provides support in several areas.
◆ Full access from any client
Provides Windows, Macintosh, Linux, and PDA users with access to the
complete set of IP-based applications, network resources, and intranet
files available, as if they were working at their desktop in the office.
◆ Split tunneling of traffic
Provides control over exactly what traffic is sent over the Network
Access connection to the internal network and which is not. This feature
provides better client application performance by allowing connections
to the public Internet to go directly to the destination, rather than being
routed down the tunnel and then out to the public Internet.
◆ Client integrity checking
Detects operating system and browser versions, antivirus and firewall
software, registry settings, and active processes and programs to ensure
the client configuration meets the organization’s security policy for
remote access.

Chapter 5
◆ Compression of transferred data

Utilizes GZIP compression to compress traffic before it is encrypted,
reducing the number of bytes transferred between the FirePass controller
and the client system, improving performance.
◆ Routing table monitoring
Monitors changes made in the client's IP routing table during a Network
Access connection. You can configure this feature to halt the connection
if the routing table changes, helping prevent possible information leaks.
◆ Session inactivity detection
Closes Network Access connections after a period of inactivity, which
you can configure. This feature helps prevent security breaches.
◆ Automatic applications start
Starts a client application automatically after establishing the Network
Access connection. This feature simplifies user access to specific
applications or sites.
◆ Automatic logon support
Opens configured connections and completes configured drive mappings
without requiring user intervention.
◆ Automatic drive mapping
Connects the user to a specific drive on the intranet. This feature
simplifies user access to files.
◆ Resource protection
Controls access to a network resource using configured rules, based on
the type of device being used for remote access. This feature helps secure
connections from unauthorized sources.
◆ Protection definitions
Collects data about a client machine and compares it with a set of safety
measures and protection criteria to mitigate the risk of unauthorized
access, information leaks, loggers, and virus attacks. You can name the
collection and assign it to protect various resources.
◆ Packet-based, group-based IP filters
Restricts groups of users to particular types of traffic, ports, and
addresses or ranges within the internal network. Also supports auditing
capabilities with packet-filter logging. The feature provides full
client-server application support without opening up the entire network
to each user.
◆ Minimized network router reconfiguration
Provides plug-and-play installation without reconfiguration of your local
network’s routing when Network Address Port Translation (NAPT) is
used. For more information about NAPT, see Table 5.1, in Configuring
global Network Access settings, on page 5-6.
◆ Flexible IP address assignment
• Static IP addresses
Assigns users IP addresses that do not change.
5-2
• IP address using RADIUS

At time of authentication, retrieves IP addresses from an external
RADIUS server using RADIUS attribute 8 (Framed-IP-Address).
• IP addresses from a pool
Assigns IP addresses dynamically from an internally configured pool
of addresses.
• DHCP Server
Assigns IP addresses using DHCP.
Understanding FirePass controller Network Access

The FirePass controller’s Network Access feature implements a
point-to-point network connection over SSL. This is a secure solution that
works well with firewalls and proxy servers. Network Access gives remote
users access to all applications and network resources. It uses standard
HTTPS protocol and works through proxy servers.
Comparing connections in Network Access and App Tunnels

While the FirePass controller’s Application Access and App Tunnels
features provide remote users with access to particular applications on a
specific server and port, Network Access can provide access to all
applications and network resources that you configure.
You can use endpoint security checks, protected configurations, recurring
policy checks, split tunneling, and IP filtering to help secure against
unauthorized client access, and restrict resources available over the Network
Access connection.
Understanding how Network Access works

Network Access global settings specify IP address pools that the FirePass
controller uses to assign IP addresses to a client computer’s point-to-point
protocol (PPP) adapter. When the end user opens the address of the FirePass
controller in their web browser, the browser opens an SSL connection to the
FirePass controller. The user can then log on to the FirePass controller. You
can see a visual representation of how Network Access works in Figure 5.1,
following.

Chapter 5
Figure 5.1 Illustration of Network Access process
Using client applications with Network Access

The applications that users run during Network Access connections are the
same ones they run in their daily work. For example, if Outlook is their
email application and Windows Explorer provides file browsing, then these
are the applications they use for Network Access connections as well. This
makes Network Access connections ideal for corporate laptop use or use
with known systems, such as an employee’s home computer. Using
Network Access, users can leverage knowledge of familiar applications, and
do not have to learn a different application.
This differs from the FirePass controller Portal Access configurations,
which would run Outlook Web Access instead of Outlook, and would use
FirePass controller’s Windows Files connections instead of the Windows
Explorer interface. For more information about the Portal Access feature,
see Introducing Portal Access, on page 7-1.
When users click a Network Access link on the webtop, the FirePass
controller downloads, installs, and runs ActiveX controls or Java plug-ins on
the client computer, which starts the Network Access connection. Network
5-4
Access uses a Java-based installer when configuration on the client web

browser prevents the automatic download and install of controls or plug-ins.
The Java installer downloads and installs the necessary controls or plug-ins.
After the FirePass controller-to-client connection is established, the client
uses an automatically configured virtual PPP adapter to communicate with
the FirePass controller. Traffic is sent from the client’s virtual PPP adapter
over the SSL-secured Network Access connection to the FirePass controller.
The FirePass controller routes the client traffic onto the internal network.
You configure whether all client traffic or only traffic designated for
specific subnets is sent over the Network Access connection. You can see a
visual representation of how Network Access works in Figure 5.1, on page
5-4.

Chapter 5
Configuring global Network Access settings

In order to make Network Access available to remote users, you need to
configure the following settings.
• Global settings
Global settings apply to all Network Access users. For more information,
see this section.
• Resource settings
Resource settings apply to specific resource groups. For more
information, see Configuring Network Access resource group settings, on
page 5-19.
• Master group settings
Master group settings apply to associated master groups. For more
information, see Configuring Network Access master group settings, on
page 5-39.
Using NAPT or a virtual subnet

You can configure Network Access using NAPT, or as a virtual subnet.
If you choose to use NAPT, communication between the FirePass controller
and internal servers on your network uses the FirePass controller interface
IP address. If you do not use NAPT, then the FirePass controller uses an IP
address from the pool configured for Network Access to communicate
between the FirePass controller and internal network servers. The
differences are outlined below.
◆ NAPT
If you use NAPT, all packets forwarded into the LAN appear to have a
FirePass controller interface as their source IP address. Most
client-server applications work with NAPT configurations. The
advantage of NAPT is that it requires no changes to the LAN, whereas
using virtual subnets does. To use virtual subnets, you must configure
your internal routers to route the virtual subnet address pool back to the
controller; the FirePass controller does not change the IP address to its
interface IP address.
◆ Virtual subnet
For the most demanding networked applications, and to fully support
Microsoft Networking, you can instead configure a virtual subnet, and
configure an address pool for the FirePass controller to use when
assigning the source IP address in forwarded packets. In this case, you
must also configure your network infrastructure, including routers and
firewalls, to recognize this new subnet and to route the traffic. The router
must know that traffic with IP addresses from the associated address pool
should be routed to the FirePass controller. To prevent routing problems,
ensure that the Network Access address pool does not contain the
FirePass controller’s own IP address. For more information about
configuring routing without NAPT, see Understanding routing, on page
5-9.
5-6
Table 5.1, following, briefly shows the trade-off criteria for each method.
Criterion Virtual subnet NAPT
Requires one or more FirePass controller is Single FirePass

subnets from the corporate the gateway for a controller IP address
network space collection of virtual
subnets
Requires addition of routes Yes No

to the virtual subnets in the
corporate routing
infrastructure
Supports Microsoft Yes No

Networking
Works with most client Yes Yes

server applications
Works with more demanding Yes No

networking applications, for
example, applications that
use IP broadcast packets for
their functionality
Connections over tunnels Yes No

persist after failover
Table 5.1 Comparison of virtual subnet and NAPT
Figure 5.2 illustrates the differences between configuring virtual subnets and
configuring using NAPT.

Chapter 5
Figure 5.2 Sample server addresses for virtual subnet configuration compared with NAPT enabled
Both with and without NAPT, the FirePass controller uses the IP address
pools to issue addresses to the remote client machines.
You can enable NAPT on the Network Access : Global Settings screen.
You also use the Network Access global settings screen to configure IP
address pools that the FirePass controller assigns to the client. You can
configure these settings in IP Address and Mask, by specifying the network
to be used for Network Access client addresses. The FirePass controller then
assigns client an address in this range.
Important
Make sure that the IP address of the FirePass controller itself does not fall
within the subnets you specify on the Network Access : Global Settings
screen.
5-8
Understanding routing
When incorporating the FirePass controller into your network, if you do not
use NAPT, you must make some routing changes to support Network
Access clients. Routing changes are required because existing hosts, routers,
or firewalls need to know how to route packets to the virtual subnet that the
Network Access connections use. If users establish a Network Access
connection, but then cannot communicate with systems on your internal
network, the most common solution is to add the needed routing
configuration.
The specific routing configuration changes you must make depend on the
way you deploy the FirePass controller in your network, typically in one of
the following ways:
• FirePass controller interface connected to the internal LAN
• FirePass controller placed in a separate network from the LAN
For more information on configuring group-based routing for master groups,

see the online help for the link to the routing table on the Users : Groups :
Master Groups screen.
FirePass controller connected to the internal LAN

In the most common deployment scenario, you connect one interface of the
FirePass controller to your internal, corporate LAN. (This interface might or
might not be the only FirePass controller interface used). The hosts on the
internal LAN have a default gateway that is not the IP address of the
FirePass controller’s LAN interface. When a Network Access client (which
has an IP address in the virtual subnet) sends packets to an internal LAN
host, the internal host routes its response packets through the default
gateway, rather than through the FirePass controller. Thus, the packets never
reach the Network Access client on the virtual subnet.
For this deployment scenario, you can use the following solutions.
◆ Use NAPT
You can configure NAPT on the Network Access : Global Settings
screen. NAPT changes (translates) the source IP address of each packet
from the Network Access client to the IP address of the FirePass
controller’s internal LAN interface. As a result, internal hosts send their
response packets to the FirePass controller, not the default gateway. The
FirePass controller then re-translates the IP addresses as needed and
passes the packets back to the Network Access client. For more
information, including reasons why you might not want to use NAPT,
see Table 5.1, on page 5-7.
◆ Add a static route to the virtual subnet in routing tables of the LAN
systems
Configure a static route to the virtual subnet in the routing table of each
host on the internal LAN that communicates with Network Access
clients. This allows the hosts to route packets to the virtual subnet
through the FirePass controller’s interface on the internal LAN. The
static route uses as the destination network, the value configured in the IP

Chapter 5
Address column on the Network Access : Global Settings screen. The

gateway for the route is the IP address of the FirePass controller interface
on the internal LAN. You should add a route for each virtual subnet you
configure in the IP Address column under Network Access Settings.
Refer to your documentation for the host operating system for
information on commands (such as the route command) that add routes
to the routing table.
FirePass controller placed in a separate network from the LAN

In the second deployment scenario, you do not connect the FirePass
controller to the internal LAN. Rather, it exists in an independent network,
such as a DMZ subnet. If no routes to the virtual subnet exist on the routers
or firewalls that separate the internal LAN from that independent network,
packets from hosts on the internal LAN cannot reach the Network Access
clients.
For this deployment scenario, you can use the following solutions.
◆ Use NAPT
Use NAPT, as described in FirePass controller connected to the internal
LAN, preceding. If this does not solve the problem, you may need to
employ the following solution, either as an alternative, or in addition to
NAPT. For more information, including reasons why you might not want
to use NAPT, see Table 5.1, on page 5-7.
◆ Add a static route to the virtual subnet in routing tables of routers
and firewalls
Configure a static route to the virtual subnet in the routing table of each
router or firewall that exists in the path between the FirePass controller
and the target hosts on the LAN or other networks. The static route uses
as the destination network, the value configured in the IP Address
column on the Network Access : Global Settings screen. The gateway for
the route is the FirePass controller interface. Refer to your documentation
for the router or firewall for information on commands to add routes to a
routing table.
Keeping connections open when the webtop is closed

You can set a global option to keep the VPN tunnel and any application
tunnels open when the user closes the webtop. You configure this option on
the Network Access : Global Settings screen. Enable the setting Leave VPN
Connection/Application tunnels open when webtop is closed. If this
setting is not enabled, the tunnels close when the user closes the webtop.
Configuring global packet filter rules

You can specify global packet filters to apply to Network Access traffic.
When you check the Use packet filter to access LAN option on the
Network Access : Global Settings screen, you can specify a set of common
5 - 10
rules that the Network Access applies to all Network Access client traffic
that comes into the FirePass controller as well as the client’s outgoing
traffic. Network Access activates these rules on service startup, and applies
changes when you click the adjacent Apply these rules now button.
Without packet filtering enabled, Network Access accepts all packets. When
you enable packet filtering, Network Access creates a default Drop ALL
rule that runs after all other global rules run. Network Access also creates a
Drop ALL rule that runs at the end of each group’s rules. Once you enable
packet filtering, you must add filtering rules to allow the traffic you want to
pass through. If you want to accept all packets not otherwise filtered out,
you should precede this default rule with an accept-all rule. To create an
accept-all rule, select ALL from the Proto box and Accept from the Action
box.
Note
You cannot delete the default rules.
When configuring global rules, you typically select the Continue action in
the global rule and then specify more granular packet filtering under the IP
Group Filter tab on the Network Access : Resources screen. For information
about configuring IP group filters, see Understanding IP Group Filters
options, on page 5-26.
Network Access checks each packet coming from the user’s Network
Access client against the common, global rules. The packet might be
explicitly accepted, dropped, or rejected. However, if the packet matches
settings from a global rule with a Continue action, the packet is also
evaluated against the more granular, resource group-level rules. The group’s
rules must then explicitly accept, reject, or drop the packet.
Network Access applies the global rules, then the group rules, from top to
bottom. At each stage, Network Access uses the first-found matching rule to
process the packet. For more information about group-level rules, see
Understanding IP Group Filters options, on page 5-26.
While working in the Packet Filter Rules area on the Global Settings screen,
when you click the Add New Rule link, the screen presents options for
specifying several setting.
◆ Rulename
Contains the name for global packet rule.
◆ Protocol
Contains the options TCP, UDP, ICMP or All, that represent the
protocol Network Access uses to process the packet.
◆ Dst Port
Represents the port number or port range that the client uses as a
destination port while accessing various resources on the internal LAN.
You specify a port number or range of port numbers using the following
format
first_port_number:last_port_number, for example, 1:65535, which
means any port. An empty box also means any port. Network Access
does not use Dst Port for processing packets over ICMP.

Chapter 5
◆ Dst Address/Mask
Represents the destination IP address used by the client when it tries to
access various resources on the internal LAN. For example, 192.168.2.1,
or subnet/mask, for example 192.168.2.0/24 or
192.168.2.0/255.255.255.0. You can specify 0/0 to mean any IP address.
◆ Action
• Accept: Ends filtering and forwards the packet to its destination.
• Continue: Passes the packet to the resource group rules.
• Drop: Does not pass the packet, and does not notify the sender.
• Reject: Drops the packet and notifies the sender. Depending on the
specific reject action type, Network Access sends the sender the
ICMP message code you select, or a TCP packet with the RST bit set.
◆ Src Address/Mask
Represents the source address and mask used by the client while
accessing resources on the internal LAN. You can use Src
Address/Mask to configure packet rules for a specific IP address pool.
◆ Log all matches
Writes to the system log all of the packets that match conditions in any
global packet rule. You can view log entries on the Reports : System
Logs screen by selecting Packet Filter from the Source list. For more
information about system logs, see Using the System Logs report, on
page 10-18.
Using overlapping IP address pools

You can use the same IP address in more than one IP address pool. IP
address pooling is useful in an ISP environment, where the same FirePass
controller hosts multiple managed customers, who often need to use the
same IP address space.
Note
The FirePass controller also supports overlapped IP address assignment

through an external RADIUS server or by defining static mapping on the
FirePass controller. The configuration steps are same as those described
here for IP address pools.
Using overlapping IP address pools: special considerations

To use overlapping IP address pools, you must route to different VLANs the
traffic for resource groups that use overlapping IP address pools. You can
not assign the same VLAN to two resource groups that use overlapping IP
pools. Because routing is configured on a per-group basis, this means that
you cannot use overlapping IP pools for multiple resource groups in a single
master groups. In other words, each resource group using overlapping IP
address pools must be associated with a different master group.
5 - 12
Configuring overlapping IP address pools

Configuration of overlapping IP address pools requires very careful
planning of the VLANs and routing configuration on the FirePass controller.
This process involves multiple tasks:
• Define overlapping IP pools.
For more information, see Defining the IP pools, on page 5-13.
• Define VLAN interfaces.
For more information, see Configuring VLAN interfaces, on page 5-14.
• Define routing tables and VLAN routes.
For more information, see Configuring routing tables and VLAN routes,
on page 5-15.
• Define master groups and associate routing tables to resource groups.
For more information, see Configuring master groups and associating
routing tables to master groups, on page 5-15.
• Define resource groups and associate overlapping IP pools to resource
groups.
For more information, see Configuring resource groups and associating
IP pools, on page 5-16.
• Associate master groups and resource groups.
For more information, see Associating master groups with resource
groups, on page 5-16.
• Configure routing rules.
For more information, see Configuring routing rules, on page 5-17.
This section presents the process, with a step-by-step explanation of a
sample configuration. This example uses the following elements.
• Two master groups: M1 and M2
• Two defined resource groups: R1 and R2
• Two overlapping IP address pools: P1 and P2
• Two routing tables: TABLE1 and TABLE2
• Two VLANS: VLAN1 and VLAN2
• Two defined routing rules, one for TABLE1 and one for TABLE2
The following sections describe how to define each element. Once you are
finished, when users log on to use R1 and R2, the FirePass controller assigns
them IP addresses from P1 and P2.
Note
Because the defined ranges for P1 and P2 are overlapping, it is possible for
more than one user to have assigned the same IP address, though never in
the same resource group. Overlapping IP address pooling provides the
option of having more than one user with the same IP address.
Defining the IP pools

The first step is to specify pools with overlapping IP addresses.

Chapter 5
To set up overlapping IP address pools

1. In the navigation pane, click Network Access, and click Global
Settings.
The Global Settings screen opens.
2. Check Allow overlapping IP addresses in different address
pools.
3. In the Add new IP Address Pool section, type P1 in the Name box.
4. In the IP Address box, type 10.0.0.0.
5. In the Mask box, type 255.255.0.0.
6. Click the Add button.
7. To add the second address pool, in the Add new IP Address Pool
section, type P2 in the Name box.
8. In the IP Address box, type 10.0.0.0.
9. In the Mask box, type 255.255.255.0.
Configuring VLAN interfaces

The next step is to define two VLANs.
To define VLAN interfaces

1. Click Device Management, expand Configuration, and click
Network Configuration.
The Network Configuration screen opens with the IP Config tab
active.
2. Click the VLAN tab.
The VLAN screen opens.
3. In the Add New VLAN section, in the Name box, type VLAN1.
4. In the Tag box, type the number to be used throughout the LAN in
the packet header, to identify this VLAN. The valid tag range is
from 1 to 4094.
5. From the Interface list, select the FirePass controller physical
interface used by this VLAN.
6. Repeat these steps for VLAN2.
WARNING
VLANs 2011, 2012, 2013, 2014, 2021, and 2022 are reserved VLAN tags,
and should not be used.
5 - 14
Configuring routing tables and VLAN routes

After you have defined overlapping IP address pools and VLANs, you must
configure routing tables and VLAN routes.
To configure routing tables and VLAN routes

Configuration, click Network Configuration, and then click the
Routing tab.
The Routing screen opens in light mode.
2. Follow these steps to add a routing table.
a) Click the Switch to advanced mode [>>] link.
The Routing screen opens in advanced mode.
b) Scroll down to the Add new routing table section at the bottom of
the screen.
c) In the Name box, type TABLE1.
d) In the Number box, type a number between 1 and 252, inclusive,
that is not used by another routing table.
e) Click the Add New button.
The Routing screen refreshes in light mode.
3. Repeat step 2, using TABLE2 for the name.
4. Click the Switch to advanced mode [>>] link.
The Routing screen refreshes in advanced mode.
5. In the Add Single route section, add to TABLE1 a route that directs
all outgoing traffic to the VLAN1 interface.
6. Repeat the previous step to create a route in TABLE2 to VLAN2.
7. Click the Finalize tab to activate the new routing table in the
networking configuration and restart the FirePass controller.
Configuring master groups and associating routing tables to master groups

After you have created the routing tables and VLAN routes, you must create
two master groups and associate the routing tables to each one.
To define master groups and associate them with routing

tables
Master Groups.
The Create new group screen opens.
3. In the New group name box, type M1.

Chapter 5
4. From the Routing Table list, select TABLE1 from the list of
routing tables.
5. Click Create.
The Master Groups screen opens, with the General tab selected.
6. Click the Back to Users : Groups : Master Groups page link in
the upper right of the screen.
The Master Groups screen opens, showing the M1 master group. In
addition, TABLE1 appears in the Routing Table column for the M1
master group.
7. Repeat these steps to create the M2 master group and associate it
with TABLE2.
Configuring resource groups and associating IP pools

After you have created two master groups and associated the routing tables
to each one, you must create two resource groups and associate them with
the corresponding IP pools.
To configure resource groups and associate IP pools

Resource Groups.
The Resource Groups screen opens.
The Create new group screen opens.
3. In the New group name box, type R1.
4. Click Create.
The Resource Groups screen opens, showing the R1 resource group.
5. In the Network Access column, click the Edit link for the R1
resource group.
The Network Access screen opens for the R1 resource group, with
the Client Settings tab selected.
6. From the list in the IP address assignment section, select
P1 : 10.0.0.0/255.255.0.0 as the IP address pool.
7. Configure other settings for Network Access favorites.
For more information on configuring Network Access, see
Configuring Network Access resource group settings, on page 5-19.
8. Repeat these steps to associate resource group R2 with IP pool
P2 : 10.0.0.0/255.255.0.0.
Associating master groups with resource groups

After you have created two resource groups and associated them with the IP
pools, you must associate the master groups with the resource groups.
Master Groups.
5 - 16
2. In the Resource Groups column, click the dynamic only link.

The Master Groups screen for the M1 master group opens, with the
Resource Groups tab selected.
3. In the Available list, select R1.
The screen refreshes to show R1 in the Selected list.
5. Repeat these steps to add R2 to the list of resource groups available
to M2.
Configuring routing rules

The final step is to direct all the incoming traffic on VLAN1 to TABLE1
and traffic on VLAN2 to TABLE2, so that it can be properly routed and
given back to the appropriate resource group M1 and M2 (and subsequently
to R1 and R2). This is done by adding a routing rule in the main routing
table of the FirePass controller.
To configure routing rules.

This is the most important step for configuring overlapping IP address
pools. In Configuring routing tables and VLAN routes, on page 5-15, you
added default routes in TABLE1 and TABLE2 to direct the traffic to
VLAN1 and VLAN2. The FirePass controller routes the traffic for M1
according to the routes in TABLE1, and traffic for M2 according to the
routes in TABLE2.
The Network Configuration screen opens, with the IP Config tab
selected.
2. Click the Routing tab.
3. In the Add new rule area, type the following values in the associated
boxes:
From: 0.0.0.0/0
To: <leave this box blank>
Interface: VLAN1
Table: TABLE1
4. Similarly, for associating VLAN2 to TABLE2 (and consequently to
R2), type the following settings:
From: 0.0.0.0/0

Chapter 5
To: <leave this box blank>

Interface: VLAN2
Table: TABLE2
Important
If you decide to disable overlapping IP address pools, check to make sure
that you redefine any overlapping IP address pools or statically defined
mappings. The FirePass controller does not automatically redefine address
pools. The presence of overlapping IP addresses along with a disabled
overlapping address pools setting can cause connectivity problems.
Configuring bitrate evaluator parameters

You can configure options on the Global Settings screen in Network Access
to update a session only when the bitrate exceeds a specified threshold. You
can use this option to distinguish between real application traffic, and
keepalive requests from application clients. Network Access disregards
keepalive requests when enforcing session timeouts.
You can specify bitrate settings in the Bitrate Evaluator Parameters area of
the Network Access : Global Settings screen.
Setting a value in the Timing window box defines, in seconds, the period
that the evaluation should use to average the bitrate. Setting a value in the
Bitrate threshold (Bytes/sec) box defines, in bytes per second, the criterion
for updating the session statistics. Network Access updates the session if the
averaged bitrate exceeds the threshold. If you set the bitrate threshold to
zero, Network Access does not apply session timeouts.
You can determine how to set bitrate value by examining regular network
usage, depending on what applications are in use and how much data those
applications generate. Typical values are 50 bytes/sec or higher. The
FirePass controller activates timing and threshold rules on service startup,
and applies changes when you click the adjacent Apply these rules now
button.
5 - 18
Configuring Network Access resource group settings

After configuring global Network Access settings, you need to configure
resource group settings. These are also called favorites. You specify
favorites on the Network Access : Resources screen.
You can create favorites that cover the following areas.
• Client Settings
For a description of these options, see Understanding Client Settings
options, following.
• DNS
For a description of these options, see Understanding DNS options, on
page 5-23.
• Hosts
For a description of these options, see Understanding Hosts options, on
page 5-24.
• Drive Mappings
For a description of these options, see Understanding Drive Mappings
• Launch Application
For a description of these options, see Understanding Launch
Application options, on page 5-25.
• IP Group Filters
For a description of these options, see Understanding IP Group Filters
• Policy Checks
For a description of these options, see Understanding Policy Checks
• Customization
For a description of these options, see Understanding Customization
Understanding Client Settings options

You can use options on the Client Settings tab to configure favorite name,
split tunneling operation, proxy settings for the client, and IP address
assignment. The Client Settings screen presents options for specifying
various settings.
◆ Connection name
Contains the name the end user sees in the Network Access area of the
webtop. If the box is empty, the link to Network Access coming from a
given Resource group does not appear in the list.
◆ Use split tunneling for traffic
Directs through the Network Access tunnel all network traffic that is not
destined for the LAN, specifically, the address specified in the LAN
address space box. A tunnel is a secure connection between computers
or networks over a public network. When you configure split tunneling,

Chapter 5
the FirePass controller directs all other traffic out of the local network
connection. You can configure both of the following options when you
enable the Use split tunneling for traffic option.
• LAN address space
Provides a list of addresses or address/mask pairs describing the target
LAN. When using split tunneling, only the traffic to these addresses
and network segments goes through the tunnel configured for
Network Access. You can use the following format to configure this
option:
10.0.0.0/255.0.0.0
10.0.0.0/8
10.0.0.0/8,10.1.0.0/8
You can use spaces, commas, or semi-colons to separate list items.
You can also use a session variable to specify a LAN address space.
When you specify a session variable, the system resolves the address
by substituting the value received during user authentication. For
example, you can have the system substitute the value from the user’s
LDAP attribute SubnetAddress when you specify the session variable
%session.ldap.auth.SubnetAddress% in LAN address space.
• DNS address space
Provides a list of names describing the target LAN DNS addresses.
You can use spaces, commas, or semi-colons to separate list items.
For example, enter *.sales.siterequest.com
*.engineering.siterequest.com to help the browser resolve which
DNS server to use for resolving a host name. For example, Internet
Explorer uses the VPN DNS server settings for hosts in the DNS
address space, and the local client DNS for others.
◆ Force all traffic except local subnet traffic
Routes all traffic (except traffic to the local subnet), through the tunnel.
Use this option if you expect your users to connect from well-known
networks, such as their home computers, and you want to allow them
access to local resources, such as their printers at home, while using
Network Access.
◆ Force all traffic through tunnel
Routes all traffic (including traffic to the local subnet) through the
tunnel. In this case, there is no local subnet. Users cannot access local
resources, such as their printers at home, until they disconnect from
Network Access.
• Allow local subnet access
Provides the option, when checked, to add the VPN interface as a
default gateway on the client computer. Use this option to permit local
subnet access and local access to any host or subnet in routes that you
have specified in the client routing table. However, if the option to
Use split tunneling is enabled, the client computer cannot remove
conflicting routes from the client routing table. VPN routes are added
using a metric that allows existing local routes to take precedence.
• Exclude subnets
Provides the option, when checked, to add routes to excluded subnets
using local interfaces to allow public local access to these subnets.
5 - 20
This feature includes support of session variables. Enter a list of IP

addresses with subnet masks to be excluded, separated by a space or
comma.
◆ Enable Client for Microsoft Networks
Select this option to allow the client PC to access remote resources on a
Microsoft network over the VPN connection. This option is functionally
the same as using the Client for Microsoft Networks locally on the
network, so if you enable this option on your local network, enable this
option over the VPN connection to provide the same functionality. This
option is enabled by default.
◆ Enable File and Printer Sharing for Microsoft Networks
Select this option to allow remote hosts to access Microsoft file shares
and network printer resources on the client system over the VPN
connection.
Note
In this release, multiple rule-based exclusions are allowed on a

per-resource basis. Network Access subnet exclusion is configured in the
same manner as session variables. Exclusion rules require only that a client
source address match an IP-subnet. The exclusion itself is defined by either
a string of one or more IP-address or IP-mask pairs, or a
%session-variable%, and multiple matches result in multiple lists of
exclusion IP-address or IP-mask pairs. This feature enhancement is useful
for mobile users requiring exclusions for network devices on the clients'
LAN or WAN.
◆ Client proxy settings

Directs Network Access clients to work through the specified proxy
server on the remote network. This option requires the client computer to
have Internet Explorer 5.0 or later installed. The following options
appear when you check Client proxy settings.
• Autoconfig script
Contains the URL of the proxy-autoconfiguration script.
• Address, Port
Contains the address and port number of the proxy server you want
Network Access clients to use to connect to the Internet.
• Bypass proxy for local addresses
Indicates whether you want to use the proxy server for all local
(intranet) addresses.
• Proxy exclusion list
Contains the Web addresses that do not need to be accessed through
the proxy server. You can use wild card characters to match domain
and host names or addresses. For example, you could specify
www.*.com, 128.*, 240.*, *., mygroup.*, *x*, and so on. You can
use spaces, commas, or semi-colons to separate list items.

Chapter 5
◆ Use gzip compression

Compresses all traffic between the Network Access client and the
FirePass controller, using the GZip method.
◆ Autolaunch based on endpoint protection
Automatically opens a Network Access connection after the FirePass
controller authenticates the user, providing that the user passes any
endpoint security requirements. When you check this option, you can
select Any endpoint configuration, which always launches Network
Access connection automatically, or an existing protected configuration,
whose requirements vary. For example, if you have a protected
configuration named ClientCert that requires a valid client certificate
before autolaunching, you can select that protected configuration here.
For more information about protected configurations, see Creating
◆ Use Alternate Webtop
Provides an alternate webtop to users with only one Network Access
favorite. You must enable the option Autolaunch based on endpoint
protection to use this feature.
◆ Use http:// path for auto-generated ProxyAutoConfig script
Runs a simple HTTP server on client computers and return the contents
of the ProxyAutoConfig script at each connect. This option makes use of
a default system browser’s proxy settings for network access
connections.
◆ Update ProxyAutoConfig script in LAN proxy settings
Enabled the client computers to modify the proxy settings for the default
LAN Connection, using the contents of the Proxy Autoconfig script, and
restores the LAN settings on exit.
◆ Automatically reconnect if link dropped
Enables the client to automatically reconnect to the HTTP server and
return the contents of the ProxyAutoConfig script after any incidence of
a dropped connection.
◆ Enable Proxy ARP feature on FirePass
Adds an entry to the FirePass ARP (Address Resolution Protocol) table
with the assigned IP address of the Network Access client and the
FirePass controller’s Ethernet address. This makes the remote Network
Access client appear to other systems to be on the local network. When
this option is enabled, FirePass controller looks for a network interface
on the same subnet as the remote client. If found, FirePass controller
creates a published ARP entry with the IP address of the remote Network
Access client and the hardware address of the network interface found.
When using this option, we recommend that you have the NAPT setting
disabled. You may use this feature in conjunction with FirePass
controller DHCP support, when the remote client is assigned an IP
address that belongs to the same subnet as the FirePass controller
interface.
◆ IP address assignment
Contains options for specifying how IP addresses are assigned. You must
select at least one of the following options.
5 - 22
• Use static IP address per user from mapping table (1st priority)
Assigns IP addresses on a per-user basis. You must configure the
static IP address to be assigned to the user in the User to IP address
mapping table. When you enable this option, a new section appears,
Configure User To IP Address Mapping Table, containing Logon and
IP Address settings you can specify to create user-to-IP address
maps.
• Retrieve IP Address from designated DHCP Server (2nd priority)
Retrieve IP address from a designated DHCP server, with the FirePass
controller acting as the DHCP relay agent. DHCP client support on
the FirePass controller allows IP network access pools, per resource
group, to be managed by an external DHCP server.
• Assign IP address using session variables (3rd priority)
Assigns an IP address to the user using a specified session variable. If
you select this option, type the session variable to use for IP address
assignment in the Session Variable field below this option. The IP
address is retrieved at the time of authentication.
• Retrieve IP address from an external RADIUS server (4th
priority)
Retrieves IP addresses from external Radius Server using RADIUS
attribute 8 (Framed-IP-Address). The FirePass controller retrieves the
IP address at the time of authentication. This option requires the use
of RADIUS as the authentication method for any master group
associated with this resource. This option is not supported in clustered
environments.
• Assign IP address dynamically using IP address pool (lowest
priority: Enabled by Default)
Assigns IP addresses dynamically from an internally configured pool
of IP addresses. When you enable this option, a new area appears,
Select IP Address Pool, containing a list of the IP address pools
defined on the Network Access : Global Settings screen.
Understanding DNS options

Select the DNS tab when you want to set parameters for DNS
Configuration. The screen presents options for specifying the following
settings:
◆ Name Servers
Represents the IP addresses of the DNS server that Network Access
assigns to the remote user. These should represent DNS server or servers
that the internal company network uses.
◆ WINS Servers
Represents the IP addresses of the WINS server to be conveyed to the
remote access point. These are needed for Microsoft Networking to
function fully. For fully functioning Microsoft network share browsing,
you should configure the FirePass controller to use a virtual subnet and
disable NAPT. For more information, see Configuring global Network
Access settings, on page 5-6.

Chapter 5
◆ Default domain suffix

Represents the DNS suffix to use on the client computer. If this box is
not specified, Network Access uses the first suffix from the name servers
configured on the Device Management : Configuration : Network
Configuration screen on the DNS tab.
◆ Enforce DNS search order
When a client PC gets its DNS settings with DHCP, if the DHCP lease is
renewed during the Network Access session, the DNS settings of the
client network interface are reset. This removes any DNS entries set by
Network Access. If DNS settings of the Network Access adapter are not
reset, however, the name resolution order changes. This can cause the
incorrect address to be supplied for a DNS request. Select the Enforce
DNS search order option to prevent this occurrence. When this setting
is enabled, the FirePass controller continuously checks the DNS order on
the network interface, and sets the Network Access-supplied entries first
in the list if they change during a session.
Understanding Hosts options

Pick the Hosts tab to set parameters for static host names. The screen
presents options for adding, editing, and deleting static host names. With
static hosts, you can configure a list of static hosts for the Network Access
client to use. The static hosts you configure modify a client computer’s local
hosts table and override the configured DNS server, so you should use them
only when you need to augment or override the existing DNS.
Important
For this file-change operation, users on Windows platforms must have local
administrative rights to modify the hosts file during the connection, or the
administrator must change the attributes of the hosts file to allow
non-administrative modification.
Understanding Drive Mappings options

Use the Drive Mappings tab to set options for specifying the name, the UNC
path to the network share, and the preferred letter to use for mapping. If the
drive letter is in use, the system uses another one connection time.
Using Drive Mappings options, you can specify network shares to be
mapped automatically on the client computer whenever a user logs on.
Because the FirePass controller does not verify the accuracy of a path, you
should make sure the path is correct.
Troubleshooting drive mapping failures

After establishing a Network Access connection, Windows needs a varying
length of time (depending on network speed and other factors, usually about
one minute) before it can start using WINS for NetBIOS name resolution.
5 - 24
During this time, the drive-mapping operation can fail and provide the
message: The network resource type is not correct. If the UNC path is
configured with the NetBIOS name, you may get the message: The
network path was not found.
If drive mapping fails, try the following corrections:
• Use an IP addresses instead of NetBIOS names
For example, specify \\192.168.191.1\share instead of \\server\share.
• Use fully qualified DNS names
For example, specify \\server.domain.com\share instead of
\\server\share.
• Check the default domain suffix
Make sure that the FirePass controller is configured with the proper DNS
suffixes.
• Try the operation again
Advise users to retry mapping. Subsequent mapping attempts usually
succeed after a 30 to 40-second delay. To retry, have the user click the
Relaunch button in the user's Network Access popup window.
• Check the Windows version
Some older Windows systems (mostly Windows 95 systems) cannot use
IP addresses in Windows Networking.
Understanding Launch Application options

Use the Launch Applications tab to set options for configuring Network
Access to start client-side applications. This feature is particularly useful for
Network Access clients who connect to application servers for which they
have a client-side component on their computers. For example, it is common
to configure Network Access connections for directly accessing an internal
Exchange server. In this case, when the client makes a Network Access
connection, it automatically starts an Outlook client on the connecting
computer. This makes access easier for the end user.
You can let the end-user control whether applications start, by enabling the
Display message box before launching applications option. This is
especially useful for slower systems, or if you want to prevent the attempt to
run certain applications when the system has insufficient memory to run
them. You can specify different applications for Windows, Macintosh, and
UNIX remote systems.
Specifying application paths and parameters

On the Launch Applications screen, to configure applications to launch
automatically, specify the complete path in the App Path box and any
application parameters in the Parameters box, and select the target
operating system from the OS list. The following examples contain strings
for the App Path and Parameters boxes.

Chapter 5
Example: Starts Internet Explorer pointed at an internal web server.

• App Path:
iexplore http://internal_application.siterequest.com
Example: Starts the Microsoft Terminal Server client against an internal
terminal server.
• App Path:
%SystemRoot%\System32\mstsc.exe
• Parameters:
/v:internalterminalserver.siterequest.com /f
You can specify environment variables in either App Path or Parameters
using the following syntax: %envvarname%. The Network Access control
resolves the value at runtime to the environment variable on the remote
system.
Running domain scripts

For certain client systems, you can automatically run domain logon scripts
after establishing a Network Access connection. The client systems must
meet the following requirements:
• The system is running Microsoft Windows 2000, Windows XP, or later.
• The remote user’s computer is a member of the specified domain.
• The user is logged on to Windows using domain credentials cached on
the local client computer.
The following example illustrates how to start a domain logon script:
• App Path
logon
• Parameters
\\domain_controller_ip_address %username%
or
domain_name %username%
The domain_name entry represents the target domain name, and the
domain_controller_ip_address entry represents the IP address of the
domain controller.
Understanding IP Group Filters options

You can specify resource group-specific packet filters to apply to Network
Access traffic only on the IP Group Filters tab.
Note
To make the IP Group Filters tab available, you must check the Use packet
filter to access LAN box on the Network Access : Global Settings screen.
For information about the global packet filtering options, see Configuring
global Network Access settings, on page 5-6.
5 - 26
Network Access applies the global rules, then the resource group rules, from
top to bottom, as they appear in the list of configured rules. At each stage,
Network Access uses the first-found matching mechanism to process the
packet.
Network Access checks each packet coming from the user’s Network
Access client against the global rules first. There, the packet is accepted,
dropped, or rejected, depending on which rule it matches. However, if the
packet matches settings from a global rule with a Continue action, the
packet is also evaluated against the resource group-level rules that you
configure on the IP Group Filters tab.
Without packet filtering enabled, Network Access forwards all packets that
the global rules pass through. When you enable packet filtering on the
Network Access : Global Settings screen, Network Access defaults to a drop
policy. This means that unless you create a rule to explicitly let traffic in, it
is denied.
Note
The default drop rule runs after all other group-based rules, and you cannot
delete the default drop rule. If you want to allow traffic not otherwise
filtered out, you must precede this default rule with a rule that accepts
traffic.
Adding group-level packet filtering rules

To apply settings for a specific resource group, first select the group from
the Resource Group list at the top of the screen.
When you click the Add New Rule link, the screen refreshes to present
options for specifying the following settings:
◆ Rule Name
Contains the name for group packet rule.
◆ Proto
Contains the options TCP, UDP, ICMP or All, that represent the
protocol Network Access uses to process the packet.
◆ Port
Represents the port number or port range that the FirePass controller uses
to communicate with the client.
You specify a port number or range of port numbers using the following
format:
first_port_number:last_port_number, for example, 0:65535, which
means any port. An empty box also means any port. Network Access
does not use Port for processing packets over ICMP.
◆ Address/Mask
Represents the destination address and mask for the packet filter rule, for
example, 192.168.2.1, or subnet/mask, for example 192.168.2.0/24 or
192.168.2.0/255.255.255.0. You can specify 0/0 to mean any address.
◆ Action
• Accept: Ends filtering and forwards the packet to its destination.

Chapter 5
• Drop: Does not pass the packet, and does not notify the sender.
• Reject: Drops the packet and notifies the sender. Depending on the
specific reject action type, Network Access sends the sender the
ICMP message destination unreachable or a TCP packet with the
RST bit set.
◆ Log all matches
Writes to the system log all of the packets that match conditions in any
global packet rule. You can view log entries on the Reports : System
Logs screen by selecting Packet Filter from the Source list. For more
information about system logs, see Using the System Logs report, on
page 10-18.
Configuring policy-fallback rules

You can configure fallback policy rules to evaluate those users who fail any
checks configured on the Policy Checks tab. For information about Policy
Checks options, see Understanding Policy Checks options, following. You
can configure the fallback IP group filters the same way you configured the
primary IP group filters, described in Adding group-level packet filtering
rules, preceding.
To activate fallback rules, check the Enable policy fallback option on the
IP Group Filters screen. Enable policy fallback also applies to Policy
Checks options, described in the following section.
Understanding Policy Checks options

Use the Policy Checks tab to set parameters for client policy, policy checks,
personal firewalls and antivirus checks, and fallback settings. The FirePass
controller enforces these settings only for Network Access connections. You
can prevent changes to the network settings or routing settings on the client
computer while a connection through the Network Access client is active.
You can also require specific applications like virus-checking software to be
running on the client computers. You can prohibit other applications like
known Trojan horses from running on client computers.
Important
The policy checks that you configure here are completely independent of any
Endpoint Security checks configured on the Users : Endpoint Security
screens. These checks are simple, recurring checks run on the client for
Network Access only. You can use them in conjunction with any Endpoint
Security checks you have configured. For information about pre-logon
sequences, see Using pre-logon sequences, on page 3-10.
Note
Policy checks are not supported on MacOS, Linux, or PDA remote clients.
5 - 28
The screen presents options for specifying the following settings:

◆ Prohibit routing table changes during Network Access connection
Prevents modifications in the client’s IP routing table during an active
Network Access connection.
When you select this option, the FirePass controller terminates the
Network Access connection if there are any changes to the network or
routing on a client computer during the connection.
◆ Enable integrated IP filtering engine
This feature is only available when you select the Use split tunneling or
Force all traffic through tunnel option on the Client Settings screen,
available from the Client Settings tab on the Network Access : Resources
screen. This protects the FirePass controller and internal LAN from
outside traffic (that is, traffic generated by network devices on the
client’s LAN), and ensures that FirePass controller traffic is not leaking
into the client’s LAN. You use this feature to prevent IP packets destined
to or originating from the LAN Address Space from being sent
unencrypted to the user’s LAN. It also prevents using a client device as a
routing gateway between the LAN and the FirePass controller.
◆ Allow access to local DHCP server
Supports DHCP renewal of the local IP addresses in conjunction with the
Force all traffic through tunnel and Enable integrated IP Filtering
engine options, when these options are enabled. Use of this feature is
dependent on the ability of the client TCP/IP stack to fallback to UDP
broadcasts for DHCP refresh/renewal. When this feature is enabled, the
FirePass controller adds specific rules to the IP filtering engine on the
client to facilitate DHCP traffic.
Important
Use the Allow access to local DHCP server option along with Prohibit
routing table changes during Network Access connection to restore the
client routing table after a DHCP refresh. Otherwise, after DHCP renewal,
the client system restores the default gateway and possibly the local routes,
which could disrupt access to VPN hosts.
◆ Processes to be present/absent
Represents a Boolean expression containing strings that specify
executable process names that must be present or absent on the client
system during an active Network Access connection. You can use the
following conventions to specify the string:
• Wildcard characters asterisk ( * ), which represents many characters,
and question mark ( ? ), which represents a single character
• The logical operators AND, OR, and NOT.
• The characters open parenthesis ( and close parenthesis )

Chapter 5
◆ Check system registry

Contains a Boolean expression that verifies certain keys and values in the
system registry database. When you specify the expression, use the
following syntax, including the quotation marks.
"key"."value" operator [data]
• "key" represents a path in the Windows registry.
• "value" represents the name of the value.
• operator represents one of the supported logical operators defined in
the conventions list, following.
• data represents the content to compare against.
• Open square bracket [ and close square bracket ] represent optional
values.
You can use the following conventions to specify the string:

• The operators ISPR (is present)
• Wildcard characters asterisk ( * ), which represents many characters,
and question mark ( ? ), which represents a single character
• The logical operators AND, OR, and NOT
• The characters open parenthesis ( and close parenthesis )
◆ Operating system service packs

Contains a Boolean expression that evaluates the list of installed service
packs and hotfixes. You should specify the operating system name (for
example, Win95, Win98, Win98SE, WinNT 4, Win2k, WinXP,
Win2003), service packs (for example, SP1 or SP2), and hotfixes (for
example, KB1234, Q1231312, Q3253).
The following example represents a complete string.
(Win2003 OR (WINXP AND SP2) OR (WIN2k AND SP4 AND
KB1234) ) AND NOT (WIN95 OR WIN98 OR WIN98SE OR
WINME)
You can check the Microsoft support site for the list of published
hotfixes for the target operating system.
◆ Internet Explorer service packs
Contains a Boolean expression that evaluates the list of installed service
packs and hotfixes for Internet Explorer. The string should be formatted
with the browser name (for example, IE5 or IE6), service packs (for
example, SP1 or SP2) and hotfixes (for example, KB326489).
The following example represents a complete string.
(IE5 OR IE6) AND NOT (IE3 OR IE4)
You can consult the Microsoft support site for the list of published
hotfixes for the target operating system.
◆ McAfee VirusScan
Contains the software products that should be running during the
Network Access session. You also can configure options to require
specific versions and last-update dates of the signature databases.
5 - 30
◆ Enable policy fallback

You can configure fallback policy rules to evaluate those users who fail
the first set of rules. You might want to allow certain clients access, but
restrict them to a subset of the network. You can configure the fallback
policies the same way you configured the primary policies, described
earlier in this section. Enable policy fallback also applies to IP Group
Filters options, described in Adding group-level packet filtering rules, on
page 5-27.
For examples and additional information, see the online help for Network
Access : Resources on the Policy Checks tab.
Understanding Customization options

You can use items on the Customization tab to customize the behavior and
appearance of the Network Access client for remote users. You can use the
customization configuration options to control what remote users see when
they connect or disconnect, how the Network Access client behaves if
Windows goes into power management mode, and what messages display in
the event of a connection error.
Configuring Customization options

Using options in the Customization section of the Customization tab, you
can configure how Network Access connections behave on the client
computer.
◆ Present the user with a message box after successfully connecting
Network Access client
Posts an alert to the end user upon establishing a Network Access
connection.
◆ Minimize window after successfully connecting Network Access
client
Minimizes the connection window upon establishing a Network Access
connection.
◆ Use Tray icon instead of Taskbar entry when minimized
Minimizes the connection window as an icon in the Windows system
tray. By default, when a user establishes a Network Access connection,
the FirePass controller displays a connection window to users notifying
them that they have successfully established a Network Access
connection. When you enable this feature, the system hides the window
and shows the connection as an icon in the Windows system tray at the
lower right of the Taskbar. Users can use the icon in the Windows system
tray to restore or maximize the connection window, or to terminate their
◆ Do not display tray icon for connection
Prevents display of the Network Access connection in the Windows
system tray.

Chapter 5
◆ Displayed bandwidth B/Sec

Reports the Network Access connection media speed to Windows. This
affects the speed shown in the connection status window on the client’s
computer. This value is also used by Windows 2000 and Windows XP to
determine the default TCP window size advertised for TCP connections
over the Network Access connection, and can in some cases affect TCP
performance over the connection. For a table of how the speed displays
and the impact on window size, see the online help for the Network
Access : Resources screen on the Customization tab.
Configuring Power Management options

Using options in the Power Management section of the Customization tab,
you can control Network Access client behavior in response to Windows
power-management operations on the client computer. You can select from
several settings.
◆ Do nothing. Ignore power management events
Indicates that Windows power management operations on a client
computer have no effect on FirePass controller system client
functionality.
◆ Prevent Windows from entering standby/hibernate during
connection
Indicates that the FirePass controller system client responds to
power-management operations by keeping the computer from
hibernating or switching to standby mode.
◆ Terminate Network Access connection if Windows is entering
standby/hibernate
Indicates that the FirePass controller system client responds to
power-management operations by ending its Network Access
connection.
Configuring Custom Messages options

Using options in the Custom Messages section of the Customization tab,
you can configure the text for policy check messages that display when
specific events occur.
◆ Connection Established
Displays the configured message when the FirePass controller makes a
Network Access connection with a client computer.
◆ Connection Established using Fallback Configuration
Displays the configured message when the FirePass controller makes a
Network Access connection using a fallback configuration.
◆ Disconnect due to Routing Table Changes
Displays the configured message when the FirePass controller terminates
a Network Access connection because a change was made to the remote
client’s routing table.
5 - 32
◆ Disconnect due to Configuration Error

Displays the configured message when the FirePass controller terminates
a Network Access connection because there was a configuration error.
◆ Check for Processes Failed
Displays the configured message when the check does not detect the
required process, or when it detects the presence of a forbidden process.
◆ Registry Check Failed
Displays the configured message when the registry check fails.
◆ System Patch Level Check Failed
Displays the configured message when the system patch level check
fails.
◆ Internet Explorer Patch Level Check Failed
Displays the configured message when the patch level check for Internet
Explorer fails.
◆ Personal Firewall/Antivirus Check Failed
Displays the configured message when the check for a personal firewall
or antivirus fails.
◆ Connection Name in Network Connections Folder
Displays the configured connection name used in the network
connections folder.
Configuring additional end-user customization options

You can configure additional end-user options to customize the end-user
experience for Network Access users. The Customize Client Components
screen contains the options. You can find the Customize Client Components
tab on the Device Management : Client Downloads : Windows (x86) screen.
Configuring FirePass controllers

The FirePass controller client component uses the FirePass Controllers List
area to determine the FirePass controllers available for connection. The
client component and Windows logon integration share these settings.
The client component connects to the FirePass controller using the HTTP
protocol and receives an HTTP 302 redirect message from the FirePass
controller. The client component then redirects the connection to that
FirePass controller. Every other connection is made over HTTPS.
To specify the list of FirePass controllers available to the

client component and Windows logon integration
1. In the navigation pane, click Device Management, click Client
Downloads, and click Windows (x86).
The Customize Package screen opens.
2. Click the Customize Client Components tab.
The Customize Client Components screen opens.
3. In the Add new FirePass controller section in the FirePass
controller box, specify a FirePass controller in the following form:

Chapter 5
[protocol://]host[:port][/landinguri]
Note: You can use http or https as the protocol.
4. Click Add Controller.
The new entry appears in the list.
You can use the up, down, and delete buttons to operate on items in the list.
The client component accesses the FirePass controllers in the order they
appear in the list. When the client component finds an available controller, it
stops looking.
Configuring user screen options

You can customize the user’s experience in several ways. These settings are
configured in the Standalone Client Settings section.
◆ Starting mode
You can select Start in Simple Mode to have the Network Access
connection start immediately after logon, or you can select Start in
Advanced Mode to have the system present a list of favorites from
which the user can select. Start in Simple Mode is the default.
◆ Minimize location
You can select Move to System Tray when Minimized to have the
Network Access connection appear as an icon in the user’s Windows
System Tray when the user minimizes the window running the Network
Access connection. The default is enabled.
◆ Tooltip visibility
You can select Show Tooltips to have the system present identifying text
on Windows when the user positions the cursor over a setting or icon.
The default is enabled.
◆ Status message visibility
You can select Show Additional Status Messages to have the system
display messages that track system status. The default is enabled.
◆ Logon prompt usage
By default, the system uses a web-based interface to logon, which
supports all pre-logon checks. The user cannot save the values in
Username and Password using the web-based interface. The system
uses the Username prompt and Password prompt labels specified in
the Customization section of the screen to present logon and password
prompts. You can select the option Use Legacy Logon Prompt to have
the system present the Windows dialog box to collect credentials. This
logon mode supports only limited pre-logon checks. The user can save
his password with this option, and the user name and password prompt
cannot be customized.
◆ Toolbar and status bar visibility and appearance
You can select Show Toolbar to have the system display the toolbar on
the user’s Network Access connection screen. You can select Show
Status Bar to have the system display a line of explanatory text in the
user’s Network Access connection screen. You can select Use Large
Icons in Toolbar and Add Text to Toolbar Icons to control how icons
display in the user’s toolbar. The default is enabled for all options.
5 - 34
Configuring proxy settings

The FirePass controller client component uses the Proxy Settings area to
determine proxy settings to use for connection. The client component and
Windows logon integration share these settings.
◆ Use System Proxy Settings
Uses the Windows proxy settings configured in Internet Explorer to
connect to the FirePass controller. This option does not apply to the
Window Logon Integration settings.
◆ Use Custom Proxy Settings
Selects a proxy from the configured items, in a specific order. For
example, when you configure all custom proxy options, the client
attempts to use a custom proxy option in the following order, until one
succeeds: Automatically Detect Proxy Settings, Use Automatic
Configuration Script, Use a Proxy Server.
◆ Automatically Detect Proxy Settings
Detects the proxy settings on the proxy server using the Web Proxy
Auto-Discovery (WPAD) protocol.
◆ Use Automatic Configuration Script
Detects the proxy settings using a configuration script at a specified
URL.
◆ Use a Proxy Server
Specifies which proxy server the client uses to connect to the FirePass
controller. You can configure two proxy server settings:
• Address
Specifies the protocol and host name of the proxy server.
• Port
Specifies the port number of the proxy server.
Configuring Windows logon integration options

You can configure Windows logon integration options for client
connections originating on Microsoft Windows 2000 and Windows XP or
later. When configured, the FirePass controller uses the user’s Windows
logon credentials for authenticating Network Access connections. In
addition, users can change their Windows passwords over FirePass
controller connections.
The Windows logon integration options provide close integration with the
Windows domain logon process. The component uses domain credentials
for authorization for external users or external authorization for internal
users. The connection users receive looks like a dial-up connection. There is
only a clientless mode, no browser window. Using the Windows logon
integration functionality enables automatic start of the connection at logon
and provides support for logon scripts such as drive mappings.
Windows logon integration settings provide the following connection
functionality:

Chapter 5
• Establish a VPN connection to the FirePass controller before users log on

onto their computers using a virtual dial-up entry. To use this feature, the
user must check the option Logon using the dial-up connection at the
Windows logon prompt. This option is available only for computers that
are members of the domain (that is, corporate computers).
• Establish a VPN connection to the FirePass controller when users log on
to their computer.
To set up Windows logon integration

1. In the navigation pane, click Device Management, click Client
Downloads, and click Windows (x86).
2. Check the Windows Logon Integration check box.
4. Click the Customize Client Components tab.
The Customize Client Components screen opens.
5. Specify a list of FirePass controllers for use by the Windows Logon
Integration component.
6. Click the Download tab.
The Download components screen opens.
7. Click the Download link, and specify a location for saving the MSI
package containing the Windows Logon Integration control.
8. Copy the file to the client computer, and double-click to install it.
You can specify the following Windows Logon Integration settings. The
default is enabled for all options except where noted.
• Phonebook Entry Name
Specifies a unique name for the virtual dial-up entry, which the system
displays on the client computer in the Network Connections folder. If
more than one resource exists, the system presents a list from which the
user can select. For this option to succeed, the connection must be
running with rights to write to the AllUsers profile.
• Reconnect Attempts
Specifies the number of automatic reconnection attempts for the
operation.
• Time between Reconnect Attempts (sec)
Specifies the amount time to wait for the client (in seconds) before the
system attempts to reconnect.
• Display Progress while Connecting
Displays the progress of the connection attempt.
• Prompt for User Name and Password
Prompts users to enter their user name and password.
• Include Windows Logon Domain
Presents the user’s domain on the Windows logon screen.
5 - 36
• Prompt for FirePass Controller Address

Prompts users to enter their FirePass controller address, as either a host
name or IP address.
• Show Icon in Notification Area when Connected
Displays to users an icon in the notification area when they establish a
connection.
• If Connection Fails, Try Next Controller
If the connection fails, tries the next FirePass controller specified in the
list in the FirePass Controllers List area.
• Move Successful Controller to Top of List
Upon successful connection, moves the FirePass controller to the top of
the FirePass controller list. The default is disabled.
Configuring session options

You can specify session-based options for client connections originating on
Microsoft Windows 2000 and Windows XP or later. Session settings govern
persistence and update configuration.
◆ Enable Autoreconnection
Specifies that the client can try to automatically reconnect to a FirePass
controller. The default is disabled.
• Maximum Autoreconnection Attempts (1-99)
Indicates the number of times the client can try to reconnect
automatically. You must check Enable Autoreconnection to specify
Maximum Autoreconnection Attempts. The default is 5.
◆ Maintain History
Specifies whether the client can store a list of the FirePass controllers it
accessed. The default is enabled.
• Save Passwords
Specifies whether the client can store the logon password along with
the history. You must check Maintain History to be able to select
Save Passwords. The default is disabled.
◆ Automatic update options
Provides a set of options that govern automatic updates for installed
components.
• Automatically Update Components
Specifies that the client can receive automatic updates for installed
components. This is the default.
• Prompt User before Installing Updates
Specifies that the system request confirmation from the user before
the client can receive automatic updates for installed components.
• Don’t Perform Component Updates
Prevents automatic updates of installed components.
Configuring user permissions options

User permissions options control how the client receives session settings
and whether a user can override certain settings.

Chapter 5
• Dynamically Download Session Settings During Logon

(Do not allow users to change session settings)
Specifies that the system downloads session settings when the client logs
on to the FirePass controller. When you check this option, users cannot
change their session settings when they are connected to the FirePass
controller.
• Do not Allow Users to override Proxy Settings
Specifies that the user cannot change the proxy settings configured in the
Proxy Setting area.
5 - 38
Configuring Network Access master group settings

When you want to customize Network Access settings for a specific group
of users, you can configure master group settings. Master group settings
include auto-logon options, the running of policy checks on client
workstations, and configuring the FirePass controller webtop.
The FirePass controller provides master-group-related options on the
Network Access : Master Group Settings screen. You can select the master
group you want to configure from the Master Group list at the top of the
screen. For more information about configuring master groups, see
Configuring a master group, on page 2-11.
The Master Groups Settings screen presents options for specifying the
following settings:
◆ Auto-logon to drive mappings using FirePass user logon credentials
Logs on using the user’s FirePass controller name and password if the
mapped drives require user authentication. Enabling this option reveals
the Domain/Workgroup option, in which you can specify a domain name
to use when logging on to the mapped drives.
◆ Perform continuous policy verification during the Network Access
connection
Periodically checks for the presence or absence of processes configured
in Policy Checks. Enabling this option reveals Process Timeout Value
in which you can specify the timeout interval (in seconds), before the
FirePass controller terminates the Network Access connection. The
FirePass controller provides continuous verification only on policies
configured to monitor processes. For more information, see descriptions
for setting processes under Understanding Policy Checks options, on
page 5-28.
◆ Click to change the status and/or webifyer position on the webtop
Opens the Users : Groups : Master Groups screen, with the User
Experience tab selected. Options available include enabling the user to
change account information on the webtop, allowing the user to create
personal webtop favorites, and migrating most-used webtop items to the
top of the list. For more information on configuring the user experience,
see the online help for the Users : Groups : Master Groups screen on the
User Experience tab.
Note
When you create a new favorite, the user must log out and log on again to
have the favorite available.
Customizing the user experience for Network Access

connections
There are a number of ways to customize the user experience for Network
Access connections.

Chapter 5
• Configuring for a Network Access-only user experience

For more information, see Configuring for a Network Access-only user
experience, following.
• Ordering the items on the user’s webtop
For more information, see Ordering the items on the user’s webtop, on
page 5-41.
• Controlling how the favorites reorder in response to frequency of use
For more information, see Controlling how the favorites reorder in
response to frequency of use, on page 5-41.
• Displaying banners and logos on the screen
For more information, see Displaying banners and logos on the screen,
on page 5-41.
• Allowing users to change their information and create favorites
For more information, see Allowing users to change their information
and create favorites, on page 5-41.
• Specifying the first-name, last-name order presented in the user’s
webtop
For more information, see Specifying the first-name, last-name order
presented in the user’s webtop, on page 5-42.
• Presenting the Network Access connection as an icon in the Windows
system tray
For more information, see Presenting the Network Access connection as
an icon in the Windows system tray, on page 5-42.
• Minimizing the connection window after successful connection
For more information, see Minimizing the connection window after
successful connection, on page 5-42.
Auto-launching web applications

Network Access Webtop functionality allows the auto-launching of web
applications from an Application Tunnels Favorites list or a Web
Applications Tunnels list, in addition to supporting legacy access options.
Use to the App Tunnels : Resources : Application Tunnels or Web
Application Tunnels screens to enable these new webtop access options.
Configuring for a Network Access-only user experience

You can configure for a Network Access-only user experience by enabling
the Use Network Access Only Webtop option on the User Experience
screen, available on the Users : Groups : Master Groups screen. This option
is useful when you have only one Network Access favorite This option is
used only when you have one Network Access favorite and Autolaunch
based on endpoint protection is enabled on the Client Settings tab on the
Network Access : Resources screen. Enabling the Use Network Access
Only Webtop option starts the Network Access connection and replaces the
webtop with the contents of the Network Access window.
5 - 40
If you also enable the option Minimize window after successfully

connecting Network Access client, available on the Network Access :
Resources screen, the system minimizes the browser window after
establishing the Network Access connection. If you enable the options
Minimize window after successfully connecting Network Access client
and Use Tray icon instead of Taskbar entry when minimized, the system
minimizes the browser window to the F5 icon in the system tray. If you
enable the options Minimize window after successfully connecting
Network Access client, Use Tray icon instead of Taskbar entry when
minimized, and Do not display tray icon for connection, the system
minimizes the browser window, and shows only the F5 icon in the system
tray.
Ordering the items on the user’s webtop

You can specify the order items appear on the user’s webtop by configuring
items on the User Experience screen, available on the Users : Groups :
Master Groups screen. You can use arrows to reorder items on the user’s
webtop, specify custom names for the different items, and determine content
for browsers that support HTML 3.2 and later, browsers for PDA, i-mode,
and other minibrowsers, and WAP phone.
Controlling how the favorites reorder in response to frequency of use

You can elect to have frequently used favorites migrate to the top of the
user’s list by enabling the Enable user-level adaptive ordering of
webifyers option on the User Experience screen, available on the Users :
Groups : Master Groups screen. Then, favorites that users click more often
move to the top of their favorites list when they next access their webtops.
Displaying banners and logos on the screen

You can control whether banners and logos show along the top of the user’s
webtop by enabling the FirePass Webtop doesn’t show logo and banner
by default option on the User Experience screen, available on the Users :
Groups : Master Groups screen. You can also control whether the webtop
contains both favorites and icons by selecting one of the following options:
• Show Favorites only, hide Webifyer icons
• Show both Favorites and Webifyer icons
• Show Webifyer icons only (classic look)
Allowing users to change their information and create favorites

You can allow users to change their information by enabling the Allow user
to change user information option. When enabled, users can change their
first name, middle initial, last name, and email address by selecting the
Tools : Account Details screen from their webtops.

Chapter 5
Specifying the first-name, last-name order presented in the user’s webtop

You can control how you want to display the user’s full name on the User
Management screen, in reports and logs, in other places in the Administrator
Console, and on the user’s webtop.
You can elect to have user names governed by the global option Default
order for full user name, available on the Device Management :
Customization : Global screen, by enabling the option Use global setting in
Device Management : Customization. When this option is disabled, you
can select an ordering option from the Order in full user name list on the
User Experience screen, available on the Users : Groups : Master Groups
screen. The ordering option applies to all users in the master group specified
in the Master Group list.
Presenting the Network Access connection as an icon in the Windows

system tray
You can have the Network Access connection appear as an icon in the
Windows system tray instead of showing as a Windows Taskbar entry when
minimized. To do so, check the Use Tray icon instead of Taskbar entry
when minimized option on the Customization tab, available on the Network
Access : Resources screen. If you check this option, when the user
minimizes the Network Access connection window, the system places an
icon in the Windows system tray instead of creating an entry for the
Windows Taskbar. Using this option simplifies the user experience, takes
less space on the user’s Taskbar, and prevents the user from using Alt+Tab
to navigate to the Network Access connection window.
You can also eliminate the tray icon completely by enabling the Do not
display tray icon for connection option on the Customization tab, available
on the Network Access : Resources screen. Using this option prevents the
user from inadvertently closing the Network Access connection.
Minimizing the connection window after successful connection

You can have the system automatically minimize the Network Access
connection window after establishing a successful connection by enabling
the Minimize window after successfully connecting Network Access
client option on the Customization tab, available on the Network Access :
Resources screen. Using this option helps simplify the user experience and
expand screen real estate by removing the Network Access connection
window.
5 - 42
6
• Introducing Application Access
• Understanding App Tunnels
• Defining App Tunnel favorites
• Configuring master group settings for App Tunnels
• Understanding Legacy Host connections
• Configuring terminal server favorites
• Configuring global settings for Application Access

Introducing Application Access

The FirePass controller Application Access features provide remote users
with web-based remote access to a wide variety of network applications and
resources, including email servers, intranet servers, file servers, terminal
services, and legacy mainframe, IBM iSeries and AS/400, Telnet
character-based terminal applications.
Application Access enables users to use an existing client to access the
server application through App Tunnels, or they can have the FirePass
controller supply the browser-based Legacy Hosts and Terminal Servers
ActiveX components or Java client.
Application Access consists of three main types of access:
• App Tunnel access
Provides remote users with browser-based access to a backend server.
App Tunnels provide secure, application-level TCP/IP connections from
the client into a specified set of IP addresses and ports on the LAN.
• Legacy host access
Provides remote users with browser-based, character-driven terminal
access to legacy VT100, VT320, Telnet, SSH, and IBM 3270 and IBM
5250 applications without any modifications to the applications or
application servers.
• Terminal services access
Provides remote users with browser-based, graphical terminal interfaces
for Microsoft® Terminal Servers, Citrix® MetaFrame applications, and
VNC servers.
Application Access does not require any application modifications or any

third-party software to enable the interaction with the application.
The connection process automatically downloads and installs all
components required on the client system. You can also preinstall the
components, if your company security policy prohibits ActiveX component
installation by the end user.
Legacy Host access supports TN5250 and IBM iSeries and AS/400
connections through an ActiveX control for Internet Explorer®, and a
self-installed plug-in for Netscape Navigator® and Mozilla® browsers on
Microsoft® Windows® operating system-based client computers to interpret
the terminal data stream. Legacy Host access provides support through Java
for VT100/320 for UNIX, and TN3270 for mainframes.

Chapter 6
Understanding App Tunnels

Application Tunnels, or App Tunnels, provide much the same functionality
as Network Access, but they allow additional control over which application
a user can access through the FirePass controller.
Using App Tunnels, you can configure secure, application-level TCP/IP
connections from the client to a specific set of IP addresses and ports on the
network. On the remote end, the browser loads an ActiveX control in
Internet Explorer, and a self-installed plug-in for Netscape or Mozilla
browsers on Windows platforms. After the process establishes a connection,
the user-defined applications that use these connections can be started
automatically.
Unlike a traditional IPsec VPN client that exposes the entire network, App
Tunnels only create connections to the specific resources used by the
configured application. You can also restrict users to the particular
application they need to use.
You can configure the following applications for use with App Tunnels:
• Applications that are accessed using HTTP or HTTPS
• Terminal emulators, including SSH
• Internet Mail (POP/IMAP/SMTP)
• LDAP-enabled clients
• Network drive mapping
• Custom applications
Note
App Tunnels do not support UDP application traffic.
6-2
Figure 6.1 shows a comparison of the flow of application data in a

traditional environment and with the FirePass controller App Tunnels.
Figure 6.1 Comparison of application data flow without and with the FirePass controller
Choosing a static or dynamic App Tunnel

The FirePass controller supports two types of App Tunnels: static and
dynamic. The system creates static tunnels when the client clicks to run a
favorite, before the application starts. The system creates dynamic tunnels
in response to an application request.
Note
You can configure a combination of dynamic and static tunnels for a single
App Tunnel definition.
Static App Tunnels support connections to a specific set of IP addresses and

ports on the network. You can configure static App Tunnels to work without
requiring the user to have administrative rights on the client system.
The following cases represent examples of when to use static App Tunnels:
• Applications that are accessed using HTTP or HTTPS
• Custom applications
• Applications that do not allow more than one instance, but there might be
an instance running and you do not want to halt the existing instance
• Internet Mail (POP/IMAP/SMTP)
• LDAP-enabled clients
• Network drive mapping

Chapter 6
• Windows file sharing (because this application uses the operating system
kernel to provide network communication or server, not the Windows
socket API)
• Terminal emulators, including SSH
Dynamic App Tunnels support applications that require dynamic IP

addressees and ports. The following are examples of candidates for dynamic
App Tunnels.
• A web application that uses ActiveX controls or Java-based plug-ins to
open a network socket directly to the application server
• A web application that uses XML to embed a hard-coded IP address or
hard-coded port number of the application server
• A custom (nonbrowser-based) application that does not communicate
using the HTTP protocol
• Applications that do not allow more than one instance, but there might be
an instance running and it is acceptable to halt the existing instance
Dynamic App Tunnels work best with applications that support multiple
instances. To determine whether an application supports multiple instances,
on a Windows computer, right-click the Windows Taskbar, select the Task
Manager item, and click the Processes tab. Then start an application several
times to see if more than one process of this application appears in the list on
the Processes screen. If the application does not support multiple instances,
there is always only one process in the list.
You can still use dynamic App Tunnels with these types of applications if
you enable the Terminate existing option when you configure the dynamic
App Tunnel favorite. When you enable this option, when the user starts an
App Tunnel that would result in an additional instance being created, the
system prompts the user to close the existing instance before starting the
additional one.
When you use dynamic App Tunnels, the system creates a tunnel when the
client application needs to communicate with the server. Therefore, dynamic
App Tunnels are also a good choice in cases in which you do not want all
ports created at the same time, for example, when you have a number of
servers performing load balancing.
Important
Running dynamic App Tunnels requires that the user has power user rights.
You configure dynamic App Tunnels on the following screens:

• In a specific definition on the Application Access: App Tunnels :
Resources screen under the Application Tunnels tab
• On the Application Access: App Tunnels: Master Groups Settings screen
on the Dynamic Tunnels/Web Application Tunnels tab
Note
If you have legacy App Tunnels that are working for you, there is no need
for reconfiguration. The system automatically uses static App Tunnels.
6-4
Defining a web application tunnel

A web application App Tunnel is a dynamic App Tunnel designed
specifically for a web browser-based application. To configure a Web
Application Tunnel, you use URLs to specify the location of the application.
In this case, the system creates the tunnel when the user clicks a link (that is,
dynamically).
Note
Although you can configure the same application using a dynamic App
Tunnel, the process for configuring web application App Tunnels is simpler.
Web applications are perfect candidates for using dynamic App Tunnels as
long as they do not use reverse proxy. If an application uses reverse proxy,
you can still try configuring it for dynamic App Tunnels. If the application
does not work through dynamic App Tunnels, you should use Portal Access
instead to configure the connection.
Web App Tunnels require a browser that supports multiple instances.
Windows Internet Explorer supports multiple instances. Mozilla and
FireFox support multiple processes within the same instance, but not
multiple instances. Therefore, even if the user’s default browser is not
Internet Explorer, all dynamic App Tunnels start an instance of Internet
Explorer or a custom minibrowser developed specifically to support
dynamic App Tunnels.
Use of the minibrowser provides additional security in that users cannot
copy text from the minibrowser window, print when the minibrowser is the
active application, or drag and drop to the minibrowser window. In addition,
the minibrowser does not allow the running of plug-ins or extensions.
Tip
You can configure this additional security for Internet Explorer users as
well by enabling the Locked Browser option when you create a Web
Application Tunnel favorite.
You configure web application App Tunnels on the following screens:

• On the Application Access : App Tunnels : Resources screen under the
Web Application Tunnels tab. For more information about creating web
application App Tunnels, see To create an App Tunnel favorite or alias,
on page 6-7.
• On the Application Access : App Tunnels : Master Groups Settings
screen under the Dynamic Tunnels/Application Tunnels tab. For more
information about options on this tab, see Understanding master group
settings for dynamic and web application tunnels, on page 6-24.

Chapter 6
Understanding access restrictions for App Tunnels

You can configure an access control list (ACL) to restrict access for a static
or dynamic App Tunnel. ACLs define locations the App Tunnel users can
access from within the App Tunnel. Defining ACLs prevents users from
navigating to locations outside the ones you specifically define for the App
Tunnels that access your network. For procedures for defining ACLs, see
Restricting access to App Tunnels, on page 6-19.
Static and dynamic App Tunnels and web application App Tunnels share
access control lists for the duration of a FirePass controller session. To
change which ACLs govern a session, users must halt the connection and
start it again.
You can configure ACLs in the following areas:
• On the Application Access : App Tunnels : Master Group Settings screen
under the Common tab
Application Tunnels tab
Web Application Tunnels tab
• In the Allow list box specific to the App Tunnel you define on the
Application Access : App Tunnels : Resources screen under the
Application Tunnels tab or the Web Application Tunnels.
The location of the ACL definition does not matter. The system combines
all ACLs to use during the session. The system combines entries in ACLs
from definitions in the following locations:
• At the master group level
• At the resource group level
• In the specific App Tunnel favorite definition
ACLs defined on the Master Group Settings screen cover the entire master
group, but you can specify additional resource-level ACLs on the Resources
screen. In addition, ACLs defined on the Resources screen cover the entire
resource group, but you can specify App Tunnel-specific ACLs in the Allow
list box for the App Tunnel.
Important
For dynamic App Tunnels, if you do not specifically allow access, the system
disallows it.
6-6
Defining App Tunnel favorites

You can create favorites and aliases to favorites on the Resources screen. A
favorite is a named and saved set of options. An alias to a favorite is a
named link to an existing favorite in another resource group. Favorites and
aliases to favorites appear as links on the user’s webtop. When a user clicks
a favorite or an alias, the system establishes the static App Tunnel and starts
the application specified.
To create an App Tunnel favorite or alias

1. In the navigation pane, click Application Access.
The Application Access : App Tunnels : Resources screen opens.
2. From the Resource Group list in the upper left, select the resource
group you want to contain the favorite.
3. Click the Add New Favorite link.
The screen refreshes to reveal additional options.
4. From the Type list, select from the following types:
• Favorite: Represents a new App Tunnel.
To create a new favorite, select Favorite, and skip to To complete
the favorite definition, following.
• Alias: Represents an association with a existing favorite from a
different resource group. If there are no other groups available, or
if you have not defined other connections, the system does not
present the Alias option.
When you select Alias, the screen refreshes to reveal additional
options, as described in To complete the alias definition, on page
6-12.
To complete the favorite definition

First, complete the procedure, To create an App Tunnel favorite or alias,
preceding, selecting Favorite from the Type list in step 4.
1. In the Name box, type the identifying label you want to use.
The FirePass controller displays this name as a label for the App
Tunnels favorite on the user’s webtop.
2. In Allow List, specify a host name or IP address and ports in the
following format:
host_name:ports or IP_address/mask:ports
For example:
*.siterequest.com:80 or 172.30.11.0/24:80,443
Note: For more information about specifying ACLs, see To specify
ACLs for favorites or aliases, on page 6-22.

Chapter 6
3. If you want to restrict access based on a defined protected

configuration, from the Endpoint protection required list, select
the protected configuration. To add endpoint protection, you must
first define it. For more information about protected configurations,
see Creating protected configurations, on page 3-27.
4. Click the Add Favorite button.
The new favorite appears in the list.
5. To add a dynamic App Tunnel, click the Add New Dynamic App
Tunnel button, and continue with the following procedure.
6. To add a static App Tunnel, click the Add button to the left of
the Static Tunnels heading, and continue with the procedure To
complete the static App Tunnel definition, on page 6-10.
To complete the dynamic App Tunnel definition

First, complete the procedure, To complete the favorite definition,
preceding, electing to configure a dynamic App Tunnel.
1. From the list of clients, select a type of application you want the
client to use. You can select one of the following types of
applications:
• Custom
• Citrix Neighborhood Agent.
• Microsoft Outlook
• Microsoft Outlook Express
• Microsoft Telnet client
• Microsoft Terminal Server Client
• PuTTY
• SecureCRT
• Private Shell
For more information on each of these client options, see Table 6.1,
on page 6-10.
2. In the accompanying Name box, specify the user-friendly name for
the system to use when presenting the name to the user in a dialog
box.
3. In the Application box, specify a string that starts an application
transparently for the user.
For example:
telnet 127.10.10.10
putty -ssh 127.10.10.10
"%SYSTEMROOT%/SYSTEM32/mstsc.exe"
6-8
Note: The system searches the path for the application, so you do
not have to specify the complete path if the path is already set. If you
do not specify a path, the FirePass controller searches the Windows
registry. If an application registers itself in the Windows registry,
like Microsoft Outlook does, for example, the FirePass controller
can run it.
4. Check or clear the Terminate Existing box, if the application you
are starting does not support multiple instances, or when you want
the system to prompt the user for confirmation in halting the
existing instance.
5. Click the Add New Dynamic Tunnel button.
You can modify any existing setting by changing it and clicking the
Update All button.
Note
When you create a new favorite, a logged-in user must refresh the webtop to
When you select one of the options in the list of clients, the FirePass
controller populates the associated boxes with common values, as described
in Table 6.1.
item description
Custom When you select Custom, you can specify the application name and path,
including any environment variables in the format %envvarname%,
enclosing the string in quotation marks when the path contains spaces. The
variables resolve to the value representing the environment variable on the
client computer. For example, to configure for the Microsoft Service
Terminal client, specify the following string in Application:
"%SystemRoot%\system32\mstsc.exe" /v: mysite
For more information about creating custom App Tunnels, see Creating
custom App Tunnels, on page 6-16.
Citrix Neighborhood Agent When you select Citrix Neighborhood Agent, the system populates the
Name box with the value Citrix Neighborhood Agent, places the value
"%ProgramFiles%/Citrix/ICA Client/pnagent.exe" in the Application
box, and enables the Terminate Existing box. These are default values
that you can change.
Microsoft Outlook When you select Microsoft Outlook, the system populates the Name box
with the value Microsoft Outlook, places the value outlook.exe in the
Application box, and enables the Terminate Existing box. These are
default values that you can change.
Microsoft Outlook Express When you select Microsoft Outlook Express, the system populates the
Name box with the value Microsoft Outlook Express, places the value
msimn.exe in the Application box, and enables the Terminate Existing
box. These are default values that you can change.
Table 6.1 Values associated with each type of client

Chapter 6
item description
Microsoft Telnet client When you select Microsoft Telnet client, the system populates the Name
box with the value Microsoft Telnet client, and places the value
"%SYSTEMROOT%/SYSTEM32/telnet.exe" in the Application box.
These are default values that you can change.
Microsoft Terminal Server Client When you select Microsoft Terminal Server Client, the system populates
the Name box with the value Microsoft Terminal Server Client, and
places the value "%SYSTEMROOT%/SYSTEM32/mstsc.exe" in the
Application box. These are default values that you can change.
PuTTY When you select PuTTY, the system populates the Name box with the
value PuTTY, and places the value "%ProgramFiles%/PuTTY/putty.exe"
in the Application box. These are default values that you can change.
SecureCRT When you select SecureCRT, the system populates the Name box with the
value SecureCRT, and places the value
"%ProgramFiles%/SecureCRT/SecureCRT.exe" in the Application box.
These are default values that you can change.
Private Shell When you select Private Shell, the system populates the Name box with
the value Private Shell, and places the value "%ProgramFiles%/Private
Shell/pshell.exe" in the Application box. These are default values that
you can change.
Table 6.1 Values associated with each type of client
To complete the static App Tunnel definition

First, complete the procedure, To complete the favorite definition,
preceding, electing to configure a static App Tunnel.
1. From the list of clients, select a type of application you want the
client to use. You can select one of the following types of
applications:
• Custom client
For more information about creating custom App Tunnels, see
Creating custom App Tunnels, on page 6-16.
• Exchange
• Internet EMail (POP + SMTP)
• Internet EMail (IMAP + SMTP)
• LDAP
• http
• https
• Telnet
• SSH
• VNC
• Front Page/WebDAV
6 - 10
• MS Terminal Services
• Citrix
• RPC port mapper
• FTP (Passive)
• MS File Shares
• Exchange Client/Server Comm.
When you select an option, the system adds boxes, if necessary, and
populates those boxes with common settings. For more information,
see Example of system response, following.
2. In the Application box, specify a string that starts an application
transparently for the user. For example:
iexplore http://127.10.10.80/sales/automation.pl
telnet 127.10.10.10
putty -ssh 127.10.10.10
3. Check or clear the Keep Alive box.

Note: Checking Keep Alive turns on the TCP-based Keep Alive
setting on both the client-to-FirePass controller connection and the
FirePass controller-to-target-host connection. Checking Keep Alive
does not prevent the user’s session from timing out.
4. Click the Add New Static Tunnel button.
You can modify any existing setting by changing it and clicking the
Update All button.
Note
Example of system response

When you select an option in step 1 of the preceding procedure, the system
adds settings, if necessary, and populates those settings with common
values. For example, you select Internet EMail (POP and SMTP) as the
application class, the FirePass controller adds a definition row, and
populates the two rows with common application settings. In the first row,
the system places a port number of 110 in the Remote Host : Port or
Range box.
The FirePass controller next generates an IP address from the
127.0.0.0/255.0.0.0 subnet, and places that generated value, along with 110,
in the Local Host : Port or Range boxes. This is the IP address and port
combination the client connects to when accessing the App Tunnel.
Finally, the system generates another IP address from the same subnet, and
places that generated value, along with 25, in the Local Host : Port or
Range boxes. This is the IP address that the system uses for SMTP
exchanges. You can change these values to match those of your local
network, when they differ from the defaults.

Chapter 6
To complete the alias definition

First complete the procedure, To create an App Tunnel favorite or alias, on
page 6-7, selecting Alias from the Type list in step 4.
1. From the Group list, select the resource group containing the
existing favorite you want to use as the source for the alias.
2. From the Favorite list, select the favorite you want to use as the
source for the alias.
3. Check Inherit Allow List to use the defined ACLs from the source,
or clear the box to reveal an Allow List you can configure
specifically for this alias.
the protected configuration.
To add endpoint protection, you must first define access rules.
5. Click the Add Favorite button.
The new alias appears in the list.
Note: The alias uses the dynamic or static application tunnel
definition from the source favorite.
Creating web application App Tunnel favorites

To make dynamic web applications tunnels available to users, you create
favorites that access your internal web sites. When the user clicks a web
application tunnel favorite, the FirePass controller starts a web browser,
which opens the specified URL The system dynamically creates all TCP
tunnels required to download the page.
To create a web application App Tunnel

The Resources screen opens.
2. Click the Web Application Tunnels tab.
The Web Application Tunnels screen opens.
group you want to contain the web application App Tunnel.
• Favorite: Represents a new web application App Tunnel.
To create a new favorite, select Favorite, and skip to To complete
the web application favorite definition, on page 6-13.
6 - 12

different resource group. If there are no other groups available, or
if you have not defined other connections, the system does not
present the Alias option.
options, as described in the following procedure.
To complete the web application alias definition

First, complete the preceding procedure, To create a web application App
Tunnel, selecting Alias from the Type list in step 5.
1. From the From group list, select the resource group containing the
existing favorite you want to use as the source for the alias.
2. From the Favorite list, select the favorite you want to use as the
source for the alias.
3. Check Inherit ACL to use the defined ACLs from the source, or
clear the box to enable the Local ACL box, where you can specify
ACLs for this alias.
4. Click the Add New button.
The new alias appears in the list.
Note: The alias uses the endpoint protection setting from the source
favorite.
To complete the web application favorite definition

First, complete the preceding procedure, To create a web application App
Tunnel, on page 6-12, selecting Favorite from the Type list in step 5.
1. In the Name box, type the identifying label you want to use.
The FirePass controller displays this name as a label for the App
Tunnels favorite on the user’s webtop.
2. In URL, type the intranet web server that serves the application. For
example: http://server.siterequest.com/index.html
Note: You can click the Add to allow list link to add the URL to
Allow list automatically.
3. In URL variables, type the arguments to be either appended to the
GET request or sent as data in a POST request to the specified URL.
4. Check Use POST for URL variables to have the system include
the variables in the POST request, or clear the box to prevent
sending of the variables.
5. Check Locked Browser to prevent certain user functionality,
including:
• Typing URLs in the browser’s address box.
• Selecting text on the page.
• Saving web pages.

Chapter 6
• Printing web pages.

6. In Allow List, specify a host name or IP address in the following
format:
host_name:ports or IP_address/mask:ports
For example:
*.siterequest.com:80 or 172.30.11.0/24:80,443
Note: For more information about specifying ACLs, see To specify
ACLs for favorites or aliases, on page 6-22.
the protected configuration. To add endpoint protection, you must
first define access rules.
The new favorite appears in the list.
Once you configure a favorite, you can select one to start automatically by
selecting it from the Default box, and clicking Update.
You can also define resource-group level ACLs for web application App
Tunnels. For more information, see To specify a resource-group level ACL,
on page 6-21.
Using the alternate webtop

Use the alternate webtop option when you want to establish an App Tunnel
connection that automatically starts one or more favorites in a small browser
window.
To establish an App Tunnel connection using alternate

webtop
The Resources screen opens and the Applications Tunnels tab
displays.
2. Check the Autolaunch based on endpoint protection option.
Note: If the client does not meet the protected configuration
criteria, the user is presented with a standard webtop instead of the
alternate webtop.
3. Check the Use Alternate Webtop option.
Note
When you configure multiple alternate webtops (for example, one for App
Tunnels, and another for Network Access), the FirePass controller starts
and displays them in a small browser window. Applications like Telnet or
Terminal Services are automatically started and displayed in additional
small browser windows because they require additional input from the user.
6 - 14
To automatically minimize the App Tunnel client and put it

in the system tray when the user logs on
1. In the navigation pane, click the Application Access option.
The Resource screen opens.
2. Click Master Group Settings.
The Common screen opens.
3. Scroll to the Customization area and check the option for Minimize
window after successfully creating Static Tunnel option.
4. Check the option for Use Tray icon instead of Taskbar entry
when minimized.
Note
When you enable these options, the users can end their App Tunnel
connection and their session by right-clicking the tray icon and selecting the
Terminate connections option.
Hide URLS of administrator-defined Favorites

To prevent users from seeing administrator-defined favorites URLs, in the
URL Display area of the Master Group Settings screen, check the option
Hide URLs of administrator-defined Favorites.
Configuring remote host and local host settings: important

considerations
If you specify a network name (that is, a DNS name, a WINS name, or a
static host name) instead of an IP address in Remote Host or Local Host,
the App Tunnel or Terminal Servers connection operation changes the hosts
file on the client computer during the connection. If you define the remote
hosts with IP addresses, then the system does not modify the hosts file.
On Windows systems, you can find the hosts file in
<drive>\<windowsdir>\system32\drivers\etc\hosts.
The temporary patch allows the App Tunnel or Terminal Server connection
to override the network name settings, while preserving the existing network
name settings for the applications. The App Tunnel or Terminal Server
connection restores the original hosts file when it ends the session.
Important

Chapter 6
The Static App Tunnels feature supports forwarding ranges of TCP ports.
To do this, specify the range in the Remote Host : Port or Range and
Local Host : Port or Range boxes as port1-port2,port3,port4-port5, and
so on. The App Tunnels feature limits the maximum number of port settings
to 50. If you use port ranges, the range you specify in the local and remote
settings must match.
Creating custom App Tunnels

You can create a custom tunnel by specifying the values you want for the
connection in the Remote Host : Port or Range and Local Host : Port or
Range boxes.
In general, F5 Networks recommends that you specify the port number of
the remote host, unless the client’s computer is already running a service on
that port. You can specify a port range containing a maximum of 50 ports. If
you specify a port range, the local and remote ranges must match.
We also recommend that the IP addresses you specify be associated with the
DNS name of the service the clients need in either the local hosts file or on
the DNS server. For example:
telnet.siterequest.com 127.10.10.10
Important
In custom App Tunnels, you can specify environment variables in the

format %variable%. The system replaces the variable with the appropriate
value when it creates the tunnel. Use quotation marks to enclose any
application strings that contain spaces.
The system supports the following variables:
• %envvarname%
Represents the value of the environment variable on the client computer.
• %group%
Represents the master group name of the user who is logging on.
• %username%
Represents the name of the user who is logging on.
• %firstname%
Represents the user’s first name.
• %lastname%
Represents the user’s last name.
• %fullname%
Represents the combination of the user’s first and last name.
6 - 16
The system also supports the following variables for mapping Microsoft
Windows network shares.
• %envvarname%
Represents the value of the environment variable on the client computer.
• %password%
Resolves to the user’s password when you enable the master group
option Auto-logon TO applicable AppTunnels using FirePass user
logon credentials.
• %host%
Represents the host address, which the system resolves to the loopback
host address.
• %port%
Indicates the loopback port.
The %port% variable is useful when original local port changes because
of conflicts with other software.
The following entries illustrate valid strings for various App Tunnels.
iexplore http://%host%:%port%/sales/automation.pl?u=%username%
telnet 127.3.54.34
%SystemRoot%\System32\mstsc.exe /v:127.107.93.167 /f
Configuring App Tunnels that open automatically

You can configure an App Tunnel to open automatically. You can have the
system restrict automatic opening of App Tunnels depending on the
assigned protected configuration.
To configure App Tunnel auto-open

1. Create an App Tunnel favorite, as described in Defining App Tunnel
favorites, on page 6-7, making sure to select a defined protected
configuration from the Endpoint protection required list.
2. Check the Autolaunch based on endpoint protection check box.
3. From the endpoint list, select the endpoint protection you want to
require, or select Any endpoint configuration to have the system
open the App Tunnels based on any security you have configured
for the clients.
4. In the Autolaunch tunnels section, check the box to the left of each
tunnels you want the system to automatically open for clients that
pass the configured endpoint security requirements.
5. Click the Apply button.
Now, when users who log on have the endpoint protection you require, the
FirePass controller automatically opens the associated App Tunnel and
provides the user access.

Chapter 6
Creating static App Tunnels to network file shares

You can configure a static App Tunnel to map to network file shares. You
can have the tunnel open automatically, depending on the assigned protected
configuration, like other App Tunnels.
To map a network drive

1. Create a static App Tunnel, and select MS File Shares.
For more information about creating application tunnels, see
Defining App Tunnel favorites, on page 6-7.
2. Retain the default value of 139 in Remote Host : Port or Range
and Local Host : Port or Range.
3. In Command Line, type a string for the process to use to mount the
drive.
You can use the following templates, substituting your network
information in the appropriate places.
mount <drive_name> \\<network_computer_name>\<shared_folder_name>
mount <drive_name> \\<automatically_generated_IP_address>\<shared_folder_name>
For example, if you want to map the H drive on the client computer
to the sales share, which is located on the corporate_presentations
computer, type:
mount H: \\corporate_presentations\sales
mount H: \\127.31.21.233\sales
Note: You can use the syntax specified in the second example when
the client operating system is Windows NT, Windows 2000,
Windows SP, or Windows Me.
For drive mapping to work, the FirePass controller must have a valid
certificate signed by a Certificate Authority accepted by the client’s
browser. Otherwise, a security warning could prevent the drive from being
mapped successfully.
Tip
When you configure App Tunnels for mapping drives, you can have clients
use their FirePass controller logon credentials by selecting the option
Auto-logon to applicable AppTunnels using FirePass controller user
logon credentials on the Application Access : App Tunnels : Master Group
Settings screen. This option applies only to App Tunnels configured to map
a network drive. If you select this option, you can also provide a domain or
workgroup name to be used when logging on to the mapped drive.
6 - 18
Restricting access to App Tunnels

Sometimes called Allow Lists, ACLs control access within App Tunnels at
three levels, each level’s ACLs being combined to govern the entire session.
You define ACLs when you want to prevent the user from accessing
locations outside the ones you specifically define for the App Tunnels that
access your network. You can specify ACLs in the following locations.
◆ In all App Tunnels in a specific master group
You define master-group level ACLs on the Master Group Settings
screen, available under Application Access : App Tunnels. For specific
procedures, see To specify ACLs for a master group, on page 6-20.
◆ For an entire resource-group
You define resource-group level ACLs on the Application Tunnels or
Web Application Tunnels tabs, available from the Application Access :
App Tunnels : Resources screen. For specific procedures, see To specify
a resource-group level ACL, on page 6-21.
◆ Within specific favorites or aliases you define
You define favorite- or alias-level ACLs in the favorite or alias directly.
For specific procedures, see To specify ACLs for favorites or aliases, on
page 6-22.
One FirePass controller session for a user shares all ACLs you define for the
master group that contains the resource groups, those for all static and
dynamic App Tunnels and web application App Tunnels in a specific
resource group, and ACLs you specify for favorites or aliases within a
resource group. For a description of ACLs, see Understanding access
restrictions for App Tunnels, on page 6-6.
Important
For App Tunnels, if you do not specifically allow access, the system
disallows it.
Specifying ACLs
When you specify an ACL, you use a specific format, consisting of various
elements. This section describes each element of an ACL and presents
specific examples of how to define an ACL entry in the list.
When you specify an ACL, use the following format:
hostname:port | :port_range
ip_address/mask:port | :port_range
Separate each entry with a return. Separate multiple ports and port ranges
with a comma. If you do not specify a port or range of ports, the system
allows access from every port.
◆ hostname or ip_address
Represents the host name or IP address that you want the user to have
access to, for example:
siterequest.com

Chapter 6
192.168.200.216:80-8080
You can use the asterisk when specifying hostname. The asterisk
matches any number of characters, for example:
*.siterequest.com:80
*.site*quest.com:23,80,443
*.siterequest*:23-25
You cannot specify a protocol or a URI in any ACL.

◆ mask
Represents the subnet mask for the IP address, specified as a number of
bits or in dotted-quad notation, for example:
172.30.11.0/24:80,443
172.30.11.0/255.255.255.0:1-65535
◆ port or port_range
Represents one or more port numbers, ranges of ports, or a combination
of individual ports and port ranges, specified in accordance with the
following guidelines:
• Every port number or range is a number from 1 through 65535.
• The port range is represented by a dash between two ascending
numbers, for example, 1-10 or 500-600.
• Each instance of a port or port range is separated by commas.
• No instance of a port or port range overlaps another, that is, one
specified port or port range cannot be contained in another port range,
so it is not valid to specify 24,22-25.
• You must specify port numbers in ascending order, for example:
www.siterequest.com:22-25,80,443
• If you do not specify a port, the system substitutes a port range of
1-65535, which represents all ports.
Important
If you specify a fully qualified domain name (FQDN) as the host name in the
ACL, the user must specify the FQDN to access the host.
To specify ACLs for a master group

1. In the navigation pane, click Application Access, expand App
Tunnels, and click Master Group Settings.
The Master Group Settings screen opens with the Common tab
active.
2. From the Master Group list near the upper left of the screen, select
the master group you want to affect.
The screen changes to reveal the existing App Tunnels defined for
the selected master group.
3. In the Allow List box in the Access Control List area of the screen,
type the host name or IP address you want the client to be able to
access. For example:
6 - 20
Separate multiple entries with a return. Separate multiple ports and

port ranges with a comma. If you do not specify a port or range of
ports, the system allows access from every port. For more
information about ACLs, see Specifying ACLs, on page 6-19.
4. Click Update.
Important
Make sure that you click Update to save your ACLs. If you select a different
master group before you click Update, the system discards any ACLs you
have specified.
You can specify ACLs on a per-resource-group basis.
To specify a resource-group level ACL

Tunnels, and click Resources.
The App Tunnels Resources screen opens with the Application
Tunnels tab active.
2. From the Resource Group list near the upper left of the screen,
select the resource group you want to affect.
the selected resource group.
3. In the Allow List box in the Access Control List area of the screen,
type the host name or IP address you want the client to be able to
access.

information about ACL elements, see Specifying ACLs, on page
6-19.
4. Click Update.
Important
Make sure that you click Update to save your ACLs. If you select a different
have specified.
ACLs specified at the resource-group level are combined with those set at
the master-group level. You can specify additional ACLs in the favorite or
alias itself.

Chapter 6
To specify ACLs for favorites or aliases

The App Tunnels Resources screen opens with the Application
Tunnels tab active.
2. From the Resource Group list near the upper left of the screen,
select the resource group you want to affect.
the selected resource group.
3. Click the Add new favorite link to create a new favorite or alias.
For associated procedures, see To create an App Tunnel favorite or
alias, on page 6-7.
4. In the Allow List for the favorite or alias, specify the ACLs, for
example:

information about ACL elements, see Specifying ACLs, on page
6-19.
5. Click Update.
Important
Make sure you click Update to save your ACLs. If you select a different
have specified.
ACLs specified at the favorite or alias level are combined with those set at
the resource-group level and the master-group level.
6 - 22
Configuring master group settings for App Tunnels

You can specify master-group based settings that apply whenever a user
who belongs to a specific master group clicks a favorite in the App Tunnels
section of the webtop. You set master group settings on the Application
Access : App Tunnels : Master Group Settings screen. The screen provides
two tabs: Common and Dynamic Tunnels/Web Application Tunnels.
Understanding common master group settings for all App Tunnels

General master group-based settings for App Tunnels govern the App
Tunnels type of Application Access connections. You can find general
master group settings on the Common tab on the Application Access : App
Tunnels : Master Group Settings screen.
On the Common screen, you can specify the following master-group-based
settings.
◆ Show administrator-defined favorites only
Restricts client access to App Tunnels that are defined and listed in the
favorites section of the user’s webtop. When you disable this option, the
system removes the Direct Connect link from the user’s webtop as well
as prevents users from creating their own favorites.
◆ Use gzip compression
Compresses all traffic between the client and the FirePass controller,
using the gzip deflate method.
◆ Auto-logon to applicable AppTunnels using FirePass user logon
credentials
Allows logon using the FirePass controller logon credentials. Use this
option when users’ FirePass controller name and password match their
Windows logon credentials. This feature permits the user to access a file
share without having to logon again.
◆ Access control list
Restricts user access to host and port combinations specified. For more
information about specifying ACLs for master-group-level access
restriction, see To specify ACLs for a master group, on page 6-20.
For general information about master groups, see Introducing master groups
and resource groups, on page 2-1.
Configuring Customization settings on the Master Group Settings screen

Settings in the Customization section affect all App Tunnels types of
Application Access connections in the master group specified in the Master
Group list at the top of the screen.
• Present the user with a message box after successfully creating Static
Tunnel
Lets the user know that the static App Tunnel was successfully created.

Chapter 6
• Minimize window after successfully creating Static Tunnel

Minimizes the user's App Tunnel control window after the App Tunnel
opens.
• Use Tray icon instead of Taskbar entry when minimized
Minimizes the connection window as an icon in the Windows system
tray. By default, when a user establishes an App Tunnel, the FirePass
controller displays a connection window to users notifying them that they
have successfully established a connection. When you enable this
feature, the system closes the window and shows the connection as an
icon in the Windows system tray at the lower right of the Taskbar. Users
can use the icon in the Windows system tray to restore or maximize the
connection window, or to terminate their connection.
• Do not show remote server address in AppTunnel window
Cleans the user’s URL so that the actual server address does not appear
in the browser’s location bar.
Configuring settings for the AppTunnels webifyer status in the group

‹groupname› section of the Master Group Settings screen
The final section of the Master Group Settings screen contains a message,
for example:
AppTunnels is presented at the Beginner level, always visible to a user
in the group <groupname>.
The User Experience screen, accessible by clicking Click to change the
status and/or webifyer position on the webtop, provides some options for
customizing what the user sees.
Understanding master group settings for dynamic and web

application tunnels
You can use options on the Dynamic Tunnels/Web Application Tunnels tab
of the Master Group Settings screen to configure split tunneling. Split
tunneling of traffic provides control over exactly what traffic is sent over
the App Tunnel connection to the internal network and which is not.
Configuring split tunneling results in better client application performance
by allowing direct routing of connections destined for the public Internet,
rather than routing the request through the App Tunnel and then out to the
public Internet.
You can set options on the Dynamic Tunnels/Web Application Tunnels
screen for each master group. To specify the master group you want to
affect, select the name from the Master Group list at the upper left of the of
the screen.
The Dynamic Tunnels/Web Application Tunnels screen contains the
following options:
6 - 24
◆ Force all traffic through tunnel

Sends all traffic to or from the local subnet through the dynamic and web
application tunnels.
◆ Use split tunneling for traffic
Routes through dynamic and web application tunnels only the traffic that
meets the specified criteria.
When you select this feature, the screen refreshes to reveal additional
options:
• DNS address space
Provides a list of names describing the target local network DNS
addresses.
Some applications use the FirePass controller DNS server settings for
hosts in the DNS address space, and the local client DNS server for
others. You can elect to use the DNS servers specified on the DNS
tab, available on the Device Management : Configuration : Network
Configuration screen, or you can specify which DNS server to use, in
the DNS address space box. You can use spaces to separate multiple
items. DNS address space supports the asterisk, which represents any
number of characters, for example, type the following to help the
application determine which DNS server to use for resolving a host
name:
*.sales.siterequest.com *.engineering.siterequest.com
• LAN address space
Provides a list of addresses or address/mask pairs describing the target
LAN.
When using split tunneling, the system passes through the configured
tunnel only the traffic to these addresses and network segments, and
traffic to any hosts specified in DNS address space. You can use
spaces to separate multiple items. You can use the following format to
configure this option:
192.168.10.0/255.255.255.0
192.168.10.0/24
192.168.10.0/24 192.168.20.0/24
Important
When you finish specifying entries in DNS address space and LAN address
space, make sure you click the Update button. If you make changes, and
then select a different master group from the Master Group list before
clicking the Update button, the system discards the changes.

Chapter 6
Understanding Legacy Host connections

You can configure access to legacy, or green screen, systems on
mainframes, and other traditional text consoles, using the Legacy Hosts
option. To set master-group-level policies and behaviors, use the
Application Access : Master Group Settings screen. For more information,
see Configuring master group settings for terminal server connections, on
page 6-36.
The Application Access : Legacy Hosts feature supports the following
terminal types:
• Tn3270, 80x24 in Java
• Tn3270, 80x32 in Java
• Tn3270, 80x43 in Java
• Tn3270, 132x27 in Java
• Tn5250, 80x32 as ActiveX control
• Tn5250, 132x27 as ActiveX control
• Vt-100 Telnet in Java
• Vt-100, 80x25 in Java
• Vt-100, 80x32 in Java
• Vt-100, 132x24 in Java
• Vt-100,132x32 in Java
• Vt-220, 80x25 in Java
• Vt-220, 80x32 in Java
• Vt-220, 132x24 in Java
• Vt-220, 132x32 in Java
• Vt-320 HTML
• Vt-320, 80x25 Telnet in Java
Password-based SSH connection (v2.0) is optional. You can find additional

information in the online help for the Application Access : Legacy Hosts :
Resources screen.
6 - 26
Defining legacy host favorites

You can create favorites for legacy host connections. A favorite is a named
and saved set of options. A favorite appears as a link on the user’s webtop.
When a user clicks the link, the system establishes a connection to the
legacy host configured.
To create a Legacy Host favorite or alias

1. In the navigation pane, click Application Access, and click Legacy
Host.
The Application Access : Legacy Hosts : Resources screen opens.
• Favorite: Represents a new connection definition.
To create a new favorite, select Favorite, and skip to step 5.
different group. If there are no other groups available, or no other
connections have been defined, the Alias option is not available.
options. Continue with these steps:
a) From the From group list, select the resource group containing
the existing favorite you want to use as the source.
b) From the Favorite list, select the favorite.
c) Click the Add New button.
The new Alias appears in the list.
5. To continue creating a new favorite, in Name, type the identifying
label you want to use.
The FirePass controller displays this name as a label for the Legacy
Host favorite in the user’s web browser.
6. In Host, type the legacy host for the connection.
7. In Port, type the port you want the connection to use.
8. Check the Use SSH check box to use SSH, or leave the box empty.
9. Check Open in a separate window to have the connection open in
a new instance of the browser window.
Note: This option is always on for 5250 sessions.
10. From the Term-type list, select the type of terminal the connection
is for,
11. In Session name, specify the name for the terminal session.
Note: Session name is available for 5250 sessions only.

Chapter 6
12. Check the Keep Alive check box to prevent the session from
ending, or leave the box empty to permit the sessions to end.
Note: Session name is available for 5250 sessions only.
13. From the Column separators list, select the type of column
separators for 5250 terminals.
14. From the Default charset list, select the character set to use for the
session. The FirePass controller provides several choices:
• DEC Supplemental Graphic Set
• MS-DOS Codepage 850 (Multilingual Latin 1)
• IBM Codepage 850
• ISO 8859-1 (Latin-1)
• Unicode
15. From the 3270 language list, select the language supported by the
3270 terminal.
16. From the Default font size list, select the default font size to use for
Java-based terminals.
17. From the Unicode encoding list, select the encoding. The FirePass
controller provides several choices:
• UTF-8
• UTF-16 little-endian
• UTF-16 big-endian
• UTF-32 little-endian
• UTF-32 big-endian
You can change any of these settings by clicking the link representing the
favorite, modifying the setting, and clicking the Update button.
6 - 28
Starting preconfigured legacy host favorites from a Web

application page or webtop
With the FirePass controller, you can start a preconfigured legacy host
favorite from a customized webtop or web application page that also
performs security checks and resolves the parameters needed to construct
and establish a legacy host session.
Security checks ensure that the user is able to activate only an authorized
favorite such as an assigned resource group, existing favorite, and protected
resource.
To launch a preconfigured Legacy Host Favorite

1. Configure a Legacy Host favorite.
Note: A new pop-up window is created, therefore, settings for Open
a new separate window are ignored.
2. On the backend server, prepare HTML content containing the
sample script that follows this procedure.
3. In the navigation pane, click Portal Access, expand Web
Applications, and click Intranet Webtops.
4. Type the URL for the favorite you configured and select Enabled to
activate the favorite.
Legacy host favorite sample script

Use the following script to create the legacy host favorite HTML file,
described in the previous procedure.
<script type="text/javascript">
function createTermConnection(params)
{
var w_name = 'TERM_CONNECTION'+(Math.random()).toString().substring(2,16);
childWindow = window.open('https:/vdesk/h3270/connect.php'+params, w_name,
'name='+w_name+',resizable=1,scrollbars=0,statusbar=0,menubar=0,width=512,height=300',
false);
}
</script>
<a href='javascript:createTermConnection("?res_group=Default_resource&res_name=aaaa")'>
Auto Launch Legacy Host</a>
Figure 6.2 Legacy host favorite sample script
Specify the resource group and resource name that the user can access, using
the res_group variable for the resource group, and the resource name with
the variable res_name. In the above example, the resource group is
Default_resource, and the resource name is aaaa.

Chapter 6
Configuring legacy hosts keyboard mapping

A keyboard map contains mapping instructions for associating one
keystroke or key sequence on the client, to another keystroke or key
sequence. For example, you can map Esc+Shift+1 to the F1 key if the client
keyboard does not have function (F) keys on it.
The FirePass controller provides default keyboard mappings for the listed
terminal types. However, you can override one or all key mappings. Using
keyboard mapping, you can customize legacy hosts favorites to use
non-standard keyboards or other code pages, and to add custom commands
and shortcuts.
The Legacy Hosts Keyboard Map section of the Legacy Hosts screen
contains the table of defined keyboard mappings that becomes the default
for the legacy hosts favorite you are configuring. You can debug user-side
keyboard mapping issues for specific devices and sessions by specifying a
keystroke in the table, and then invoking that keystroke when connected to a
legacy hosts session.
To modify or add to the mapping table

1. In the navigation pane, click Application Access, and click Legacy
Hosts.
The Legacy Hosts : Resources screen opens.
2. From the list to the left of the Load button, select the terminal type
you want to configure a keyboard map for.
3. Click the Load button.
The FirePass controller loads the saved mapping table into the box.
If no saved table exists, the FirePass controller uses the default
mapping table.
4. Edit the table as needed to override the mappings you need to
change, or to add key sequences to be translated into application
commands. For more information about the structure of the
mapping table, see Understanding the mapping table, following.
5. When you specify the settings you want, click the Save button.
Understanding the mapping table

Each line in the keyboard mapping table list contains one mapping rule for a
single key. You can type directly in the table to specify entries. The first
column in the table contains any modifiers, which represent the Ctrl, Alt,
and Shift keys on the keyboard. The second column contains the key, such
as F12 or Tab. The third column contains the action command. The first and
second columns must be separated only by blank spaces. At least one tab
character is required between the second and third columns. You can omit
content in the first and second columns to create a map for modifiers only,
or for keys only.
6 - 30
Commands are specific to one application or terminal type. You can supply
command arguments within the parentheses. A command with no arguments
ends with an pair of empty parentheses.
The default keyboard mapping contains default commands for standard
terminal types. You can add commands that act as application shortcuts.
These shortcuts can send commonly-used strings to your host applications
using the Send("String") command.
For example, if you want a specific key combination to send a text
command plus a program function key whenever the user presses Ctrl and
Alt and Shift and F12, the mapping rule might look like this:
Ctrl+Alt+Shift F12 Send("MY COMMAND"); PF1();
You can map the number pad keys divide ( / ), multiply ( * ), and minus ( - )
differently from the keyboard keys slash ( / ), asterisk ( * ), and hyphen ( - ).
In addition, you can map the Num Lock key to a command.
You can find additional information in the online help for the Application
Access : Legacy Hosts : Resources screen.
Configuring master group settings for legacy hosts connections

who belongs to a specific master group clicks a favorite in the Legacy Hosts
section of the webtop. You set master group settings on the Application
Access : Legacy Hosts : Master Group Settings screen.
Understanding general master group settings for legacy host connections

General master group-based settings for legacy host connections govern the
legacy host type of Application Access connections. You can specify the
following master-group-based settings.
• Limit Legacy Hosts Access to Favorites only (for Extranets, partner
and customer access, etc.)
Removes the Direct Connect link from the user’s webtop, and prohibits
the user from creating custom favorites, which limits client access to
Legacy Hosts that are defined and listed in the favorites section.
• Restart the Legacy Hosts Server
When clicked, restarts a subsystem on the FirePass controller, which can
correct a problem without causing disruption to other FirePass controller
users.

Chapter 6
Configuring settings for the legacy hosts webifyer status

for example:
Legacy Hosts is presented at the Beginner level, always visible to a user
in the group <groupname>.
status and/or webifyer position on the webtop, provides a some options
for customizing what the user sees.
6 - 32
Configuring terminal server favorites

You can create favorites for terminal server connections. A favorite is a
named and saved set of options. A favorite appears as a link on the user’s
webtop. When a user clicks the link, the system establishes a connection to
the terminal server configured.
You can provide users access to internal Microsoft® Terminal Servers,
Windows XP® desktops, Citrix MetaFrame® servers, and VNC servers. To
specify group-level settings for Terminal Servers, use the Application
Access : Terminal Services : Master Group Settings screen. For more
information, see Configuring master group settings for terminal server
connections, on page 6-36.
To create a Terminal Servers favorite or alias

1. In the navigation pane, click Application Access, expand Terminal
Servers, and click Resources.
The Application Access : Terminal Servers : Resources screen
opens.
4. From the Type list, select from the following types.
• Favorite: Represents a new terminal server connection.
To create a new favorite, select Favorite, and skip to step 5.
different group. If there are no other groups available, or no other
connections have been defined, the Alias option is not available.
options. Continue with these steps:
a) From the From group list, select the resource group containing
the existing favorite you want to use as the source.
b) From the Favorite list, select the favorite.
c) Click the Add New button.
The new Alias appears in the list.
5. To continue creating a new favorite, in Name, type the identifying
label you want to use.
The FirePass controller displays this name as a label for the favorite
under Terminal Servers in the user’s web browser.
6. In Host, specify name or IP address.
You can enter a list here for MetaFrame and VNC hosts. The
FirePass controller shuffles the entries, then tries to use the first one
in the list. If connection fails, the FirePass controller tries the next
one in the list, and so on, until a working server is found. You can
use this simple technique for high availability solutions.

Chapter 6
7. In Port, type a number to use for the port.

To automatically populate Port with the appropriate default value,
select from the adjacent list. Options are:
• Microsoft Terminal Server - default value 3389.
• Citrix MetaFrame - default value 1494.
• VNC - default value 5900.
• Citrix MetaFrame Browser - default value 80.
This option is useful for accessing Citrix server farms, and for
resolving application names to IP address:port.
• Citrix MetaFrame Portal - default value 80.
This option provides functionality similar to Citrix NFuse web
portal. In this case, the FirePass controller contacts the Citrix
master browser using the supplied user credentials, and obtains a
list of published applications configured for that specified user.
Note: Citrix MetaFrame Browser relies on the Citrix XML Service,
which must be enabled on the target server.
8. In Select a program, type the full path to the application on the
target server to limit terminal access to a single program, restricting
access to the whole system.
For Citrix, always precede the application name with a pound sign
( # ) for published applications, for example, #app_name.
9. In Working Dir, specify the working directory for the application
you specified in the preceding step.
10. If you want to use the Citrix Java client or Java RPD client, check
the Java client box.
Note that the RDP Java client does not support full screen mode,
Copy and Paste to the clipboard, redirect local resources, redirect
local audio, or bitmap caching.
11. From Color Depth, select the number of colors the display on the
target server supports.
Options are 16 Colors, 256 Colors (this is the default setting), High
Color (16 bit), True Color (24 bit), and True Color (32 bit).
12. From Screen resolution, select a screen resolution option.
You can choose to use the master group display settings, or from
five standard resolutions between 800x600 and 1600x1200. You can
also choose full screen, a custom size, or a percentage of screen size,
which allows you to type a number to specify the percentage of your
computer screen used by the window.
13. To enable Citrix session reliability, check the box Enable session
reliability (Citrix only). This allows the Citrix ICA client to
connect over the Citrix reliability port, and to reconnect
automatically if the connection to the remote host is dropped. With
session reliability enabled, remote users are not required to log on
again if the connection is dropped, then reconnected.
6 - 34
14. If you want to use a custom port for Citrix session reliability, type
the port number in the Session reliability port (Citrix only) box.
The default port is 2598.
15. From the Window Type list, select the method for displaying the
terminal server window.
• The default is to display the terminal window embedded in the
current browser window.
• To open the terminal window in a new browser window, select
New browser window.
• For Citrix applications, you can choose to open a separate
window with a menu, or a Citrix seamless window. The seamless
window makes the Citrix client window appear in an application
window, and not a browser window, as specified by the Citrix
server.
• The option Separate window with menu displays a window
similar to a seamless window, with a title bar that provides a
Citrix client menu.
16. Check the Redirect local resources (drives, printers, COM ports)
check box to have the target server’s local resources available to the
client after the application starts, or leave the box clear to have users
retain the resources on their computers.
17. Several options are available only for Microsoft Terminal Services
users. Check the boxes for the options you wish to enable.
• Show desktop wallpaper
• Show contents of window while dragging
• Menu and window animation
• Themes
• Server authentication
18. In Encryption (Citrix-only), select the encryption level for Citrix
MetaFrame connections.
This setting specifies an internal Citrix parameter, which must
match the MetaFrame server setting. Connection from the client to
the FirePass controller is made using SSL, regardless of this setting.
• Basic
This is the default.
• RC5 128 bit logon only
• RC5 40 bit
• RC5 56 bit
• RC5 128 bit

Chapter 6

You can change any of these settings by clicking the link representing the
favorite, modifying the setting, and clicking the Update button.
Configuring master group settings for terminal server connections

who belongs to a specific master group clicks a favorite in the Terminal
Servers section of the webtop. You set master group settings on the
Application Access : Terminal Servers : Master Group Settings screen.
When you enable master group policy routing for a particular master group,
you should not allow users of the master group to create terminal server
favorites for accessing servers that are not part of the VLAN defined for that
master group.
Understanding general master group settings for terminal server

connections
General master group-based settings for terminal server connections govern
the terminal server type of Application Access connections. You can specify
the following master-group-based settings.
• Screen resolution
Sets the initial screen resolution for Terminal Servers and Citrix
MetaFrame content, which users can override. Although users can
change screen resolution if they wish, you should set the initial resolution
sufficiently large to accommodate the application window. For example,
if you select 640x480, users cannot start Ethereal® applications because
there is no access to the OK button.
• Limit Terminal Servers Access to Favorites only (for Extranets,
partner and customer access, etc.)
Removes the Direct Connect link from the user’s webtop, and prohibits
the user from creating custom favorites, which limits client access to
Terminal Servers that are defined and listed in the favorites section.
• Auto-logon to applicable Terminal Services using FirePass controller
user logon credentials
Uses the user’s FirePass controller user name and password to access
Terminal Servers. You can also enter an optional domain or workgroup
name for the FirePass controller to use when users log on to Terminal
Servers. In situations in which the user’s FirePass controller user name
6 - 36
and password match the Windows Domain credentials, this feature

permits the user to access a Terminal Servers connection without having
to log on again.
• Use anonymous credentials to retrieve application list from Citrix
servers
Queries the Citrix servers for a list of applications using anonymous
credentials. Typically, Citrix servers do not need user credentials to
present the list of applications.
Specifying Citrix ICA client location

You can provide a location from which a client can download and install an
ICA Citrix client package, the FirePass controller or a web server. The
system automatically updates the Citrix ICA client when one of these
conditions is met:
• The end user does not have an ICA Citrix client installed on his PC.
• The client PC is using a version of the Citrix ICA client older than
specified.
For information about where to obtain the Citrix ICA client, refer to the
Citrix documentation.
Specifying the FirePass controller

By default, the ICA Citrix client package is not located on the FirePass
controller.
To specify the FirePass controller

Servers, and click Global Settings.
2. Next to ICA Client not installed, click the link click here to install
or click here to reinstall, to upload the Citrix client onto the
FirePass controller.
The message Please browse for wficac.cab or wficat.cab and
click upload appears.
3. Click the Browser button to specify the location of the Citrix client
wficac.cab or wficat.cab file.
The wficat.cab file provides more Citrix client features, including
audio redirection, and has a larger .cab package than the
wficac.cab.
4. Click the Upload file button to upload the Citrix client onto the
5. In the Version box, use the default setting or specify the Citrix
client version you want to use on the client's PC.

Chapter 6
6. Click the Update button for your changes to take effect.
Note
Do not rename the .cab file before uploading to the FirePass Controller.
Make sure .cab file name matches the name of .inf file inside the package.
Specifying a Citrix website or custom URL

Use the Citrix web-site or Custom URL option to have the client PC
dynamically download and install the Citrix client package from a web
server.
To specify a Citrix website or custom URL

Servers, and click Global Settings.
2. Scroll down to the Citrix ICA Client location, and select the Citrix
web-site or Custom URL option.
3. In the URL box, specify the location from which to download the
ICA Citrix client package.
4. In the Version box, use the default setting or specify the version of
the Citrix client you want to use on the client's PC.
Specifying the ICA Citrix client version to download and install on to end user’s PC
The default setting is the minimally required version of the ICA Citrix client
version that the FirePass controller supports. If you want to upgrade your
client, select a later version in the Version box.
Important
Do not specify a version later than the one located on the FirePass
controller or web server; otherwise the client PC downloads and reinstalls
the Citrix client package each time it connects to the terminal servers.
To specify a newer version of the ICA Citrix to download

and install on the client PC
1. With a web browser, download the wficat.cab file (Citrix client
package) from the Citrix website and save it on your PC.
2. Double-click the wficat.cab file to view its contents.
A list of files appears.
3. In the wficat.inf file, locate the string wfica.ocx to determine the
version of the Citrix ICA client.
Information similar to the following appears:
[wfica.ocx]
file-win32-x86=thiscab
6 - 38
clsid={238F6F83-B8B4-11CF-8771-00A024541EE3}
FileVersion=8,00,24737,0
4. Copy the FileVersion, for example, 8,00,24737,0, from the

wficat.inf file, and paste it into the appropriate Version box on the
Application Access : Terminal Servers: Global Settings screen.
Include the commas in the version string.
5. Click the Upload file button to upload the wficat.cab onto the
To specify the Citrix JICA client location

1. Upload the ICA Citrix JAVA client to the FirePass console before
attempting to use it.
2. For the JICA client not installed setting, click the link click here
to install.
The ICA Citrix JAVA client archive should contain three files:
• version.dat is the version of the JAVA client
• cryptojN.jar is the encryption component required for ICA
encryption
• JICAEngN.jar contains the functionality of the ICA from a
Citrix web-site
Note
For information about where to obtain the ICA Citrix JAVA client, refer to
the Citrix documentation.
Using Citrix session reliability

The FirePass controller supports Citrix in several areas of functionality:
Terminal Services, static and dynamic AppTunnels, and Portal Access
through custom ICA file processing and automatic static AppTunnels.
Previously, the main ICA connections between Citrix ICA clients and
Metaframe servers occurred on TCP port 1494. As of Metaframe
Presentation Server v3.0 (current revision is v4.0), the default port is now
2598, which corresponds to a new Session Reliability mechanism supported
by the FirePass controller.
Citrix session reliability now tunnels ICA traffic (common gateway
protocol) using port 2598.

Chapter 6
By enabling the Session Reliability feature, Citrix ICA client version 8 and
later will try to establish a connection on a specified port (the default port is
port 2598). If a TCP connection cannot be established, then the ICA client
automatically switches to the ICA protocol on a different port (the default
port in this case is TCP port 1494).
Note
Both static and dynamic AppTunnels and TerminalServices always accept

incoming connections on a loopback socket regardless of the remote port
reachability. If a remote port is unreachable, the static AppTunnel message
No route to host is displayed, and the local connection is dropped. The
Dynamic AppTunnels process drops the connection silently. In both cases,
the Citrix ICA client does not fallback to port 1494, and fails to connect at
all.
When session reliability is enabled, the Citrix ICA client automatically

reconnects if the connection to the remote host is dropped. The remote user
session and all its applications should continue to run without requiring the
user to re-enter his credentials.
To enable support for session reliability in Citrix ICA client

version 8 and later
1. In the navigation pane, click Application Access, and expand
Terminal Servers.
2. Click Add New Favorite.
3. Create a Terminal Server Citrix favorite, and check the Session
Reliability (Citrix-only) option and specify the remote TCP port.
4. Use an ICA file with the following line in the [applicationserver]
section: CGPAddress=*:remote_TCP_port
For more information about ICA files, refer to the Configuration
Guide (.ini/.ica File Reference) PDF on the Citrix website.
5. Use the Citrix Program Neighborhood and create a new connection,
or select Properties of existing connection.
Note: The Enable session reliability feature on the Options tab is
enabled by default.
Optionally, the Citrix feature is also available from the FirePass Terminal
Services screen for both Admin and user favorites: check the Session
Reliability (Citrix-only) option and enter a custom port number (the default
value is port 2598).
Using terminal servers screen resolution

You can use the screen resolution feature to allow a user to specify the
resolution of his terminal server window. This feature is available for all
terminal servers supported by the FirePass controller:
6 - 40
• RDP (Microsoft Terminal Server)

• ICA (Citrix)
• VNC
A Terminal Server window resolution is specified in several ways on a
per-master group basis from the screen Application Access : Terminal
Servers : Master Group Settings.
• pre-defined resolution
A list of pre-defined resolutions, like 1024x768.
• user-defined resolution
• percent of screen
A Terminal Server window’s size is specified as a percent of the entire
desktop.
• fullscreen
Additionally, users can specify a default Terminal Server window resolution
in the Terminal Server interface.
By default, a Terminal Server window opens and is embedded in the
FirePass controller webtop window with the specified resolution (except for
the fullscreen option).
If the option to Open in new window is enabled, the system opens a new
browser window opened and the Terminal Server window is embedded
there.
There are a few configurations settings specific to a Terminal Server
application.
• For Citrix you can either open a separate window (not embedded in a
browser window) or use the terminal server in seamless mode, in which
case any window of the remote Citrix desktop becomes a separate
window on the local desktop and can be switched by pressing the
Alt-Tab keys.
• For the RDP, you can configure support for special keys (Alt-Tab,
Ctrl-Esc, Alt-Ctrl-Del, or others) in the Terminal Server window. This is
done on the FirePass controller console’s Application Access : Terminal
Servers : Master Group Settings screen.
Configuring keyboard redirection for Microsoft Terminal Servers

The keyboard redirection setting specifies how and when to apply Windows
key combinations, for example, Alt+Tab. On the Master Group Settings
screen for Application Access, you can configure to apply key combinations
only locally on the client computer, always, and only when the client is
running in full-screen mode.
Table 6.2 presents the Microsoft Terminal Servers shortcut keys that this
setting affects.

Chapter 6
Key combination Description
Alt+Page Up Switches between programs from left to right.
Alt+Page Down Switches between programs from right to left.
Alt+Insert Cycles through the programs in the order they were started.
Alt+Home Displays the Start menu.
Ctrl+Alt+Break Switches the client between window and full-screen mode.

Ctrl+Alt+Break is F12 on NEC98.
Ctrl+Alt+End Brings up the Windows Security dialog box.

Ctrl+Alt+End is F15 on NEC98.
Alt+Delete Displays the Windows menu.
Ctrl+Alt+minus ( - ) Places a snapshot of the active window, within the client, on

the Terminal Server clipboard (provides the same
functionality as pressing Print Scrn on the local computer).
Ctrl+Alt+plus ( + ) Places a snapshot of the entire client windows area on the

Terminal Server clipboard (provides the same functionality
as pressing Alt+Print Scrn on the local computer).
Table 6.2 Microsoft Terminal Servers shortcut keys
Configuring Terminal Servers webifyer status in the group ‹groupname›

section of the Master Group Settings screen
for example:
Terminal Servers is presented at the Beginner level, always visible to a
user in the group <groupname>.
status and/or webifyer position on the webtop, provides a some options
for customizing what the user sees.
For information on how to set User Experience options, see the online help
for the User Experience tab, available on the Users : Groups : Master
Groups screen.
6 - 42
Configuring global settings for Application Access

You can configure global settings that apply to all Application Access
connections. You set global settings on the Application Access : Global
Settings screen.
Handling Windows power-management events

You can select one of the following power-management settings to apply to
Windows-based App Tunnels, Terminal Servers, and the ActiveX version of
5250 Legacy Hosts Access. This setting specifies what should occur when
Windows enters the standby, or hibernate, mode.
• Do nothing: Ignore power management events
• Prevent Windows from entering standby/hibernate mode while a
connection exists
• Terminate connection if Windows enters standby/hibernate mode
Configuring client messages for Windows loopback

There is an issue introduced in Windows XP SP2 in which an error occurs
when attempting to connect to IP addresses in the loopback range. You can
read more about the issue by clicking the KB884020 link on the Application
Access : Global Settings screen.
The FirePass controller displays a message when it encounters a computer
that has not received the loopback fix. By default, the FirePass controller
displays the following message:
Your computer requires an update to run this application. Click here
or enter the following link into your web browser to install the required
update from Microsoft (KB884020).
http://support.microsoft.com/default.aspx?kbid=884020
You can change the message by modifying the text in the box in the
Customization section, and clicking the Update button. The message can
contain any valid HTML.

Chapter 6
6 - 44
7
• Introducing Portal Access
• Configuring web applications on the FirePass

controller
• Configuring Windows files
• Configuring Mobile E-Mail
• Configuring content inspection
• Using the FirePass controller reverse proxy

Introducing Portal Access

Portal Access connections enable end users to use a web browser to access
specific services on the internal network. With Portal Access, the FirePass
controller communicates with back-end servers, and translates the content
into HTML pages for the client browser. The advantage is that the client
computer requires no client software other than a browser application.
This method of access differs from connections configured for Network
Access and App Tunnels, which provide direct access from the client to the
internal network. These technologies do not manipulate or analyze the
content being passed between the client and the internal network. These
technologies do require small, automatically installed client components,
but provide the most seamless direct access to internal applications. Portal
Access configuration provides an administrator refined control over the
applications that a user can access through the FirePass controller, as well as
inspection of contents of transferred data.
For more information on connections configured for Network Access and
App Tunnels, see Chapter 5, Configuring Network Access and Chapter 6,
Configuring Application Access.
The other advantage of Portal Access is security. Because Network Access
and App Tunnel connections communicate directly with the server, client
connections must come from a trusted computer. Publicly available
workstations do not meet this requirement. However, even though a
workstation does not meet those requirements, your users should still be
able to access certain applications.
In Portal Access connections, the client computer itself never communicates
directly with the end-point application. That means that all communication
is inspected at a very high level, and any attacks originating on the client
computer fail because the attack cannot navigate through the links that have
been rewritten by reverse proxy. In Portal Access connections, the FirePass
controller communicates with the back-end servers, and then generates the
HTML page for presentation in the browser window.
Introducing Portal Access features and operation

Portal Access provides remote users with web-based remote access to a
wide variety of network applications and resources, including:
• Intranet web servers
• Email servers
• Windows file servers
• Terminal servers
• Legacy, character-based applications
Portal Access serves the internal resource into and out of the end user’s web
browser. The application being accessed and the protocol being supported
(HTTP and HTTPS) dictate how Portal Access operates. Figure 7.1 shows
the process that Portal Access follows.

Chapter 7
Figure 7.1 The Portal Access functionality of the FirePass controller
Introducing Portal Access application support

You can use Portal Access when users need access but they are away from
their regular computers. FirePass controller provides additional functionality
to secure connections from client machines, such as public kiosks or PDAs,
which might not have the necessary applications installed or configured, but
usually do have browsers installed. In this case, the web browser serves as
the interface to the application.
You can set up different types of access for users in different master groups.
For example, you can enable Windows Files access to users from one master
group, and prevent access by users in another master group. In addition, you
can enable browsing of internal web sites by name or IP address, which
would be typical for employees, or limit access only to specified favorites,
which would be useful in an extranet for partners and customers.
Using Web Applications

Web Applications access allows remote users secure access to internal web
servers, such as Microsoft® Outlook® Web Access (OWA), Microsoft
SharePoint®, IBM® Domino® Web Access (also known as Lotus® iNotes®),
Domino Sametime®, and Citrix® NFuse™. Using Web Application
functionality, you can also provide access to most web-based applications
and internal web servers. Portal Access provides access to web applications
7-2
by performing an intelligent proxy of the content through the FirePass

controller, so it changes all links to reference the FirePass controller address,
rather than the originating server. The high performance, full-content
rewrite engine also supports rewriting complex JavaScript™, Java™
applets, and Flash® content. You can use features such as the web cache,
minimal content rewriting bypass mode, user-defined content processing
scripts, and a number of others, to help refine compatibility and tune
performance.
Using Windows Files

Microsoft Windows® Files access allows remote users browser-based access
to browse, upload, download, move, copy, or delete files in shared
directories. The FirePass controller communicates with file servers using the
Server Message Block (SMB) protocol, which can support Windows 2003,
Windows 2000, Windows for Workgroups, Windows NT® 4.0, Windows
XP, Windows 2008, and Windows Vista.
Using Mobile E-Mail

Mobile E-Mail access provides very lightweight access to POP/IMAP and
SMTP email servers and LDAP address books using a standard web
browser, or mini browsers on a PDA or smart phone. Users can send and
receive messages, download attachments, and attach files from the internal
LAN to send email messages. Mobile E-Mail is intended to complement a
fat client by optimizing content for low bandwidth, mobile devices.
Using Content Inspection

Content Inspection scans URL arguments and POST data sent by users
through Web Applications, and blocks the request if it appears as if it might
be an attack. Content Inspection guards against cross-site scripting attacks,
SQL injection attacks, buffer overflow attacks, and viruses from files
uploaded using Windows Files, Web Applications, or Mobile E-mail.

Chapter 7
Configuring web applications on the FirePass

controller
You can configure the FirePass controller to provide access to web
applications without requiring client configuration changes or software
downloads. Typically, you use Portal Access when your users only require
access to specific internal web portal-based applications, and do not require
full Network Access. The FirePass controller provides security by rewriting
links in all requests to internal servers. When the FirePass controller
processes the connections, it uses the proxy engine’s built-in logic and
additional custom-configurable content-processing scripts to modify the
URLs and other links in the original HTML document. The controller
changes these links by rewriting the path to the URL. You can use stream
editor (SED) scripts to modify intranet web pages to handle issues related to
the FirePass controller sending custom content through the proxy engine.
F5 Networks has tested the following web applications to ensure that the
FirePass controller handles them without client reconfiguration.
• Microsoft Outlook Web Access (OWA)
• Microsoft SharePoint
• IBM Lotus Domino Web Access (also known as Lotus iNotes)
• Domino Sametime
Some of your custom web applications will work with Portal Access without
you having to make changes to the applications. However, some of your
web applications, particularly those that make extensive use of JavaScript,
Java applets, ActiveX controls, and Flash components, might require that
you use content processing scripts or other configuration changes to enable
the user to access them using Portal Access connections.
If you have a specific web application that requires additional configuration
to work through Portal Access, you can generally use Application Tunnels
or Network Access. These access methods provide a direct connection to the
internal network, and do not require proxy-based changes or modification of
web application content.
If you cannot use Application Tunnels or Network Access to solve access
issues, you can try the proxy feature minimal content-rewriting bypass. For
more information about this feature, see Configuring web applications for
minimal rewriting, on page 7-10.
Understanding proxy and cache functionality

You can use the FirePass controller Portal Access : Web Applications
feature for the following operations:
• Rewrite of complex HTML, JavaScript, Java applets, and Flash content
• Dynamic cache of rewritten content
7-4
• Extensive bypass configuration and content pre-processing and

post-processing using scripts
The FirePass controller uses a high-performance, full-content rewrite engine

to handle complex HTML, JavaScript, Java applets, and Flash. You can also
enable a built in dynamic cache, so that the FirePass controller does not have
to repeatedly rewrite content for static objects such as HTML, JavaScript,
style sheets, and Java applets. Also, the web applications engine supports
rewrite of complex applets such as Citrix, VNC (when presented by Java
applets), as well as .jar and .cab archive resigning.
In some cases you might want to bypass the FirePass controller’s reverse
proxy to support some very complex web applications using the minimal
content-rewriting bypass feature. To use this feature, your applications must
reside on the single target server. When you use the bypass feature, the
proxy engine operates differently.
With the bypass feature, the proxy engine:
• Uses the FirePass controller name to replace only the originating host
name in the address. If the URL also contains a port, then the proxy
engine replaces the host name and port with the FirePass controller name
and port.
• Does not rewrite URL references to other servers
• Does not modify cookies, when you enable the global setting, cookie
pass through.
• Applies minimal content settings at the master group level
You can use the bypass feature by configuring a one-to-one mapping

between one of the following options:
• A URL pattern and an internal intranet host
• A dedicated FirePass Web service on an alternate port or IP address, and
an internal host
You can use SED scripts to rewrite output instead of preventing rewriting by
configuring bypass. For information about Web application content
processing using SED scripts, see Configuring content processing for web
applications, on page 7-19.
Setting cookie availability for web bypass

In some cases, for example, if your web application manipulates a client
cookie, you want the FirePass controller to pass the cookie to the browser
without altering it.
To specify cookie pass through

Applications, click Content Processing, and click the Global
Settings tab.
The Content Processing : Global Settings screen opens.

Chapter 7
2. Scroll down to the Web Applications Global Settings section.

3. Check the Do not block cookies at FirePass, pass them to the
browser for specified URL patterns check box.
4. In the box, specify the list of URLs or URL patterns you want the
FirePass controller to ignore when performing proxy operations.
5. To have the FirePass controller add URLs from sites that require
cookie manipulation, check the Automatically add websites that
require client side cookie manipulation check box.
6. Click Update.
Defining favorites for Portal Access Web Applications access

To make Portal Access Web Applications available to users, you create
favorites to internal web sites and URLs. A favorite is a collection of
settings that represents a single link on the user’s webtop. When the user
clicks a Portal Access Web Application favorite, the FirePass controller
opens the connection and runs the configured application.
Note
Understanding Portal Access favorites options

You add new favorites using the Portal Access : Resources screen. To
access the screen, in the navigation pane, click Portal Access, expand Web
Applications, and click Resources. When you click the Add new favorite,
link, the screen reveals additional options.
• Type
Indicates whether the link is a new configuration (Favorite) or a pointer
to an existing one in another master group (Alias). Alias is available as
an option only when there are Portal Access favorites configured in
another resource group.
• Name
Contains the name for the intranet site that you are defining as a favorite.
This is the name the user sees on the webtop. The string you specify can
be any name; box format is not limited. For example:
Site Request application
• URL
Indicates the intranet web server that serves the application. For example:
http://server.siterequest.com/index.html
• URL variables
Contains variables to be either appended to the GET request or sent as
data in a POST request to the specified URL. For more information and
examples, see Working with URL variables, following.
7-6
• Post URL variables

Indicates that you want the variables in URL variables to be included in
the POST request to the URL specified. For more information and
examples, see Working with URL variables, following.
• Enforce user-agent
Contains the string you want the FirePass controller to send to the
internal web server instead of the browser’s actual user-agent identifier.
For more information, see Specifying user-agent strings, on page 7-8.
• Open in new window
Indicates whether the application opens in the existing browser window
or in a new browser window.
Check this option to open the application in a new window, or leave the
option cleared to have the application replace the user’s webtop.
• Endpoint protection required
Provides a list of Protected Configurations defined on the Users :
Endpoint Security : Protected Configurations screen. If the user’s
endpoint protection does not satisfy the defined condition, the FirePass
controller does not include this favorite on the webtop or allow access.
Once you have configured all of the necessary parameters for your
application, click the Add New button to add the favorite. When you have
configured at least one favorite, you can specify which link serves as the
default by selecting it from the Default box, and clicking Update.
The default favorite starts automatically when users of the resource group
open their web application favorites. With more than one default favorite
defined, for example, when a user has multiple resource groups assigned,
the FirePass controller starts only one of the defaults.
Working with URL variables

Although they are optional, you can use URL variables to support favorites,
such as automatic user logon to intranet web sites, or for customizing
intranet content for a user. You can use the %username% and
%password% variables as values in a GET request. At logon time, the
FirePass controller replaces the parameters with the user’s FirePass
controller user name and password.
URL variables are specified in the form:
variable1=value1&variable2=value2&variable3=value3
The following is an example of how to build an intranet favorite that
contains a URL variable. First you specify the string in the URL box:
Then you specify the variables you want to use in the Url variables box:
show_custom_content=1&user=%username%&password=%password%
For FirePass controller user johndoe with password johndoepassword,

using these variables results in the following actual favorite link:

Chapter 7
http://server.siterequest.com/index.html?show_custom_content=1&
user=johndoe&password=johndoepassword
Alternately, you can specify that the FirePass controller send the variables in
a POST request to the configured URL. This is a more secure way to
provide a user name and password for logging on to an intranet site, because
the variables are not visible on the URL line of the browser for someone to
see.
For example, if you have the following form contents on an intranet logon
page:
<form action=logon.php method=POST>
<input type=TEXT name=user>
<input type=PASSWORD name=password>
<input type=HIDDEN name=do_logon value=1>
<input type=SUBMIT value=Logon>
</form>
First, you specify the string in the URL box:
http://server.siterequest.com/logon.php
Then you specify the variables you want to use in the Url variables box:
user=%username%&password=%password%&do_logon=1
For FirePass controller user johndoe with password johndoepassword,

using these variables results in the following actual favorite link:
http://server.siterequest.com/logon.php
The FirePass controller sends the following data directly to the
server.siterequest.com site in a POST request:
user=johndoe&password=johndoepassword&do_logon=1
Specifying user-agent strings

The user-agent string identifies what the client’s web browser uses with a
specific network protocol. Some servers use the user-agent string to
determine what content to send to the client browser. Although optional,
specifying a user-agent string is useful when you need to simplify FirePass
controller content. For example, for a highly complex web application, it
might help to downgrade the content supplied by specifying the following
user-agent string:
Mozilla/4.7 [en] (Windows NT 4.0; U)
Table 7.1, following, contains a list of common user-agent strings.
7-8
Browser User-agent string
IE 6.0 on Windows Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
IE 5.5 on Windows Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Table 7.1 User-agent strings for several browsers

IE 5.0 on Windows Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
IE 4.5 on Windows Mozilla/4.0 (compatible; MSIE 4.5; Windows NT)
IE 4.01 on Windows Mozilla/4.0 (compatible; MSIE 4.01; Windows NT)
Mozilla 1.7.8 on Windows Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
Mozilla 2.0.0.15 on Windows Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.15) Gecko/20080623
Firefox/2.0.0.15
Netscape 7.2 on Windows Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804
Netscape/7.2 (ax)
Netscape 4.5 on UNIX Mozilla/4.5 [en] (Win98; U)
Netscape 3.04 on UNIX Mozilla/3.04Gold (Win95; U)
Opera 5 on UNIX Opera/5.12 (Windows 2000; U) [en]
Opera 5 mimicking Netscape Mozilla/4.0 (compatible; MSIE 5.0; Windows 98) Opera 5.01 [en]
on Windows
Safari 2.0 for Macintosh OS X Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/412 (KHTML, like
Gecko) Safari/412
Safari 3.1 for Macintosh OS X Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_2; en-us) AppleWebKit/525.13
(KHTML, like Gecko) Version/3.1 Safari/525.13
FireFox 1.0.4 on the Macintosh Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8)
Gecko/20050511 Firefox/1.0.4
FireFox 1.0.6 on Windows Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716
Firefox/1.0.6
FireFox 1.0.1 on Linux Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.7.6) Gecko/20050222
Firefox/1.0.1
Tip
An easy way to enter a user-agent string is to copy and paste the string from
the Logons report into the Enforce user-agent box. You can find the string
on the Reports : Logons screen in the User Agent column.

Chapter 7
Configuring web applications for minimal rewriting

You can use the minimal content rewriting feature to prevent rewriting of
your web application content. You can define minimal content rewriting
operation on the WebApplications : Master Group Settings screen.
There are several configuration requirements for using the minimal
content-rewriting bypass feature:
• The application must reside on a single server. The FirePass controller
cannot process URLs for separate servers when the minimal
content-rewriting bypass feature is enabled.
• You must configure cookie pass-through on FirePass controller in order
to use the minimal content-rewriting bypass feature if there is client-side
JavaScript that directly processes cookies.
• You cannot use automatic cookie pass-through with minimal
content-rewriting bypass.
You can configure the minimal content-rewriting bypass feature in only one
of two modes:
◆ Pattern-based
Provides a pattern-matching mechanism for URLs. You specify a
protocol, host, and path for the FirePass controller to match. If the
FirePass controller encounters a URL that has a defined Pattern-based
bypass rule, the FirePass controller does not modify URLs on the
returned page.
Implementing Pattern-based bypass requires no network changes, but
you must specify the protocol, host, and path that the application uses so
that the FirePass controller can match the incoming URLs.
◆ Alternative Host/Port-based
Provides a dedicated IP address and TCP port through which the FirePass
controller proxies connections to the application server. When
configuring the FirePass controller in Alternative Host/Port-based mode,
you must configure one FirePass controller port for each port the
application server uses. If your application uses SSL encryption, you
must also install on the FirePass controller the same SSL certificate and
private key that is installed on the application server.
Note
The minimal content-rewriting bypass feature is available only if you have

the hotfix for FirePass software 5.4.2, or if you are using FirePass software
5.5 or later.
Configuring pattern-based bypass

Instead of having the FirePass controller reverse proxy rewrite URLs and
JavaScript, you can use the pattern-based bypass option. The pattern-based
bypass functionality replaces the target server name with a name you
specify, and processes requests based on the patterns you list. The pattern
7 - 10
searches are case-sensitive, so you might have to specify the same pattern in
upper- and lowercase. Patterns must be unique within the intranet to prevent
interference with other web applications.
When you use this feature, the FirePass controller replaces all references to
the target server’s protocol://address:port with the FirePass controller’s
protocol://address:port. For example, if a Web application consists of
URLs starting with /myapp/ and /myimages/, you would associate the
patterns /myapp/*,/myimages/* with the server. You must specify the
target server in the following form:
protocol://servername[:optional port]
An example target server is http://myserver
Important
The root directory of the server cannot be used as the pattern for the
pattern-based bypass mode, for example, you cannot specify http://, /, or /*.
You can find pattern-based bypass settings on the Master Group Settings
screen. To access the screen, in the navigation pane, click Portal Access,
expand Web Applications, and click Master Group Settings.
When you configure settings, first select from Master Group the master
group you want to have access to the application.
In the Minimal Content-Rewriting Bypass section, you can configure the
following options:
◆ Comma separated list of patterns
Contains a list of match patterns for the web application. In this box,
specify the application paths that you do not want the FirePass controller
to translate. Separate each directory with a comma.
For example, if you do not want the FirePass controller to translate a set
of URLs, including all pages in the location:
https://tech.siterequest.com/appdir1/
https://tech.siterequest.com/appdir3/text.html
Type the following text:

/appdir1/*,/appdir2/*,/appdir3/text.html
◆ http[s]://<IP Address/Name>[:Port]
Contains the target server. In this box, specify the protocol and host
portion of the URL for the application.
For example, if you do not want the FirePass controller to translate the
URL:
Type the following text:

https://tech.siterequest.com

Chapter 7
You can specify a pattern using the wildcard characters asterisk ( * ), which
represents many characters, and question mark ( ? ), which represents a
single character. The patterns must be unique. When you specify a pattern,
you must include at least one subdirectory for each application.
Configuring the Alternative Host/Port-based type of bypass

The first step to configuring the Alternative Host/Port-based bypass type of
minimal content rewriting is to create a web service and enable WebAccess
Bypass. For information about creating web services, see Configuring web
services, on page 8-20. When you create the web service, if you want to use
the Alternative Host/Port-based bypass type of minimal content rewriting,
you check the WebAccess Bypass check box to indicate that the FirePass
controller uses the web service only for proxy pass-through operations. For
more information, see the following procedure.
Next, you configure alternative host/port-based minimal content-rewriting.
For more information, see Configuring web applications for minimal
rewriting, on page 7-10.
To enable WebAccess Bypass

Configuration, click Network Configuration, and then click the
Web Services tab.
2. From IP, select an available IP address to which users will connect
or create a new address using the IP Config tab.
3. Specify a port that is not already in use by another FirePass
controller web service.
4. Specify a host name.
If you add the host name to your DNS server, users can connect to
the application using the name of the host instead of having to use
the IP address.
5. Check the Enable SSL check box.
6. Click Add New.
The Web Service Configuration page opens.
7. From the Certificate list, select a certificate to use with the new
web service.
8. Check the WebAccess Bypass box.
Note: When you check the WebAccess Bypass check box, the
FirePass controller disables the user logon and administrator logon
to that service.
10. Click the Finalize tab.
11. Click the Finalize Changes button.
7 - 12
12. Wait while the finalize process completes.

13. If necessary, restart services.
Applications, and click Master Group Settings, to configure
Alternative Host/Port-based bypass options. For more information,
see Configuring Alternative Host/Port-based bypass, following.
Note
Depending on how your firewall is configured, if you specify a new port, you
might need to configure your firewall to allow communication on that port.
You might need to specify a new port if you have one internal side that
allows traffic through, or if you use servers outside the company on another
network (also known as one-armed configuration).
Configuring Alternative Host/Port-based bypass

When you use the Alternative Host/Port-based bypass feature, the FirePass
controller uses the proxy engine to make connections to the application
server through specified IP address and port combinations, and replaces a
specific internal host name with the name and port number you specify.
The Alternative Host/Port-based section on the Master Group Settings
screen contains a list of the web services with a checked WebAccess
Bypass option. The Alternative Host/Port-based section is empty if you
have not checked WebAccess Bypass for at least one existing web service.
In this case, the section contains a message, No Bypass Web Services
configured, along with a Click here to configure link that opens the
Device Management : Configuration : Network Configuration screen. From
there, you can add a new web service or configure an existing one by
checking Web Access Bypass on the associated Web Service Configuration
screen.
For a procedure of how to configure a web service for minimal-rewriting
bypass functionality, see Configuring web applications for minimal
rewriting, on page 7-10.
In the box under Alternative Host/Port-based, type the URL for your
application, using the following format (where [ ] indicate optional values):
http[s]://<IP Address/Name>[:Port]
When you finish, make sure to click the Update button to have your settings
take effect.

Chapter 7
Configuring NTLM and basic authentication proxy

NTLM uses a challenge-response mechanism for authentication, in which
clients prove their identities without sending the server a password. The
mechanism consists of three messages: Type 1, negotiation; Type 2,
challenge; and Type 3, authentication. Although Windows 2000 continues
to support the protocol, the standard is now Microsoft Kerberos.
You can enable NTLM and basic authentication proxy on the Master Group
Settings screen. To access the screen, in the navigation pane, click Portal
Access, expand Web Applications, and click Master Group Settings. The
FirePass controller supports sending through the proxy engine NTLM and
basic authentication over HTTP on behalf of the user, which provides
several benefits:
• Prevents client browsers from caching basic or NTLM authentication
credentials.
• Allows client browsers not supporting basic or NTLM authentication to
authenticate against web sites requiring this, such as Microsoft Internet
Information Services (IIS).
• Allows automatic logon (single sign-on) to sites supporting basic or
NTLM authentication with user's FirePass controller credentials.
There is a negative security implication to running the FirePass controller

without enabling the Proxy Basic and NTLM auth using FirePass user
logon form option. The implication is that, depending on the application,
after logging off an internal application configured for basic or NTLM
authentication, users might be able to regain access to the internal
application without entering logon information. This is because web
browsers commonly cache basic or NTLM user credentials.
When you configure the FirePass controller to send basic or NTLM user
credentials through the proxy engine, the controller replaces the basic or
NTLM browser dialog box with a form-based dialog box, which prevents
the web browser from caching user credentials.
The NTLM and Basic Auth Proxy feature provides the following options:
◆ Proxy Basic and NTLM auth using FirePass user logon form
Indicates whether to use the FirePass controller to proxy HTTP basic and
NTLM authentication. If you enable this option, the FirePass controller
presents a user logon web form whenever a protected site needs logon
credentials. Basic and NTLM authentication proxying is enabled by
default.
◆ Auto-logon to Basic and NTLM protected sites using FirePass user
credentials
Controls whether the FirePass controller can pass along the user’s
FirePass controller logon credentials to automatically log on to protected
sites on the user’s behalf. If the user’s FirePass controller credentials do
not match those required for the protected site and you enabled Proxy
Basic and NTLM auth using FirePass user logon form, the FirePass
controller presents a user logon web form. Otherwise, the FirePass
controller presents an authentication dialog box. When you enable this
option, you can also configure the following options:
7 - 14
• NTLM Auth Domain (optional)

For protected sites requiring NTLM authentication, you can specify a
default domain to be used in conjunction with the auto-logon support.
• Basic Auth Domain (optional)
For protected sites requiring basic authentication, you can specify a
default domain to be used in conjunction with the auto-logon support.
When specified, this value is prepended to the user name during basic
authentication (for example: BASICDOMAIN\username).
Using NTLM version 2

The FirePass controller is designed to recognize a stronger crypto-algorithm
NTMLv2 server authentication, and is able to use this type of authentication
instead of NTLM. This feature uses the established OpenSSL library.
Although no specific FirePass controller configuration is required to use
NTLMv2, FirePass uses NTLM (v1) by default. The server must be
specifically configured to use NTLMv2 authentication only.
Configuring split tunneling for Portal Access

You can define Portal Access split tunneling functionality on the Master
Group Settings screen. To access the screen, in the navigation pane, click
Portal Access, expand Web Applications, and click Master Group
Settings. You can use the split tunneling feature to specify which URLs
should be processed by the FirePass controller proxy engine and which
URLs should not. Split tunneling functionality helps:
• Improve controller performance by lowering processing overhead
• Make some web pages available (such as the performance-impacting
pages served by many public portal sites) that might not be compatible
with reverse-proxy technology
When you enable the setting Use URL patterns for split tunneling, the
screen reveals additional options.
◆ Rewrite
Contains a comma-separated list of patterns to compare with incoming
URLs. The FirePass controller proxies matching URLs. If the box is
empty, the FirePass controller rewrites all URLs. You can type an
asterisk ( * ) to specify that the FirePass controller rewrite all URLs.
◆ Bypass
Contains a comma-separated list of patterns to compare with incoming
URLs. URLs that match are accessed directly, bypassing the FirePass
controller reverse-proxy engine. If the box is empty, all URLs bypass the
reverse-proxy engine, meaning that rewriting is done for all URLs that
pass the test specified by patterns in the Rewrite box.

Chapter 7
You can use the wildcard characters asterisk ( * ), which represents many
characters, and question mark ( ? ), which represents a single character, in
both the Rewrite and Bypass boxes. The FirePass controller first processes
all patterns in the Rewrite box, and then all patterns in the Bypass box.
Example: http://*.siterequest.com/*
The format requires a slash separator ( / ) between the host information and
the path. For example, you must specify: http://server.siterequest.com/*
instead of http://server.siterequest.com* or http://www.*/*.com* instead
of http://www.*.com* for the filter to work.
The split tunneling filters apply to favorites, to direct browsing, and to the
links within a rewritten page. If you enable split tunneling, the FirePass
controller presents only web pages that satisfy one of these filters. The
FirePass controller applies the specified default action to the others
(although a public site might still be available outside the webtop). If you do
not use split tunneling, the FirePass controller processes all URLs through
the reverse-proxy engine.
Split tunneling patterns ignore any part of the URL after the first pound sign
( # ) or question mark ( ? ) symbol; that is, anchors and URL variables are
ignored.
Note
The Network Access feature also provides split-tunneling functionality. The

functionality is slightly different, however. For more information, see
Introducing Network Access, on page 5-1.
Understanding access control lists for Portal Access

You can configure Portal Access Master Group Settings so that users can
only access favorites that you define. Even if you do so, however, the page
represented by the favorite might contain links to other locations. To prevent
users from accessing other locations, you can specify access control lists
(ACLs), making available only particular web servers and pages. ACLs
define locations that Portal Access connection users can access from within
the connection. Defining ACLs prevents users from navigating to locations
outside the ones you specifically define for the Portal Access connections
that access your network.
All Portal Access connections share access control lists for the duration of a
browser session.
You can configure options in the following areas:
• On the Portal Access : Web Applications : Master Group Settings screen
• On the Portal Access : Web Applications : Resources screen
• In the Allow list box specific to the Portal Access favorite you define
The system uses ACLs in the following order:
• At the master group level
• Overrides from the resource group
7 - 16
• Overrides from the favorite definition

• The default action specified on the Master Group Settings screen
That means that ACLs defined on the Master Group Settings screen cover
the entire master group, but you can specify resource-level overrides on the
Resources screen. In addition, ACLs defined on the Resources screen cover
the entire resource group, but you can specify connection-specific ACLs in
the Allow list box for the favorite. Next, ACLs defined at the favorite-level
override all other ACLs. Finally, the system uses the default Allow or Deny
action specified on the Master Group Settings screen.
The FirePass controller processes ACLs in the following manner:
• The FirePass controller first processes all URL patterns specified in the
Deny list boxes on the Master Group Settings and Resources screens.
These lists are generated only when Portal Access first starts. To refresh
these lists after changes are made, users must log out, and then log on
again.
• If there is a match to an entry defined in the Deny list, the system denies
access to the URL.
• If the boxes are empty or if there is no match, the FirePass controller
passes processing to URL patterns specified in the Allow list boxes on
the Master Group Settings and Resources screens, and in the Allow list
box for the favorite. These lists are generated only when Portal Access
first starts. To refresh these lists after changes are made, users must log
out, and then log on again.
• If there is a match to an entry, the system allows access. If the boxes are
empty or if there is no match, the system applies the action specified in
the Default action box on the Master Group Settings screen.
In the Deny list and Allow list boxes, you can specify one URL pattern per
line. You can use the wildcard characters asterisk ( * ), which represents
many characters, and question mark ( ? ), which represents a single
character, in both the Deny list boxes on the Master Group Settings and
Resources screens. Each URL filter must specify a complete protocol and
path. If you use asterisk ( * ) or question mark ( ? ) characters as a part of the
URL, you can use the backslash ( \ ) character to escape these characters.
These characters can also be represented using their percentage-symbol and
number equivalents.
For example, the following specifies two URLs containing wildcards:
http://www.*.com/*.html
http://www.*.com/*.php
http://www.*.com:80/*.php\?a=1&*
If you do not specify a port, the system allows access from all ports.
The format requires a slash separator ( / ) between the host information and
the path. For example, you must specify: http://server.siterequest.com/*
instead of http://server.siterequest.com* or http://www.*/*.com* instead
of http://www.*.com* for the filter to work.
On the Portal Access : Web Applications : Master Group Settings screen,
you can select the check box Restrict using of IP addresses as URL
hostnames via Web Applications to prevent the use of IP addresses as host

Chapter 7
names. This prevents the FirePass controller from using an IP address as the
first part of a website address. For example, if this check box is not selected,
an address like 192.168.1.2 can be used erroneously as
192.168.1.2.siterequest.com in some instances.
Select the check box Path is case insensitive if you are writing ACL rules
to detect Windows-based Web server addresses, which might use uppercase
and lowercase characters.
Understanding Java sockets support

The Java patcher system can be configured so the secure socket layer (SSL)
server ports are not open to any address or port. All signed applets are
entered into a FirePass controller security policy. To use this feature, select
Allow or Deny for Java sockets on the Portal Access : Web Applications :
Resources : Access Control Lists for Java Sockets screen.
Preserving host names

You can define which host names to preserve on the Master Group Settings
screen. You might want to prevent the replacing of host names with the
FirePass controller name if you want to provide access to a web application
that uses the host name for a specific purpose. For example, preserving the
host name is useful for web applications that have JavaScript code that sets a
cookie based on the actual server name in the browser.
To access the Master Group Settings screen, click Portal Access, expand
Web Applications, and click Master Group Settings.
When you check Preserve FirePass hostname when accessing Web
Applications, the screen reveals a box. Into the box you can specify a
comma-separated list of patterns to match against URLs. You can use the
wildcard characters asterisk ( * ), which represents many characters, and
question mark ( ? ), which represents a single character, in the box. This
option instructs the reverse-proxy engine not to replace Host in the HTTP
headers.
If the box is empty, the FirePass controller replaces the host name on all
URLs. For example, using the typical reverse-proxy operation, the Host
value gets replaced, as shown in the following example:
Host: firepass.siterequest.com
(client to FirePass controller)
Host: company_server.siterequest.com
(FirePass controller to internal web application)
When you check the Preserve FirePass hostname when accessing Web
Applications check box, the FirePass controller delivers the Host header to
the internal web application without alteration, as Host:
firepass.siterequest.com.
7 - 18
Configuring content processing for web applications

You can define Portal Access content processing functionality on the
Content Processing screen. To access the screen, click Portal Access,
expand Web Applications, and click Content Processing.
When sending connections through the proxy engine, the FirePass controller
uses an advanced, full-content rewrite engine to modify the URLs and other
links in the original HTML document. The modified path begins with f5-w-.
For example, The FirePass controller rewrite engine converts the link shown
in the following example to the string shown in the following result.
<a href='http://siterequest.com/...'>
<a href='https://firepass.siterequest.com/
f5-w-X8d676sba8c650337ebf0937652fd678ac8a7663628f8a7d9449c9/. '>
If a web site has very complex or poorly written code, it is possible that
some links will not be re-written, or will be re-written incorrectly.
Additionally, the FirePass controller may not always be able to fully parse
and patch advanced JavaScript code, which could result in improper display
and loss of functionality.
You can apply the content-processing features to address these conflicts.
Locating proxy conflicts

You can find the source of the problem by comparing a connection made
directly between a client and the web application to a connection made
through the FirePass controller.
The following tools are helpful in making this comparison:
• The web browser’s source-viewing functionality
• The network packet dump option, available on the Device Management :
Maintenance : Troubleshooting Tools screen
For more information about the network packet dump feature, see
Capturing network packets, on page 8-63.
• The Test Content Processing Settings feature, available on the Portal
Access : Web Applications : Content Processing screen
For more information, see Testing content processing settings, on page
7-23.
• The FirePass controller engine-trace function
For more information about the engine-trace function, see Chapter 13,
Using Web Applications Engine Trace.
Configuring processing scripts for content processing

You can use the Preprocessing Scripts screen for modifying web pages as
they pass through the reverse proxy. To access the screen, in the navigation
pane, click Portal Access, expand Web Applications, click Content
Processing, and then click the Preprocessing Scripts tab.

Chapter 7
The FirePass controller can perform special-purpose processing of content

passing through Web Applications, using SED-based scripts. You can create
specialized SED scripts that modify intranet web pages to address issues
related to the proxying of unusual or incorrectly formatted content.
Adding a SED script

You can use SED scripts to modify intranet web pages to handle issues
related to proxying unusual or incorrectly formatted content. Here, you can
specify a URL pattern and an accompanying SED script for processing
content passing through Web Applications. You can specify a single URL
match pattern list for each processing type. For example, you can specify
response preprocessing, processing that occurs before patching; response
postprocessing, processing that occurs after patching; or request processing,
processing requests from a user before the FirePass controller sends it to the
web site.
The FirePass controller processes URL content using the first match it finds
in the list of defined entries (starting at the top of the list). If a SED script
matches content, they system does not search for another match after that
match is made.
The first step in configuring content processing by adding a SED script is to
create a favorite.
To add a favorite that uses a SED script

Applications, click Content Processing, and then click the
Preprocessing Scripts tab.
The Preprocessing Scripts screen opens.
The screen refreshes to reveal new options.
3. In Processing script name, type the name of the favorite.
This can be any string that can help you identify the specified
content processing functionality.
4. In URL match patterns, specify a comma-separated list of patterns
to compare with incoming URLs. The FirePass controller processes
matching URLs using the specified script.
If the box is empty, the FirePass controller does not process content
from any URL. You can use the wildcard characters asterisk ( * ),
which represents many characters, and question mark ( ? ), which
represents a single character, to specify the patterns, for example,
http://*.siterequest.com/*
5. In Content Type, specify the content-type HTTP header that the
FirePass controller should process with the script.
An empty box means that the FirePass controller processes text/*
content types, for example, text/plain, text/html, and so on. For
SED script processing, you can specify additional types, for
example, application/xhtml+xml that the FirePass controller
7 - 20
should process using the specified SED script. If a page to be

matched does not have a defined Content Type, you can specify
application/unknown.
6. In Sed processing script, specify the SED script the FirePass
controller should use for processing the web application request or
response data.
For example, if you specify s|HTTP://|http://|g the FirePass
controller performs a global search for HTTP://, and replaces each
instance it finds with a http:// string.
You can use much more complex scripts, and include regular
expressions, to search for and replace or modify content, and to
correct HTML errors on pages.
You can use the FP_ServiceAddr variable inside SED scripts.
Processing replaces this variable with the FirePass controller name.
You can also use content processing scripts to insert
<FP_DO_NOT_TOUCH> and </FP_DO_NOT_TOUCH> tags
around sections of code on pages that you do not want the rewrite
engine to rewrite.
Note: In certain cases, you must use the backslash character to
escape forward slash characters in the SED script.
7. From the Processing list, select where to apply the content
processing script. You can apply the SED script to the user request
or to the server response. If you elect to apply the script to the
response, you can apply the script before or after the reverse proxy
engine performs content patching. Options are:
• Pre-process response data (before content patching): Applies
the SED script to response data received from a web site before
the content is patched by the reverse proxy engine. In most cases,
you should select this default option of Pre-process response
data (before content patching).
• Post-process response data (after content patching): Applies
the SED script on response data after the content is patched by
web applications.
• Process request data: Processes request data from a user before
it is sent to the web site.
You can find more information about using SED scripts on the Ask F5sm
web site by searching FirePass-controller-related Solutions.
Example 1 of using a SED script

In this example, we use a script to replace an applet. The problem the script
is solving is that a page with a video streaming applet does not work as
expected through Portal Access Web Applications.

Chapter 7
The administrator used the tcpdump command to determine that the

problem is that the applet does not rely on URLConnection for streaming,
that instead, it uses sockets.
Note
The FirePass controller patches Java applets (when the option is enabled),
even those that use sockets, so this example is for illustrative purposes only.
In this case, the administrator developed a SED-based content processing

script to replace the applet with an image, using a different CGI for
displaying still images, along with a piece of JavaScript to reload the image
automatically. You can find the script in the section SED content processing
script for example 1, following.
In the source for the web application, HTML comments take the applet out
of the context. Then, the script injects an image named noapplet following
the </APPLET> tag, and provides the onload callback im_loaded. The
script injects the im_loaded implementation preceding the </HEAD> tag,
reloads the image immediately after the implementation loads, and adds a
time-based query parameter to ensure that the browser does not cache the
image.
The result is that the location that previously contained the non-working
applet now shows a static image.
SED content processing script for example 1
This shows a SED script that performs content processing on a page that
contains a video streaming applet that does not work in web applications.
s@</HEAD>@ <script>function im_loaded(){d = newDate;document.images['notapplet'].
src="/axis-cgi/jpg/image.cgi?="+d.getMilliseconds();}</script></HEAD>@
s@<APPLET@<img onload = 'im_loaded()'name=notapplet

src='/axis-cgi/jpg/image.cgi' width='320'height='240'>@

In this example, we describe how to prevent the rewriting of certain URLs
by the reverse-proxy engine. The problem the script is solving is that an
intranet application dealing with XML data or XSL style sheets does not
work properly.
The FirePass controller attempts to determine which links on HTML pages
it should rewrite. However, the reverse proxy engine might not always
correctly analyze XML or XSL data and pages that make extensive use of
JavaScript. If you determine through analysis that proper operation requires
the preservation of some links that are being rewritten, you can use a SED
script to return content to its original condition. The result is that the URLs
that were previously rewritten are now returned to a usable state.
SED content processing script for example 2
The following section contains a SED script that performs content
processing on a page that contains XML or XSL content that does not work
in web applications.
7 - 22
To search for certain types of pages, you can specify a match pattern in
URL match pattern, for example */pathnet/XSLTS/*. Then in the SED
processing script box, you can use a SED script, such as s|/f5-w-[^/]*|//|g. In
this case, the FirePass controller should process content after performing its
patching, so from the Processing list on the Preprocessing Scripts screen,
select Post-process response.
This script removes the f5-w- information that reverse proxy adds. In
general, the page will work correctly after postprocessing, as long as the
links on the page are to the same host (or are relative links).

You can also specify a slightly more complex SED script than the one
described in Example 2 of using a SED script to remove rewriting from one
particular link on a page, or to a more selective set of links. The following
script requires a link containing /eerequest/ on the page to remove the f5-w-
references.
/eerequest/ {
s|/f5-w-[^/]*|//|g
}
For more information, see the SED man page.
Testing content processing settings

You can test the content of a processed web page under Test Content
Processing Settings on the Preprocessing Scripts screen. To access the
screen, in the navigation pane, click Portal Access, expand Web
Applications, click Content Processing, and then click the Preprocessing
Scripts tab.
Once you apply the SED scripts you want, you can use this functionality to
preview a page’s content as it would be delivered from the FirePass
controller. To test content, in the navigation pane, click Portal Access,
expand Web Applications, click Content Processing, and click the
Preprocessing Scripts tab.
When you specify a URL in the box and click the Test button in the Test
Content Processing Settings section, the FirePass controller fetches and
displays the HTML source that the FirePass controller delivers for the
configured URL. When the processing testing mechanism finds and displays
the page represented by the URL, the content also reflects any script
processing and content cleaning results. You can also click a link, View
processed page through Web Applications, to view how the page looks
when presented to the end user.
If the page is a valid URL, the results box, labeled Original URL source,
contains the page source. If the URL is not valid, the testing functionality
returns the message Invalid URL entered or Error fetching URL source.
You may also get the Error fetching URL source if the URL you are trying
to fetch requires authentication. If that happens, you can specify the
authentication you need by viewing the page and then trying the test again.

Chapter 7
Troubleshooting web application failures

While there are a number of reasons that SED processing might fail on an
application accessed through the FirePass controller, the most common
reason is that a JavaScript tested the page’s content and either the test failed,
or the content did not match the script’s expectations. If the content fails the
JavaScript test, errors might be reported or the application could refuse to
allow further operations.
Some common JavaScript tests perform the following functions:
• Check the protocol of the URL to make sure it is http://
• Check the URL to make sure its host name matches the server name sent
in the JavaScript
• Perform a checksum on the page and make sure it matches the original
JavaScript tests frequently fail when the site is accessed through the
FirePass controller, because the FirePass controller modifies URLs to use
the HTTPS protocol and to contain the host name of the FirePass controller.
You can use one of the following solutions to work around this issue:
• Modify the application so that the tests allow for the changes made by
• Use a content processing script to modify or remove the JavaScript test.
Note
You can use the Minimal Content Rewriting Bypass feature to avoid the full
content rewrite typically needed with Web Applications. Configuring this
feature helps deal with complex portal and web application content. For
more information, see Configuring the Alternative Host/Port-based type of
bypass, on page 7-12.
Cleaning web application content

You can have the FirePass controller use the HTML Tidy open-source
parser to reformat HTML content passing through Web Applications prior
to content patching. This may be necessary for some sites to deal with
proxying specially formatted HTML content.
Note
Content cleaning is a very processor-intensive operation. We recommend

not enabling this feature except for debugging purposes, to help with
troubleshooting content-rewrite issues.
You can specify a list of URLs under Web Applications Content Cleaning
on the Preprocessing Scripts screen. To access the screen, in the navigation
pane, click Portal Access, expand Web Applications, click Content
Processing, and then click the Preprocessing Scripts tab.
In the box under Web Applications Content Cleaning, you can use the
question mark ( ? ), which represents a single character, to specify URLs
7 - 24
that you want the FirePass controller to process for content cleaning. An
empty list means that the FirePass controller does not reformat content from
any URL.
Note
The content-cleaning function cannot fix severe coding or content errors.
Configuring mobile device (Pocket PC) cleanup support

The FirePass controller provides Web Application Support for the correct
recognition of mobile devices, compatible with Windows CE, that also
allows PocketPC mode to work properly with post-logon agents such as
Cache Cleaner.
When you add a new browser of the type Pocket PC Browser, on the
Device Management : Configuration : New Browsers screen, the Pocket PC
browser displays Web Application favorites.
Configuring global settings for content processing

The FirePass controller rewrites URLs, JavaScript, and Java applets on all
Portal Access web pages to resolve internal to external URLs.
You can use options on the Portal Access Global Settings screen to
configure the FirePass controller behavior when processing web pages as
they pass through the Portal Access reverse-proxy engine. To access these
options, in the navigation pane, click Portal Access, expand Web
Applications, click Content Processing, and click the Global Settings tab.
Options include:
• Present alternative browser User-Agent strings to specific application
hosts: For information, see Configuring enforce-user-agent strings on a
per-host basis, following.
• Suspend updating the FirePass controller user session for specified
URLs: For information, see Preventing session update, on page 7-26.
• Omit from some application pages the Home/Logout tab, which is
ordinarily added to all proxied web pages: For information, see
Configuring Home/Logout tab injection, on page 7-27.
• Perform non-buffering uploads to URLs that match specified patterns.
For information, see Configuring non-buffering uploads, on page 7-27.
• Suspend rewriting of Java byte code for specified URLs: For
information, see Preventing Java byte code rewriting, on page 7-27.
• Configure OWA and iNotes: For information, see Understanding the
Flash rewriting support, on page 7-28.
• Configure OWA and iNotes: For information, see Configuring OWA,
iNotes, and other specific web applications, on page 7-28.

Chapter 7
• Specify global settings for web applications: For information, see

Configuring web applications global settings, on page 7-29.
Note
Configuration for most global settings requires a service restart.
To access the Global Settings screen, in the navigation pane, click Portal
Access, expand Web Applications, click Content Processing, and then
click the Global Settings tab.
Configuring enforce-user-agent strings on a per-host basis

The FirePass controller can present a specified User-Agent string to a
particular web site instead of the actual browser’s User-Agent. An
alternative User-Agent string is useful in downgrading content if content
patching errors are occurring.
You can also specify a per-host, user-agent string to use with content
processing on the Global Settings screen. To access the screen, click Portal
Access, expand Web Applications, click Content Processing, and click the
Global Settings tab. This feature provides the following options:
• Intranet Host
Contains the URL for the intranet server that communicates with the
FirePass controller. For example,
server.siterequest.com
• Alternative User-Agent String
Contains the string the configured intranet host sends to the FirePass
controller. The specified user-agent string causes the intranet host to
impersonate the specified browser by sending the associated user-agent
string.
• List of browsers
Contains a list of the common browsers. Selecting a browser from this
list populates the associated user-agent-string box, which you can
modify, if you wish.
For more information about user-agent strings, see Specifying user-agent

strings, on page 7-8.
Preventing session update

Some web applications pages loaded through Web Applications connections
contain JavaScript code that regularly refreshes the page or sends HTTP
requests, regardless of user activity or inactivity. A session that is
abandoned at such a site does not time out, because it appears to be active.
You can use the session update feature to prevent these sessions from
remaining active indefinitely, and you can specify sites whose session
activity is to be disregarded for purposes of computing idle time.
7 - 26
In the list, you can use the wildcard characters asterisk ( * ), which
single character, to specify URLs that should not update the FirePass
controller session. An empty list means all URLs update a session.
Configuring non-buffering uploads

The FirePass controller caches files before uploading them to a server. You
can use the non-buffering upload option to upload a large amount of data
(32 MB to 1024 MB), such as video or voice files to a server through the
FirePass controller without caching the file. This speeds the upload process.
To allow upload of large files, make sure to change the value in the Restrict
maximum upload size (32-1024 MB) option on the Portal Access : Content
Inspection screen. Then in the Non-buffering uploads section on the Portal
Access : Web Applications : Content Processing screen, specify a pattern
that represents the server to which the files are to be uploaded.
Configuring non-buffering uploads

You may type a comma-separated list of URL patterns to perform
non-buffering uploads for URLs that match specified patterns. An empty list
on the Portal Access : Web Applications : Content processing screen, causes
the system to buffer all URLs.
The pattern match supports the wild card characters asterisk (*) and question
mark (?); for example:
*://somehost.com/upload*
*://otherhost.com/post.php*
Configuring Home/Logout tab injection

The FirePass controller inserts into HTML pages a small amount of HTML
that contains the JavaScript that displays the Home and Logout navigation
links. In the box in the Home/Logout tab injection section, type the full URL
for the page into which you do not want the FirePass controller to insert
JavaScript. Pages generated without the JavaScript contain no Home or
Logout links.
Preventing Java byte code rewriting

You can use the Java Byte Code Rewriting feature to suspend rewriting of
Java classes, or .jar, .cab, or .zip archives for specified match patterns.
By default, the FirePass controller handles Java byte code so that all HTTP,
HTTPS, and socket-based network communication is sent to the FirePass
controller through secure HTTPS tunneling. This approach provides a
secure and portable proxy mechanism for web-based, client-server
applications that utilize client Java applets.
The reverse proxy rewriting engine supports most network-related classes
and methods. As long as the Java applet uses TCP, and the network traffic is
initiated from the client, the applet is supported. If the applet contains

Chapter 7
server-initiated connections through the use of the ServerSocket class,

reverse proxy cannot process the applet. Reverse proxy rewrites and re-signs
only those Java applets that require patching.
Since reverse proxy modifies the byte code, the final applet delivered to the
end-user is different from the original applet. The FirePass controller
re-signs the applet with its own signing certificate. In some cases, this can
result in a browser warning being displayed to the client.
To prevent Java modification problems with reverse proxy, ensure that all
network-related classes conform to the Sun Java specification. The rewriting
functionality might not support class files written in a proprietary format. If
the class files do not contain standard byte code, then reverse proxy cannot
modify the content.
The FirePass controller caches rewritten Java applet for the next client
request. Because of the caching operation, if your application uses Java
applets, make sure to check the Enable Dynamic Cache on FirePass.
Generally improves WebApplications performance check box on the
Portal Access : Web Applications : Caching and Compression screen.
In the box in the Java Byte Code Rewriting section, you can use the
question mark ( ? ), which represents a single character, to specify URLs for
which the FirePass controller should not rewrite classes or .jar, .cab, or .zip
archives. An empty list means the FirePass controller rewrites all classes or
.jar, .cab, or .zip archives. For more information about the process of
rewriting, see Configuring web applications for minimal rewriting, on page
7-10.
Understanding the Flash rewriting support

The rewrite engine fully supports and rewrites Flash files, .swf, and Flash
ActionScript. Because of specific Flash file formatting, web application
connections through Portal Access cannot be configured to stream Flash
files. Instead, the FirePass controller fully downloads the Flash files from
the server, rewrites them, and then sends them to the user. If you plan to
deliver large Flash files, for example, Flash files containing a video stream,
users might experience a significant delay before the file displays the
stream.
Configuring OWA, iNotes, and other specific web applications

For effective access, some web applications, such as Microsoft Outlook
Web Access and IBM iNotes, require a special access mode. In the Feature
Web Applications section of the Content Processing screen, you can specify
the host name or comma-separated list of host names for which you want to
switch to special mode.
For each host you specify, the FirePass controller uses the optimal caching
and compression settings, overriding the global settings specified on the
Portal Access : Caching and Compression screen. You can also check
Automatically detect hosts for OWA and iNotes to have the FirePass
controller evaluate the hosts and switch to special mode automatically. For
more information, see Configuring caching and compression, on page 7-31.
7 - 28
Configuring web applications global settings

You can configure cookie pass-through using the box in the Web
Applications Global Settings area. You might want to allow cookies to pass
from the client to specific web sites. With the setting, you can specify a
comma-separated list of patterns to compare with incoming URLs. If there
is no pattern, the FirePass controller blocks cookie pass-through for all
URLs. You can type an asterisk ( * ) to allow cookies to pass through for all
URLs. You can use the wildcard characters asterisk ( * ), which represents
character.
*://msnbc.msn.com*
*://www.yahoo.com*
*://www.ibm.com*
If your web site includes JavaScript that does any client-side cookie
manipulation, you must specify a pattern that allows the cookie to pass
through to the client browser. For security reasons, cookies are not passed
through by default. When troubleshooting or testing initial support for a web
portal or application, check the Do not block cookies at FirePass, pass
them to the browser for specified URL patterns check box, and type an
asterisk ( * ) in the box. This configuration instructs the FirePass controller
to pass all cookies through to the client browser. Then after testing, you can
restrict the cookies being passed.
Configuring Content Processing Global Settings requires a service restart,
and also provides the following options:
• Enable HTTP/1.1 support for back-end requests
Allows the FirePass controller to support HTTP requests that originate
from an HTTP/1.1 version server.
• Automatically patch Java Applets
Intercepts the Java applet and unwraps it if it is a .jar, .cab, or a .zip
archive. Next, each class is searched, and when the applet-rewrite
functionality finds an Applet, JApplet, Socket, or URL, or InetAddress
class, it rewrites it accordingly, along with rewriting its inheritance
definitions. Then, the applet is repacked and resigned, if necessary, using
the F5 signing certificate. The FirePass controller then passes the
transformed applets to the web client, and caches them, if the dynamic
cache option is set.
By specifying URLs under Java Byte Code Rewriting on the Content
Processing Global Settings screen, you can suspend rewriting for specific
URLs. For more information, see Preventing Java byte code rewriting,
on page 7-27 and Configuring the Alternative Host/Port-based type of
• Automatic MIME type recognition
Examines the content associated with a site to determine its Multipurpose
Internet Mail Extensions (MIME) type so that the application can present
the information correctly.

Chapter 7
• Block non-HTML data

Prevents download of files such as .doc and .pdf from being downloaded
from web applications. Only HTML content is allowed to pass through
the proxy.
• Remedy IE gzip compression bug by adding leading 2 kilobytes of
whitespace to HTML pages
Compensates for an Internet Explorer bug that strips off the leading two
kilobytes of server messages when it accesses a web page compressed
using gzip. It does so by adding 2K of leading, padding spaces. Selecting
this option does not affect the appearance of the application on other
browsers. Select this option if you enable compression on the Caching
and Compression screen, and if any of your users might connect using an
unpatched version of Internet Explorer 6. To access the Caching and
Compression screen, in the navigation pane, click Portal Access, expand
Web Applications, and click Caching and Compression.
• Do not block cookies at FirePass, pass them to the browser for
specified URL patterns
Allows the FirePass controller to pass cookies to the user’s web browser.
This option is useful for supporting web applications that use JavaScript
in the browser to manipulate cookies. We recommend that you specify a
pattern or list of patterns that allows cookie pass-through only for web
applications with URLs that match the pattern.
• Automatically add websites that require client side cookie
manipulation
Adds to the list the web sites that require client-side cookie manipulation
when the FirePass controller encounters them. By default, this feature is
enabled. F5 Networks strongly recommends disabling this option once
the learning phase is over.
• Encrypt hostnames
Uses AES encryption to modify the name of the host that is passed
through the proxy. When you enable this option, the system does not use
dynamic cache, regardless of the state of the Enable Dynamic Cache on
FirePass. Generally improves WebApplications performance check
box on the Portal Access : Web Applications : Caching and Compression
screen. When Encrypt hostnames is not enabled, the system passes host
names as hex-encoded strings.
• Obfuscate cleartext cookies
Obscures cookies sent in clear text format so users cannot read them. By
default, this feature is enabled.
• Translate hidden form parameters if they look like URLs
Select this option to translate hidden form parameters if they appear as a
URL, such as http://XXX. This option is useful when you have
JavaScript that manipulates hidden form parameters. F5 Networks
recommends limiting the effect of this option by specifying a list of URL
patterns to match against. In the list, you can use the wildcard characters
asterisk ( * ), which represents many characters, and question mark ( ? ),
which represents a single character. An empty list means all URLs are
patched.
7 - 30
Configuring caching and compression

You can define caching and compression functionality on the Caching and
Compression screen. To access the screen, in the navigation pane, click
Portal Access, expand Web Applications, and click Caching and
Compression. Using options on this screen, you can configure settings that
determine caching and compression of files sent from the FirePass controller
to remote user’s web browsers, as well as the transmission of cookies and
file downloads from intranet servers to users.
When using dynamic cache, the FirePass controller does not distinguish
between static or dynamic content. It distinguishes between objects that the
remote server designates as those that the FirePass controller can and those
it cannot cache. The remote server indicates the object’s ability to be cached
by setting the appropriate cache control in the response’s HTTP headers. If
the remote server indicates that an object may be cached, and this option is
checked, the FirePass controller caches the object in its dynamic cache.
Note
You should not enable dynamic cache when you are using group-based
VLAN to access hosts with the same host name or IP address on different
VLANs.
The FirePass controller validates the currentness of cached objects by

sending an if-modified-since request-header to the remote server and
receiving either a (not modified) response or the modified object. This
ensures that objects in the cache remain fresh.
If client browsers request both compressed (gzip) and non-compressed
objects simultaneously, the FirePass controller stores each type into the
cache for maximum performance.
Caching errors do not affect web application functionality. When the
FirePass controller cannot cache an object for any reason, the FirePass
controller simply sends the object to the user. In other words, operation is
the same as if caching is turned off.
You can determine whether the FirePass controller has presented content to
a client from the cache, by checking the response headers in pages returned
to the browser for the presence of the following string:
X-Cache: HIT from your.firepass.hostname
Setting caching and compression

The Caching and Compression screen provides the following caching and
compression options:
• Enable Dynamic Cache on FirePass. Generally improves
WebApplications performance:
Caches content to prevent the need for repeated rewriting. You can also
clear the dynamic cache by clicking the Clear Cache button. If you
specify Encrypt hostnames, the FirePass controller does not use this
caching setting, even if you enable it.

Chapter 7
• Enable Compression. Saves bandwidth, at the expense of server

resources:
Uses the gzip compression utility to substantially reduce the size of
generated content. The most noticeable improvement in speed occur
when accessing pages that contain big Java classes or other large
elements (images, scripts, and so on), but not when accessing pages that
reference Java packages (.jar files), class archives (.zip files), or
compressed images (.jpg, .png, and Compressed TIFF files).
For iNotes and other Java-based web mail packages, enabling
compression vastly improves the speed in which pages are loaded. You
can also specify a comma-separated list of URLs for the FirePass
controller not to compress, even when compression is turned on. In the
list, you can use the wildcard characters asterisk ( * ), which represents
character. Turning on gzip compression reduces FirePass controller
resources, which can affect scalability.
Configuring global caching and compression settings

You can select from several global caching and compression settings. Each
global setting caching option has an inherent trade-off between web
application performance and security. The global settings you can select
include:
• Don't cache anything, except Style Sheets and JavaScript includes
Provides a good compromise between security and performance. By
default, web applications mark every screen as non-cacheable with the
exception of JavaScript and style-sheet includes. The reason is that
typically, these sizeable includes are designed with caching in mind.
When caching is turned off, a high percentage of the traffic consists of
these includes. Given that the content of these includes is rarely
confidential, they are not marked as non-cacheable by default.
• Don't cache anything, except for images, style sheets and JavaScript
includes
Results in better performance than the first option, but less security.
• Cache nothing at the remote browser
Impacts performance more than the first two options, but provides better
security. OWA and iNotes require some caching, so select another option
when you are serving OWA and iNotes application pages.
• Don't enforce no-cache
Provides the best performance of all options, but the least amount of
security. Use this option only with trusted terminals such as home
computers. This option caches according to the web browser settings. For
this setting, you can specify a comma-separated list of URLs for which
the FirePass controller should ignore no-cache. If there is no list
specified, no URLs are exempt from no-cache. When you specify the list,
you can use the wildcard characters asterisk ( * ), which represents many
characters, and question mark ( ? ), which represents a single character.
You would use this option in cases where the no-cache header causes
problems.
7 - 32
For example, if Cache nothing at the remote browser is set, when

proxying HTTP content, The FirePass controller automatically sets a
Cache-Control: no-cache header. The Cache-Control: no-cache header
can cause problems for some XML applications, mostly on Internet
Explorer browsers, because the client does not retrieve XSL files that are
not cacheable. When this occurs, the browser displays an error indicating
that the XSL file is not cacheable or is not available. You can work
around this issue by specifying http://*.siterequest.com/*.xsl in the box
so that the FirePass controller does not insert the cache control headers
into files that end with an .xsl extension.
Configuring intranet webtop options

You can specify an intranet web page to replace the webtop for a specific
master group on the Intranet Webtops screen. To access the screen, in the
navigation pane, click Portal Access, expand Web Applications, and click
Intranet Webtops. If you elect to use a web page, no other access functions
are available. Configured intranet webtops apply to all users in a master
group.
You would configure this feature when you want to replace the standard
FirePass controller webtop with an internal intranet portal front-page. An
intranet webtop completely replaces the standard FirePass controller
webtop, which typically displays administrator and user-defined favorites.
Note
In addition, you can create a custom replacement page that contains

JavaScript code that starts FirePass controller favorites. You can store the
replacement webtop page on the FirePass controller, using WebDAV, or on
an external server. For more information and code samples, see the online
help on the Device Management : Customization screen under Advanced
WebDAV customization.
Intranet webtops have the following properties and elements.

• Request
Indicates whether to transmit the URL and its accompanying arguments
in GET, or in a POST request. Using POST is a more secure way to
provide a user name and password for logging on to an intranet site,
because the variables are not visible on the URL line of the browser for
someone to see.
• URL
Indicates the intranet web server that serves the application. For example:
• URL variables
Contains variables to be either appended or sent in a GET command to
the specified URL. For more information and examples, see Working
with URL variables, on page 7-7.

Chapter 7
• Enabled
Indicates whether the web application serves the specified page as the
webtop for users in the associated group. For additional information on
how to use a page as a customized webtop and run FirePass controller
favorites, see the online help on the Device Management : Customization
screen.
Preserving page content

The FirePass controller supports the ability to present favorites on a custom
portal page located on the FirePass controller, using WebDAV, or from a
custom portal page stored on one of your own internal servers. You can use
the portal page as an alternative to the FirePass controller webtop.
For more information about WebDAV functionality, search for WebDAV in
the online help.
Once you have the portal page, you can configure it as a FirePass controller
webtop or define a reverse-proxy favorite. Then, users who log on to the
FirePass controller using that portal page can start favorites, such as
AppTunnels or Network Access connections, by clicking portal links.
If you have HTML, JavaScript, or CSS content that you want to preserve,
you can do so by placing a <FP_DO_NOT_TOUCH> tag at the beginning
and a </FP_DO_NOT_TOUCH> tag at the end of the code. The tags
prevent the code inside them from being rewritten.
Note
In earlier versions, the online help for the Device Management :

Customization screen in the WebDAV section, contained sample code that
you could use for this purpose. The new reverse-proxy engine rewrites some
of the content so that pages using the sample code no longer work. If you
are using the sample code, you can also use these tags to prevent the
rewriting.
Configuring proxy options

You can specify proxy settings on the Proxies screen. To access the screen,
in the navigation pane, click Portal Access, expand Web Applications, and
then click Proxies. The FirePass controller can use HTTP and HTTPS
proxies for web access. The Set up optional HTTP and SSL proxies for
public Internet access section provides options for proxies for HTTP, SSL,
or both. In addition, you can elect to use basic proxy authorization,
specifying a user name and password to the proxy.
The FirePass controller web-access mechanism requires a proxy if there is
no outbound access to the Internet. Also, Web Applications functionality
might require proxy settings if the FirePass controller does not have direct
access to the web servers on the local network.
7 - 34
Proxy settings consist of an address and port number. You can also specify a
comma-separated list of addresses or subnets to which the FirePass
controller should allow direct access, that is, not through the proxy server.
When you check Enable HTTP proxy or Enable SSL proxy and click
Update and Test, the FirePass controller presents Address and Port boxes
for each type of proxy. You can also specify a list of the IP addresses to
which the FirePass controller should allow direct access rather than through
the proxy.
Note
The FirePass controller makes sure it can connect to a specified proxy

before committing the settings. Because of this, testing a new configuration
might take a minute or so if the settings are incorrect.
In the No proxy for the following addresses (comma separated) box, you
can specify the leading digits for IP addresses for resources to which you
want the FirePass controller to allow direct access. Use commas to separate
these addresses. You can use the X[.Y[.Z]] format for IP address templates,
for example, 19 or 192 or 192.168 or 192.168.200 or 192.168.200.12. If
there is no list of addresses, the FirePass controller uses a proxy for all
resource access.
Note
The FirePass controller does not support specifying a subnet mask using
24-bit (CIDR) addresses for the proxy exclusion list.

Chapter 7
Configuring Windows files

You can configure Windows Files favorites that give users access to files in
network shared Windows folders. Once connected, users can view,
download, move, rename, and delete files. You can also specify global
settings that apply to all Windows files connections through Portal Access.
Configuring Windows Files favorites

You can use the Resources screen to configure favorites for the user’s
webtop. To access the Resources screen, in the navigation pane, click Portal
Access, and click Windows Files. To set other policies and behaviors, you
can use the Master Group Settings screen. For more information on master
group settings, see the online help.
When you click Add new favorite on the Resources screen, the screen
reveals additional options.
• Type
Indicates whether the link is a new configuration (Favorite) or a pointer
to an existing one in another master group (Alias). Alias is available as
an option only when there are Portal Access favorites configured in
another master group.
• Name
Contains the name for the intranet site that you are defining as a favorite.
This is the name the user sees on the webtop. The string you specify can
be any name; the input format is not limited. For example:
Project management & "dailies"
• Path
Contains the Microsoft Universal Naming Convention (UNC) string. A
UNC name typically references a shared folder and file accessible over a
network rather than a drive letter and path. You can include path
arguments such as %username% to substitute for user’s logon and
%group% to substitute for the user’s master group name. For example
\\publicsrv.eng.siterequest.com
• Endpoint protection required
Provides a list of Protected Configurations defined on the Users :
Endpoint Security : Protected Configurations screen. If the user’s
endpoint protection does not satisfy the defined condition, the system
prevents access to the specified resource. For more information about
protected configurations, see Creating protected configurations, on page
3-27.
Important
The FirePass controller does not verify paths, so make sure the path is
specified correctly.
7 - 36
Configuring Windows Files master group settings

You can specify options that apply to all Windows Files users on the Master
Group Settings screen. To access the Master Group Settings screen. in the
navigation pane, click Portal Access, expand Windows Files, and click
Master Group Settings.
The Master Group Settings screen provides a set of options that govern the
operation of Windows Files functionality through Portal Access
connections.
◆ Limit Windows Files Access to Favorites only (for Extranets, partner
and customer access, etc.)
Prevents master group members from browsing outside of folders
specified in favorites.
◆ Enable file upload
Controls the uploading files for users in the associated master group. To
specify the maximum file upload size, and set antivirus checks for
downloaded files, see Configuring buffer overflow protection, on page
7-47.
◆ NetBIOS Machine Name
Specifies the NetBIOS name of the FirePass controller, using 1 to 15
alpha-numeric characters. The default is the host name.
◆ Name Resolution Service Order
Specifies the sequence in which the FirePass controller attempts to
resolve NetBIOS names to IP addresses for Window-based file access.
List each options separated by a space. The default order is host wins
bcast, which represents the following options:
• host
Resolves a standard host name to an IP address, using the system
/etc/hosts, NIS, or DNS lookups,
• wins
Resolves WINS server names to an IP address. This option is valid
only when you configure a WINS server, as described in the WINS
Servers entry, following.
• bcast
Performs a broadcast on the servicing interface to resolve NetBIOS
names to IP addresses. Do not use this option when you define master
group-based policy routing for the user’s master group.
◆ WINS Servers
This setting is necessary for multi-segment networks, when the FirePass
controller and the LAN are on different network segments, or when the
LAN itself has multiple segments. You must specify WINS Servers for
networks structured as multi-segment LAN environments. When the
Name Resolution Service Order has the wins option specified, then you
must specify one or more valid WINS Servers in WINS Servers.
◆ Default Domain/Workgroup
Contains the name of the Windows domain or workgroup where the
FirePass controller resides. You must specify Default

Chapter 7
Domain/Workgroup when the FirePass controller unit address is not on

the target LAN. We also recommend that you define the Default
Domain/Workgroup setting for multi-segment LAN environments.
◆ Auto-logon to Windows File shares using FirePass user logon
credentials
Directs the FirePass controller to use the user’s FirePass controller logon
name and password to automatically log on to Windows file servers and
shares.
◆ Click to change the status and/or webifyer position on the webtop
Opens the User Experience screen for the associated master group, where
you can change the location and operation of favorites on the user’s
webtop. For more information, see the online help for the screen.
In addition to these settings, the FirePass controller automatically enables
SMB signing for authentication when the connecting server requires it.
Also, the FirePass controller can access Windows file servers that support
DFS.
7 - 38
Configuring Mobile E-Mail

You can configure the Portal Access : Mobile E-Mail feature to enable users
to access email from any client computer. The Mobile E-Mail feature
provides very lightweight access to multiple Post Office Protocol (POP) and
Internet Message Access Protocol (IMAP) mailboxes and address books,
using data from the FirePass controller’s internal database or from an LDAP
directory. You can configure different Mobile E-Mail settings for each
master group. There are several options for configuring logon options:
• Allowing the user to enter a logon name and password directly
• Using the FirePass controller database for logon information
• Querying an LDAP server to retrieve logon credentials
Users can use any web browser to access the mailbox. In particular, users
who are away from the office can use browsers on mobile devices to quickly
browse through emails.
A user can configure any number of email accounts, but you can limit access
to only the corporate account you create, by checking the Limit E-Mail
Access to Corporate mail account only (for Extranets, partner and
customer access, etc.) check box. This limitation is useful for users logging
on from extranets, and for partner and customer access. You can also disable
the downloading of attachments, which can help prevent introduction of
untrusted material onto the client’s machine.
Configuring Mobile E-Mail includes the following options:
◆ Master Group
Presents a list of all master groups. Select the one you want to configure.
◆ Enable corporate mail account
Provides access to the user’s corporate email account.
◆ Account name
Represents the string users see as the name of the link on their webtop.
Corporate Mail is the default.
◆ Mail server
Represents the mail server name or IP address. For example,
mailserver.siterequest.com.
◆ Type
Presents the support options: POP and IMAP. Select the one you want.
◆ IMAP Folders
Represents the comma-separated list of folders that you want users to
see, if you are using an IMAP mail server. This list prevents the
confusion created by mail servers that display items that are not email
messages, such as contacts or calendars, as empty email folders. Users
can also add to the list themselves.
◆ Logon Information
Presents a list of options for logging on to Mobile E-Mail.

Chapter 7
• User supplies display and logon information during first logon:

Gets email information from users when they attempt to use Mobile
E-Mail for the first time.
• Use FirePass database for display and logon information:
Retrieves email address, logon name, and password from the FirePass
controller internal database.
• Use LDAP query for mail server, display, and logon information:
Queries an LDAP server to dynamically retrieve each user’s email
information. When you select this option, you must configure the
LDAP query. For descriptions of the query options, see Configuring
the LDAP query, following.
◆ Outgoing Mail server

Represents the outgoing email server name or IP address for the FirePass
controller to use when sending email. If you do not specify a server, the
FirePass controller uses the settings specified in Primary server on the
Device Management : Configuration : SMTP Server screen.
When you finish configuring all of the options, click the Update button.
Important
If you use LDAP authentication over SSL, specify a host name, and be sure
that the host name exactly matches the name on your LDAP server’s
certificate.
Configuring the LDAP query

When you select the Use LDAP query for mail server, display, and logon
information option on the Logon information list in the Corporate email
account section of the Mobile E-Mail screen, you must also specify the
following options:
• LDAP server
Represents the IP address or host name of the LDAP server.
• Port
Represents an LDAP port, such as 389.
Provides support for using SSL for the connection.
Presents a list of the LDAP protocol version (2 or 3) for you to select.
The default protocol version is 3. If you use Active Directory, you must
use version 3.
• Bind DN
Represents the distinguished name the FirePass controller should use to
bind to the LDAP directory.
• Bind password
Represents the password for the BIND DN. You can leave the box empty
to require no authentication.
7 - 40
• Search base
Indicates the level of the entry in the tree to be used for the search, for
example:
cn=Recipients,ou=Exchange,o=FirePass
• Filter template
Contains the string to use when searching for the user. You can use %s
in the filter expression to have the FirePass controller insert a user logon,
for example:
(&(objectclass=person)(cn=*%s*))
• Attribute for mail server
Contains the attribute in the LDAP schema that stores the mail server
name.
• Attributes for user's display name, email address, and logon
Contains the attributes in the LDAP schema that stores the associated
information.
• Attribute for mail server
Represents the attribute in the LDAP schema that stores the mail server
name.
• Attribute for user’s display name
Represents the attribute in the LDAP schema that stores the name that
indicates who sent the email.
• Attribute for user’s email address
Represents the attribute in the LDAP schema that stores the originating
address of the email.
• Attribute for user’s logon
Represents the attribute in the LDAP schema that stores the name the
user types when logging on to the email server.
Configuring LDAP as the email address source

By default, Mobile E-Mail uses a list of users from the FirePass controller
database as an address book. You can elect instead to use an LDAP server as
the email address source. When you select Use LDAP server to obtain
addresses, you must also configure the following options:
• LDAP server
Represents the IP address or host name of the LDAP server.
• Port
Represents an LDAP port, such as 389.
Provides support for using SSL for the connection.
Presents a list of the LDAP protocol version (2 or 3) for you to select.
The default protocol version is 3. If you use Active Directory, you must
use version 3.

Chapter 7
• Bind DN
Represents the distinguished name the FirePass controller should use to
bind to the LDAP directory.
• Bind password
Represents the password for the BIND DN. You can leave the box empty
to require no authentication.
• Search base
Indicates the level of the entry in the tree to be used for the search, for
example:
cn=Recipients,ou=Exchange,o=FirePass
• Filter template
Contains the string to use when searching for the user. You can use %s
in the filter expression to have the FirePass controller insert a user logon,
for example:
(&(objectclass=person)(cn=*%s*))
• Name attribute
Represents the attribute in the LDAP scheme that stores the user’s name.
• Address attribute
Represents the attribute in the LDAP scheme that stores the user’s email
address, which is typically mail.
Disabling email attachments

By default, email attachment downloads are enabled. You can disable
downloads by checking the Disable attachment download check box. This
can help you protect remote client computers by preventing the introduction
of content that may contain viruses.
Changing where Mobile E-Mail links appear on the webtop

You can customize the location of favorites on the user’s webtop. To access
the customization page, click the Click to change the status and/or
webifyer position on the webtop link on the user’s home page webtop.
7 - 42
Configuring content inspection

You can configure several kinds of functionality to provide content
inspection. These are provided as tabs on the Content Inspection screen. To
access the screen, in the navigation pane, click Portal Access, and click
Content Inspection, and then click one of the tabs.
• XSS scripting
Represents cross site scripting, a type of attack that gathers data from a
user for unauthorized use of security vulnerabilities in web applications.
You can use options on this screen to aid in preventing such attacks. For
more information, see Configuring cross site scripting security,
following.
• SQL injection
Represents the unauthorized process of introducing SQL commands in
the command string to gather database information. You can use options
on this screen to test for such activity. For more information, see
Configuring SQL injection scanning, on page 7-45.
• Buffer overflow
Represents a security vulnerability that, when exploited, allows for
running unauthorized code on the user’s computer. You can use options
on this screen to reduce the possibility of this type of activity. For more
information, see Configuring buffer overflow protection, on page 7-47.
• Antivirus
Represents the activity of detecting and preventing the introduction of
viruses onto the user’s computer. You can use options on this screen to
configure virus scanning and to check uploaded files for viruses. For
more information, see Configuring anti-virus scanning of uploaded files,
on page 7-48.
Configuring cross site scripting security

You can use the XSS scripting screen to specify cross site scripting (also
called CSS or XSS). To access the screen, in the navigation pane, click
Portal Access, click Content Inspection, and then click the XSS scripting
tab.
The FirePass controller aids in preventing cross site scripting attacks on
vulnerable web servers. This is done by scanning URL arguments and form
POST data sent by users through Web Applications, and blocking the
request if it looks suspicious.
Note
The FirePass controller user webtop and administrative console interfaces

are already protected against cross site scripting attacks.
A web site may inadvertently include malicious HTML tags or script in a

dynamically generated web page, based on unvalidated input from
untrustworthy sources. This can happen when a web server does not

Chapter 7
adequately ensure that generated pages are sufficiently encoded to prevent

unintended execution of scripts, and when input is not screened to prevent
malicious HTML from being presented to the user.
This vulnerability is used as the basis for cross site scripting attacks, and can
occur when a user relies on an untrustworthy source of information, such as
an external untrusted web site link or a link in an email message. For
example, an attacker may construct a malicious link such as:
<A HREF="http://siterequest.com/comment.cgi?mycomment=<SCRIPT>malicious
code</SCRIPT>">Click Here</A>
When a user clicks this link, the URL sent to siterequest.com includes
malicious code. If the web server returns to the user a page that includes the
value of mycomment, that is, if the web server does not properly filter user
input or generated output, a vulnerable client might be able to execute the
malicious code.
Scanning for suspicious characters

Options in the Restricting web site input to allowed character set section
instruct the FirePass controller to scan user input data for suspicious
characters such as less than ( < ) and greater than ( > ), and their
URL-encoded equivalents of %3c and %3d. The FirePass controller bases
the definition for suspicious characters upon a defined allowed character set.
The default match pattern is:
'[[:space:]+]*(;|or|union|select|insert|update|delete|drop|exec|having|shutdown|xp_).*--
If the operation detects any suspicious characters, the FirePass controller
blocks the user’s request.
The FirePass controller provides the following options for restricting input
to an allowed character set:
• Scan URL parameters for restricted characters
Inspects user input data in HTTP GET for suspicious characters within
URL arguments.
• Scan form POST data for restricted characters
Inspects user input data within URL-encoded form POST data for
suspicious characters.
• User defined allowed character set (advanced)
Provides an area for defining your own character set to use for scanning
URL arguments and form POST data. Checking this option populates the
box with the default list of characters, URL-encoded according to RFC
1738, which you can modify.
Scanning for embedded script code

Options in Scanning web site input for embedded script code instruct the
FirePass controller to scan user input data for suspicious strings such as
<SCRIPT and javascript: and their URL-encoded equivalents. The
FirePass controller bases the definition of suspicious strings on a defined
script search element list. If the scan detects any suspicious active elements,
the FirePass controller blocks the user’s request.
7 - 44
The FirePass controller provides the following options for scanning for
embedded code:
• Scan URL parameters for embedded script code
Inspects user input data for active elements such as scripts within URL
arguments.
• Scan form POST data for embedded script code
Inspects user input data within URL-encoded form POST data for active
elements, such as scripts.
• User defined script search elements (advanced)
Provides an area for defining your own search elements. For example,
you can modify the active element set of strings used for scanning of
URL arguments and form POST data. Checking this option opens a box
containing the default list of elements. You can modify this value or
define your own.
<script <object <applet <embed <form javascript: vbscript: mocha: livescript: about:
onload= onmouseover= text/javascript script> &{ url( expression(
Excluding sites from XSS scanning

You can also specify a comma-separated list of URLs to exempt from
scanning operations. In the Web site exceptions list section, you can use the
question mark ( ? ), which represents a single character. If the box is empty,
it means that the FirePass controller scans requests to all sites. For example,
if a particular intranet web site supports entering HTML tags, you should
exclude this site from URL argument and form POST data scanning.
Configuring SQL injection scanning

You can use the SQL injection screen to specify virus scanning and database
update options. To access the screen, in the navigation pane, click Portal
Access, click Content Inspection, and then click the SQL injection tab.
SQL injection exposures allow attackers to modify calls to backend
databases by adding to or manipulating SQL statements. To exploit a SQL
injection flaw, the attacker embeds malicious SQL commands into the
content of a parameter intended to be part of an SQL call. Consequences can
range from trivial to severe.
The web application is responsible for detecting and blocking these attacks.
However, the FirePass controller offers additional lines of perimeter defense
against injection attacks initiated in web applications accessed through
Portal Access.

Chapter 7
You can:
• Filter input URL parameters and form POST data for suspicious
characters
• Block requests with suspicious extended content.
Filtering for suspicious characters

Options in Filtering suspicious web site input instruct the FirePass controller
to scan and filter user input data for suspicious characters such as
apostrophe ( ’ ), number sign ( # ), double-dashes ( -- ), and semi-colons ( ; )
and their URL-encoded equivalents %27, %23, and %3b. (There is no
encoding for double-dashes.) Because valid web site input can contain these
characters, you might want to limit the web site match list or only enable the
more-specific blocking options in Blocking suspicious web site input,
following.
If the parser detects any of these characters, it removes the character from
the input string. It passes the rest of the string through to the application.
The FirePass controller provides the following options for filtering for
suspicious characters:
• Scan/filter URL parameters for suspicious characters
Inspects URL variables to determine the presence of suspicious
characters.
• Scan/filter form POST data for suspicious characters
Inspects form POST data to determine the presence of suspicious
characters.
• User defined block match regular expression (advanced)
Enables customization of the regular expression used in the filtering
operation. When you check this option, you can then modify the text
using standard regular expression (regex) syntax. You can restore the
default match pattern by clearing the option.
Note
This technique can prevent many attacks, but it also can result in many false
positives, and could alter valid input. For example, the name O'Hara would
be changed to OHara, and fail to match a valid record.
Blocking suspicious web site input

The blocking option performs a more sophisticated match for particular
types of SQL injection attacks, by identifying strings with complex
combinations. When the parser finds a match, it displays a warning and
blocks the page. The FirePass controller adds a warning message to the
FirePass System Log.
7 - 46
You can view and customize the default pattern by checking the User
defined block match regular expression (advanced) check box. You can
then modify the text using standard regular expression (regex) syntax. You
can restore the default match pattern by clearing the check box.
Specifying sites for SQL injection scanning

You can specify a comma-separated list of URLs to scan for SQL injection
attacks. In the Web site match list section, you can use the wildcard
characters asterisk ( * ), which represents many characters, and question
mark ( ? ), which represents a single character. If you select SQL injection
filtering or blocking and you leave this list empty, it means that the FirePass
controller scans all sites.
Configuring buffer overflow protection

You can use the Buffer overflow screen to specify virus scanning and
database update options. To access the screen, in the navigation pane, click
Portal Access, click Content Inspection, and then click the Buffer
overflow tab.
A buffer overflow attack is an attempt to corrupt the execution stack of a
web application by sending input that exceeds the length of the application’s
data buffer. By sending carefully crafted input to a web application, an
attacker could cause the web application to execute arbitrary code,
effectively taking over the machine. Even if the input string does not take
over the target system, an attacker can use a buffer overflow as a
denial-of-service attack.
Buffer overflow attacks exploit inputs of several types.
• Files uploaded using the Windows or UNIX file access features
• Form POST data input to web applications
• GET query strings input to web applications
Web applications, web servers, and the services they use all can contain
buffer overflow vulnerabilities. The best defense is to restrict the length of
any attempted input string to the appropriate maximum for the application.
While it is the responsibility of the application to parse input, you can
specify maximum levels for your environment, providing an outer perimeter
of defense against exploits such as these.
The FirePass controller provides the following options for applying buffer
overflow protection:
• Restrict maximum upload size (32-1024 Mb)
Constrains files that the user uploads to a specific size. The default value
is 32 MB.
• Restrict maximum length of a GET query string
Constrains the request string to the maximum specified. The default
value is 2048 bytes.

Chapter 7
• Restrict maximum length of POST data

Constrains the response string to the maximum specified. The default
value is 16384 bytes.
If you check the Restrict maximum length of a GET query string check
box or the Restrict maximum length of POST data check box, you can
also specify a comma-separated list of URLs to exclude from buffer
overflow checks. In the web site exceptions box, you can use the wildcard
characters asterisk ( * ), which represents many characters, and question
mark ( ? ), which represents a single character. If you specify buffer
overflow options and you leave this list empty, it means that the FirePass
controller checks input to all sites accessed through Portal Access.
Configuring anti-virus scanning of uploaded files

You can use the Antivirus screen to configure Portal Access to check
uploaded files for virus infections. To access the screen. in the navigation
pane, click Portal Access, click Content Inspection, and click the
Antivirus tab. When the antivirus feature is active, it scans files that are
uploaded using any of the following Portal Access functions:
• Windows Files
• Web Applications
• Mobile E-Mail
The FirePass controller provides the following options for checking

uploaded files for viruses:
• Disable virus scanning
Does not perform virus scanning of uploaded files. We recommend that
you only select this option if you are sure that you have another service
performing virus scanning.
• Enable ICAP client
Instructs the FirePass controller to act as an Internet Content Adaptation
Protocol (ICAP) client and use it for inspection using the response
modification mode. For more information, see Enabling the ICAP client,
following.
• Enable standalone virus scanner
Activates scanning using the standalone virus scanner, the Open Source
Clam Antivirus running locally on the FirePass controller. For more
information, see Enabling the standalone virus scanner, following.
Enabling the ICAP client

ICAP is an open standard for Internet proxy servers to communicate with
content servers. If your corporate antivirus protection is based on an
antivirus service that has ICAP capability, the FirePass controller can use an
ICAP client for upload inspection. When you select Enable ICAP Client
and click Update, the screen reveals additional options, in which you can
specify the host name, IP address, or path and port of the ICAP server.
7 - 48
You specify the path and port of the ICAP server using the following
format:
[icap: // ]<domain-name > [<:port >][/ path]
Following are some examples of how to specify the path and port of the
ICAP server:
• siterequest_domain.siterequest.com: Specifies the domain name.
• siterequest_domain.siterequest.com:1345: Specifies the domain name
and port.
• siterequest_domain.siterequest.com:1345/avscan: Specifies the
domain name, port, and path.
• siterequest_domain.siterequest.com/avscan: Specifies the domain
name and path.
• icap://siterequest_domain.siterequest.com:1345/avscan: Specifies the
ICAP protocol, domain name, port, and path.
Enabling the standalone virus scanner

You can use the default virus scanner, Clam AntiVirus, to detect viruses in
files uploaded during Portal Access connections. When you select Enable
Standalone Virus Scanner and click Update, the screen reveals additional
options.
In the Virus DataBase Update section, you can specify how to update the
virus scanning files. You can update the Clam AntiVirus database manually,
by periodically uploading database files, or automatically, by a process that
runs on the FirePass controller to periodically checks the Clam AntiVirus
site for database updates.
The Virus Database section shows the most recent updates for the Clam
AntiVirus database.
Configuring for manual update

Clam AntiVirus stores virus information in two files: main.cvd and
daily.cvd. These are available for download from the following sources:
• http://database.clamav.net/daily.cvd
• http://database.clamav.net/main.cvd
If you are using the manual update method, download these files to your
computer, and then upload them to the FirePass controller, using the Browse
button to locate the file.
Configuring for automatic update

When you select Automatic update and click Update, the FirePass
controller reveals additional options.
In Download site, you can specify a Clam AntiVirus mirror site. You can
select a site from http://www.clamav.net/mirrors.html, or specify
database.clamav.net (a round-robin record that allocates traffic among the
database mirrors). The default is database.clamav.net.

Chapter 7
The update process uses the HTTP protocol. You can specify the frequency
of updates (as the number of Updates per day), number of Retry attempts
to download an update, and, if you use an HTTP proxy, any needed proxy
parameters.
Note
The Clam AntiVirus feature is valid only for Portal Access connections.
7 - 50
Using the FirePass controller reverse proxy

The FirePass controller provides a reverse proxy implementation that
supports diverse applications, without the need for built-in SED scripting or
application-specific knowledge, although administrators can still use SED
scripts. Additionally, the reverse proxy engine employs reusable
components with an efficient interface between the FirePass controller and
parsers. Parsers can, however, run standalone in the FirePass controller or in
a TMOS plugin.
The major applications supported by the reverse proxy include:
• Microsoft Outlook Web Access (OWA)
• iNotes
• SharePoint
• Citrix
• MS Terminal Server
Common web pages supported by the reverse proxy include Google Maps,
CNN, and eBay.
Understanding client-server implementations

On the FirePass controller, parsers for HTML, CSS, and Javascript are
available. The reverse proxy includes pluggable parsers for the content types
CSS, VBS, HTML, and JavaScript. The reverse proxy determines the parser
to use based on MIME type and other criteria.
On the client side, there are also Javascript and HTML parsers.

Chapter 7
Figure 7.2 The reverse proxy client/server implementations
Understanding the reverse proxy

The FirePass controller reverse proxy primarily takes content from backend
servers and rewrites that content such that when presented to the browser,
the browser requests (generated from that content) are directed to the
FirePass controller. There are many ways this is achieved, but rewriting of
URLs is the most common and important mechanism. The portal takes
content and rewrites it for clientless access to web applications protected by
the FirePass controller. Specifically, the FirePass controller portal rewrites
content for two reasons:
• To make Intranet targets resolvable, no matter what the Intranet host is,
the request must go through the FirePass controller.
• To make all requests resolvable by the FirePass controller, FirePass
controller unambiguously decides where to proxy the request.
In the new reverse proxy implementation, the string /f5-w-<mangled
protocol://host:port> is prefixed to every HTML link or dynamic URL.
This provides the required multiplexing behavior on a single FirePass
controller.
For example, assume content from a server contains:
<a href=http://server.company.com/link.htm>Click Here</a>
7 - 52
In addition to URLs, cookies must be rewritten so that they are returned to

the server correctly. Rewritten cookies contain additional prefix information
that describes the path, domain, and protocol (HTTP or HTTPS) for the
cookie.
For example, an un-encrypted cookie on the client might look like this:
2f3A2e676f6f676c652e636f6d3A_PREF Sent
ID=f50c538aa75b7993:TM=1177442823
where 2f3A2e676f6f676c652e636f6d3 contains encoded information
describing the domain, path, and protocol, A_PREF is the cookie name, and
ID=f50c538aa75b7993:TM=1177442823 is the content of the cookie.
Understanding the reverse proxy and Flash

The reverse proxy includes a Flash™ patcher. The Flash patcher is able to
patch the content of HTML-formatted text fields that are static as if they are
dynamic, even if the content is set using bound variables, and even if the
content is loaded from a server to bound variables by means of a
getVariables action or method.
Flash patcher then unpatches the content of HTML-formatted text fields
before sending the information to a server.
Note
Flash patcher cannot patch Flash version 4. With version 4 Flash, the Flash
file is returned unpatched. Flash patcher cannot patch ABCScript, which
can exist in Flash version 9 or later. Version 9 and later Flash files with
ABCScript are returned unpatched.
Configuring the reverse proxy dynamic cache

The reverse proxy dynamic cache differs from the standard Apache
mod_proxy implementation. You can control the dynamic cache from the
FirePass controller Console : Portal Access : Caching and Compression
screen. Dynamic cache is enabled by default.
When resetting the cache, be sure to click the Clear cache button.

Chapter 7
Other dynamic cache default parameters include:

• Cache size is 200,000 * 1024 bytes
• Object expiration time is 1 hour
• Maximum expiration time is 1 day
• Last modified factor is 10 (with a range from 0-100)
• Garbage collection interval is 1 hour
The reverse proxy dynamic cache does not distinguish between static or
dynamic content. It does distinguish cacheable and non-cacheable objects, if
this is specified by the remote server (when an administrator configures
appropriate cache control HTTP headers). However, only the remote server
determines whether an object is to be cached, and only then does the
FirePass controller reverse proxy cache the object. Cached objects are
usually (if not specified otherwise) re-validated with the sending of a
conditional request to the remote server (if-modified-since). If there is a
short not modified response or a new modified object, the object is cached
or refreshed.
Note
If users request both compressed (GZIP) and non-compressed objects

simultaneously, both the compressed and non-compressed objects are stored
in cache for maximum performance.
To determine whether an object is from cache

If a response header contains the following designations, then the object is
from cache:
X-Cache: HIT from your.firepass.hostname
Note
X-Cache does not set for an http error 304 Not Modified response.
Troubleshooting reverse proxy issues

There are several tools available to analyze reverse proxy-related issues.
• Use the View Source option in the web browser section of the FirePass
controller console to perform a comparison of objects patched by the
FirePass controller. Perform this once through an intranet tunnel, and
then a second time directly through an Application Tunnel or SSL VPN
tunnel to see what has been patched by the FirePass controller.
• Use the Network packet dump option in the Server : Maintenance :
Low-Level screen on the FirePass controller console. The results display
TCPDUMP output of all traffic for a particular Ethernet interface.
7 - 54
• Use the Test Content Processing Settings link from the Portal Access :
Web Applications : Content Processing screen to fetch source material
directly for a particular page. This option also displays the source, and
displays any source changes made by applicable content processing
scripts.
• Use the HttpWatch from Simtec option to capture HTTP and HTTPS
traffic through Internet Explorer. The results can then be used to compare
traces through My Intranet or directly through an Application Tunnel or
SSL VPN tunnels.
• Use the Web Applications Engine Trace tool from the Device
Management : Maintenance : Debugging Tools screen to perform a
debug trace of the reverse-proxy that can be uploaded and viewed by
technical support.
It is common to use two sessions to troubleshoot a reverse proxy issue:
• one user session for which a problem exists
• a second administrator session to control the user session
To troubleshoot a reverse proxy issue:

1. The user opens a Web browser and logs on to the FirePass controller
as the user.
2. The admin opens a second Web browser and logs on to FirePass
controller as an administrator, then from the navigation pane, clicks
Device Management, expands Maintenance, and clicks
Troubleshooting Tools.
3. The admin scrolls down to the Web Applications Engine Trace
section (at page bottom) and enters the user logon name, then clicks
the Get user sessions button.
4. The admin selects the Connect link to the right of the session for
which troubleshooting is needed.
5. The user starts an application through the reverse proxy.
6. The admin reloads the troubleshooting page and clicks the Get user
sessions button again after the user encounters the problem with the
application under test.
7. The admin clicks Browse (or right-clicks and selects the Open in
new window option) to display the requests list, request log,
front-end, and back-end data.
8. The admin downloads all log data (for offline browsing) by clicking
the download link. A compressed zip file containing the logs is
downloaded. The admin then selects the index.html file inside the
zipped archive to view the logs using a Web browser.
The Web browser presents the data in a window divided into four
frames:
• At the top, the requests table displays the time, process ID, and
request line boxes. These are the requests handled by the reverse
proxy module.

Chapter 7
• In the middle, the request log displays the events that took place
during the reverse proxy session.
• At the bottom left, the front-end request/response for the
client-FirePass controller side displays.The request headers and
body appear, if present, and the response headers and body for
requests between the client and the FirePass controller also
appear.
• At the bottom right, the back-end request/response for the
FirePass controller-remote server side appears. This table
displays the request headers and body, if present, and the
response headers and body for requests between the server and
For every front-end request, one or more back-end request/response

combinations is possible (especially when HTTP authentication used).
Check the request log for links to other servers and other back-end
request/response entries. The response body (content) may be color-coded to
show how the reverse proxy interprets content and patches the content
accordingly.
You cannot toggle troubleshooting on and off for a session, but you can
finish the session, either by the user logging off, or by using the admin
console to force the user session to finish.
Using the URL decoder program

You can use the URL decoder program to decode URLs, and to determine
host information.
For example, an encoded URL appears as such:
https://firepass.com/f5-w
687474703a2f2f67726f7570732e676f6f676c652e636f6d$$/
/watched.gif
The decoder input is typed in the console, as follows:
dsmith@fpl:~$ ./decoder
687474703a2f2f67726f7570732e676f6f676c652e636f6d
And the response is:
decode: input len = 48
http://groups.google.com
To access the console, in the navigation pane, click Device Management,
expand Maintenance, click Troubleshooting Tools, and under Console
access, click the link Please click here to start a console session to the
Maintenance Account.
7 - 56
Using the Portal Access URL decryption tool

The FirePass controller Portal Access functionality works as a reverse
proxy, transforming and encoding HTTP or HTTPS URLs. The reverse
proxy rewrites content from servers, and this content includes the URL. The
reverse proxy encoded host names with strong cryptography, using the AES
standard. A rewritten URL appears in the following example.
<a href-http://firepass.company.com/f5-w-f5Hac4...$$/path...
F5 provides a Perl script, that employs openssl, to convert the rewritten part
of an encrypted host name to readable form. To decrypt the URL, you need
the rewritten part of the URL. This is everything between the f5-w-f5 and
the $$, or f5-w-f5H and the $$.
To perform a URL decryption conversion

Maintenance, click Troubleshooting Tools, and under Console
access, click the link Please click here to start a console session to
the Maintenance Account.
2. Run the hex.pl script on the mangle.
> hex.pl -dn
111a6bed4c78d73a7e5f31b5a699b799128dcd0d2050ee6cebfdf307c
c0ec65f > value
3. Use openssl to perform the decryption. Use the session ID as the

key, as specified in the -K parameter.
4. Use the following command to decrypt the hex of the URL mangle
using openssl:
> openssl enc -d -nosalt -aes-128-ecb \
-K 161e1ace26423f8de6287e9017951019 -iv "" -in value
>> cnn.com
URL Decryption Tool hex.pl Perl Script

#!/usr/local/bin/perl
use Getopt::Std( "getopts" );
getopts("nde", \%opts);
$in = shift;
if( defined $opts{ e } ) {
print HexEncode($in);
} elsif( defined $opts{ d } ) {
print HexDecode($in);
} else {
die "Usage: -e or -d string\n";
}
if( not defined $opts{ n } ) { print "\n"; }
sub HexEncode {
my $res = shift;
uc(unpack("H*",$res));

Chapter 7
}
sub HexDecode {
my $res = shift;
$res =~ s/([\da-fA-F]{2})/pack("C", hex($1))/ge;
$res;
}
To use the hex.pl Perl script

1. Obtain the FirePass controller session value (MRHsession) which
can be found as a cookie after authentication.
2. Obtain the rewritten URL of interest and copy the text.
[smith@zool ~]$
[smith@zool ~]$ cat mangle
fedb871db6c438cb1f286b8e3139d0e506626f1727f9b2da0d65ae160
336f843
[smith@zool ~]$ cat sess
a5281af11c313f41200c0d9a30a492ac
[smith@zool ~]$ cat dehex
./hex.pl -dn
fedb871db6c438cb1f286b8e3139d0e506626f1727f9b2da0d65ae160
336f843 > value
[smith@zool ~]$ cat decrypt
openssl enc -d -nosalt -aes-128-ecb -K
a5281af11c313f41200c0d9a30a492ac -iv "" -in value
[smith@zool ~]$
[smith@zool ~]$ ./dehex
[smith@zool ~]$ ./decrypt
http://i.a.cnn.net
[smith@zool ~]$
[smith@zool ~]$
3. Decyrpt the URL, as in the previous procedure.
Using the reverse proxy and proxy bypass

The FirePass controller Bypass features are disabled for the reverse proxy.
In some situations, difficult intranet applications may be passed through a
reverse-proxy bypass mode which can apply a one-to-one mapping between
either of the following:
• A URL pattern and an internal intranet host
• A dedicated FirePass controller web service on an alternate port and an
internal host
7 - 58
The advantages of this special mode of operation are that cookie processing
is greatly simplified, although cookie pass-through should be explicitly
enabled if necessary for a given site. This must be done manually if using
bypass mode for a site, as automatic cookie pass-through is not supported
with bypass mode.
Another advantage is that there is no longer a need to prefix every HTML
link or dynamic URL with a mangled string to encode the internal
destination host and port. Since there is less mangling (only the host name
and port are re-written), there is less chance for incompatibilities.
Note
Applications must be resident on a single target server; distributed

applications cannot be managed with the reverse proxy bypass feature.
Using the reverse proxy and Portal Access tools

Portal Access tools are also available for troubleshooting the FirePass
controller Fire Monkey engine.
Using HTTPwatch for Internet Explorer

HTTPwatch is a useful tool for troubleshooting FirePass controller for
Internet Explorer only. It provides information about how the browser is
interacting with the FirePass controller and it is a very detailed tool. You can
use the F5 corporate license for this tool and download HTTPwatch from:
http://www.simtec.ltd.uk
Using livehttpheaders for Mozilla/FireFox

The tool livehttpheaders is a Mozilla plugin that allows you to view HTTP
headers. It provides a Web Development menu from the Tools menu. This
utility allows you to replay a session to a webserver.
Access this utility through mozdev.org at
http://livehttpheaders.mozdev.org
Using the reverse proxy and SED script support

SED scripts on the FirePass controller are normally used in the following
form:
s/regexp/replacement/flags
Use the following formatting rules in FirePass controller-supported SED
scripts:
• The slash [ / ] character may be uniformly replaced by any other single
character within any given s command.
• The / character (or whatever other character is used in its stead) can
appear in the regexp or replacement only if it is preceded by a \
character.

Chapter 7
• New lines may appear in the regexp using the two character sequence \n.
The s command attempts to match the pattern space against the supplied
regexp. If the match is successful, then that portion of the pattern space
that was matched is replaced with replacement. The replacement can
contain \n references (where n is a number from 1 to 9, inclusive), and
which refers to the portion of the match that is contained between the nth
\ (and its matching \). Also, the replacement can contain unescaped &
characters that reference the whole matched portion of the pattern space.
To include a literal \, &, or newline in the final replacement, be sure to
precede the desired \, &, or newline in the replacement with a \. The s
command can be followed with zero or more of the following flags:
• g - applies the replacement to all matches to the regexp, not just the
first instance)
• number - replaces only the number-th match of the regexp.
For more information about SED scripts, refer to the following resources:
• http://www.dbnet.ece.ntua.gr/~george/sed/sedfaq.html
• http://www.ptug.org/sed/sedfaq.htm
• http://www.wollery.demon.co.uk/sedtut10.txt
7 - 60
8
Managing and Monitoring the FirePass
Controller
• Maintaining the FirePass Controller
• Configuring global FirePass controller settings
• Maintaining the network configuration settings
• Using realms
• Completing other configuration activities
• Performing maintenance
• Monitoring the FirePass controller
• Customizing the user’s webtop
• Configuring for multiple languages

Maintaining the FirePass Controller

You can perform a number of tasks to ensure that the FirePass controller is
monitored and maintained so that it provides the best performance possible.
You can also customize and configure the FirePass controller and tailor it to
your needs based on your networking environment.
Some of the tasks you can perform include the following:
• Configuring global FirePass controller settings
You can configure a number of different global settings such as Admin
E-Mail, network configuration, SMTP server, and many more. For more
information on this task, refer to page 8-2.
• Maintaining the networking configuration settings
You can configure the FirePass controller’s network interface, IP
addresses, routing tables, and so forth. For more information on this task,
refer to page 8-3.
• Using realms
You can configure full access realms, real-specific settings, realm-level
group access setting, and many more. For more information on this task,
refer to page 8-29.
• Completing other configuration activities
You can configure other administrate-level functionality such as
configuring RSA SecurID server, SNMP agent HTTP and SSL proxies,
and many more. For more information, refer page 8-34.
• Performing general maintenance
You can activate licenses, backup and restore you configuration, restart
services, use troubleshooting tools, and many others. For more
information on this task, refer to page 8-45.
• Monitoring the FirePass controller
You can view statistics, system health information, load statistics and
many others. For more information on this task, refer to page 8-66.
• Customizing user’s webtop
You can customize the appearance and functionality of the user’s
webtop. For more information on this task, refer to page 8-70.
• Configuring multiple languages
You can set up multi-language support for the FirePass controller. For
more information on this task, refer to page 8-71.

Chapter 8
Configuring global FirePass controller settings

The FirePass controller has several kinds of global settings. The global
settings presented in this chapter cover the kinds of maintenance activities
that you probably set only once or change infrequently. These are organized
into the following areas:
• Admin E-Mail
For more information, see Configuring Admin E-mail, on page 8-34.
• Network Configuration
For more information, see Maintaining the network configuration
settings, on page 8-3.
• New Browsers
For more information, see Adding definitions for other types of browsers,
on page 8-35.
• RSA SecurID
For more information, see Configuring a new RSA SecurID
authentication server (for native RSA authentication), on page 8-36.
• SMTP Server
For more information, see Specifying the SMTP email server, on page
8-40.
• SNMP
For more information, see Configuring an SNMP agent, on page 8-41.
• Proxies
For more information, see Specifying HTTP and SSL proxies, on page
8-42.
• Time
For more information, see Specifying the time, time zone, and NTP
server, on page 8-43.
8-2
Maintaining the network configuration settings

Network configuration is the process of setting up the FirePass controller’s
network interfaces, IP addresses and corresponding netmasks, routing tables
and routing policies, Domain Name System (DNS) servers, static host name
mappings, web services, and other IP-to-service assignments. You configure
web services to allow communication with FirePass controller for the
following purposes:
• Administrator access to the Administrative Console
• User logon for access to FirePass controller features
• An HTTP server that redirects users to a secure logon page
• Failover pair and cluster synchronization
• Offloading SSL to a BIG-IP® Local Traffic Manager
If you are configuring a failover pair or a cluster member, you also need to
configure an HTTP service for the synchronization agent. For more
information about failover configuration, see Understanding FirePass
controller high availability, on page 11-1. For more information about
clustering configuration, see Configuring FirePass controller clusters, on
page 12-3.
To access network configuration settings

1. On the navigation pane, click Device Management, expand
The Network Configuration screen opens with the IP Config tab
selected.
2. Click the tab whose settings you want to specify.
• Interfaces: Provides settings for configuring connections on the
physical ports on the FirePass controller device, such as interface
speed and duplex. For more information, see Understanding the
Interfaces tab settings, on page 8-6.
• VLAN: Provides settings for configuring VLAN tags and
interfaces. For more information, see Configuring VLAN settings,
on page 8-9.
• IP Config: Provides settings for adding, modifying, or deleting
IP addresses to interfaces. For more information, see Configuring
IP addresses and subnets, on page 8-9.
• Routing: Provides settings for determining how the FirePass
controller should forward IP traffic. For more information, see
Configuring routing tables and rules, on page 8-11.
• DNS: Provides settings for configuring DNS servers that the
FirePass controller uses. For more information, see Configuring
DNS, on page 8-18.

Chapter 8
• Hosts: Provides settings for configuring the fully qualified

domain name (FQDN) for the FirePass controller, and for
specifying entries the FirePass controller should add to its static
host name mapping file. For more information, see Configuring
host names, on page 8-19.
• Web Services: Provides settings for configuring web services,
and for managing SSL server certificates. For more information
about web service configuration, see Configuring web services,
on page 8-20, and for more information about SSL server
certificates, see Understanding SSL server certificates, on page
4-1.
• Misc: Provides settings for configuring which IP source
addresses FirePass controller should use for other various
functions. For more information, see Configuring other network
settings, on page 8-25.
3. When you make configuration additions, edits, or deletions, a
Finalize tab appears. No additions, edits, or deletions take effect
until you click the Finalize tab and follow the instructions for
committing the changes. Some changes require a restart of the
FirePass controller. For more information, see Changing network
configuration settings that require restart, on page 8-5.
Understanding the finalization process

Some changes to web services settings require a restart of the FirePass
controller as part of the finalize process. When you complete the finalize
operation, the new configuration becomes effective immediately, unless the
change requires a system restart. In that case, the FirePass controller
prompts you to restart the system. You can cancel the restart operation, but
the system cannot commit your changes until you restart the FirePass
controller.
All of the settings and operations described in this section refer to options
available in tabs on the Network Configuration screen. To access the screen,
click Device Management, expand Configuration, and click Network
Configuration. Then click the tab indicated in the section to find the
associated options.
Changing network configuration settings that do not require restart

You can finalize changes without restarting the FirePass controller for any
of these changes on these tabs:
• VLAN tab
• Add, modify, and delete new or existing VLANs
• Assign IP addresses to new VLANs
• Routing tab
• Add, modify, and delete new or existing routing tables
8-4
• Add, modify, and delete new or existing routes in routing tables

• Add, modify, and delete new or existing routing rules
• Hosts tab
• Add, modify, and delete new or existing static Hosts entries
• Misc tab
• Any change on the Misc tab
• IP Config tab
• Add, modify, and delete the IP address of an existing interface or
VLAN
Important
If there is a web service running on the interface or VLAN, then you must
restart the system. If there is no web service associated with the IP address
being changed, then you do not need to restart it.
You can make some other IP configuration changes without restarting the
FirePass controller, but some of the changes require one. For changes that
require a restart, the FirePass controller posts a prompt. For more
information, see Changing network configuration settings that require
restart, following.
Changing network configuration settings that require restart

You must restart the FirePass controller as part of the finalize process when
you make any of the changes listed here:
• Interfaces tab
Any change to the interface options
• DNS tab
Any change to the DNS options
• Web Services tab
Any change to the web service configuration options
• Failover tab
Any change to the failover configuration options
• Clustering tab
Any change to clustering configuration options
• Hosts tab
Changing the host name of the FirePass controller, if you have enabled
failover

Chapter 8
Understanding the Interfaces tab settings

You can use settings on the Interfaces tab to specify the functionality of the
physical ports into the FirePass controller. Each port is an independent
network interface that you must connect to separate subnets. The number
and types of ports available varies, depending on the FirePass controller
model you have.
You can determine which ports you have on the Interfaces screen. To access
the screen, in the navigation pane, click Device Management, expand
Configuration, click Network Configuration, and click the Interfaces tab.
In addition to the built-in ports, the FirePass controller may also have
VLAN interfaces defined. You can find additional configuration options on
the Interfaces tab for these logical interfaces. For more information about
VLAN configuration, see Configuring VLAN settings, on page 8-9.
Important
Any additions, deletions, or configuration changes you make do not take
effect until you commit them using the Finalize tab. Some configuration
changes require that you restart the FirePass controller for them to take
effect. For more information, see Changing network configuration settings
that require restart, on page 8-5.
Shared MAC addresses

If the FirePass controller uses a shared MAC address, we recommend that
you connect each FirePass controller network interface to a separate Layer 2
(data link layer) network segment. To do so, use one of the following
methods:
• Ensure that the FirePass controller network interfaces do not connect to
the same Layer 2 device (physical separation), provided that the Layer 2
devices do not share MAC address tables.
• Connect the FirePass controller network interfaces to a single Layer 2
device, and configure the Layer 2 device to use a separate VLAN for
each connection (virtual separation), provided that the switch supports
per-VLAN MAC address tables.
Important
If you deploy a FirePass platform that uses a shared MAC address, and you
do not use physical or virtual separation to segment traffic, you may
experience packet loss when accessing the FirePass controller.
Table 8.1 lists MAC address assignment information for each FirePass
controller.
8-6
Platform MAC address assignment
FirePass 1000 Each network interface has a unique

MAC address.

MAC address.

MAC address.
FirePass 4100 The management interface has a unique

MAC address.
The other network interfaces share a
single MAC address.
FirePass 4300 The management interface has a unique

MAC address.
The other network interfaces share a
single MAC address.
Table 8.1 MAC address assignment
Specifying ports for the FirePass 4100 and 4300

The FirePass 4100 and 4300 platforms provide the following network ports:
• The Management port, called Management in the Configuration utility,
provides a direct connection to the FirePass 4100 or 4300 controllers on
the Administrative Console. The Management port runs only
administrative services.
• There are four 1-gigabit ports available on the FirePass 4100 and 4300
platforms. These are labeled 1.1 to 1.4 on the controller chassis, and
eth1.1 - eth1.4 in the Configuration utility.
The eth1.1 port connects the FirePass 4100 or 4300 platforms to your
main network. The eth1.1 port runs user and administrative services.
We recommend that you use eth 1.1 to connect to your network.
You can use the eth 1.2, eth1.3, and eth 1.4 ports for other purposes, or
for additional segmentation as required by your network.
Note
There are two additional ports available on the FirePass 4300 platform.
These fiber ports are labeled 2.1 and 2.2 on the controller chassis, and
eth 1.21 and eth 1.22 in the configuration interface. These ports provide
direct connections to a LAN, or to additional services such as dedicated
clustering, failover synchronization, or DMZ use. Additionally, you can also
run primary user and administrative servers on these ports. You must install
a small-form-factor pluggable (SFP) into the ports to enable them.

Chapter 8
Specifying ports for the FirePass 4000

The FirePass 4000 platform provides the following network ports:
• The WAN port (PCI Ethernet card), called eth0 in the Configuration
utility, connects the FirePass controller to the WAN.
You can use eth0 as a WAN port to connect to the Internet. We
recommend that you use eth0 to connect to your network. The eth0 port
is a 10/100 mbit port that is not labeled on the controller chassis.
• The LAN port (the left port of the pair of ports), called eth1 in the
Configuration utility, connects the FirePass 4000 to your main network.
The LAN port runs user and administrative services.
The eth1 port is a 10/100 megabit port that is not labeled on the
controller chassis.
• You can use the right port of the pair of ports, called eth2 in the
Configuration utility, for another purpose, or for additional segmentation
as required by your network.
The eth2 port is a 10/100/1000 mbit port that is not labeled on the
controller chassis.

The FirePass 1200 platform provides two 10/100 megabit ports. These are
labeled 1 and 2 on the controller chassis, and Port1and Port2 in the
Configuration utility.
• The Port 1 port is used for primary user and administrative services. Use
this port to connect the FirePass controller to your network.
• The Port 2 port provides a direct connection to additional services, such
as failover synchronization, DMZ use, or for protecting your wireless
LAN.

The FirePass 1000 platform provides the following network ports:
• The WAN port, called eth0 in the Configuration utility, provides a direct
connection to the FirePass 1000’s Administrative Console. The WAN
port runs only administrative services.
• The LAN port, called eth1 in the Configuration utility, connects the
FirePass 1000 to your main network. The LAN port runs user and
administrative services.
• You can use the DMZ port, called eth2 in the Configuration utility, to
connect to additional services, such as failover synchronization.
8-8
Configuring VLAN settings

On the FirePass controller, you can configure virtual local area networks
(VLANs). Segmenting computers into VLANs has many advantages.
◆ Flexible configuration
VLANs are configured through software rather than hardware, which
makes them extremely flexible.
◆ Subnet-to-user-group mapping
Using VLANs, you can map incoming Network Access connections to
different VLAN subnets, based on the user’s master group.
◆ Performance improvement through broadcast domain restriction
Using VLANs reduces the size of broadcast domains, so requests for
MAC addresses can be handled within a smaller IP address space.
◆ Simplified administration
One of the biggest advantages of VLANs is that when a computer is
physically moved to another location, it can stay on the same VLAN
without any hardware reconfiguration.
For example, if the controller is connected to a VLAN-enabled Ethernet
switch on which two servers are connected on separate VLANs, you can
direct Group A to VLAN1-Server1, and Group B to VLAN2-Server1,
even if the two servers have the same IP addresses internally. In other
words, accessing the same IP address over Network Access connects
members of different groups to different physical servers in different
VLANs.
When you create a VLAN, you assign it a unique name and an identifying
tag that confirms to IEEE802.1Q standards. (The valid tag ranges are from 2
to 2010 and from 2015 to 4094.) Then you associate one or more FirePass
controller physical interfaces to the VLAN. The VLAN uses this interface
when communicating with other computers on the VLAN.
You can create associations for master group-to-VLAN Network Access
connections to limit packets to specific VLANs. That means that you can
configure a service on a specific IP address, and then specify that users’
group membership direct them to different physical servers.
For specific steps, see the online help for the Network Configuration screen.
To access the screen, click Device Management, expand Configuration,
click Network Configuration, and click the VLAN tab.
Configuring IP addresses and subnets

A FirePass controller can be a member of several subnets, and it can have
several digital certificates. For those and many other reasons, it may need
more than one IP address. You can assign multiple IP addresses to each
interface.

Chapter 8
To add, change, or delete the IP address and configure

subnets
The Network Configuration screen opens.
2. Click the IP Config tab.
The IP Config screen opens.
3. In the Add New IP area of the screen, add new IP addresses and
netmasks.
4. In the IP Configuration table, edit or delete existing IP addresses.
For each IP address, you can specify or edit the following settings:
• IP Address/Netmask
Enter the IP address in dotted-decimal notation, and the subnet
mask in CIDR notation. (Specify the netmask as the number of
bits to be masked.) For example, in dotted-decimal notation,
255.255.255.128 corresponds to a mask of 25.
For a table mapping bits notation to dotted-decimal and
hexadecimal notation, see online help for the IP Config screen.
(For access, click Device Management, expand Configuration,
click Network Configuration, and click the IP Config tab.)
• Interface
Indicate the interface associated with the IP address.
• Virtual
Indicates that this is a shared, virtual IP address.
The Virtual option is present only if you have failover enabled
on the Device Management : Configuration : Clustering and
Failover screen. Pairs of FirePass controllers configured for
failover share a virtual IP address, which enables the standby
controller to take over from the active controller if the active
controller fails, preventing interruption to remote client systems.
For more information, see Understanding FirePass controller
high availability, on page 11-1.
• Broadcast
Indicates the IP address the FirePass controller uses to send
broadcast messages. This is an optional setting. If you do not
specify a broadcast IP address, FirePass controller calculates a
default broadcast address from the IP address and mask.
5. When you are finished configuring IP addresses, click the Finalize
tab to commit your changes. The FirePass controller does not apply
the changes until you have finalized the configuration and restarted
the FirePass controller, if necessary.
WARNING
Be extremely careful when changing the FirePass controller’s IP
configuration settings. If you enter incorrect settings, the FirePass
controller might become inaccessible from the network. If the FirePass
8 - 10
controller becomes inaccessible, you must use the Maintenance Console to

reset the FirePass controller’s configuration to the default settings. For
more information, see the FirePass Controller Getting Started Guide,
available as a separate document on the F5 Networks Technical Support
Web site, https://support.f5.com.
Configuring routing tables and rules

You can use the Routing tab on the Device Management : Configuration :
Network Configuration screen to add entries to the FirePass controller
routing table.
The Routing screen has two modes:
• light, where you can maintain the main routing table
For more information, see Using light mode to configure routing tables,
following.
• advanced, where you can add and maintain additional routing tables, and
you can maintain routing rules
For more information, see Using advanced mode to configure routing
tables and rules, on page 8-13.
Using light mode to configure routing tables

You can use light mode to modify the default gateway, and to add one or
many routes to the main routing table.
Adding one route in light mode
To add a single route in light mode

Configuration, click Network Configuration, and click the
Routing tab.
2. Specify the default gateway.
The role of the default gateway is to provide the next-hop IP address
and interface for all destinations that are not located on one of the
controller’s local subnets, or for remote subnets that have an explicit
static route defined. In other words, the default gateway is used to
create a default route that directs packets addressed to networks not
explicitly listed in the routing table. This step is optional.
3. In the To (IP/Len) box, specify the destination IP address and
netmask.
Format IP addresses as dotted-decimal/length, for example
128.146.1.0/24

Chapter 8
The Netmask (Len) is always expressed in bits notation. (That is,

the netmask is expressed as the number of bits to be masked.) For
example, a bits count of 25 corresponds to a mask of
255.255.255.128 in dotted-decimal notation.
If you specify all zeros in To (IP/Len), that is, 0.0.0.0/0, the
FirePass controller applies that route to any packet whose
destination IP address does not match that of another route.
For a table mapping bits notation to dotted-decimal and
hexadecimal notation, see the online help for the Routing screen. To
access the screen, click Device Management, expand
Routing tab.
4. In Metric, specify the number to use, from 1 to 15.
The number indicates the cost of the route, specified in number of
hops. You can represent computers on the local subnet by
specifying the number 1. For each router crossed after that, add one.
The value helps the FirePass controller determine which route to use
in the case of multiple, closest-matching routes to the same
destination address. For multiple routes to the same destination, the
route with the lowest cost metric is the most preferred route. This
step is optional.
5. From the Interface list, select the interface you want the FirePass
controller to use for the outgoing traffic.
Interface contains a list of all of the physical ports, <default>, lo,
and any VLANs you have configured. This step is optional. For
information about physical ports, see Specifying ports for the
FirePass 4100 and 4300, on page 8-7, Specifying ports for the
FirePass 4000, on page 8-8, Configuring VLAN settings, on page
8-9, or Specifying ports for the FirePass 1000, on page 8-8, as
appropriate.
6. In Via (IP), specify the gateway IP address.
7. From the Src (IP) list, select the Source IP address.
A blank source or destination IP address or Interface acts as a
wildcard and signifies all. This step is optional.
8. If this is a failover unit, select the For mode (Active Only, Standby
Only, or Always) during which this route is used. For definitions of
each option, see To configure a service, on page 8-22.
If you are deploying the FirePass controller in a failover
configuration, and you need the controller to use a shared IP address
as the source IP address for all the outgoing traffic from the FirePass
controller, you must specify two different default routes:
• One route for the active unit, using the redundant system’s shared
IP address. For this configuration, select the shared IP address as
the Src IP and Active Only as the mode. This causes the active
FirePass controller to always use the shared IP address as the
source IP address for all outgoing packets.
8 - 12
• Another route for the failover (or standby) unit, using the unit’s
device-specific, self IP address. For this configuration, select one
of the self IP addresses as the Src IP and Standby Only as the
mode. This causes the standby FirePass controller to use the self
IP address as the source IP address for all outgoing packets.
For more information about configuring web services for failover,
see Understanding FirePass controller high availability, on page
11-1.
9. In MTU and Window (Bytes), specify the size of the largest packet
to transmit.
The Maximum Transmission Unit (MTU) is a term for the
maximum number that represents the largest packet size allowed in
a single transmission. Windows (Bytes) represents the number of
bytes a sender can transmit without receiving an acknowledgement.
It is related to the size of the receiving buffer. This step is optional.
10. Click the Add route button.
The presence of an asterisk ( * ) next to a setting name denotes a required

value.
Adding many routes in light mode

For convenience, you can add any number of blank lines to a routing table
and then edit them as a group.
To add multiple routes in light mode

Routing tab.
2. In Count, specify the number of routes you want to add.
3. Click Add many routes.
4. Once you have added the rows you want, you can edit the values
directly in the table, and click the Update button to have the
modifications take effect.
Using advanced mode to configure routing tables and rules

You can use advanced mode to add one or many routes to any routing table,
to add and delete routing tables, and to add and delete routing rules.

Chapter 8
Adding one route in advanced mode
To add a single route in advanced mode

Routing tab.
2. Select the table you want to modify from the Insert into table list.
3. In the To (IP/Len) box, specify the destination IP address and
netmask.
Format IP addresses as dotted-decimal/length, for example
128.146.1.0/24
For more information about IP address format, see step 3, on page
8-11, in the preceding procedure.
4. In Metric, specify the number to use, from 1 to 15.
For more information about the Metric option, see step 4, on page
5. From the Interface list, select the interface you want the FirePass
controller to use for the outgoing traffic.
Interface contains a list of all of the physical ports, <default>, lo,
and any VLANs you have configured. This step is optional. For
information about physical ports, see Specifying ports for the
FirePass 4100 and 4300, on page 8-7, Specifying ports for the
FirePass 4000, on page 8-8, Configuring VLAN settings, on page
8-9, or Specifying ports for the FirePass 1000, on page 8-8, as
appropriate.
6. In Via (IP), specify the gateway IP address.
7. From the Src (IP) list, select the Source IP address.
A blank source or destination IP address or Interface acts as a
wildcard and signifies all. This step is optional.
8. If this is a failover unit, select the Failover mode (Active Only,
Standby Only, or Always) during which this route is used.
For more information about this option, see step 8, on page 8-12, in
the preceding procedure, For more information about configuring
web services for failover, see Understanding FirePass controller
high availability, on page 11-1.
9. In MTU and Window (Bytes), specify the size of the largest packet
to transmit.
For more information about the Metric option, see step 9, on page
10. Click Add route.
The presence of an asterisk ( * ) next to a setting name denotes a required

value.
8 - 14
Adding many routes in advanced mode

For convenience, you can add any number of blank lines to a routing table
and then edit them as a group.
To add multiple routes in advanced mode

Routing tab.
2. Click the Switch to advanced mode link to switch to the advanced
routing mode.
The Advanced Routing Mode screen opens.
3. In the Add many empty routes area, select the table you want to
modify from the Insert into table list.
4. In the Count box, specify the number of routes you want to add.
5. Click Add many routes.
6. Once you have added the rows you want, you can edit the values
directly in the table, and click the Update button to have the
modifications take effect.
Editing and deleting routes in advanced mode

If you are in light mode, switch to advanced mode by clicking the Switch to
advanced mode link.
To edit a route, change the value in the table and click the Update button.
To delete a route, check the check box to the left of the route or routes you
want to delete, and click the Delete Selected button at the bottom of the
table.
Adding, editing, and deleting routing tables in advanced mode

You can add up to 252 routing tables. The kernel reserves tables 254 and
255, and the FirePass controller reserves table 253. You can add tables 1
through 252. Routing table lookup order depends on IP rules priority, and
and does not rely on the routing table number.
To add a routing table

Routing tab.
routing mode.
3. Scroll down to the Add new routing table area.

Chapter 8
4. In the Name box, type the string to use to identify the routing table.
Routing table names can contain up to 512 alphanumeric and
underline ( _ ) characters. The string you specify cannot match the
name of an existing table.
5. In the Number box, specify a number from 1 to 252.
6. Click Add New.
To edit a routing table

Routing tab.
routing mode.
3. Click the link to display the routing tables.
4. Change directly in the table the value for To (IP/Len), Metric,
Interface, Via (IP), Src (IP), MTU, or Window (bytes), as
described in the preceding procedure.
The presence of an asterisk ( * ) denotes a required value.
5. Click Update.
To delete a table
Routing tab.
routing mode.
3. Click the link to display the routing tables.
4. Click Delete to the right of the table you want to delete.
WARNING
Routing table deletion occurs immediately, without a confirmation alert, so
be sure you are ready to delete the table when you click the Delete button.
Adding routing rules in advanced mode

You can specify rules that manage which routing tables to use, and in what
order, for particular routes or groups of routes. A blank source or destination
IP address signifies that the FirePass controller routs all incoming traffic.
8 - 16
To add a rule
Routing tab.
routing mode.
3. In the From box, type the source IP address and netmask.
The FirePass controller applies the rule to incoming IP packets
matching the address and netmask specified.
4. In the To box, type the destination IP address and netmask.
The FirePass controller applies the rule to outgoing IP packets
matching the address and netmask specified.
5. From the Interfaces list, select the interface you want the FirePass
controller to apply the rule to.
Available interfaces include all of the physical interfaces and any
defined VLANs.
6. In Table, specify the target routing table for this rule.
When an incoming IP packet matches this rule, it is routed as
specified in this table.
7. In Priority, specify a number from 0 to 32765, with lower numbers
representing higher priority for this rule. The FirePass controller
assigns the main table the number 32766, and assigns the default
table the number 32767.
The value in the Priority box controls the order in which the
FirePass controller applies the rules. The lower the number, the
higher the priority, and the earlier the rule is evaluated during the
routing operation. The FirePass controller routes the traffic
according to the first match in the table.
8. Click Add New.
Editing and deleting routing rules in advanced mode

You can edit rule values directly in the rules list.
To edit routing rules

Routing tab.
routing mode.
3. Scroll to the Rules area of the screen.

Chapter 8
4. Directly in the list, change the value for To, From, Interface,
Table, and Priority, as described in To add a rule, preceding.
The presence of an asterisk ( * ) denotes a required value.
5. Click Update Table.
To delete a routing rule

Routing tab.
routing mode.
3. Scroll to the Rules area of the screen.
4. Check the Select box to the left of the rule or rules you want to
delete.
There is no Select box next to the predefined rules, identifiable by
the priority values of main: 32766 and default: 32767, because you
cannot delete these rules.
5. Click Delete Selected at the bottom of the list.
Configuring DNS
You can configure the IP addresses of the DNS you want the FirePass
controller to use. You also can specify the FirePass controller’s default
domain suffixes.
To configure the DNS

Configuration, click Network Configuration, and click the DNS
tab.
The DNS configuration screen opens.
2. In the Name Servers area of the screen, specify the IP addresses of
up to three DNS servers.
3. In the Default domain suffixes area of the screen, specify up to six
domain suffixes.
The FirePass controller uses these values to resolve incomplete
domain names. For example, if the domain suffix list contains the
entries f5.com and com, and a user submits the URL
http://www.support, the controller resolves the host names in the
following order:
http://www.support
http://www.support.f5.com
http://www.support.com
8 - 18
4. In the DNS Cache area of the screen, check the Enable DNS cache
box.
The FirePass controller uses this value to cache the controller results
of the DNS requests. This provides an increase in controller
performance.
5. Click Update.
Important
effect until you commit them using the Finalize tab.
Configuring host names

You can specify the fully qualified domain name (FQDN) of the FirePass
controller, add, edit, and delete static host names.
Important
effect until you commit them using the Finalize tab.
Specifying the FirePass controller’s FQDN

The FQDN specified here serves only to provide the unique identification of
the FirePass controller. Changing this box does not lead automatically to
any changes anywhere else (for example, web services configuration).
To configure the FQDN

Configuration, click Network Configuration, and click the Hosts
tab.
The Hosts configuration screen opens.
2. In FQDN of the controller, specify the fully qualified domain
name, for example
fp4100.sales.siterequest.com
Note: Both nodes of a redundant system must have the same FQDN.
3. Click Update.
Adding, editing, and deleting static host names

The FirePass controller stores static host names in a local table, and uses
them to augment or override the configured DNS. The FirePass controller
uses the local table to locate an IP address for a domain name, before
consulting the DNS.

Chapter 8
To add a static host name

Configuration, click Network Configuration, and click the Hosts
tab.
The Hosts configuration screen opens.
2. In Hostname, type the name of the static host.
3. In IP, type the IP address of the static host.
4. Click Add New to add the name to the list of local host names.
Configuring web services

A web service is a method of communication that applications written in
various programming languages and running on various platforms can use to
exchange data over networks, such as the Internet or an intranet. You can
configure web services for several classes of operation:
• User logon and functionality
You must have at least one service configured to allow User access.
• Administrator logon
You must have at least one SSL-enabled service configured to allow
Administrator access.
• Web access bypass
• Offloading SSL to a BIG-IP Local Traffic Manager
• Synchronization among clustered and failover units
If you have a clustering or failover configuration, you must configure for
use by the Synchronization Agent, at least one service that is not
redirected to an SSL service.
You can configure services to use different roles and different ports,
although they might also share roles and ports. A service consists of any
distinct combination of roles, functionality, and IP address/port assignment.
Understanding services configuration

You can configure services using options on the Network Configuration
screen. The screen presents a list of the currently configured services. You
can also add new web services. To view or modify current settings for a web
service, click its associated Configure link. The Web Server Configuration
details screen opens. For information about adding a service, see To add a
service, following. For descriptions of each configuration option, see To
configure a service, on page 8-22.
8 - 20
The Services column of the table of web services contains one or more of
the codes described in Table 8.2.
Code Meaning You must configure
A Configured to allow administrator access At least one
B Configured for WebAccess Bypass Optional
E Configured to offload SSL processing to Optional

BIG-IP system
S Configured as a synchronization port At least one, if you have

failover or clustering
configured
U Configured to allow user access At least one
Table 8.2 Web services codes and roles
Note
If you plan to configure clustering or failover, you must configure a service

for the Synchronization Agent to use. This service must allow HTTP access
and not redirect to an SSL service, so you do not typically use the same
service for synchronization and for user access. For more information, see
Chapter 11, Using FirePass Controllers for Failover, and Chapter 12,
Using FirePass Controllers in Clusters.
To add a service
The Web Services screen opens.
3. Scroll to the Add new service area.
4. From the list of IP addresses configured for the FirePass controller,
select the IP address to use for the new service.
You can add IP addresses using options on the IP Config tab. For
more information, see Configuring IP addresses and subnets, on
page 8-9.
5. In Port, specify the port to use for this service.
6. In Name, assign a name to the service, or specify the fully-qualified
domain name of the service listening on this port.
7. Check the SSL check box to specify encrypted communications.
F5 Networks recommends enabling SSL for all services other than
those that provide redirect, offload, or synchronization support, and
when you need to provide access to devices that do not support SSL.

Chapter 8
8. Click Add New.

The new service now appears on the configured services table.
Configure it according to instructions in the following procedure.
To configure a service
The Web Services screen opens.
3. Click the Configure link in the row next to the service you want to
modify.
The configuration detail screen opens.
4. In Hostname, specify the FQDN of the service.
This step is optional, depending on the IP address you are
configuring, and whether you have entries in your DNS
corresponding to the IP address.
For example, if you are configuring the self IP address on a failover
pair, you might not want to specify FQDN, but if you are
configuring the shared IP address on a failover pair, you do. For
more information about IP addresses for failover pairs, see
Configuring the active controller with a self IP address, on page
11-9, and Configuring the active controller with a shared IP
address, on page 11-10.
Note: The CN on the certificate should match the hostname of the
web service that the certificate is assigned to. You could have
multiple hostnames if you have multiple IP addresses configured.
5. In IP Address, select the IP address configured for the FirePass
controller.
You can add a new IP address using options on the IP Config tab.
For more information, see Configuring IP addresses and subnets, on
page 8-9.
6. In Port, modify the port number for this service.
7. Check Use SSL, to enable secure communication for this service.
The screen refreshes, revealing the following options:
• From the Certificate list, select an installed certificate.
To use SSL, you must have an SSL certificate installed on the
computer.
• You can also edit existing certificates, generate a request for a
new certificate, or generate a self-signed certificate using the
links provided.
Note: The FirePass controller includes a preconfigured, default SSL
server certificate for firepass.company.xyz. You can use this
certificate while configuring and testing a FirePass controller, but
the certificate is not unique, and the certificate’s server name will
8 - 22
not match the name you give to the FirePass controller, so anyone
connecting to the FirePass controller sees warning messages from
their web browser. Before you make the FirePass controller
available to external users, you should replace the default server
certificate with a signed certificate. For more information, see
Installing a server certificate, on page 4-8.
8. If you do not check Use SSL, you can also configure the following
options:
• In HTTPS URL to redirect to, specify the name of a server or
service to which to forward the session. You can leave this box
blank.
• Check the Do not redirect to HTTPS check box to permit access
to browsers that do not support SSL communication, for
example, mini-browsers on some Internet-enabled mobile phones
and PDAs.
9. Check the Synchronization Agent check box to indicate that you
want the synchronization agent to use this service for cluster or
failover configuration synchronization. A synchronization service:
• Must allow HTTP connections, without redirecting to an HTTPS
service.
• Must not be on a shared IP address if it is to be used for
synchronizing failover pairs for high availability.
• Must be on a virtual IP address if it is to be used for
synchronizing clusters of failover pairs.
Note: The Synchronization Agent option is visible only when
clustering or failover is configured. For more information, see
Chapter 11, Using FirePass Controllers for Failover, and Chapter
12, Using FirePass Controllers in Clusters.
10. Check User Logon to allow an end-user to log on using this web
service.
11. Check Admin Logon to allow administrators to log on using this
web service.
If this box is not checked, the FirePass controller redirects a logon
request to the standard end-utility, so that even with a valid
administrator logon, the user does not have access to the
administrative functions.
12. Check WebAccess Bypass to restrict the service to web application
favorites that are configured to use the minimal content rewriting
bypass feature.
For more information about configuring for minimal content
rewriting, see Configuring the Alternative Host/Port-based type of
13. Check Offload SSL processing to a BIG-IP Local Traffic
Manager to use the BIG-IP Local Traffic Manager to handle the
SSL processing that the FirePass controller normally performs as

Chapter 8
part of processing the secure client request. For more information

about how to configure this feature, see Offloading SSL processing
to BIG-IP system, following.
14. From For Mode, select the failover option you want the web
service to use.
• Always: Indicates that this web service always runs, regardless of
the role configured for the controller.
Always is used for web services configured for synchronization
on the device-specific, self IP address.
• Active Only: Indicates that this web service runs only when the
controller is functioning in an active role.
Active Only is used for web services on the shared IP address
configured for failover.
• Standby Only: Indicates that this web service runs only if the
controller is in a standby state.
Standby Only is rarely used. It is used only for administrator
access to the standby unit, without first having to check whether
the first or second unit is standby.
The For Mode list is visible only when you have failover
configured. For more information see Chapter 11, Using FirePass
Controllers for Failover.
Offloading SSL processing to BIG-IP system

You can configure the FirePass controller to offload its processor-intensive
SSL transactions to a BIG-IP local traffic management (BIG-IP system)
system, version 9.x. When you enable this feature, the BIG-IP system
performs the following functions:
• Accepts and processes any HTTPS connections sent by clients.
• Acts as a proxy between the requesting client and the FirePass controller.
• Establishes an HTTP connection with the FirePass controller.
• Delivers HTTP content to the FirePass controller.
If you plan to offloading SSL process, you can use the following topics:
• Understanding BIG-IP system, following
• Using virtual servers on BIG-IP systems, on page 8-25
• Configuring offloading of SSL processing, on page 8-25
Understanding BIG-IP system

The BIG-IP Local Traffic Manager system is specifically designed to
manage local network traffic. Local traffic management refers to the
process of managing network traffic that comes into or goes out of a local
area network (LAN), including an intranet.
8 - 24
A commonly-used feature of the BIG-IP system is its ability to intercept and

redirect incoming network traffic, for the purpose of intelligently tuning the
load on network servers. However, tuning server load is not the only type of
local traffic management. The BIG-IP system includes a variety of features
that perform functions, such as inspecting and transforming header and
content data, managing SSL certificate-based authentication, and
compressing HTTP responses. In so doing, the BIG-IP system not only
directs traffic to the appropriate server resource, but also enhances network
security and frees up server resources by performing tasks that web servers
typically perform.
Using virtual servers on BIG-IP systems

When you create a virtual server, you specify its type, either a host virtual
server or a network virtual server. Then you can attach various properties
and resources to it, such as application-specific profiles, session persistence,
and user-written scripts called iRules that define pool-selection criteria.
When associated with a virtual server, the collection of properties and
resources determines how the BIG-IP system manages local traffic.
For information about configuring virtual servers and managing SSL on the
BIG-IP system, see the BIG-IP Local Traffic Manager documentation.
Configuring offloading of SSL processing

When you offload SSL processing, you configure the FirePass controller to
allow insecure access, so that you can establish an HTTP network
connection between the controller and BIG-IP system. Configuring the
offloading of SSL processing involves two tasks:
• Configuring the FirePass controller
• Configuring BIG-IP system
For more information about offloading to SSL, see the deployment guide
that describes configuring the FirePass controller and BIG-IP system, on the
Solution Center site at http://www.f5.com/solutions/.
Configuring other network settings

You can use options on the Misc tab on the Device Management :
Configuration : Network Configuration screen to select which IP address to
use for the NetBIOS network broadcasts, and NAS IP Address for RADIUS
Requests. The source addresses selected here should be those assigned to
interfaces facing your internal network. The screen presents the following
options
◆ NetBIOS broadcast source address
Represents the IP address that the Portal Access feature Windows Files
uses to browse Microsoft Windows file servers. Generally, you should
set this IP address to the internal address that the corporate LAN uses to
route data back to the FirePass controller.

Chapter 8
◆ NAS IP Address for RADIUS Requests

Represents the IP address that the FirePass controller inserts as RADIUS
attribute 4, NAS-IP-Address for all of the requests the FirePass controller
makes to the RADIUS server. This value should match the
NAS-IP-address configured on the RADIUS server as a part of the
authentication policy.
Important
Any changes you make do not take effect until you commit them using the
Finalize tab.
Configuring access scope

You can control access to App Tunnel and Web Applications resources by
specifying a list of hosts that the system allows end users to access. You can
specify access control lists in the following locations:
• On the Common tab, available on the Application Access : App Tunnels
: Master Group Settings screen
• On the Application Tunnel tab, available on the Application Access :
App Tunnels : Resources screen
• On the Application Tunnel tab, available on the Application Access :
App Tunnels : Resources screen
• On the Web Application Tunnel tab, available on the Application Access
: App Tunnels : Resources screen
• For each favorite you configure for Application Tunnels or Web
Application Tunnels in Application Access
You can specify an entry in the list using the following format, using a
return to separate each entry:
hostname [:port]
ip_address [:port]
• hostname
Represents the host name or IP address to which you want to allow the
user access. You can use the wildcard characters asterisk ( * ), which
single character. For example:
*.site*quest.com:23,80,443
*.siterequest*:23-25
• port
Represents a port number or a range of ports. If you do not specify a port,
the system allows connections on all ports. For example:
www.siterequest.com:80
www.siterequest.com:23-25
www.siterequest.com:23-25,80,4
172.30.11.0/24:8
172.30.11.0/255.255.255.0:0-65535
8 - 26
You cannot specify a protocol or URI in any access scope list.

The system combines all entries from each list. The static, dynamic, and
web application tunnels then share the list during a session.
The entries you define in any access control or allow list fall outside the
scope of the Limit AppTunnels Access to Favorites only (for Extranets,
partner and customer access, etc.) and Allow Direct Connection options.
Specifying an entry in an allow list enables the user to access to that
location.
When you create a new resource group and select an existing resource group
to copy settings from, the system includes any entries in the access control
list.
You can have the system add an entry to the list based on a URL you type
when defining a favorite. This feature exists on the Web Application
Tunnels tab, available on the Application Access : App Tunnels : Resources
screen.
You can also specify an allow list on the Portal Access : Web Applications :
Resources screen. The system uses these entries for Portal Access Web
Applications only, and not for any App Tunnel connections.
To add an entry for Web Applications Tunnels in

Application Access
The Resources screen opens.
2. Click the Web Applications Tunnels tab.
The Web Applications Tunnels favorites screen opens.
4. In URL, type a URL.
5. Click the Add to allow list link.
The entry appears in the Allow list box.
To add an entry for Web Applications in Portal Access

Applications, and click Resources.
The Portal Access Resources screen opens.
3. In URL, type a URL.
4. Click the Add to allow list link.
The entry appears in the Allow list box.

Chapter 8
To control visibility of the favorite’s allowed-hosts list, click the show

favorites allow list link on the Application Access : App Tunnels :
Resources screen, or on the Portal Access : Web Applications : Resources
screen.
8 - 28
Using realms
An administrative realm is a complete set of roles, master groups, and
resource groups. The concept of realms extends the existing role-based
administration and simplifies FirePass controller administration by
providing an organizational structure for master groups and their associated
resource groups.
A FirePass controller realm consists of a set of defined master and resource
groups and realm administrators, with feature access delegated them by a
superuser. Superusers are users who have cross-realm access to all groups
and features. A superuser creates realm administrators, upgrading them from
FirePass controller users, and delegating full or restricted access to FirePass
controller functionality or groups. Realm administrators are users who can
create their own hierarchy of access to the groups and resources inside their
realm. In a typical setup, the master and resource groups of one realm are
not accessible to administrators of another realm, although superusers or
realm administrators can grant access across realms.
The FirePass controller provides a default realm named Full Access
containing a default superuser account named administrator. Full Access
gives superusers complete access to realm-configuration. Everyone serving
as administrator in the Full Access realm is considered a superuser.
Superusers have a realm list in the menu bar of the Administrative Console
that enables navigation to other realms.
Superusers can grant users administrative access to the Full Access realm.
Realm administrators can grant users administrative access only to their own
realm. An administrator in one realm cannot be an administrator in any other
realm, including the Full Access realm.
Tip
Realms are particularly useful for managing groups with clear functional or
geographic divisions and in the service-provider scenario.
Configuring the Full Access realm

The first time the first superuser logs on to a FirePass controller, the screen
for Administrative Realms contains one realm, Full Access, and one
account, admin. The only actions available inside the Full Access realm are
adding and deleting administrators. To set feature and group access, the
superuser must first create a realm.
Only a superuser can add other superusers, create or delete realms, configure
default features and groups for a realm, and delete realms in the Full Access
realm.
A given user can serve as administrator in only one realm. If you have
administrators who need access to more than one realm, you can add them to
the Full Access realm, where they will have access to all realms.

Chapter 8
Configuring the FirePass controller for realms

When you have a complete subset of users who need access to a specific set
of resources, realms can give you the higher-level grouping mechanism you
need. The following tasks encompass the general process for realm
configuration:
• Add superusers.
For step-by-step procedures for adding superusers, see the online help the
Device Management : Security : Administrative Realms screen.
• Create realms.
For step-by-step procedures for creating realms, see the online help the
• Specify realm administrators.
For step-by-step procedures for specifying realm administrators, see the
online help for the Device Management : Security : Administrative
Realms screen.
• Specify default features and groups for each realm.
For more information, see Configuring realm-specific settings,
following.
• Add administrators within the realm.
For more information, see Assigning administrative privileges to a user
account, on page 8-32.
• Restrict a realm administrator's access.
For more information, see Configuring realm-level group access,
following, and Configuring realm-level feature access, on page 8-31.
Configuring realm-specific settings

It is often difficult to determine which set of administrators should do
specific tasks, since each network setup is unique. But generally, realm
administrators do the realm-level configuration, that is, configuration
restricted to the associated administrator’s realm. However, depending on
the setup, a realm-level administrator might not have access to
administrative functions. In that case, an administrator from the Full Access
realm would also do the following tasks:
• Assign administrative privileges to a user account
• Add a superuser
• Create and delete a realm
• Add and delete a realm administrator
• Configure default features and groups for a realm
• Specify which groups and features are accessible in a realm
• Restrict a realm administrator's access
A realm administrator or superuser can perform these realm-based

operations using the Administrative Realms screen. To access the screen,
click Device Management, expand Security, and click Administrative
8 - 30
Realms. Realm administrators or superusers can use the Edit link in the
Administrators column associated with the specific realm to add and delete
administrators for the realm.
WARNING
All delete operations occur immediately, without a confirmation alert, so be
sure you are ready to delete a realm or an administrator before you click
Delete.
Configuring realm-level group access

On the Device Management : Security : Administrative Realms screen,
realm administrators or superusers can use the Edit link in the Group access
column associated with the specific realm to specify which groups
administrators can access.
By default, the list presented represents the groups available in the
administrator’s Administrative Console. Administrators can restrict
accessibility to specific groups by clearing the Allow access to all groups
check box. After saving, administrators can use Edit again to specify which
groups the realm should contain.
Modifying access at this level affects all administrators in a realm. Realm
administrators or superusers can specify administrator-level restrictions
using the groups link in the Administrators column for the associated realm.
Note
If the groups link is not present, it means that the realm is not configured to
have access to any groups.
Configuring realm-level feature access

On the Device Management : Security : Administrative Realms screen,
realm administrators or superusers use the Edit link in the Feature access
column associated with the specific realm to specify which navigational
areas the administrators can access.
By default, the list presented represents the links in the navigation pane of
the FirePass controller’s Administrative Console. To control access in the
realm, administrators can check the Allow access to all features check box,
or check or clear the check box next to each feature.
Modifying access at this level affects all administrators in a realm. Realm
administrators or superusers can specify administrator-level restrictions
using the features link in the Administrators column for the associated
realm.
Note
If the features link is not present, it means that the realm is not configured
to have access to any features.

Chapter 8
Configuring administrator-specific access

Providing they have access to the Device Management: Security :
Administrative Realms screen, realm administrators and superusers can
use the features or groups links associated with a realm administrator to
grant or restrict access to specific groups or features.
By default, the list presented when administrators click the Features link
represents the navigation pane available to all users and administrators in the
realm.
The features link for a specific administrator is the one you use to restrict
access to administration tasks. When the realm administrator or superuser
clears the Administrative Realms check box, the navigation pane in the
associated administrator’s Administrative Console no longer displays the
Administrative Realms item.
Assigning administrative privileges to a user account

You can configure any existing user account with administrative privileges.
F5 Networks recommends giving administrative access to separate user
accounts rather than sharing a single account, in realms with more than one
administrator. That way, you can better track which administrator made a
change.
Important
Because superusers have cross-realm access and because they can add
other superusers, you should make sure to add only trusted sources as
administrators of the Full Access realm.
The FirePass controller logs all activities of any user with administrative
privileges in Application Logs. You can find Application Logs on the
Reports : App Logs screen.
Adding realm administrators

A superuser must add the first realm administrator. After that, any
administrator in the realm can do this, provided they have access to the
By default, the new administrator has access to all features and groups in the
realm. Any superuser or realm administrator can restrict access using the
features and groups links next to the administrator's name. We recommend
that you allow only superusers access to the Realms screen.
For more information, see Configuring administrator-specific access,
preceding, and procedures in the online help for the Device Management :
Security : Administrative Realms screen.
8 - 32
Deleting realm administrators

A superuser and any administrator in the realm can delete a realm
administrator, provided they have access to the Device Management :
Security : Administrative Realms screen.
WARNING
Realm delete occurs immediately, without a confirmation alert, so be sure
you are ready to delete an administrator before you click Delete.
Upgrading with administrators configured in versions previous to

FirePass software version 5.4
Versions previous to FirePass software version 5.4 did not support realms.
When you upgrade to versions later than 5.4, the upgrade process creates a
realm called Administrators to contain each existing FirePass controller
administrator. Each account in the Administrators realm retains the group
and feature access assignments you configured in the previous version.
Using reports inside realms

Reports show only realm-specific statistics.

Chapter 8
Completing other configuration activities

You can configure other administrator-level functionality using options
under the Configuration item in the navigation pane. The following lists
additional options that you can configure for administrator-level
functionality:
• Specify the FirePass controller administrator’s email address
For more information, see Configuring Admin E-mail, following.
• Add definitions for other types of browsers
For more information, see Adding definitions for other types of browsers,
on page 8-35.
• Configure a new RSA SecurID server
For more information, see Configuring a new RSA SecurID
authentication server (for native RSA authentication), on page 8-36.
• Specify the SMTP email server
For more information, see Specifying the SMTP email server, on page
8-40.
• Configure an SNMP agent
For more information, see Configuring an SNMP agent, on page 8-41.
• Specify HTTP and SSL proxies
For more information, see Specifying HTTP and SSL proxies, on page
8-42.
• Specify the time, time zone, and NTP server
For more information, see Specifying the time, time zone, and NTP
server, on page 8-43.
Configuring Admin E-mail

You can specify the address and other information for the FirePass
controller to use when sending email security alerts and notifications to the
administrator. The Device Management : Configuration : Admin Email
screen contains several settings that you can specify.
• Admin E-Mail Address
Indicates the recipient address of the notification. This is the address that
the email contains in its To: field.
• E-Mail From Name
Identifies the FirePass controller that generated the email. You can
specify %serialnumber% to insert the serial number of the FirePass
controller.
• E-Mail From Address
Indicates the sender of the email. This is the address that the email
contains in its From: field. You can specify %serialnumber% to insert
the serial number of the FirePass controller.
• Reply-To E-Mail Address
Indicates email address that you want end users to use when replying to
notices that the FirePass controller sends.
8 - 34
To configure Admin E-mail

Configuration, and click Admin Email.
The Administrator’s Email Address screen opens.
2. In Admin E-Mail address, specify the administrator’s email
address for the FirePass controller to send notifications to.
3. In E-Mail From Name, type the information that identifies the
FirePass controller that sent the email. You can use the variable
%serialnumber% along with any other identifying text. When you
use %serialnumber%, the FirePass controller replaces it with the
originating FirePass controller model and serial number when it
generates the email-from name.
For example, to indicate that an alert originated from a specific
FirePass controller in your branch office in Japan, you could type
FirePass 4100%serialnumber% Japan branch office
4. In E-Mail From Address, specify the email address of the FirePass
controller that is sending the email. You can use the variable
%serialnumber% to include in the email address the model and
serial number of the originating FirePass controller.
For example, you could specify
support%serialnumber%@firepass.co.xyz or
support@%serialnumber%.co.xyz
5. In Reply To E-Mail Address, you can specify an email address
where recipients should reply when the FirePass controller sends
them email.
Although this is an optional box, specifying a value ensures that
replies to the email go to a valid recipient SMTP address, instead of
to the FirePass controller, which cannot receive SMTP mail.
Adding definitions for other types of browsers

You can add and classify definitions for browsers, such as mini-browsers
and phones. All browsers do not support all functions on all devices. For
example, you cannot use caching on phones. So the FirePass controller
restricts some functionality to suitable browsers.
Browsers identify themselves by the user-agent box they send in their HTTP
headers, which classifies them as full browsers, mini-browsers, or phone
browsers. You can use options on the Device Management : Configuration :
New Browsers screen to configure additional browsers.
To add a definition for a browser

Configuration, and click New Browsers.
The Classify new browser type screen opens.

Chapter 8
2. In the User Agent text box, type or paste the user-agent string
exactly as it appears in the HTTP header the browser sends in the
HTTP request.
For example, for Mozilla 1.7.8, the User-Agent is
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8)
Gecko/20050511
You can find other user-agent strings by referring to your browser’s
documentation, and by inspecting the user-agent HTTP header that
the browser sends.
3. From the Type list, select a browser type:
• Desktop Browser
• Minibrowser
• i-mode phone
• HDML, or early WAP phone
• WAP 1.1+ phone
• Pocket PC browser
4. Check the Supports images and Supports color options according
to the capabilities of the browser.
5. Check the Supports UTF-8 option to enable UTF-8 support for
browsers that support UTF-8.
Note: The Desktop browser and Pocket PC browser provide built-in
support for UTF-8, so the system keeps this option selected for these
browsers.
6. Click Add.
The browser definition is added to the list on the Force New
Browser Type panel.
Configuring a new RSA SecurID authentication server (for native

RSA authentication)
To enable communications between the FirePass controller and the RSA
Authentication Manager / RSA SecurID Appliance, you must add an agent
host record to the RSA Authentication Manager database. The agent host
record identifies the FirePass controller within its database and contains
information about communication and encryption.
The process of configuring the FirePass controller to work with an RSA
SecurID authentication server requires several tasks.
◆ On the RSA SecurID authentication server, configure the server to
recognize the FirePass controller as an agent host.
For more information, see Step 1: Configure the RSA SecurID
authentication server to recognize the FirePass controller as an agent
host, following.
8 - 36
◆ On the RSA SecurID authentication server, identify the users who are
authorized to use the FirePass controller.
For more information, see Step 2: On the RSA SecurID authentication
server, identify the users who are authorized to use the FirePass
◆ On the FirePass controller, import the server configuration file.
For more information, see Step 3: Configure the FirePass controller to
use the RSA SecurID authentication server, on page 8-38.
For more information about how to use the RSA SecurID authentication
method, see Setting up RSA SecurID authentication, on page 2-92.
You can also find information about setting up the RSA SecurID
authentication server on the Solution Center at
http://www.f5.com/solutions/.
Step 1: Configure the RSA SecurID authentication server to recognize the

FirePass controller as an agent host
To configure the RSA SecurID authentication server to recognize the
FirePass controller as an agent host, you must add the FirePass controller as
an agent host in the RSA Authentication Manager. To create the agent host
record, you must have the following information.
• The name of the FirePass controller
• The actual IP addresses for all network interfaces of the FirePass
controller, including all failover pairs and cluster members
If you use the RADIUS method, then configure the FirePass controller as a
Communication Server agent type on the RSA Authentication Manager
(RSA ACE/server). If you use the SecureID (Native RSA Protocol) method,
configure the FirePass controller as a UNIX agent. The RSA Authentication
Manager uses this setting is to determine how communication with the
FirePass controller occurs.
Important
Host names within the RSA Authentication Manager / RSA SecurID
Appliance must resolve to valid IP addresses on the local network.
To add the FirePass controller as an agent host on the RSA

SecurID authentication server
1. On the administrative interface of your RSA SecurID authentication
server, click the Agent Host tab, and select the Add Agent item.
2. In Name, specify a name for identifying the FirePass controller
agent host configuration.
This may or may not be a DNS-resolvable name. This name can be
different from the FQDN configured on the FirePass controller.

Chapter 8
3. In Network address, type the IP address used by the FirePass

controller while communicating with the RSA SecurID Server.
This address must be the source IP address present in the IP packets
received by the RSA SecurID Server from the FirePass controller.
Note: You will need this address in Step 3: Configure the FirePass
controller to use the RSA SecurID authentication server, on page
8-38.
4. From the Agent Type list, select UNIX Agent.
5. For Encryption Type, select DES.
6. Clear the Node Secret Created check box, if it is available.
7. Click the Open to All Locally Known Users check box.
8. Clear the Search Other Realms for Unknown Users check box.
9. Click the Requires Name Lock check box.
10. Clear any selection from the check boxes Enable Offline
Authentication, Enable Windows Password Integration, and
Create Verifiable Authentication.
Note: These options became available on the agent host
configuration screen starting with RSA ACE/Server 6.0.
11. Click OK.
12. Click the Agent Host tab, and select the Generate Configuration
Files item.
The Generate Configuration File screen opens.
13. Select the One Agent Host option, and then select from the list the
FirePass controller agent host you just configured.
14. Save the agent host configuration file on your local system.
15. Click OK.
Step 2: On the RSA SecurID authentication server, identify the users who
are authorized to use the FirePass controller
See your RSA SecurID Server administrator guide for information on how
to activate users on the agent host you created for the FirePass controller.
Step 3: Configure the FirePass controller to use the RSA SecurID

authentication server
Configuration, and click RSA SecurID,
The Configure a New RSA SecurID Server screen opens.
2. In Name, type a name that identifies the RSA SecurID
authentication server configuration on the FirePass controller.
This name can be any arbitrary string.
8 - 38
3. In Configuration file, type the path and name of the Configuration

File you created in Step 1: Configure the RSA SecurID
authentication server to recognize the FirePass controller as an
agent host, on page 8-37, or click the Browse button to search for it.
4. In Source IP, type the IP address to be used for communicating
with RSA SecurID authentication server, or select it from the list.
If there is a NAT device in the network path between the FirePass
controller and the RSA SecurID authentication server, type the
address as translated by the NAT device.
Otherwise, select the IP address from among those configured on
In all cases, this IP address must match the SourceIP address in the
IP packets that the RSA SecurID server receives.
Note: Because the FirePass controller is an appliance with multiple
IP addresses, this setting is very important. It must be the same
address as the IP address you specified in the Network address box
while configuring the FirePass controller as an agent host on RSA
SecurID server in Step 1: Configure the RSA SecurID
authentication server to recognize the FirePass controller as an
agent host, on page 8-37.
Using RSA SecurID on FirePass controllers configured for failover

There are some specific considerations for using RSA SecurID on FirePass
controllers that are configured for failover.
On the RSA SecurID authentication server:
• When you configure the FirePass controller as an agent host, use the
virtual IP address of the FirePass controller as the primary IP address.
• Configure each failover unit as a secondary node on the RSA SecurID
server, using the actual IP address, not the virtual IP address.
• If the FirePass controller is deployed in a failover configuration, define
all host name/IP addresses that resolve to the FirePass controller.
For more information about creating, modifying, and managing agent host
records and configuring secondary nodes, see the appropriate RSA Security
documentation.

Chapter 8
On the FirePass controller:

• When you configure an RSA SecurID authentication server, use the
shared, virtual IP address of the FirePass controller failover pair as the
source IP address.
Specifying the SMTP email server

You can have the FirePass controller send email messages from the FirePass
controller administrator and users. You can configure the Simple Mail
Transfer Protocol (SMTP) server for this purpose on the Device
Management : Configuration : SMTP Server screen. The FirePass controller
uses the SMTP server to send all emails, including:
• Messages from users of the Portal Access : Mobile Email functionality.
• Messages from the FirePass controller administrator.
To specify an email server for the FirePass controller to use

1. In the navigation pane on the FirePass controller, click Device
Management, expand Configuration, and click SMTP Server,
The SMTP Server screen opens.
2. In Primary server, type the name of the email server you want to
use, such as mailserver.siterequest.com.
3. In Optional backup server, type the name of an SMTP server you
want the FirePass controller to use if the primary server is
unavailable.
4. Click Update.
After you configure the SMTP server, you can test it.
Note
The FirePass controller does not support email sent using an SMTP server
that requires authentication.
To send a test email through the SMTP server

Management, expand Configuration, and click SMTP Server,
The SMTP Server screen opens.
2. In the Send the test E-Mail area, specify an email address that you
want the FirePass controller to send the test email to.
3. Click Send.
4. Check the email account that you sent this email to verify that it
received a test message from the controller.
To determine the success of the test, check for the presence of the
message FirePass platform SMTP Test.
8 - 40
Configuring an SNMP agent

You can use a Simple Network Management Protocol (SNMP) agent to
monitor the FirePass controller. The SNMP agent uses a standard
NET-SNMP version 5.4 distribution to support the management information
base (MIB) modules. In addition to the standard MIB supported by the
NET-SNMP library, the FirePass controller supports its own enterprise
MIB: FIREPASS-SYSTEM-MIB, for managing FirePass
controller-specific features. For more information on the MIB modules that
the SNMP agent supports for the FirePass controller, see the online help for
the SNMP screen.
Important
When configuring systems described in the following procedure, F5
Networks strongly recommends making sure that only the internal LAN has
access to the port configured in Run SNMP agent on port setting. In
addition, we recommend restricting the access location specified in
Accessed from setting to that of your SNMP Manager.
To configure an SNMP agent

Management, expand Configuration, and click SNMP,
The SNMP screen opens.
2. Check the Run SNMP agent on port check box and specify a port
number. The standard SNMP port is 161.
If you specify a nonstandard port in this procedure, make sure that
your SNMP Manager is configured appropriately.
3. In System name, specify a name to identify the SNMP agent for
this FirePass controller, such as the FirePass controller’s name.
Note: Each member of a cluster or failover pair must have a distinct
name. The SNMP names and locations are not synchronized
between failover pairs because each member is tracked separately
and must be uniquely identified.
4. In System location, type the FirePass controller’s location.
5. In System contact, specify an email address to contact, such as the
address for the FirePass controller administrator.
6. In Community name in the rocommunity, rwcommunity, and
Traps configuration sections, type the community name that
corresponds to your SNMP Manager configuration. Community
name is a standard SNMP access token.
7. In Accessed from in the rocommunity and rwcommunity sections,
type one of the following to indicate the access location.
• The string anywhere
• The string nowhere

Chapter 8
• A list of space-separated host names, IP addresses, or

IPaddress/IPmask pairs
8. Check SNMPv1 traps, SNMPv2 traps, and SNMPv3 informs to
indicate the SNMP version for the associated list of host names.
You can check one or more check boxes as appropriate to your
configuration.
9. In the boxes in the Hosts area, specify a list of space-separated trap
destination host names or IP addresses. You can also configure a
port number by following the host name with a colon and the
number you want to use, for example
my.trap.host:162
The hosts should correspond to the configuration in your SNMP
Manager.
10. Click Submit.
Specifying HTTP and SSL proxies

You can configure the FirePass controller to use HTTP and SSL proxies for
web server access. Some situations require proxies.
• If the FirePass controller has no direct outbound access to the Internet,
you must configure the settings for the proxy server used to relay the
requests. This is also required for the mechanism used for the Online
Update functionality to work.
• If the FirePass controller does not have direct access to web servers on
the internal LAN, you might also have to configure a proxy for Web
Applications favorites to work.
You can find settings for these features on the Proxies screen. To access the
screen, click Device Management, expand Configuration, and click
Proxies. For more information about proxies settings, see Configuring
proxy options, on page 7-34.
To specify HTTP or SSL proxies

Configuration, and click Proxies,
The Proxies screen opens.
2. To enable an HTTP proxy, check the Enable HTTP Proxy check
box. In the Address text box, type the HTTP proxy’s IP address,
and in the Port text box, specify the HTTP proxy’s port number.
3. To enable an SSL proxy, check the Enable SSL Proxy check box.
In Address, type the SSL proxy’s IP address, and in Port, specify
the SSL proxy’s port number.
4. To use basic proxy authorization, check the Use Basic Proxy
Authorization check box. In Username, type the user’s logon
name, and in Password and Validate, type the user’s password.
8 - 42
5. In the box at the bottom of the screen, specify a comma-separated

list of IP addresses or subnets to which you want the FirePass
controller to allow direct access.
If the box is empty, the FirePass controller uses a proxy for all
resource access.
The FirePass controller uses this setting for all connections that go
through a proxy, even web applications.
6. Click the Update and Test button.
The FirePass controller verifies that it can connect to the proxies
you specified before committing the settings.
Note
If the settings are incorrect, the test may take some time to complete.
Specifying the time, time zone, and NTP server

You can specify a time zone for the FirePass controller’s location, and you
can specify a Network Time Protocol (NTP) server for the FirePass
controller to use. You can also manually set the time.
To specify a time zone for the FirePass controller

Configuration, and click Time,
The Time screen opens.
2. To specify a time zone for the FirePass controller, select a time zone
from the list, and click the Apply button.
3. Click the click here to restart the FirePass services link to initiate
a restart of the FirePass controller services.
The Restart Services screen opens.
4. Click the Restart button to begin the restart operation.
When the operation completes, the new time appears at the top of
the screen.
To specify an NTP server for the FirePass controller


Chapter 8
2. To specify an NTP server, specify the server name in the New NTP
Server box, and then click the Apply button.
When the operation completes, the new time appears at the top of
the screen.
Note
If you are using RSA authentication, F5 Networks recommends using an

NTP server.
To specify date and time manually

2. Type the values you want to use in the box in the Set Date and Time
Manually area, using the format described in the following section.
3. Click Apply.
Time and date format

Use the following format to specify the time and date on the Time screen.
MMDDhhmm[[CC]YY][.ss]
• MM - month number in a year
• DD - day number in a month
• hh - hour number, in 24-hour format
• mm - minutes number
• CC - century (that is, the 21st century) minus 1
For the purposes of the FirePass controller, this value is 20.
• YY - the last two digits of the year. So CCYY is the full year
representation.
• .ss - seconds number
Notes
• Brackets indicate optional values.
• If you do not specify CC and YY values, the FirePass controller uses the
current century and year. If the date you specify has not yet occurred in
the year, the FirePass controller uses the previous year.
• Type a period before the last two digits, if you want to set seconds.
Example
To set the time to 11:30:45 AM on September 24, 2004, type the following
string: 092411302004.45
8 - 44
Performing maintenance
Maintenance for the FirePass controller includes the following activities:
• Activate License
For more information, see Managing FirePass controller licenses,
following.
• Backup/Restore
For more information, see Backing up and restoring the FirePass
• Local Update
For more information, see Upgrading controller software, on page 8-48.
• Logs
For more information, see Managing log files, on page 8-51.
• Accounting
For more information, see Configuring for RADIUS accounting, on page
8-58.
• Online Update
For more information, see Updating the software online, on page 8-51.
• Restart Services
For more information, see Shutting down and restarting the FirePass
• Troubleshooting Tools
For more information, see Using the troubleshooting tools, on page 8-61.
• User Session Lockout
For more information, see Locking out user sessions, on page 8-49.
Managing FirePass controller licenses

When you want to install, upgrade, or reactivate the FirePass controller
license, you can use items on the Device Management : Maintenance :
Activate License screen.
Obtaining a license for the first time

The FirePass controller already has an installation type, serial number, and
registration key assigned. You can check these values on the Current
Settings screen. To access the screen, in the navigation pane, click Device
Management, and click Current Settings.
The FirePass controller was factory-equipped with a unique code, called a
base registration key. When you purchased the controller, a record was
created on the F5 Networks licensing server, indicating what features you
purchased. To operate the FirePass controller, you must activate your
license. The activation process connects this controller’s base registration
key with the licensing server record.

Chapter 8
Installing a new license or adding capacity or features to an existing license

You can automatically generate an encrypted license request to add
concurrent session capacity, and to activate the module registration key
when you purchase new features.
If, during the licensing process, you cannot connect to the licensing server
using the automatic method, check the FirePass controller’s gateway, DNS,
and proxy settings. Also make sure your firewall allows outgoing
connections to https://activate.f5.com. If you still cannot connect to the
licensing server, use the manual license activation method.
To install a new license or add features

Maintenance, and click Activate License.
The Activate License screen opens.
2. For each new feature you are adding, type or paste the module
registration key in the box provided, and click the Add button.
3. Select the Registration Method.
If the FirePass controller can resolve directly to the F5 Networks
licensing server, and it has outgoing SSL access to port 443, select
the Automatic method. Otherwise, or if you are not sure, select the
Manual method.
4. Click the Request License button.
5. If you selected the Automatic registration method:
a) Accept the End User License Agreement, and provide your
business email address and contact details at the prompts.
A screen opens, displaying your license file.
b) Click the Continue button to activate and install your license.
6. If you selected the Manual method, the Activate License screen
opens.
a) Select and copy all of the contents in the Product Dossier box.
b) Click the Click here link here to access F5 Licensing Server link.
The Activate F5 License screen opens in a new browser window.
c) Paste the contents you copied from Product Dossier in the
previous step to the Product Dossier box on the Activate F5
License screen.
d) On the Activate F5 License screen, click the Activate button.
e) Accept the End User License Agreement, and provide your
business email address at the prompt.
f) After a few moments, the licensing server displays your new
license file.
g) Select all of the text in the License File box on the Activate F5
License screen, and copy it to your system's clipboard.
8 - 46
h) Return to the FirePass controller browser window.

i) On the Device Management : Maintenance : Activate License
screen, paste into the License File box the text you copied from
the licensing server.
j) Click the Install License button.
Some confirmation messages appear.
7. Click the Continue button to activate and install your license.
It may take several seconds for the license to become valid, and in
certain cases, for example, for a new license, the process might
prompt you to restart the FirePass controller.
8. Log off, and log on again.
The FirePass controller presents the newly licensed features.
Important
If your license includes a FIPS or SSL-accelerator option, you must restart
the FirePass controller after activating the license.
Backing up and restoring the FirePass controller

You can back up and restore the current FirePass controller configuration,
including the users and groups portions of the FirePass controller
configuration, all favorites, most reports, and some non-network elements
included within Device Management. We recommend that you back up your
system before and after upgrading FirePass controller software.
You can transfer the FirePass controller configuration information to a
replacement controller if a hardware failure occurs, or for upgrading
purposes. The backup operation does not preserve network settings, so you
should configure the network settings before restoring a backup on a
different platform.
Important
Both the platform you use for backing up and the one you use for restoring
must run the same version of the FirePass controller software, including all
hotfixes.
To back up and restore FirePass controller configuration

information
Maintenance, and click Backup/Restore.
The Backup / Restore screen opens.
2. The next step is dependent on your intent:
• To back up the current configuration, including user and group
accounts, global and master-group access settings, and favorites,
click the Create backup of your current configuration link.

Chapter 8
When the process posts the dialog box, click Save it to disk,
browse to a location where you want to store the backup file, and
click OK.
• To create a full backup of the configuration, including user and
group accounts, global and master-group access settings, and
favorites, click the Create backup of your current
configuration and log messages link. When the process posts
the dialog box, click Save it to disk, browse to a location where
you want to store the backup file, and click OK.
• To configure automated backups, check the Perform nightly
backups check box, check SCP or FTP, click Save, specify the
information requested, and click the Save or Backup Now
button.
• To restore a backed up configuration, click the Browse button in
the restore section, and select the backed up file. Then, click the
Restore your saved configuration link.
A FirePass controller backup file name appears similar to the
following:
backup-bip025328s-URM-5_5-20051021233816.zip, for a
partial backup, and
backup-full-bip025328s-URM-5_5-20051021235036.zip, for a
full backup.
The backed up files are protected with strong encryption, and are checked
for integrity prior to being restored.
WARNING
Backing up and restoring across FIPS-compliant systems restores only the
user accounts and groups configuration. It does not restore network settings
and certificates. This is a FIPS requirement.
Cavium RoHS FIPS card support

The Cavium RoHS card provides new versions of the FirePass 4100/4300
RoHS-certified platform support for FIPS cards. This card replaces the
non-RoHS FIPS card for all FirePass controller systems.
Upgrading controller software

You can modify FirePass controller software from an installation file that
you download from the F5 Networks Technical Support Server. Typically,
you download these upgrade releases from the F5 Networks Technical
Support Server, or receive them directly. For more information, see
Upgrading from a downloaded file, on page 8-50.
You can also upgrade the FirePass controller online. For more information,
see Updating the software online, on page 8-51. Whenever you upgrade the
FirePass controller software, you must update all cluster and failover
8 - 48
members to the new version as well. When you update clusters and failover
pairs, make sure to apply the update to the primary or active member first;
otherwise, synchronization wipes out all upgrade activity.
Important
Always back up the FirePass controller before an upgrade. Additionally,
since you cannot downgrade between FirePass software versions, we
recommend that you create a snapshot to back up your system. For more
information about the snapshot feature, see Backing up and restoring the
Note
If you do upgrade your system, we recommend that you extend the idle
time-out activity period to avoid the system timing out before the upgrade
completes.
Preparing for download

To prepare for upgrading, you can prevent new users from logging on to a
FirePass controller, and you can stop currently active user sessions. You can
find both of these functions on the User Session Lockout screen. To access
the screen, click Device Management, expand Maintenance, and click
User Session Lockout.
Locking out user sessions

When you check the Lockout new user sessions check box, the FirePass
controller refuses all logons from users. Newly logging on users see the
message configured in the session-lockout message box. Currently logged
on users experience no interruption in service.
The default session-lockout message is The FirePass administrator has
placed this system in maintenance mode. Please try again later. You can
change the message and click the Update button to present your own
customized message to newly logging on users.
You can still log on as an administrator using the /admin/ URI.
Ending user sessions

You can stop all currently active sessions using the Kill all sessions (except
this one) link. When one or more sessions are active, the screen displays a
warning, indicating the number of sessions to be affected. Clicking the Kill
all sessions (except this one) link halts all sessions except the one you are
using when you click the link. Once all sessions halt, the screen displays a
message, There are no other sessions at this time.

Chapter 8
Upgrading from a downloaded file
To download the upgrade file using a browser

The following instructions have been tested with Netscape, Mozilla, Internet
Explorer, and Safari. To access the FTP server with one of these browsers,
perform the following steps.
1. Type the following into the browser’s address box, where
<username> is your Ask F5SM user name:
ftp://<username>@ftp.f5.com
2. When prompted for your password, type your Ask F5SM account
password.
Note
Although some browsers allow you to include passwords as part of the URL,
F5 Networks recommends that you do not do so because of the possibility of
someone intercepting the password.
To download the upgrade file using the command line

1. Type the following command:
ftp ftp.f5.com
2. When prompted for your password, type your Ask F5SM account
password.
Now that you have the file, you can use the Local Update feature to upgrade
the software.
To update the FirePass controller from a local file

Maintenance, and click User Session Lockout.
The User Session Lockout screen opens.
2. Check the Lockout new user sessions check box.
If you wish, you can edit the message the controller presents to
newly logging on users. For more information, see Locking out user
sessions, on page 8-49.
3. Click the Kill all sessions (except this one) link.
For more information, see Ending user sessions, on page 8-49.
4. In the confirmation alert, click OK to stop all user sessions, or
Cancel to halt the operation.
Maintenance, and click Local Update.
6. Click Browse, and select the file.
7. Click Open.
8. Type the password you received along with the update file.
The default password is F5Networks.
8 - 50
9. Click Submit.
The update screen displays progress indicators that show the
progress of the download, install, and restart processes.
10. After restart completes, you can verify that the update completed
successfully by navigating to the Device Management : Current
Settings screen. The Current Settings screen displays the version
and build number, and all hotfixes that have been applied.
Updating the software online

You can use the Online Update feature to upgrade the FirePass controller to
the most currently available version. To determine availability of a new
release, consult the Online Update screen. To access the screen, in the
navigation pane, click Device Management, expand Maintenance, and
click Online Update.
To upgrade to the new version, follow the instructions presented on the
screen. You can also review the release notes for any available version.
When you click a release, the FirePass controller downloads the update
package and restarts the controller.
Managing log files

You can view, archive, download, and purge FirePass controller logs
manually or automatically at specified intervals. Periodic purging and
archiving of logs is important to manage storage space on the FirePass
controller. Using FirePass controller, you can perform these tasks:
• View the date of the most recent purge and the date of the next-scheduled
operation.
• Specify a log-purge schedule.
• Specify and configure the storage format for archives.
• Purge the temporary logs on the FirePass controller.
Purging files does not delete the log files, but rather moves them out of
current storage, and makes them available for archiving.
• Download and delete logs that exist in temporary storage.
• Specify a remote system log server for application and kernel messages.
• Delete system logs.
To archive data from purged logs, check the Create Archive check box. If
you do not check this option, purged data is permanently deleted.
Note
F5 Networks recommends that you do not keep the archives on the FirePass
controller. Delete the archive from the Temporary Archive Storage after you
have externally archived it.

Chapter 8
Using system logs

You can configure system logs to integrate with your existing log
management process and tools. The FirePass controller provides support for
extensive syslog capability. The following list represents the types of
messages that are logged in the system log.
• User session log
Represents when the user logged on, when the user logged off, and other
messages related to logon operations.
• Application logs
Represents all favorites that end-users and administrators can access.
• Pre-logon check messages
Includes messages returned from pre-logon checking of client systems.
• System events
Includes events such as system up and system down, restart, and others.
For more information, see the online help for the Logs screen, available
under the Maintenance item in the navigation pane.
Understanding log files

The FirePass controller records logging information in the following files:
• fp_app_log
Application log: For more information, see Application log-specific
(fp_app_log) example and variables, on page 8-54.
• fp_browser_log
Browser log: For more information, see Browser log-specific
(fp_browser_log) example and variables, on page 8-55.
• fp_logon_log
Logon log: For more information, see Logon log-specific (fp_logon_log)
example and variables, on page 8-55.
• fp_sess_log
Session log: For more information, see Session log-specific (fp_sess_log)
• fp_usage_log
Usage log: For more information, see Usage log-specific (fp_usage_log)
When you configure the FirePass controller to transfer these files over a
network to a remote system, the system compresses these files into a single
archive (a .zip file). The FirePass controller names files using a specific
format, as shown in the following example.
logs-bipnnnnnns-URM-5_5-yyyymmddhhmmss.zip
Log names follow these conventions:
• bipnnnnnns - serial number, typically with bip as the first three
characters, followed by six digits and a final character of s.
• yyyy - year, in four-digit representation.
• mm - month, in two-digit representation, from 01 to 12.
8 - 52
• dd - day of month, in two-digit representation, zero padded for days 1-9.

• hh - hours, in two-digit representation, from 01 to 24.
• mm - minutes, in two-digit representation, from 00 to 60.
• ss - seconds, in two-digit representation, from 00 to 60.
A typical log name is logs-bip025328s-URM-5_5-20050922001003.zip.
Understanding the format of log data

The FirePass controller creates logs as ASCII text files, and terminates each
line with a single newline character (hexadecimal 0x0A, that is UNIX-style
line termination, not DOS-style). There are no header or footer lines. Each
line of text represents a single event, and (unless noted) has the following
format:
IP_address--[mm/dd/yyyy hh:mm:ss]"var1=value1;var2=value2"
The following example illustrates a typical log entry.
192.168.200.170--[08/18/2005 00:52:23]
"sid=1e9ce3c6ee9601562efddc41169f2937;logon=access;group=Default;
message=Entered Admin Console
The following list describes each part of the log entry.
◆ IP_address
Represents the IP address of the computer that generated the log entry.
◆ [mm/dd/yyyy hh:mm:ss]
Represents the timestamp of the event being logged. Rectangular
brackets enclose the timestamp. Forward slashes delimit the values for
month, day, and year values. Colons separate the values for hours,
minutes, and seconds. The fp_sess_log and fp_browser_log files each
have two consecutive timestamp settings, each separately bracketed. The
fp_app_log also has a second bracketed box following the first
timestamp setting. It contains a text string, described, following.
◆ "var1=value1, var2=value2, varN=valueN"
Represents a series of pairs consisting of the name that the FirePass
controller uses to describe the data and the data itself. Double quotes
enclose the varN=valueN pairs, as a group. The entries for each log
share some variables and contain some type-specific variables. The
Variables shared by all logs section, following, describes the options
common to more than one log. Subsequent sections describe the
type-specific variables, as well as present examples of typical entries. For
more information, see the following sections:
• Application log-specific (fp_app_log) example and variables, on page
8-54
• Browser log-specific (fp_browser_log) example and variables, on
page 8-55
• Logon log-specific (fp_logon_log) example and variables, on page
8-55
• Session log-specific (fp_sess_log) example and variables, on page
8-56

Chapter 8
• Usage log-specific (fp_usage_log) example and variables, on page

8-57.
Variables shared by all logs

◆ sid
Indicates the FirePass controller session ID during which the event
occurred. The sid variable appears in fp_app_log, fp_browser_log,
fp_sess_log, and fp_usage_log.
◆ logon
Indicates the name of the logged on FirePass controller user associated
with the event. The logon variable appears in all logs.
◆ group
Indicates the name of the FirePass controller master group that contains
the logged-on user. The group variable appears in fp_app_log,
fp_browser_log, fp_sess_log, and fp_usage_log.
Application log-specific (fp_app_log) example and variables
Format
Example
192.168.200.170--[08/24/2005 22:19:51]
"sid=347cb5ea4ee9a4f6bf184ff56b97ed28;logon=access;group=Default;
message=Entered Admin Console
Variables
◆ Shared variables, as described in Variables shared by all logs, preceding.
◆ message
Describes the action occurring in FirePass controller session.
Other messages typical of administrator-related activity include:
• Access menu Welcome, param a = welcome, param click = 1
• Access menu Network Configuration, param a = ipconf
Other messages typical of client-related activity include:
• Network Access: dialing Click to connect to Network Access
• Network Access: dialing Connection to SA server
• Open Network Access Connection using remote IP address
192.168.192.6
• Network Access Connection terminated, Logged out
8 - 54
Browser log-specific (fp_browser_log) example and variables
Format
IP_address--[mm/dd/yyyy hh:mm:ss] [mm/dd/yyyy hh:mm:ss]
"var1=value1;var2=value2"
Example
192.168.200.170--[08/24/2005 22:19:51][08/24/2005 22:22:20]
agent_OS=WinXP;user_agent=Mozilla/4.0 (compatible; MSIE 6.0;
Windows NT 5.1; SV1)
For this item, the second timestamp indicates the ending time of the logged
activity.
Variables
◆ Shared variables, as described in Variables shared by all logs, on page
8-54.
◆ agent_OS
Indicates the operating system information of the client, taken from the
HTTP header user agent setting.
◆ user_agent
Indicates the browser information of the client, taken from the HTTP
header user agent setting.
Logon log-specific (fp_logon_log) example and variables
Format
Example
192.168.200.170--[08/24/2005 21:13:40]
logon=access;valid=yes;passed=yes;User-Agent=Mozilla/5.0 (Windows;
U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Variables
8-54.
◆ valid
Indicates whether the logging on user’s computer presented a valid client
certificate. Possible values are yes and no.
◆ passed
Indicates whether the logging on user’s computer passed the active
pre-logon check. Possible values are yes and no.

Chapter 8
◆ user_agent
Indicates the browser information of the client, taken from the HTTP
header user agent setting.
Session log-specific (fp_sess_log) example and variables
Format
IP_address--[mm/dd/yyyy hh:mm:ss] [mm/dd/yyyy hh:mm:ss]
"var1=value1;var2=value2"N
Example
192.168.200.170--[08/24/2005 22:19:51][08/24/2005 22:22:20]
home_address=;protocol=HTTPS;nonstandard_port=0;content_type=
HTML;desktop_dns=;desktop_dns=;finish=:0;"0
For this item, the second timestamp indicates the ending time of the logged
activity.
Variables
8-54.
◆ home_address
Represents the IP address of the remote desktop using Desktop Access.
An empty value indicates no Desktop Access connection.
◆ protocol
Represents the protocol used to access the FirePass controller, either
HTTPS (typical) or HTTP (unsecured).
◆ nonstandard_port
Represents the port number used to access the remote desktop for
Desktop Access connections. An empty value indicates no Desktop
Access connection.
◆ content_type
Represents the content form used to communicate with the standalone
VPN client. For a Windows-based browser, the value is typically HTML
it could be WML, in the case of a wireless hand-held device (PDA, cell
phone), for example.
◆ desktop_dns
Indicates the IP address of the remote DNS used by the remote desktop
for Desktop Access connections. An empty value indicates no Desktop
Access connection.
◆ desktop_finish
Indicates the length of the session, in seconds (integer) for Desktop
Access connections. An empty value indicates no Desktop Access
connection.
◆ server_addr
Indicates a reserved value.
8 - 56
Additional values
◆ N
Represents the status code of FirePass controller session, as indicated by
the following values.
• 0 - Server session in progress.
• 1 - Logged out from server
• 2 - Server session timed out
• 3 - Redirecting to desktop
• 4 - Desktop session in progress
• 5 - Logged out from desktop
• 6 - Desktop session timed out
• 7 - Session handed off to failover box
Usage log-specific (fp_usage_log) example and variables
Format
[mm/dd/yyyy hh:mm:ss]
[internal_function]"var1=value1;var2=value2"
Example
[08/23/2005 19:32:10] [uroam_admin]
"sid=35351d251f1b7bda0c427ff2a0d65a10;logon=access;group=Default
;time=3549;
Variables
8-54.
◆ time
Indicates the length of session, in seconds (integer), for the FirePass
controller connection.
◆ internal_function
Indicates the functionality used during FirePass controller session, as
indicated by the following values.
• uroam_admin - Admin Console
• uroam_mnemail - Mobile E-Mail
• uroam_mnfilemanager - Windows Files
• uroam_geekster - AppTunnels
• uroam_helppages - Help
• uroam_mnintranets - Web Applications
• uroam_mydesktop - Desktop Access
• uroam_nfs - UNIX Files
• uroam_terminal - Terminal Servers

Chapter 8
• uroam_vault - Tools
• uroam_mnoptions - Account Details
• uroam_mndesktopupdate - Desktop Software Download
• uroam_look - Webtop settings
• uroam_mnsessions - View Current Sessions
• uroam_mnstats - System Statistics
• uroam_vpn - Network Access
• uroam_x11 - X Window System (X11) Access
Configuring for RADIUS accounting

You can configure the FirePass controller to use RADIUS accounting
according to the standard described in RFC 2866, with certain exceptions.
The FirePass controller sends the following information to RADIUS
accounting server.
When a user logs on to the FirePass controller, it sends session start
information to the RADIUS accounting server. Session start information
consists of the RADIUS loginName, for example, joeu; the RADIUS
sessionId of the user’s session, for
example,123456789abcdefghijklmnopqrstuvy; and a RADIUS accounting
status start message, to indicate that the session has started.
Once the user finishes using the FirePass controller and terminates the
session by logging off of the controller, the FirePass controller sends session
end information to the RADIUS accounting server. Session end information
consists of the RADIUS loginName, for example, joeu; the RADIUS
session Id of the user’s session, for example,
123456789abcdefghijklmnopqrstuvy; a RADIUS accounting status stop
message, to indicate that the session has ended; and the RADIUS service
duration, for example, 300 seconds, which represents the total time for
which user session was active.
If the user does not log off of the controller, but simply closes the browser
window, the FirePass controller sends the RADIUS stop message when the
user’s session times out.
The FirePass controller sends the RADIUS accounting messages
asynchronously. It stores the user’s session start and session end information
in its database and sends it to the RADIUS accounting server periodically at
an interval of one minute.
Important
Be sure that the RADIUS accounting server is configured to recognize the
FirePass controller as a client.
8 - 58
To configure RADIUS-based accounting

Maintenance, and click Accounting.
The RADIUS Accounting screen opens.
2. Specify Timeout (in seconds) and Retries (number of retries).
We recommend setting both the time-out and number of retries to 3.
The allowable range for each value is 1 - 65535.
3. Specify the Service Type.
The FirePass controller uses this value as the RADIUS Attribute
Service Type (attribute number 6), and inserts the value for all the
requests the FirePass controller makes to the RADIUS Server.
4. Specify the Server, Port, and the Shared Secret.
Use the same shared secret in the RADIUS server configuration and
in the FirePass controller configuration.
5. If you have secondary and tertiary backup RADIUS servers, check
Use a secondary RADIUS server and Use a tertiary RADIUS
Accounting server, and then configure them the same way.
Shutting down and restarting the FirePass controller

You can use software options to restart the FirePass controller or its
services. To open the screen, in the navigation pane, click Device
Management, expand Maintenance, and click Restart Services.
Restarting the FirePass controller or services

You can restart the FirePass controller hardware using the Administrative
Console or the Maintenance Console. You can also restart all FirePass
controller software components by using the Administrative Console.
To restart the FirePass controller or services using the

Administrative Console
Maintenance, and click Restart Services.
2. Do one of the following:
• To restart the FirePass controller software components, click
Restart Services.
• To restart the FirePass controller hardware, click Restart
Controller.
3. Depending on the confirmation screen, do one of the following:

Chapter 8
• On the Restart Services confirmation screen, click the Restart

button to initiate the restart, or click the Back to Device
Management : Maintenance : Restart Services page link to cancel
the operation.
The Restart Services operation does not affect active user
sessions.
• On the Restart Controller confirmation screen, review the
warnings, if there are any, and then click the Restart button to
initiate the restart, or click the Back to Device Management :
Maintenance : Restart Services page link to cancel the operation.
Restarting the FirePass controller ends any active user sessions.
To restart the FirePass controller hardware using the

Maintenance Console
1. To start a Maintenance Console session, in the navigation pane,
click Device Management, expand Maintenance, and click
The Troubleshooting Tools screen opens.
2. Click the Please click here to start a console session to the
Maintenance Account link.
3. In the Maintenance Console, type maintenance, and press return.
4. On the first Configure FirePass Controller screen, type Y to accept
the agreement.
You can also type N to cancel the operation.
5. On the second Configure FirePass controller screen, type 9, labeled
Restart/shutdown controller.
6. On the Shutdown/Restart Controller screen, type 2, labeled Restart
FirePass Controller, and press return.
7. On the Restart confirmation screen, type Y to initiate the restart, or
N to cancel the operation.
Restarting the FirePass controller ends any active user sessions.
Shutting down the FirePass controller

You can shut down the FirePass controller using the Administrative Console
or the Maintenance Console.
Important
After shutting down, you must have physical access to the FirePass
controller device to start up the controller again. You cannot use the
browser interface to start up the FirePass controller.
8 - 60
To shut the FirePass controller down using the

1. On the navigation pane, click Device Management, expand
Maintenance, and click Restart Services.
2. Click the Shutdown Controller link.
3. On the Shutdown Controller confirmation screen, review the
warnings, if there are any.
Shutting down the FirePass controller ends any active user sessions.
4. Click the Shutdown button to initiate the restart, or click the Back
to Device Management : Maintenance : Restart Services page link to
cancel the operation.
To shut the FirePass controller down using the

Maintenance Console
1. To start a Maintenance Console session, in the navigation pane,
click Device Management, expand Maintenance, and click
2. Click the Please click here to start a console session to the
Maintenance Account link.
3. In the Maintenance Console, type maintenance, and press return.
4. On the first Configure FirePass Controller screen, type Y to accept
the agreement.
You can also type N to cancel the operation.
5. On the second Configure FirePass controller screen, type 9, labeled
Restart/shutdown controller, and press return.
6. On the Shutdown/Restart Controller screen, type 1, labeled
Shutdown FirePass Controller.
7. On the Shutdown confirmation screen, type Y to initiate the restart,
or N to cancel the operation.
Shutting down the FirePass controller ends any active user sessions.
Using the troubleshooting tools

You can use the tools provided to troubleshoot FirePass controller
installations. The FirePass controller provides several troubleshooting tools.
◆ Console access
Provides Telnet access to the Maintenance Console. For more
information, see Accessing the console, following.

Chapter 8
◆ F5 Support Diagnostic tool

Compiles a set of data for the F5 Support team to use. For more
information, see Using the F5 Support Diagnostic tool, following.
◆ Network packet dump
Creates a packet of data to use for troubleshooting purposes. For more
information, see Capturing network packets, on page 8-63.
◆ Web Applications engine trace
Creates a set of files that provides settings that help troubleshoot
problems. For more information, see Understanding Web Applications
engine trace, on page 13-1.
Accessing the console

You can access the Maintenance Console from the Troubleshooting Tools
screen. To access the console, click the Please click here to start a console
session to the Maintenance Account link.
Important
Although you can access the Maintenance Console from the
Troubleshooting Tools screen, you can initiate operations that result in the
inability to access the FirePass controller over the network. For example,
when you initiate a Snapshot operation, the system boots into Maintenance
mode, and you cannot access the FirePass controller from the browser. To
continue, you must access the controller using the serial console connected
directly to the physical device. Therefore, we recommend using caution
when initiating operations through the Maintenance Console. For more
information, see the FirePass® Controller Getting Started Guide, available
as a separate document on the F5 Networks Technical Support Web site,
https://support.F5.com.
Using the F5 Support Diagnostic tool

You can use this utility to capture a variety of support information from the
FirePass controller. You can click the Capture a new dataset link to collect
a new set of data. The screen refreshes and posts the message Processing
new dataset. Please be patient as the operation completes.
Note
The FirePass controller stores the data in an encrypted format. The F5

Support team uses their support server to decrypt the password and extract
the text.
Once a dataset is captured, additional links appear, offering the options to

download the dataset, email it to F5 Support, or delete it.
You can click the Download existing dataset link to save the collected data
to your computer. Your browser’s download dialog appears. Save the file,
and send it to support@f5.com using the support case number as the
subject of your email, unless instructed otherwise by F5 Support.
8 - 62
You can click the Email existing dataset to F5 Support link to email the
collected data directly from the FirePass controller to F5 Support. The
screen refreshes, and a confirmation of the sent message appears, or
notification of any error. The SMTP options, available on the Device
Management : Configuration : SMTP Server screen, must be configured
correctly for this option to work. In addition, your company might place
firewall restrictions on external emails originating from within your
network. In that case, you can download the dataset and email it directly.
You can delete a dataset to conserve storage. Before deleting a dataset,
confirm with F5 Support that they have received the files. Then click the
Delete existing dataset link to delete the dataset. The screen refreshes and
the options to download, email, and delete the dataset no longer appear.
Using the session variable dump tool

You can use this utility to capture a user’s session variable information from
You can enable the Save user’s session variables to Logon Report option
to have the system write a user’s session variables to the Logon report for
that user. Then you can view the variables on the Reports : Logon screen.
Capturing network packets

You can use the network-packet capture feature to troubleshoot networking
problems by capturing the network packets coming to and leaving from the
To configure for network-packet capture

Maintenance, and click Troubleshooting Tools.
2. From the Interface list, select an interface based on your platform:
• For the 1000, 1200, or 4000 platforms, select a network interface.
• For the 4100 or 4300 platforms, select either the Management
interface or one of the physical interfaces.
3. From the Packet type list, select the scope of packets to capture:
TCP, UDP, or All Types.
4. From the Max packet count list, select the number of packets to
capture.
5. Select one of the following options:
• Specify destination IP (empty for all traffic)
The destination IP address accepts alphanumeric characters and
the period ( . ), hyphen, ( - ), and underscore ( _ ).
• or expression (e.g.: host 172.16.1.2 and not udp port 443)
You can specify an expression, including alphanumeric
characters and the period ( . ), hyphen, ( - ), and underscore ( _ ).

Chapter 8
An empty IP address or expression value means that all the traffic is

captured.
6. To filter out the traffic to your current browser, check the Exclude
this browser’s address check box.
Note: This option is useful when you do not specify the destination
IP address.
7. To filter out broadcast UDP packets and ARP requests, check the
Ignore broadcasts and Ignore ARP check boxes.
8. Click the Please click here to start sniffing the network traffic
link to start capturing the traffic.
A dotted line draws in a new window to indicate activity.
9. You can wait until the maximum packet count is reached, or click
the Click here to stop the capture and view the results link to halt
the operation.
A description of the captured packets appears in the window.
10. View the data inline, or click the Click here to download the data
link to save the file locally, so you can analyze the packet dump file
offline.
11. Click the Click here to view the same data SSL-decoded link to
see the same data set with SSL sessions decoded.
The packet dump screen refreshes with the same dataset
SSL-decoded. You can then select one keypair to use to decrypt and
display the embedded application data, or click the Click here to
view the normal presentation of the same data link to return to the
previous view.
Note
You can use a protocol analyzer that supports reading network traces in
libpcap format to view the packet dump file offline.
Using the Web Applications engine trace

The FirePass Web Applications engine trace feature provides an easy way
for you to capture logs of user web sessions. The logs provide detailed
information about how the FirePass controller is translating the data stream.
8 - 64
Situations when you would use the Web Applications engine trace feature
include the following:
• When a user has trouble connecting to a Web site using a FirePass
controller Web Applications session.
• If a web page is not displaying properly on a client computer.
• If Java or JavaScript is not working on a client computer.
• When the web page contains non-HTML elements, such as XML, Flash,
or ActiveX components, and a client computer cannot access the page.
For more information about using the Web Applications engine trace
feature, see Understanding Web Applications engine trace, on page 13-1.

Chapter 8
Monitoring the FirePass controller

You can view statistics, system health information, and near-real-time load
conditions on the FirePass controller. The following pages contain
information on all of these monitoring methods. You can also use the
information in the FirePass reports. For more information on reports, see
Chapter 10, Using FirePass Controller Reports.
Displaying FirePass controller statistics

You can view statistics and information for the FirePass controller,
including total memory, average load, performance averages, and number of
network connections. To navigate to the Statistics screen, in the navigation
pane, click Device Management, expand Monitoring, and click Statistics.
The Statistics screen opens, containing measurement data presented by
interface. You can check Refresh every 20 sec to have the data update and
redisplay every 20 seconds.
Figure 8.1, following, illustrates a typical Statistics screen for a FirePass
4100 or 4300 model.
Figure 8.1 A typical Statistics screen for a FirePass 4100 or 4300 platform
8 - 66
Displaying FirePass controller system health

You can view system health information for the FirePass controller. The
System Health screen displays the measurements for various hardware
components. To navigate to the System Health screen, in the navigation
pane, click Device Management, expand Monitoring, and click System
Health. The System Health screen opens, containing measurement data
presented by interface.
You can configure the FirePass controller to send an email to the
administrator if any measured values fall outside of the minimum or
maximum limits. For minimum and maximum limits, see the online help for
the Device Management : Monitoring : System Health screen.
Figure 8.2, following, illustrates a typical System Health screen for a
FirePass 4100 or 4300 platforms configured for failover.
Figure 8.2 A typical System Health screen for a FirePass 4100 or 4300 platforms
Monitoring the load on a FirePass controller

You can view system load information for the FirePass controller. The
System Load screen displays the measurements for various hardware
components.
Figure 8.3 illustrates a typical System Load screen for a FirePass 4100 or
4300 platform.

Chapter 8
Figure 8.3 A typical System Load screen for a FirePass 4100 or 4300 platform
To monitor the load on the FirePass controller

Monitoring, and click System Load.
The System Load screen opens.
2. Scroll down to see more graphs of information.
3. To select the reporting period, click one of the links near the top of
the screen (Last 3 Hours, Last Day, Last Week, and Last Month).
8 - 68
4. To have the data update and redisplay every 20 seconds, check

Refresh every 20 sec.
5. To delete all data from the monitoring database, click the link, Click
here to zeroinit the load monitor database at the bottom of the
screen.
Using load statistics

You can use an external device to monitor the load status of FirePass
controllers. The external device may use the Statistics screen to poll the
FirePass controller for session and load averaging statistics.
Through the HTTP authentication, you can use the Access to the Load
Status screen. The user name is fixed: gtmuser. Note, however, that
although this name implies that this feature is specific to Global Traffic
Manager, it can be used by other load balancing systems if proper
credentials are supplied to the authentication request, and the load balancing
system is equipped to parse the load status page.
The Load Status screen displays the following categories of information
about the FirePass controller:
• Session usage
• Usage percent (sessions used per licensed sessions)
• CPU load average
To view the FirePass controller load statistics, type the following URL into
your browser, then click the Update button:
https://firepassname/load_status.php
Note
The FirePass controller initially inserts the key word all in the IP Address
box as a default value to indicate that all IP addresses are allowed to access
the Load Status screen. If you replace this keyword with an IP address, you
cannot, later, reenter the keyword all back into this box. Alternatively, the
Load Status Access Security IP address range can be limited to a specific
set of IP Addresses and subnet masks. Enter the IP address and mask on the
Load Status Access Security screen, separated by commas. When this box is
empty, however, it represents a Deny All request by default.
When a user submits the wrong credentials to access the load status screen,
the controller prompts the user to resubmit the credentials. When the
FirePass controller denies a user access to the load status screen because the
IP address is not specified in the Load Status Access Security screen, the
FirePass controller displays the following message in the user’s browser:
403 Forbidden. You do not have permission to access the above URL on
this server.
The following URL is provided to retrieve load status reports:

Chapter 8
https://firepassnamorip/load_reports.php?reporttype=[summary|gr
oup]&group=master_group_name&output=output_type&from=date_start
&to=date_end
where:
reporttype= is summary or group
group= is the name of the master group; if the group value is not set, a
combined summary report for all master groups is generated
output= is represented by xls, html, txt (comma-separated text)
from= is represented by lastweek, last2weeks, lastmonth, lastyear,
ISO-8601 formatted date (YYYY-MM-DD); if this value is not set,
lastweek is used as the default
to= is represented by ISO-8601 formatted date (YYYY-MM-DD)
Customizing the user’s webtop

You can customize the appearance (logos, colors, and text) and functionality
of the user’s webtop. You can also specify which links are available and the
order in which they appear.
To customize the user’s home page

1. In the navigation pane, click Device Management and click
Customization.
The Customization screen opens.
2. Specify the settings you want.
3. Click the Update button that is associated with the section
containing the changed settings.
The online help for the Customization screen contains definitions of each
option, and presents descriptions of how to use the available features. For
more information about the customization options, see online help for the
Customization screen.
8 - 70
Configuring for multiple languages

The FirePass controller supports multiple languages for user names and
favorites. The FirePass controller retrieves the value of the HTML
Accept-Language tag from the end user’s web browser when the user logs
on. The FirePass controller supports the following languages:
• English
• Japanese
• Simplified Chinese
• Traditional Chinese
• Korean
To set up multi-language support

1. In the navigation pane, click Device Management and click
Customization.
The Customization screen opens.
2. Click the Expand button next to Show Advanced

Customization.
3. Check Choice of language in logon page.
4. From the list, select the language you want to use when presenting
the user’s webtop.
5. If applicable, select the order of the user’s name.
6. Using a localized Windows system, open a new browser instance
and log on to the FirePass controller using a user account.
The system presents the webtop in the language you specify.
Note
Users can switch the webtop to English by clicking the Eng link at the top of
the webtop.
To create a user account with a localized user name

1. In the navigation pane, click Users and click User Management.
The User Management screen opens.
2. Create a local user account with a localized user name.
3. After the user account is created, you can impersonate a user on the
Users : Impersonate User screen by typing the localized user name
and clicking OK.

Chapter 8
To create a localized favorite

1. In the navigation pane, click Application Access and click App
Tunnels.
The App Tunnels screen opens.
2. Create a favorite using a localized name.
3. Log on as a user, or impersonate a user to see the localized favorite.
Note
Users can switch the webtop to English by clicking the Eng link at the top of
the webtop, but the localized favorite name is not affected by the switch.
8 - 72
9
Using FirePass Controller Client
Components
• Downloading client components
• Using Windows clients with the FirePass controller
• Using Macintosh and Linux clients with the FirePass

controller
• Establishing client connections
• Understanding Network Access error messages on

Macintosh or Linux clients
• Controlling the client using the command line

interface
• Using the command line interface on the client

Downloading client components

The FirePass controller downloads components to the end user’s computer
at initial logon, and whenever a feature or favorite, such as Network Access,
is started, the downloaded client components enable the various features of
FirePass controller functionality.
The type of control downloaded differs depending on the user’s operating
system. For proper functionality, the controls require certain conditions:
For Microsoft® Windows®-based computers, the user must have ActiveX or
Java enabled for the browser. All client components can be installed without
power user privileges, except for the Windows Group Policy feature, which
requires Power User privileges.
For Apple® Macintosh® (OS X only) and Linux®-based systems, the user
must have Superuser authority, or the user must supply the Administrative
password at the time of initial installation.
For more information about downloading and installing the client
components, see Installing client components on Windows systems,
following. For more information about the Component Installer, see Using
the Component Installer, on page 9-4.

Chapter 9
Using Windows clients with the FirePass controller

The FirePass controller includes support for remote Windows clients, so you
can use the FirePass controller for secure remote access.
Installing client components on Windows systems

Installing and running a FirePass controller component on Windows-based
systems requires certain user rights. Table 9.1 contains a list of the endpoint
inspectors, and shows the user rights required for downloading and
installing the associated components. Preinstalling components provides
seamless upgrade for clients after you upgrade the FirePass controller. For
information about preinstalling components, see Using MSI to preinstall
client components, on page 9-4.
You can use the component installer feature to provide completely
transparent installation and upgrading of components, regardless of the
rights under which the user is working. For more information about the
Component Installer, see Using the Component Installer, on page 9-4.
FirePass controller Power User Administrator

endpoint inspector Guest rights User rights rights rights
Check for Google Desktop No support OK OK OK
Extended Windows and No support OK OK OK

Internet Explorer info
Firewall check No support OK OK OK
Check for Antiviruses No support OK OK OK
Check Processes No support OK OK OK
Check Registry No support OK OK OK
Check Files No support OK OK OK
Switch to PWS No support OK OK OK
Check Time OK OK OK OK
Show virtual keyboard OK OK OK OK
UI mode OK OK OK OK
Check OS OK OK OK OK
Check client certificate OK OK OK OK
Write to logon log OK OK OK OK
Table 9.1 User rights requirements for endpoint inspector support
9-2
FirePass controller Power User Administrator

endpoint inspector Guest rights User rights rights rights
Send mail OK OK OK OK
External Far-end check Varies based on Varies based on Varies based on Varies based on
check required check required check required check required
Table 9.1 User rights requirements for endpoint inspector support
For client systems that have the inspector component pre-installed using the
MSI package, the requirements are the same. In cases in which user rights
are insufficient, although the system cannot download the update, the
previously installed component still works.
For the Java-based client adapters listed in the Table 9.2, Sun Java or
Microsoft Java must be installed on the user workstation.
FirePass controller component User rights Power User rights Admin rights
Cache cleanup OK OK OK
VT-xxxx legacy terminal (Java) OK OK OK
VT-3270 legacy terminal (Java) OK OK OK
TN-5250 legacy terminal (Java) OK OK OK
VT-320 legacy terminal (Java) OK OK OK
X11 UNIX adapter OK OK OK
Microsoft Terminal Server OK OK OK
Citrix Terminal Server OK OK OK
VNC OK OK OK
SSL-VPN (Network Access) Preinstall component Preinstall component OK

connector
Application connector OK, but system cannot OK, but system cannot OK
(host name) modify Hosts file modify Hosts file
Application connector OK OK OK
(IP address)
Table 9.2 User rights requirements for installing and running other FirePass controller components
For client systems that have the components pre-installed using the MSI
package, the requirements are the same. In cases in which user rights are
insufficient, although the system cannot download the update, the
previously installed component still works.

Chapter 9
Using MSI to preinstall client components

Your security policy may prohibit installing ActiveX components, or your
browser security policy may prohibit downloading active elements. For
these reasons, you might prefer to preinstall components on your users’
Windows systems.
You can use the Device Management : Client Downloads : Customize
Package screen to configure a Microsoft Installer Package (MSI) containing
the Windows controls needed for the various FirePass controller functions.
You can then download this package, and other packages, from the Device
Management : Client Downloads : Download screen.
This is valid only for Windows-based installations. There is no MSI
functionality for installing on client systems running other operating
systems.
The Client Downloads screen provides tabs for Customize Package,
Common Settings, Winlogon Integration, BIG-IP Edge Client™, Customize
Client Components, and Download. On the Customize Package tab, you can
specify the components you want in the downloaded package.
On the Winlogon Integration tab, you can specify options that govern
Windows logon integration. For more information, see the online help for
the Device Management : Client Downloads : Windows (x86) screens.
On the BIG-IP Edge Client™ and FirePass Legacy Client tabs, you can
configure options for the two available standalone clients. You configure
common settings for both clients on the Common Settings tab.
On the Download tab, you can review the selected components and start the
download operation. You can install downloaded packages onto client
computers, or you can copy the packages to a shared location so that
individual users can complete their own installation.
Using the Component Installer

You can use the Component Installer to install and upgrade client-side
FirePass controller components for all kinds of user accounts, regardless of
the rights under which the user is working. This component is especially
useful for installing and upgrading client-side components when the user has
insufficient rights to install or upgrade the components directly.
You must use an account that has administrative rights to initially install the
Component Installer on the client computer as a part of Client Components
Package (MSI). Once installed and running, the Component Installer
automatically installs and upgrades client-side FirePass controller
components. It can also update itself.
The Component Installer requires that the installation or upgrade packages
be signed using the F5 Networks certificate or another trusted certificate. By
default, F5 Networks signs all components using the F5 Networks
certificate. You can add your own certificate and use it to sign the
components. For more information, see Adding your own trusted certificates
to the F5FirePassRoot certificate store, following.
9-4
Adding your own trusted certificates to the F5FirePassRoot certificate store

The Component Installer service works with components only if they are
signed by the F5 Networks certificates. You can re-sign components with
your own trusted certificate and upload them on the FirePass controller
using the Code Signing tab on the Device Management : Customization
screen. When you add your trusted certificate to that store, the installer
service allows installation and upgrade of packages signed with your
certificate.
You can distribute the certificates to client computers using the Windows
utility certmgr.exe, or another certificate-distribution utility. For example,
you can specify the following command at the Windows command line to
add one trusted certificate:
certmgr /add /all /c fptrusts.cer /s /r localMachine F5FirePassRoot
The fptrusts.cer file name represents the name of the certificate file you
received from your Certificate Authority. The rest of the command should
be typed exactly as it appears. You can add multiple certificates by
specifying the command once for each certificate you want to add, or
include all certificates in the same file.
Installing Component Installer Service

The Component Installer Service is available as a separate Windows
Installer Package (MSI). This file is used for automated service deployment
in corporate environments.
Once installed, the service helps to provide a more seamless installation
experience. It automatically installs and updates signed FirePass controller
components on client systems.
On the navigation pane, expand Device Management, click Client
Downloads, select Windows (x86), and select the Download tab to
download the Component Installer Service MSI package
A user with administrative rights can install the MSI package by double
clicking the .msi file. An Installation Wizard guides the user through a
three-click installation.
The MSI package installs the F5 Component Installer Service and FirePass
controller Auto Update ActiveX components.
The user can see the current F5 Component Installer Service state using the
Service Management Tool from the Windows Control Panel/Administrative
Tool/Services area.
You can find a corresponding Purge log F5 Auto Update ActiveX Control
utility from %windir%\Downloaded Program Files.
To remove the installer service, use the Windows Add/Remove Programs
from the Control Panel.
The Installer service installs the following files:
• Windows Service Binary:
%windir%\system32\F5InstallerService.exe

Chapter 9
• FirePass controller Auto Update ActiveX component

%windir%\Downloaded Program Files\InstallerControl.dll
• FirePass controller Auto Update registration file
%windir%\Downloaded Program Files\InstallerControl.inf
• %tmp%\f5instal.txt (ActiveX Control)
• %windir%\TEMP\F5InstSrv.txt (Service)
Note
The Component Installer Service will likely not install the VPN drive on
Windows Vista because the driver is not signed. As a result, popups may
occur to which there will be no response by the FirePass controller.
Installing Windows CE (Pocket PC)

You can install the standalone client for the Pocket PC, distributed in the
form of a .cab package, directly to a device.
You can download the .cab file from either the Network Access webifyer or
by following these steps.
To download the .cab file

1. On the navigation pane, expand Device Management, click Client
Downloads, click Windows CE (Pocket PC), and select PN Client
for Windows Mobile.
2. Or, you can expand Device Management, click client Downloads,
click Windows CE (Pocket PC), and select the Download tab.
Note
For Pocket PC client downloads, you must manually configure split

tunneling (URI exceptions) configuration using the standard interface
provided by the client operating system. By default, all requests to URLs
containing no dots, for example, http://intranet or \\internal_network_site,
are considered requests to the work meta-network. If the dial-up connection
is the only connection configured for work meta-network, then Connection
Manager starts and uses it for such traffic.
If a client application does not use the Connection Manager API for
networking, users must establish the SSL VPN connection manually using
the provided Connection Manager interface.
9-6
Introducing BIG-IP Edge Client features

The BIG-IP Edge Client™ includes several features that are not available in
the web client. These features are especially useful for roaming users; that
is, users who take a laptop from one place to another, and wish to remain
connected to the corporate or company network as much as possible.
Understanding location awareness

The BIG-IP Edge Client™ provides a location awareness feature. Using
location awareness, the client connects automatically only when it is not on
a specified network. The administrator specifies the networks that are
considered in-network, by adding DNS suffixes to the client installer
download package. With a location aware client enabled, a user with a
corporate laptop can go from a corporate office, with a secured wireless or
wired network connection, to an offsite location with a public wireless
network connection, and maintain a seamless connection to allowed
corporate resources.
Understanding automatic reconnection

The BIG-IP Edge Client™ provides an automatic reconnection feature. This
feature attempts to automatically reconnect the users computer to corporate
network resources whenever the client connection is dropped or ended
prematurely.
Installing the BIG-IP Edge Client for Windows

Using the BIG-IP Edge Client™, users can access FirePass connections
without using a web browser. The client gives users seamless access to the
network access connection.
You can provide the BIG-IP Edge Client™ to your users after you configure
and download the package.
Connecting with the BIG-IP Edge Client

After a user installs the BIG-IP Edge Client™ for Windows, the user starts
the the client by choosing Start, then All Programs, then BIG-IP Edge
Client. If the client has not been configured with a list of FirePass controller
addresses, the user is prompted for an address.
When the client first starts, the client window appears, as in Figure 9.1, on
page 9-8.

Chapter 9
Figure 9.1 BIG-IP Edge Client™ screen
On the BIG-IP Edge Client™ screen, the client can configure the following
connection options:
• Auto-Connect
Starts a secure access connection as it is needed. This option uses the
DNS suffix information defined on the Device Management : Client
Downloads page, on the BIG-IP Edge Client™ tab, to determine when
the computer is on a defined local network. When the computer is not on
a defined local network, the remote access connection starts. When the
computer is on a local network, the client disconnects, but remains active
in the system tray. When you open the disconnected client, the message
Disconnected - LAN detected appears in the top pane of the client
window, as shown in Figure 9.1.
• Connect
Starts and maintains a secure access connection at all times, regardless of
your computer’s network location.
• Disconnect
Stops an active remote access connection, and prevents the client from
connecting again. After you click this option, a remote access connection
does not start again until you click one of the previous two options.
In addition, the client can click the Change Server button to change the
FirePass server.
Viewing BIG-IP Edge Client traffic and statistics

The BIG-IP Edge Client™ provides a simple throughput graph, as well as
more extended logging and statistic viewing features.
9-8
To view the remote access traffic throughput graph

1. If the client is minimized to the system tray, click the system tray
icon.
The BIG-IP Edge Client™ screen opens, as shown in Figure 9.1.
2. At the bottom of the client window, click the Show Graph button.
The BIG-IP Edge Client™ shows a graph of traffic throughput.
Figure 9.2 BIG-IP Edge Client™ screen with traffic graph expanded

Chapter 9
To view remote access traffic details

1. If the client is minimized to the system tray, click the system tray
icon.
The BIG-IP Edge Client™ screen opens, as shown in Figure 9.1.
2. At the bottom of the client window, click the View Details button.
The details pop-up screen opens, as shown in the figure, following.
Figure 9.3 BIG-IP Edge Client™ details screen
The Details screen provides four tabs that contain information relevant to
the operation of the BIG-IP Edge client. Click each tab to view the
information for that feature. The tabs are:
• Connection Details - Shows details of the current connection,
including status, server, tunnel details, and the amount of traffic sent and
received.
• Routing Table - Shows the current routing table for the client system.
• IP Configuration - Shows the current IP configuration for the client
system. The information in this tab is the same information you see when
you issue the command ipconfig /all at the Windows command
prompt.
• Miscellaneous - Shows version information for the client software, the
servers defined in the client, and the DNS suffixes used for network
location awareness.
9 - 10
Installing the FirePass legacy client for Windows

Using the FirePass legacy client, remote users can access your corporate
LAN without using a Web browser. The client gives users access to these
FirePass controller features:
• Network Access
• Application Access
• Terminal Services
You can use the Client Downloads screen to download the following
components:
◆ F5 Networks VPN Client for Windows
The F5 Networks VPN Client for Windows is a program that allows a
user to initiate and use Network Access, App Tunnel, and Terminal
Services sessions outside the context of an Internet browser. The F5
Networks VPN Client for Windows uses the FirePass controller API.
◆ F5 Networks Client COM API library
The F5 Networks Client COM API library is a set of routines that you
can use to construct standalone applications that allow the user to access
FirePass controller services. The API is provided as a C++ library. The
F5 Networks VPN Client for Windows uses the FirePass controller API
to provide the following functionality:
• Log on to the FirePass controller
• Get a list of authorized, preconfigured favorites
• Select a favorite
• Show parameters of the selected favorite
• Establish a connection to one or more favorites
• Mark a selected favorite to be connected automatically in subsequent
sessions
• Close favorites
• Log off of the FirePass controller
You can find descriptions of optional settings in the online help for the
FirePass Legacy Client screen. To access the screen, on the navigation pane,
expand Device Management, click Client Downloads, and select the
FirePass Legacy Client tab.
Note
You can type typically forbidden characters such as : * ? < > | in the
Network Access connection name box. However, use of these characters
prevents Windows Vista connections, although they are not a problem for
other Windows platforms.

Chapter 9
Understanding Windows XP and Vista 64-Bit VPN driver support

The following Windows VPN drivers are supported for specific 32-bit
Windows versions:
• WinNT4.0: urvpnnt.sys
• Win95: urvpn95.sys
• Win98/Me: urvpn9x.sys
• Win2k/XP/Win2003 Server: urvpndrv.sys
• Windows Vista: urvpnwlh.sys
The FirePass controller provides a custom VPN driver that mimics the
virtual ISDN dialup adapter used to support Network Access connections
with Microsoft Windows. New Windows operating system drivers are
available based on pre-existing functionality:
• Windows XP and Windows 2003 Server 64-bit AMD/Intel:
urvpnx64.sys
• Windows Vista 64-bit AMD/Intel: urvpnv64.sys
Note
The Intel Itanium 64-bit CPU is not supported.
If you use ActiveX, browser-based, client MSI package, or installation using

the urvpn.exe driver installer during initial Network Access client
installation, the correct version of the 640bit VPN drive is installed
automatically. All drivers for all supported platforms are included in the
urvpn.exe installer.
Installing the F5 Networks Client API

The F5 Networks Client API is a library that provides an interface and
methods for use by third-party applications. Using this API, the third-party
applications can access FirePass controller Network Access, App Tunnels,
and Terminal Server Connector favorites. Application vendors can use it to
provide seamless remote access from their proprietary application clients to
application servers inside a network accessible to the FirePass controller.
COM-aware third-party applications can invoke the F5 Networks Client
API. You can create COM-aware applications using any development
environment supporting COM and ActiveX controls; for example,
VisualBasic, VisualC++, and Delphi.
You can also use the F5 Networks Client API inside scripts, including
scripts of the following type: JavaScript, VBScript inside Internet Explorer,
and Windows Scripting Host.
For more information about using the F5 Networks Client API, and the
available interfaces, methods, and events, please visit F5 DevCentral at
http://devcentral.f5.com/. F5 DevCentral provides technical
documentation and tips, as well as a developer forum for posting feedback
and questions about using the F5 Networks Client API.
9 - 12
Using standalone client web logon

The FirePass controller standalone client web logon feature supports
pre-logon inspection and all available authentication methods (including
two factor authentication). Web logon also supports refreshing of expired
passwords and caching of user credentials and locally cached credentials.
The FirePass controller logon screen for the standalone client displays a
Save Password check box option that is controlled by client settings. An
administrator can encrypt user credentials with a per-user key and store the
credentials locally by checking this box. On subsequent logon, the logon
form boxes are automatically populated with the stored credentials. When a
user uses the command line interface or starts the FirePass controller
standalone client from a shortcut, the standalone client logs in automatically
without the user having to press the Submit button on the logon form.
The standalone client (in web-logon mode) displays the standard FirePass
controller logon screen inside the standalone client application frame. An
additional check box allows the user to save a password. An administrator
can hide this check box by disabling the Maintain History in the Client
Settings area.
Using proxy settings

Use the Common Settings screen to customize Windows client settings and
configure proxy settings. The following proxy settings are available:
• Use System Proxy Settings - Uses the Windows client proxy settings
configured in Internet Explorer to connect to the FirePass controller. This
option does not apply to the Windows Logon Integration settings.
• Use Custom Proxy Settings - Uses proxy settings determined by the
user. When you enable the custom proxy settings options, the client
attempts to use a configured option from start to finish, until a proxy
setting succeeds. For example, when you configure all the custom proxy
options, the client attempts to use a custom proxy option in the following
order, until one succeeds:
• Automatically Detect Proxy Settings - Client detects proxy settings
on the proxy server using the Web Proxy Auto-Discovery (WPAD)
protocol.
• Use Automatic Configuration Script - Client detects the proxy
settings using a configuration script at a specified URL.
• Use a Proxy Server - Specifies which proxy server the client uses to
connect to the FirePass controller.
• Address - Specifies the protocol and host name of the proxy

server.

Chapter 9
• Port - Specifies the port number of the proxy server.
Note
If you do not select an option under Use Custom Proxy Settings, the system
tries to connect directly.
Using Windows logon integration

For Microsoft® Windows 2000®, XP and later, you can use the Windows
dialer and Winlogon integration settings to specify the kind of VPN
connection to establish to the FirePass controller for either of two instances:
• Before the user logs on the PC using a virtual dial-up entry.
To use this feature, the user must enable the option Log on using the
dial-up connection at the Windows Logon prompt.
• When the user logs on to the PC.
The user’s Windows credentials are used for authenticating your network
access tunnels.
Windows logon integration includes these settings:
Dial-Up Entry Name
Specifies a unique dial-up entry name for the virtual dial-up connection.
Reconnect Attempts
Specifies the maximum number of reconnection attempts to the virtual
dial-up connection.
Time between Reconnect Attempts (sec):
Specifies the amount of time to wait for the client (in seconds) before the
system attempts to reconnect to virtual dial-up connection.
Display Progress while Connecting
Displays the progress of the virtual dial-up connection.
Prompt for User Name and Password
Prompts the user to enter his user name and password.
Include Windows Logon Domain
Includes the user's domain at the Windows logon screen.
Prompt for FirePass Controller Address
Prompts the user to enter the FirePass controller address. The address can
be a host name or an IP address.
Show Icon in Notification Area when Connected
Displays an icon to the user in the notification area when a virtual dial-up
connection is established.
If Connection Fails, Try Next Controller
If the connection fails, the system tries the next FirePass controller
specified in the FirePass Controller list.
9 - 14
Move Successful Controller to Top of List

When the user successfully connects to the virtual dial up connection
using the FirePass controller, the system moves this FirePass controller
to the top of the FirePass Controller list.
To configure Windows logon integration

1. In the navigation pane, click Device Management, expand Client
Downloads, and select Windows (x86).
2. Select the Customize Package tab.
3. Check the Windows Logon Integration check box, and click
Update.
4. Click the Common Settings tab.
5. Specify a list of FirePass controllers.
To add a FirePass controller, type the FirePass controller IP address
in the FirePass controller box, then click Add Controller.
6. Winlogon Integration tab.
7. Specify settings for Windows logon integration.
9. Click the Download customized package link to download the
package containing the Windows Logon Integration control.
Understanding the ICAP client

Internet Content Adaptation Protocol (ICAP) is an open standard for
Internet proxy servers to communicate with content servers. If your
corporate antivirus protection is based on an antivirus service that has ICAP
capability, the FirePass controller can install an ICAP client and use it for
upload inspection. If you select this option, you see several additional
settings. Use these settings to specify the host name, IP address, or path and
port of the ICAP server.
You specify the path and port of the ICAP server using all of this
information in the following format:
[icap://]<domain-name>[<:port>][/path]

Chapter 9
Examples of specifying a path and port for the ICAP server:

• abc.xyz.com - specifies the domain name
• abc.xyz.com:1345 - specifies the domain name and port
• abc.xyz.com:1345/avscan - specifies the domain name, port, and path
• abc.xyz.com/avscan - specifies the domain name and path
• icap://abc.xyz.com:1345/avscan - specifies the ICAP protocol, domain
name, port, and path.
To configure ICAP
1. In the navigation pane, expand Portal Access, click Content
Inspection, and select the Antivirus tab.
2. Select the Enable ICAP Client option.
3. Click Update.
The ICAP settings appear.
Using Macintosh and Linux clients with the FirePass

controller
The FirePass controller includes Network Access support for remote
Macintosh and Linux clients, so you can use the FirePass controller for
secure remote access in mixed-platform environments. As with the
Windows platform support, you do not need to preinstall or preconfigure
any client software when using FirePass controller with Macintosh and
Linux systems.
Introducing supported Network Access features

All of the primary Network Access features are supported on Macintosh and
Linux clients. For a list of Network Access features, see Configuring
Network Access resource group settings, on page 5-19. The FirePass
controller does not support Drive Mappings or Policy Checks features on
Macintosh and Linux systems.
For more information about Network Access and configuring Network
Access features, see Chapter 5, Configuring Network Access.
Features supported on Macintosh and Linux clients include:
• Secure remote access to your internal network, with support for IP-based
applications.
• Split tunneling, so only network traffic that you specify goes through the
9 - 16
• Packet-based and group-based IP filtering, giving you the ability to

restrict groups of users to specific addresses, ranges of addresses, and
ports.
• Compression, to reduce the amount of traffic passing between the remote
client and your internal network.
• Application launching.
You must configure the starting of remote client applications based on the
operating system on the remote computers. You can configure all other
features independent of the remote client operating systems. For details, see
Configuring the starting of applications on Macintosh or Linux clients,
following.
Configuring the starting of applications on Macintosh or Linux

clients
The launch application feature specifies a client application that starts when
the client begins a Network Access session. You can use this feature when
you have remote clients who routinely use Network Access to connect to an
application server, such as a mail server.
To configure the application start for Macintosh and Linux

1. In the navigation pane, click Network Access.
The Network Access Client Settings screen opens.
2. From the Resource group list (above the tabs), select the group for
which you are configuring application launch settings.
The screen refreshes to display the information for the group you
selected.
Note: The group must already exist in order to configure Network
Access for that group. For information on creating groups, see
Managing user information in an external data store, on page 2-6.
3. Click the Launch Application tab near the top of the screen.
The Launch Applications screen opens.
4. In the App Path box, type the path of the application.
For example:
• For Macintosh, type open.
• For Linux, type /usr/bin/mozilla.
5. In the Parameters box, type any parameters you want to include.
For example:
• For Macintosh, type /Applications/ie.app http://www.f5.com.
• For Linux, type http://www.f5.com.

Chapter 9
6. From the OS list, select an option.

• For Macintosh, select Mac.
• For Linux, select UNIX.
7. Click Add to add the configuration.
When remote users in the group make a Network Access
connection, the application you configured starts automatically.
Installing the client on Macintosh and Linux systems

The first time a remote user starts Network Access, the FirePass controller
downloads a client component. This client component is designed to be
self-installing and self-configuring, but the user’s browser must have Java
enabled on Macintosh systems, or have Mozilla or Firefox to install a plugin
on Linux systems.
If the browser does not support this requirement, the FirePass controller
prompts the user to download the controller client component from the
controller and install it manually. Users can find instructions on
downloading the components manually on the Network Access Help page,
available on their webtop after they log on to the FirePass controller.
Important
The remote user must have superuser authority, or must be able to supply an
administrative password in order to successfully install the Network Access
client.
Both Macintosh and Linux systems must also include PPP support (this is
most often the case). When the user runs the Network Access client and
makes a connection for the first time, the client detects the presence of pppd
(the point-to-point protocol daemon), and determines whether the user has
the necessary permissions to run it. If pppd is not present, or if the user does
not have permissions needed to run the daemon, the connection fails.
After installation, the Macintosh client must restart the browser before
launching Network Access.
Note
If you have a firewall enabled on your Linux system, you need to enable
access on IP address 127.0.0.1 port 44444.
9 - 18
Establishing client connections

Users can initiate connections through Network Access from Windows,
Linux, and Macintosh OS X systems, using various browsers. They can also
use Network Access from Windows mobile versions on PDAs and Pocket
PC phones.
For a list of browsers that Network Access supports, and a complete list of
the clients that the FirePass controller supports, see the most current version
of the release notes.
Important
When the user clicks a configured Network Access link, a small window
opens. It must remain open for the whole duration of the Network Access
session. If the user closes the window, it terminates the connection.
Note
On Microsoft Windows platforms, the user might also see a new network
connection icon in the system tray.

Chapter 9
Understanding Network Access error messages on

Macintosh or Linux clients
Macintosh or Linux clients might receive error messages while working
with Network Access connection. Table 9.3, following, contains a list of the
error messages as well as a description of their meaning and any
recommendations for resolving the error.
Error
code Meaning
1 Another Network Access client is already running

The client is either running or is in its shutdown stage. Wait a few
seconds, and try connecting again.
2 Invalid version format
3 Control channel timeout on wait state during handshake
4 Null input received by control channel
5 Control channel timeout while in session
6 Unrecognized command from control channel while in session
7 Unrecognized command from control channel during handshake
8 Deadlock detected while acquiring lock
9 Unrecognized command from plugin during handshake
10 Invalid command for handling bytes transmitted
11 Invalid command for handling bytes received
12 Control channel does not receive initial handshake
13 Network Access client does not start
14 Timeout on reading initial configuration from the FirePass controller
15 Invalid format on parameters from the FirePass controller
16 Invalid local IP address on parameters from the FirePass controller
17 Invalid local port on parameters from the FirePass controller
18 Invalid session ID format on parameters from the FirePass controller
19 No session ID was specified
20 Cannot resolve the FirePass controller IP address
Table 9.3 Network Access error codes on Linux or Macintosh clients
9 - 20
Error
code Meaning
21 The FirePass controller IP address was not specified
22 Control channel socket error
23 Control channel does not respond to default command
24 Control channel hangs on disconnection or does not respond
25 Unrecognized command from plugin while in session
26 Control channel window timeout
27 PPP daemon or the FirePass controller file descriptors have changed
28 SSL handshake with the FirePass controller failed
29 No DNS server was specified
30 Timeout while receiving command from plugin
31 Timeout while sending information to plugin
32 Signal caught
33 Invalid remote IP address on parameters from the FirePass controller
34 Timeout while writing to Network Access tunnel

Possible network reconfiguration caused the connection to the FirePass
controller to drop.
35 Timeout while reading from PPP daemon
36 Timeout while writing to PPP daemon
37 Timeout while reading from Network Access tunnel
38 Network Access client initialization error
39 Invalid split tunneling settings on parameters from the FirePass controller
40 Timeout while starting PPP daemon
41 PPP daemon does not exist on the host system

Verify that PPP daemon is installed or has been installed at the
non-standard location.
42 Cannot open pseudo terminal
Table 9.3 Network Access error codes on Linux or Macintosh clients

Chapter 9
Controlling the client using the command line

interface
You can access and control the Windows Standalone Client interactively or
using an API. Using the command line interface (CLI), you can employ
scripted applications to establish a Network Access connection, and to open
one or more App Tunnels.
The standalone client command line interface supports the following
commands:
• -start
Begins a FirePass controller session, logs on to the specified host, and
automatically runs the Network Access favorites specified in parameters.
For more information, see Using the -start command, following.
• -stop
Halts the specified session or specified favorite within a session. For
more information, see Using the -stop command, on page 9-25.
• -info
Posts to the screen information about sessions and favorites. For more
information, see Using the -info command, on page 9-27.
• -profile
Posts to the screen information about the profile specified. For more
information, see Using the -profile command, on page 9-31.
• -help
Posts to the screen information about the command line interface
commands. For more information, see Using the -help command, on page
9-32.
Using the -start command

You can use the -start command to begin a session with the FirePass
controller, log on to the controller, and run one or more favorites. The
command returns a 0 (zero) when successful, and writes the assigned
session ID to stdout.
You can specify that -start run in one of two modes.
• Blocked
Returns on failure or upon completion of a specified operation (for
example, session establishment or favorite start).
• Nonblocked
Starts the specified operation and immediately returns a value, without
waiting for the operation to complete. You can use the -info command to
get operation status at a later time.
9 - 22
Overview of -start command arguments

The -start command provides arguments for using a unique ID to start a
session or favorite, or a name to start a favorite. Table 9.4 contains a list of
the arguments that the -start command supports.
Parameter Alias Values Description Comment
/config /c String Specifies the configuration Uses the default program profile, if
profile file name. /conf is not specified.
/nonblock /nb None Turns on nonblocking mode. Returns immediately.
/host /h [http|https]host[:port] Represents the FirePass If no value is specified, uses the

[/landing_uri] controller host name. default value from the program
profile or presents a dialog box.
/user /u String Indicates the user name. If no value is specified, uses the
default value from the program
/password /p String Indicates the password. If no value is specified, uses the

default value from the program
/userhex /uh String Indicates the user name in If no value is specified, uses the
hex-encoded format. default value from the program
/passwordhex /ph String Indicates the password in If no value is specified, uses the
hex-encoded format. default value from the program
/mode /m [simple|advanced] Indicates the UI mode. Simple is the default mode.
/sid /s String Indicates the session ID. Starts a favorite in an already

established session.
/sid is a required parameter. All
other parameters are optional.
You can use the -info command
to get the /sid value.
/fid /f String Represents the favorite’s You can use the -info command
unique ID. to get the /fid value.
/fname /n name[:{vpn|apptunnel Indicates the name of the You can also specify a type if the
|terminal}] favorite to affect. name is not unique.
to get the /fname value.
/verbose /v None Enables verbose output to

stdout.
/minimize /t None Minimizes the window after

start.
Table 9.4 Command arguments for the -start command

Chapter 9
Process exit codes for the -start command

The process returns an exit code that indicates the status of the command.
Table 9.5 contains the value and description of each code that the -start
command returns.
Code Description
0x0 Operation completed successfully.
0x1 User terminated operation.
0x2 Authentication attempt failed.
0x4 Autolaunch operation failed.
0x8 User attention requested.
0x10 Favorite start failed.
0x100 Error unknown.
0x200 Parameter unknown.
0x300 Parameter value incorrect.
0x400 Session ID unknown.
0x500 Favorite ID unknown.
Table 9.5 Process exit codes for the -start command
Examples of using the -start command

This section presents examples of possible -start command sequences.
Note
You can get session and favorite ID values using the -info command.
Description
Runs the standalone client in simple mode and does not send a return value
until the system authenticates the user and establishes the session.
Command
f5fpc -start /h firepass.com:443 /u joe
Output
session id: 15
9 - 24
Description
Establishes a session named corp and starts the favorite named sales in
nonblocking mode.
Command
f5fpc -start /nb /h firepass.com /u joe /p password /m advanced /n corp:vpn /n
sales:apptunnel
Output
session id: 15
Description
Starts the favorite named sales in the already established session with a
session ID of 15.
Command
f5fpc -start /s 15 /n sales:vpn
Description
Starts the favorite whose favorite ID is 1 in the already established session
with a session ID of 345.
Command
f5fpc -start /s 345 /f 1
Using the -stop command

You can use the -stop command to halt the session or specified favorite.
Note

Chapter 9
Overview of -stop command arguments

The -stop command provides arguments for using a unique ID to halt a
session or favorite, or using a name to halt a favorite. You must specify a
session ID for all -stop commands. Table 9.6 contains a list of the
arguments that the -stop command supports.
/sid /s string Indicates the session ID. Halts the session as well as all
established favorites running in
the session.
/sid is a required parameter. All
other parameters are optional.
to get the /sid value.
/fid /f string Represents the favorite’s You must also include the /sid.
unique ID. You can use the -info command
to get the /fid value.
/fname /n name[:{vpn|apptunnel Indicates the name of the You must also include the /sid.
|terminal}] favorite to affect. You can also specify a type if the
name is not unique.
to get the /fname value.
Table 9.6 Command arguments for the -stop command
Process exit codes for the -stop command

Table 9.7 contains the value and description of each code that the -stop
command returns.
Code Description
Table 9.7 Process exit codes for the -stop command
9 - 26
Examples of using the -stop command

This section presents examples of possible -stop command sequences.
Note
Description
Closes the Network Access connection whose session ID is 15, and halts all
running favorites.
Command
f5fpc -stop /s 15
Description
Closes the Network Access connection whose name is corp, and halts all
running favorites.
Command
f5fpc -stop /s 15 /n corp:vpn
Description
Stops the favorite whose unique ID is 1 running in the session whose ID is
345.
Command
f5fpc -stop /s 345 /f 1
Using the -info command

The -info command provides information about sessions and favorites
running on the FirePass controller. You use the -info command to retrieve
session and favorite information to use in conjunction with the -start and
-stop commands.
Overview of -info command arguments

The -info command provides arguments for retrieving session or favorite
information and favorite names. The system presents information in the
following format:
session_id favorite_id favorite_type favorite_name status_code user_friendly_message
The following example illustrates a sample of the output that the -info
command returns.
15 1 vpn EMPLOYEE 0 available

Chapter 9
Table 9.8 contains a list of the arguments that the -info command supports.
/sid /s string Indicates the session ID. For -info commands that do not
contain a value for /sid, the
operation returns a list of all
sessions and statuses.
For -info commands that contain a
value for /sid, the operation
returns a list of favorites and their
status codes.
For -info commands that do not
contain a value for /fid or /fname,
the operation returns a list of all
favorites and status codes.
For -info commands that contain a
value for /fid or /fname, the
operation returns information
about that favorite only.
/fid /f string Represents the favorite’s You must also include the /sid.
unique ID.
/fname /n name[:{vpn|apptunnel Indicates the name of the You must also include the /sid.
|terminal}] favorite to affect. You can also specify a type if the
name is not unique.
Table 9.8 Command arguments for the -info command
Process exit codes for the -info command

Table 9.9 contains the value and description of codes that the -info
command returns.
Code Description
Table 9.9 Process exit codes for the -info command
Other codes returned depend on parameters specified.
9 - 28
Examples of using the -info command

This section presents examples of possible -info command sequences.
Description
Returns all active sessions.
Command
f5fpc -info
Output
there are 2 active sessions
session code status
15 1 session established
345 4 user should select host from presented list
Note
The code value returned represents the session status. For information
about session status codes, see Session status codes, on page 9-30.
Description
Returns the status and list of favorites for session whose ID is 15.
Command
f5fpc -info /s 15
f5fpc -info /s 15 /f 1
session code status
15 1 session established
session favorite type name code status
15 1 vpn network1 1 established
15 2 apptunnel AS400 0 available
15 3 apptunnel SALES 0 available
Description
Returns information about the favorite whose unique ID is 1, which is
running in the session whose ID is 15.
Command
f5fpc -info /s 15 /f 1

Chapter 9
Return
15 1 vpn network1 1 established
Note
The code value returned represents the favorite status. For information
about favorite status codes, see Session status codes, following.
Description
Returns information about the favorite whose name is sales, which is
running in the session whose ID is 15.
Command
f5fpc -info /s 15 /n SALES:apptunnel
Return
15 3 apptunnel SALES 0 available
Note
The code value returned represents the favorite status. For information
about favorite status codes, see Favorite status codes, on page 9-31.
Session status codes

Table 9.10 contains the value and description of session codes that the -info
command returns.
code status
0x1 Session established.
0x2 Logon in progress.
0x4 User must select the host from presented list.
0x8 Autolaunch in progress.
0x10 User attention required.
Table 9.10 Session status codes for the -info command
9 - 30
Favorite status codes

Table 9.11 contains the value and description of favorite status codes that
the -info command returns.
code status
0x0 Favorite not active.
0x1 Favorite running.
0x2 Favorite connecting.
0x10 Process requires attention.
Table 9.11 Favorite status codes for the -info command
Using the -profile command

Returns information from the profile configuration file. The profile contains
information such as FirePass controller IP address and gateway IP
addresses.
Overview of -profile command arguments

The -profile command provides an argument for specifying the
configuration file name. Table 9.12 contains a list of the arguments that the
-profile command supports.
/conf /c string Represents the configuration If no /conf value is specified, the operation
profile file name. uses the default current program profile.
Table 9.12 Command arguments for the -profile command
Process exit codes for the -profile command

Table 9.13 contains the value and description of codes that the -profile
command returns.
Code Description
Table 9.13 Process exit codes for the -profile command

Chapter 9
Code Description
Table 9.13 Process exit codes for the -profile command
Examples of using the -profile command

This section presents examples of possible -profile command sequences.
Description
Returns information about the FirePass controllers configured in the default
profile file.
Command
f5fpc -profile
Return
Name Address Port Description
Main 44.58.251.1 443 The main gateway
Asia 28.45.13.22 443 Asia gateway
Using the -help command

Returns help for a specific command.
Overview of -help command arguments

The -help command provides an argument for specifying the configuration
file name Table 9.14 contains a list of the arguments that the -help
command supports.
/help -? string Represents the command. If no command is specified,

/? displays a list of all commands.
Table 9.14 Command arguments for the -help command
9 - 32
Examples of using the -help command

This section presents examples of possible -help command sequences.
Description
Returns a list of all standalone client command line interface commands.
Command
f5fpc -help
f5fpc /?
Description
Returns help about the -start command.
Command
f5fpc -start /?
Description
Returns help about the -stop command.
Command
f5fpc -stop -help

Chapter 9
Using the command line interface on the client

You can configure the FirePass Windows Client for download to a user’s
computer.
To configure the FirePass Windows client for download

1. In the navigation pane, expand Device Management, expand
Client Downloads, click Windows (x86), and click the Customize
Package tab.
2. Check the FirePass Windows Client check box.
The Download screen opens.
4. Click the Download customized package link, and save the
f5fpcsetup.exe file to the location you want.
To configure Network Access favorites

1. In the navigation pane, expand Network Access, and click
Resources.
The Network Access Resources screen opens.
2. Configure Network Access favorites.
3. On the navigation pane, expand Application Access, expand App
The Application Tunnels screen opens.
4. Configure App Tunnel favorites.
To configure Network Access favorites

1. Log on to a client computer.
2. Double-click f5fpcsetup.exe, and follow the instructions to install
the FirePass Windows Client.
To use the FirePass Windows client command line

interface
1. Log on to a client computer.
2. To open a Windows command window, click Start, select Run, and
type cmd in the box.
The Windows command window opens.
3. At the command prompt, type cd /d "C:\Program Files\F5 VPN"
Include the quotation marks in the string you type.
9 - 34
4. Run a command.
The following are examples of commands you can run.
To do this At the command line, type:
f5fpc -help
List all FirePass controller Windows
Client command line interface
commands
f5fpc -info /?
List all options for the -info
command
f5fpc -start /h <FirePass> /u

Open a Network Access session <username> /p <password>
f5fpc -info
Get information about the current
Network Access session
f5fpc -info /s <session>

Use the session ID returned in the
previous command to get more
detailed information about this
session
f5fpc -start /s <session> /f

Start Network Access using a <favorite-id>
favorite ID returned in the previous
command
View the status of the open App f5fpc -info /s <session

Tunnel

previous command to get more
information about the session
f5fpc -start /s <session> /f

Open an App Tunnel using a <favorite-id>
favorite ID returned in the previous
command

View the status of the open App
Tunnel, at the command prompt
f5fpc -stop /s <session> /f

Use the favorite ID to close the App <favorite-id>
Tunnel
f5fpc -stop /s <session>

previous command to close the
current session, including the
Network Access connection
fpfpc -info
Get the session information again,
and confirm that the session has
been closed
Table 9.15 Process exit codes for the -start command

Chapter 9
Troubleshooting client components

A client utility is available to troubleshoot FirePass Windows client systems
and components. You can use it to collect debugging information for client
access issues. The tool is most useful for debugging App Tunnels and
Network Access.
To download the Client Components Troubleshooting

utility
1. In the navigation pane, click Device Management, expand Client
Downloads, and select Windows (x86).
3. Click the link to the Download Components Troubleshooting
Utility.
The utility has two working view panels; a left view and a right view. The
left view lists the System and Possible Client Components on that system.
And the right view lists a detailed view of a selected component or group.
Group information includes setup status for each component (installed, not
installed, or not properly installed). The detailed view displays the
component’s installed path (a status of not found displays if the path is
missing), the component version, file date, size, and status of the digital
signature.
When you select a system, the right view displays general system
information, including the operating system version, service packs, and so
on.
The Generate Report command from the File menu opens a text editor and
shows the following information:
• All information related to the component(s)
• General system information
• All the F5 Client Components log files
With the Enable logs option from the Tools menu, you can change the F5
log level of information to specify more detailed logs.
Use the Network Access Diagnostics option from the Tool menu to resolve
problems with Network Access issues. The Network Access Diagnostics
function scans the user system to gather information about the client
environment.
The Network Access Diagnostics feature performs three tests:
• Installation test
Checks for installation integrity —determines whether the SSL VPN
Driver (urvpndrv.sys) and IP Filter Driver (urfltw2k.sys) are installed
correctly, and checks DLL registration for: urxhost.dll, urxdialer.dll
and F5NAHelper.dll.
9 - 36
• Ping test
The Ping test performs an icmp echo to different hosts: external host by
name, by IP address, Loop back address (127.0.0.1) ping to default
gateway, and ping to DNS sever. It assumes that all ping tests are
successfully performed.
• Operating system network services test
Checks Windows network services status: DNS Client, Network
Connections, DNS Client, Remote Access Connection Manager, and
VPN driver as an urvpndrv service. Network Access requires that all
these services are in the running state.

Chapter 9
9 - 38
10
• Overview of FirePass controller reports
• Using the App Logs report
• Using the Group report
• Using HTTP Logs reports
• Using the Logons report
• Using the Sessions report
• Using the Summary report
• Using the System Logs report
• Understanding logging options

Overview of FirePass controller reports

You can display and print reports that describe FirePass controller activity
and status. You can also download and save a report as a Microsoft® Excel
(.xls) file.
You can find several types of reports on the Reports screen. To access the
reports screen, in the navigation pane, click Reports.
◆ Application Logs (App Logs) report
Provides aggregate and per-user access logs. For more information, see
Using the App Logs report, on page 10-2.
◆ Group report
Provides a snapshot of the user-group distribution and group-based usage
averages. For more information, see Using the Group report, on page
10-4.
◆ HTTP and HTTPS Logs report
Provides various types of server logs, such as a HTTP and HTTPS server
access logs, HTTP and HTTPS server error logs, and a SSL engine log.
For more information, see Using HTTP Logs reports, on page 10-6.
◆ Logons report
Provides a list of all attempts to log on to the FirePass controller. For
more information, see Using the Logons report, on page 10-10.
◆ Sessions report
Provides a list of all active user sessions and a history of sessions, along
with the corresponding user names, logon names, times, and status. For
more information, see Using the Sessions report, on page 10-12.
◆ Summary report
Provides a summary of global or group-based user activity, including
statistics, and descriptions of browser-type usage over specified periods
of time. For more information, see Using the Summary report, on page
10-16.
◆ System Logs report
Displays local system logs. If you use an external syslog server, you must
configure your FirePass controller to generate log errors locally. For
more information, see Using the System Logs report, on page 10-18.
For information about archiving and purging logs, see the online help for the
Device Management : Maintenance : Logs screen.

Chapter 10
Using the App Logs report

The App Logs report contains a list of entries indicating actions that users,
administrators, and superusers perform on the FirePass controller. You can
use the App Logs report to track user activity on the FirePass controller.
To display the App Log report

1. In the navigation pane, click Reports, and click App Logs.
The App Logs report screen opens.
2. Choose the options you want or download the log.
For more information about App Logs report options, see Working
with the App Logs report, following.
Working with the App Logs report

You have several options when working with this particular report. You can
take any one of these actions, several of them, or all of them.
• To download and open the report as an Excel (.xls) file, click the
Download report data link.
The process starts the local or browser-based Excel application and
opens the report.
• To save the report locally on a Windows-based computer, right- click the
Download report data link, and then follow the instructions to save the
report to your local desktop.
• In reports that contain more than 20 records, navigate to other screens by
clicking the navigation buttons at the top of the screen for First ,
Previous , Next , and Last .
• To filter the report for a specific user, click the link representing the
user’s name in the Logon column.
To show all users again, click the Show all records link at the top of the
report.
• To display details about a specific session, click a link in the Session ID
column.
To return to the App Logs screen, click the Back to Reports : App Logs
page link at the top of the screen.
Understanding entries in the App Logs report

Each entry in the App Logs report contains data that identifies one action or
operation by a user. The FirePass controller records all user operations. You
can use the contents of this log to monitor user activity on the FirePass
controller.
The log contains several types of data.
10 - 2
• Time
Represents the start date and time of the associated session. A typical
Time value looks similar to the following example: 10/25/2005 0:28.
• Source IP
Represents the IP address where the session originated. A typical Source
IP looks similar to the following example: 192.168.12.10.
• Logon
Represents the name for the logged on user who originated the session. A
typical Logon looks similar to the following example: joeu
• Session ID
Represents the unique identifier assigned to the session. A typical
Session ID looks similar to the following example: f8e63
• Record
Represents a single action recorded for the associated user. A typical
Record looks similar to the following example: [594330] Access menu
App Logs.
• User agent string
Represents the string the browser returns to identify itself. A typical User
agent string looks similar to the following example: Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1; SV1).

Chapter 10
Using the Group report

The Group report provides a snapshot of the user-group distribution and
group-based averages. The FirePass controller records activity for each
group.
To work with the Group report

1. In the navigation pane, click Reports, and click Group Report.
The Group report screen opens.
For more information about Group report options, see Working with
the Group report, following.
Working with the Group report

opens the report.
• To specify a varying date range for the Group report:
• Select starting date from the Reporting period from lists.
• Select the ending date from the to (inclusive) lists.
• Click the Apply button .
• To restrict the report to a predefined date range, click the Last Week,
Last 2 Weeks, Last Month, or Last Year links.
The dates in Reporting period from and to (inclusive) change to reflect
the predefined range.
Understanding entries in the Group report

Each entry in the Group report contains data that identifies how users from
the various master groups have used the FirePass controller. You can use the
contents of this log to determine the activity level of each master group on
the FirePass controller. If no users from a specific master group logged on
during the report interval, there is no entry for that group in the report.
The Group log contains several types of data.
• Group
Represents the name of the master group. A typical Group value looks
similar to the following example: Default.
10 - 4
• Users
Represents two variables: the number of user accounts in the master
group shown in the Group value, and the percentage of the total users in
all master groups. A typical Users entry looks similar to the following
examples: for user accounts: 9, and for percent of total: 67%.
• Sessions
Represents the two variables: the total number of logons by users in the
master group shown in the Group value, and a percentage of the total
logons for users in all groups. A typical Sessions entry looks similar to
the following examples: total: 15, and for percent of total: 92%.
• Avg. Time at
Shows a calculated average of time spent on the FirePass controller
webtop. The entry is a number representing the average number of
seconds in each mode during the reporting period.
• Favorite webifyer
Represents the unique identifier assigned to the session. Some possible
values include Windows Files, Terminal Servers, and Web Applications.

Chapter 10
Using HTTP Logs reports

The HTTP Logs report provides several types of server logs. You can use
entries from various logs to monitor the HTTP activity on the FirePass
controller.
• HTTP server access log
• HTTP server error log
• HTTPS server access log
• HTTPS server error log
• SSL engine log
The FirePass controller updates content in the logs in the HTTP Log report
in real-time. You can use an online calendar to select the day for which you
want to display a HTTP Log report.
To work with the HTTP Logs report

1. In the navigation pane, click Reports, and click HTTP Logs.
The HTTP Logs report screen opens.
For more information about HTTP Logs report options, see Working
with the HTTP Logs report, following.
Working with the HTTP Logs report

• To sort the list, click the Date, Class, IP, ID, or Text column at the top of
the report.
• From the list at the top of the screen, select a log type, and then click the
the Apply button .
• To download the log, click the log name link at the top of the report, and
follow the instructions to open or save the report.
• To reveal the page-navigation and online calendar boxes, click the
Reveal button . Then do any of the following:
• To display a specific page, type the page number in the Select Page
box, and then click the go button.
• To specify the number of records per page, type the number of records
in the Records Per Page box, and then click the go button.
• Click the Calendar link, and click the date for which you want to
display the report.
• To display additional records in the report, click the Previous button ,
or the Next button at the top or bottom of the report to view the
previous or next 20 records.
10 - 6
Understanding entries in the HTTP Logs report

The HTTP Logs report provides access to several logs containing different
types of data. Each entry in the HTTP Logs report contains data that
describes the HTTP commands that the FirePass controller runs. The HTTP
Logs report consist of several logs.
• Server access log (http)
• Server error log (http)
• Server access log (https)
• Server error log (https)
• SSL engine log
Understanding the Server access log (http) log

You can download extra-access_log to view the content of the Server
access log (http). To download the log, click the log name at the top of the
table.
The Server access log (http) contains several types of data.
• Date
Date value looks similar to the following example:
[24/Oct/2005:00:17:48 -0700].
• Class
Represents the class of event associated with the entry in the log. The
Server access log (http) does not have any associated Class values.
• IP
Represents the IP address where the session originated. A typical IP
looks similar to the following example: 192.168.12.10.
• ID
Represents the unique identifier assigned to the log entry. A typical ID
value looks similar to the following example: 400.
• Text
Represents the HTTP command that the FirePass controller processed. A
typical Text value looks similar to the following example: "GET
/vdesk/admincon/index.php?a=welcome&click=1 HTTP/1.1" 200
3095.
Understanding the Server error log (http) log

You can download extra-error_log to view the content of the Server error
log (http). To download the log, click the log name at the top of the table.
The Server error log (http) contains several types of data.
• Date
[24/Oct/2005:00:17:48 -0700].

Chapter 10
• Class
Represents the class of event associated with the entry in the log. A
typical Class value looks similar to the following example: notice.
• IP
• ID
• Text
Represents the HTTP command that the FirePass controller processed. A
typical Text value looks similar to the following example: "CONNECT
10.4.10.10:81 HTTP/1.0" 200 0.
Understanding the Server access log (https) log

You can download https.extra-access_log to view the content of the Server
access log (https). To download the log, click the log name at the top of the
table.
The Server access log (https) contains several types of data.
• Date
[24/Oct/2005:00:17:48 -0700].
• Class
Represents the class of event associated with the entry in the log. The
Server access log (https) does not have any associated Class values.
• IP
• ID
• Text
Represents the HTTPS command that the FirePass controller processed.
A typical Text value looks similar to the following example: "GET
/vdesk/admincon/stats.php?a=lo&exp=&newpage=29&newerrpp=20
&newfilen=2&sorttype=&go=1 HTTP/1.1" 200 13180.
Understanding the Server error log (https) log

You can download https.extra-error_log to view the content of the Server
error log (https). To download the log, click the name at the top of the table.
The Server error log (https) contains several types of data.
10 - 8
• Date
[24/Oct/2005:00:17:48 -0700].
• Class
typical Class value looks similar to the following example: notice.
• IP
Represents the IP address where the session originated. The Server error
log (https) does not show any IP values.
• ID
Represents the unique identifier assigned to the log entry. The Server
error log (https) does not show any ID values.
• Text
Represents the HTTPS command that the FirePass controller processed.
A typical Text value looks similar to the following example: Apache
configured -- resuming normal operations.
Understanding the SSL engine log

You can download ssl_engine_log to view the content of the SSL engine
log. To download the log, click the log name at the top of the table.
The SSL engine log contains several types of data.
• Date
[24/Oct/2005:00:17:48 -0700].
• Class
typical Class value looks similar to the following example: error.
• IP
Represents the IP address where the session originated. The SSL engine
log does not show any IP values.
• ID
• Text
Represents errors that the SSL engine sent to the FirePass controller. A
typical Text value looks similar to the following example: System: No
such file or directory (errno: 2).

Chapter 10
Using the Logons report

The Logons report provides a list of attempts to log on to the FirePass
controller, both successful and unsuccessful.
You can filter the report for unsuccessful attempts, which quickly provides
an audit trail for detecting access attempts by unauthorized sources. In
addition, the FirePass controller administrator receives a security alert
message if a specified number of unsuccessful attempts (default 20) to log
on occur within a configurable interval (default 5 minutes). You can change
the number of unsuccessful attempts and configure the interval on the User
Access Security screen, available under Security in the navigation pane.
To work with the Logons report

1. In the navigation pane, click Reports, and click Logons.
The Logons report screen opens.
For more information about Logons report options, see Working
with the Logons report, following.
Working with the Logons report

opens the report.
• To save the report locally on a Windows-based computer, right-click the
• To filter the report for unsuccessful logon attempts, click the Show
Failures link.
To show all logon attempts, click the Show All link.
To display details about a particular logon attempt, click the link for the
user’s name.
Understanding entries in the Logons report

Each entry in the Logons report contains data that describes the Logons on
the FirePass controller. You can use the contents of this log to monitor logon
activity on the FirePass controller.
10 - 10
The Logons report contains several types of data.

• Logon
Represents the name for the logged-on user who originated the session.
A typical logon looks similar to the following example: joeu.
• Valid user?
Indicates whether the user who attempted the operation was recognized
as a user on the FirePass controller. Values for Valid user are Yes and
No.
• Passed?
Indicates whether the logon attempt succeeded. Values for Passed are
Yes and No.
• Name
Represents the values from the First Name and Last Name settings in the
user’s details. If the FirePass controller cannot determine an associated
user, the Name column contains N/A.
• Time (<time_zone>)
Represents the start date and time of the associated session, represented
in the time zone configured for the controller. A typical time value looks
similar to the following example: 10/25/2005 0:28.
• User agent
Represents the string the browser returns to identify itself. A typical User
agent string looks similar to the following example: Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511.
• From
Represents the IP address where the session originated. A typical From
value looks similar to the following example: 10.40.11.4.

Chapter 10
Using the Sessions report

The Sessions report provides various types of reports for user sessions and a
history of sessions, along with the corresponding user names, session
duration, and status.
To display the Session report

1. In the navigation pane, click Reports, and click Sessions.
The Sessions report screen opens.
For more information about Sessions report options, see Working
with the Sessions report, following.
Working with the Sessions report

opens the report.
• To have the data update every 20 seconds, check the Refresh every 20
sec check box.
• To filter the list for a specific user, type a logon name in the Show
sessions for box, and then click the magnifying glass .
To show all users, clear the Show sessions for box, and then click the
magnifying glass .
• To show a list of currently active sessions, click the Currently active tab.
On the Currently active tab, you can halt a specific session by clicking
the associated Kill link at the end of the row.
• To show a list of the sessions for the current day, click the Today’s
sessions tab.
On the Today’s sessions tab, you can get details about a specific session
(such as browser type or IP address) by clicking a date link in the Start
column.
10 - 12
• To show a list of all sessions that have occurred, click the Complete
History tab.
On the Complete History tab, you can get details about a specific session
(such as browser type or IP address) by clicking a date link in the Start
column.
• To show daily aggregate session counts, click the Session Summary tab.
On the Session Summary tab, you can get details about a specific session
by clicking a link in the Date column.
Understanding entries in the Sessions report

Each entry in the Sessions report contains data that describes session activity
on the FirePass controller. You can use the contents of these logs to monitor
sessions on the FirePass controller.
The Sessions report provides access to several logs containing different
types of data.
Understanding the Currently active log

The Currently active log contains a list of the active connections to the
FirePass controller. The logs contains several types of data.
• Name
user’s details. If the FirePass controller cannot determine an associated
user, the Name column contains N/A.
• Logon
Represents the name for the logged on user who originated the session. A
typical logon looks similar to the following example: joeu.
• Start Time (<time_zone>)
in the time zone configured for the controller. A typical Start Time value
looks similar to the following example: 10/25/2005 01:21:54.
• Expiration Time (<time_zone>)
in the time zone configured for the controller. A typical Expiration Time
value looks similar to the following example: 10/25/2005 001:21:54.
• Status
Indicates the status of the associated session. A typical Status value looks
similar to the following example: Logged on server.
• Id
Represents the unique identifier assigned to the session. A typical ID
value looks similar to the following example: f8e63.

Chapter 10
Understanding the Today’s sessions log

The Today’s sessions log contains a list of the active connections to the
FirePass controller. The Today’s sessions report contains several types of
data.
• Start (<time_zone>)
in the time zone configured for the controller. A typical Start value looks
similar to the following example: 10/25/2005 01:21:54.
• User
Represents the logon name of the logged on user who originated the
session. A typical User value looks similar to the following example:
joeu.
• Name
user’s details.
• Duration
Represents the length of the session, in the format HH:MM:SS, where
HH represents the hour, in 24-hour format, MM represents the minutes,
from 1 through 60, and SS represents the seconds, from 1 through 60. A
typical Duration value looks similar to the following example: 00 24 43.
• From
• To
Indicates the type of connection requested. A typical To value looks
similar to the following example: MyNetwork.
• Status
Indicates the status of the session. A typical Status value looks similar to
the following example: Server session in progress.
Understanding the Complete history log

The Complete history log contains a list of the active connections to the
FirePass controller. The Complete history report contains several types of
data.
• Start (<time_zone>)
in the time zone configured for the controller. A typical Start value looks
similar to the following example: 10/25/2005 01:21:54.
• User
Represents the logon name of the logged on user who originated the
session. A typical User value looks similar to the following example:
joeu.
• Name
user’s details.
10 - 14
• Duration
Represents the length of the session, in the format HH:MM:SS, where
HH represents the hour, in 24-hour format, MM represents the minutes,
from 1 through 60, and SS represents the seconds, from 1 through 60. A
typical Duration value looks similar to the following example: 00 24 43.
• From
• To
Indicates the type of connection requested. A typical To value looks
similar to the following example: MyNetwork.
• Status
Indicates the status of the session. A typical Status value looks similar to
the following example: Logged out from server.
Understanding the Session summary log

The Session Summary log contains a list of the active connections to the
FirePass controller. The Session Summary report contains several types of
data.
• Date
Indicates the date of the session summary. A typical Date value looks
similar to the following example: 10/25/2005.
• Min
Indicates the smallest number of connections (greater than 0) that
occurred on the date indicated. The value in Min is a number.
• Avg
Indicates the average number of connections that occurred on the date
indicated. The value in Avg is a value calculated based on the number of
connections, divided by the number of hours in a day.
• Max
Indicates the largest number of simultaneous connections that occurred
on the date indicated. The value in Max is a number.
The Sessions Summary screen also contains the number of access requests
the FirePass controller processed as well as a visual representation of the
maximum number of simultaneous connections.

Chapter 10
Using the Summary report

The Summary report provides a summary of global or a group-based user
activity, including stats and descriptions of operating system and browser
type usage over specified periods of time. You can also display optional bar
graphs in the report.
To display the Summary report

1. In the navigation pane, click Reports, and click Summary Report.
The Summary report screen opens.
For more information about System Logs report options, see
Working with the Summary report, following.
Working with the Summary report

• From the For the group list, select the group that you want to create a
Summary report for.
opens the report.
• To specify a varying date range for the Summary report:
• Select starting date from the Reporting period from lists.
• Select the ending date from the to (inclusive) lists.
• Click the Apply button .
• To include bar graphs in the report, check the Show graphs check box.
• To restrict the report to a predefined date range, click the Last Week,
Last 2 Weeks, Last Month, or Last Year links.
The dates in Reporting period from and to (inclusive) change to reflect
the predefined range.
Understanding entries in the Summary report

The Summary report screen provides a number of aggregated statistics of
various types. You can select varying reporting periods from the predefined
lists.
10 - 16
• Stats
Provides measurements of various activity, such as total sessions,
average FirePass controller session, and average number of sessions per
week.
• Daily Activation
Shows the breakdown of logon activity by day of the week, from Sunday
through Saturday.
• User Activity Totals
Shows the breakdown of user activity, from high activity to inactive,
including the number of users and the percentage of total users they
represent.
• Browser Type
Indicates the type of browser used to log on and the number of users who
used each type.
• OS Type
Indicates the type of operating system used to log on and the number of
users who used each type.
• Session terminations
Indicates the number of sessions that ended for each method of ending.
• Feature Access
Indicates how the users used the sessions with the FirePass controller. A
typical value in the Feature Access table is Administrative Console.

Chapter 10
Using the System Logs report

The System Logs report displays local system logs. If you use an external
syslog server, you can configure the FirePass controller to log errors locally.
You can use the Device Management : Maintenance : Logs screen to specify
and configure an external syslog server.
To display the System Logs report

1. To access the System Logs report, in the navigation pane, expand
Reports, and click System Logs.
The System Logs report screen opens.
For more information about System Logs report options, see
Working with the System Logs report, following.
Working with the System Logs report

• From the Period list, select the month to include when creating the
Summary report.
• From the Source list, select the category to include when creating the
Summary report, or select All to include all categories.
opens the report.
Understanding entries in the System Logs report

The System Logs report screen provides a number of aggregated statistics of
various types. You can select varying reporting periods from the predefined
lists.
• Date
Indicates the date on which the FirePass controller logged the entry. A
typical Date value looks similar to the following example: Oct-25.
• Time
Indicates the time, in 24-hour format, at which the FirePass controller
logged the entry. A typical Time value looks similar to the following
example: 1:30:08.
10 - 18
• Source
Indicates the origin of the logged entry. A typical Source value looks
similar to the following example: firepass.
• Message
Indicates the type of activity the logged entry represents. A typical
Message value looks similar to the following example:
[-] FirePass service started on firepass.siterequest.com.

Chapter 10
Understanding logging options

The following logging options and database control features are available
from the Device Management : Maintenance : Logs screen.
• Disable database logging
When checked, this option disables database logging in the FirePass
controller. When log messages are disabled, the system can achieve
better performance, such as an increase in authentications per second.
• Disable local system logging
When checked, this option disables local system logging from the
• Logging levels (Emergency, Alert, Critical, Error, Warning, Notice,
Information)
For each FirePass component (Application Access, Endpoint Security,
Portal Access, and so on), there is an option list from which you can
select a logging level per component.
• HTTP and SSL logging options
This HTTP logging option includes an on or off toggle for HTTP Access
Logs, selectable HTTP Error Log levels (Emergency, Alert, Critical,
Error, Warning, Notice, Information), and SSL Engine log levels (Error,
Warning, Information).
• Purge logs
This displays the last-purged and next-purged schedule near the top of
the Purge logs area. The actual interval and day posted depends on the
option selected in Keep logs for list, and the dates applicable to your set
up.
• Temporary archive storage
When enabled, you can create new archives and transmit those archived
logs in several ways: E-Mail, FTP, and SCP.
• Local logs
This provides options for logging for applications.
• System logs
This provides options to log user activity and system events to a remote
system log server.
10 - 20
11
• Understanding FirePass controller high availability
• Configuring the active FirePass controller
• Configuring the standby FirePass controller
• Post-configuration tasks
Understanding FirePass controller high availability

A failover configuration is ideal for providing high availability for one site
at a single location. High availability is the process of ensuring access to
resources despite any failures or loss of service in the setup. For hardware,
high availability is ensured by the presence of a redundant system, a
configuration that transfers service to another piece of hardware in the event
of failure on the first piece of hardware.
Two FirePass controllers have the capacity to act as a redundant system, or
failover pair: two identically configured controllers working together to
provide a higher degree of availability than a standalone controller for
remote users.
A redundant system of FirePass controllers is composed of one controller in
an active state, and one in a standby state, at any given moment. The active
controller serves all requests from users. If the active controller fails, the
standby controller takes over the active role. This process of transferring
control from one device to another is called failover.
You can configure a redundant system as a pair of newly acquired
controllers, or you can expand your current setup into a failover
configuration.
Important
If you plan to introduce a failover configuration into your environment, and
your configuration is already in production, you should review Introducing
a failover member into a production environment, on page 11-5 before
continuing.
For organizations with larger sites and multiple locations with FirePass
controllers, a cluster of FirePass controllers can provide additional
scalability of a high-availability configuration. For more information about
clustering, see Understanding FirePass controller clusters, on page 12-1.
Introducing failover configuration

This chapter assumes you already have installed the FirePass controllers and
have completed their initial network configuration by running Quick Setup.
For Quick Setup information, see the FirePass Controller Getting Started
Guide, available as a separate document on the F5 Networks Technical
Support Web site, https://support.f5.com. For initial network configuration
information, see Configuring web services, on page 8-20 of this guide.
The procedures in this chapter guide you through the process of completing
failover configuration for a pair of FirePass controllers. Once the controllers
are properly configured for failover, you need to make subsequent
configuration changes only on the active controller. The active controller
synchronizes information on the standby controller, except network
configuration and SNMP configuration.
These are the requirements for configuring failover for a pair of FirePass
controllers:

Chapter 11
• You must have two FirePass 1000, 1200, 4000, 4100, or 4300 systems
available.
• Each member of the redundant system must be running the same
software version.
• Either both systems have identical features licensed, or one of the two
units is licensed as a failover-only FirePass controller.
Important
If you have a failover-only controller, you must configure it second. For
more information, see Configuring the standby FirePass controller, on
page 11-15.
Reviewing the configuration process

To configure the failover settings on the FirePass controllers, you need to
complete several tasks, in order.
This section presents an overview of the configuration process and links to
procedures containing specific steps.
The process for setting up failover has three main tasks.
• First you configure the active FirePass controller.
• Then you complete similar tasks to configure the standby FirePass
controller.
• Once both controllers are configured, you will want to verify the
configuration.
Important
If you plan to introduce a failover configuration into your environment, and
your configuration is already in production, you should review Introducing
a failover member into a production environment, on page 11-5 before
continuing.
Reviewing the configuration of the active failover member

The first part of the failover configuration process involves setting up the
active member of the redundant system.
◆ Enable failover
Enabling failover is the first task in configuring the active controller.
There are two parts to this task, each of which is covered in Enabling
failover on the active controller, on page 11-7.
• Activating failover.
You must activate the failover option and restart the controller to
enable additional failover screens.
11 - 2
• Configuring a fully qualified domain name (FQDN)

You must make sure that the controllers in a redundant system share a
name.
◆ Configure a device-specific, self IP address
This is part of the initial installation and configuration tasks, but if you
have not already done so, configure at least one device-specific (that is,
not virtual), self IP address for each interface and VLAN interface you
plan to use for failover. For more information, see Configuring the active
controller with a self IP address, on page 11-9.
Note: If you change an IP address on a VLAN interface, verify that the
configuration is using the new IP address on the synchronization agent
and for the heartbeat.
◆ Configure a shared, virtual IP address
Configure the active controller with a shared or virtual IP address. A
shared or virtual IP address is a shared identifier of a computer. The
active controller and the standby controller share this IP address, so that
either controller can assume the shared IP address when it is the active
controller. For more information, see Configuring the active controller
with a shared IP address, on page 11-10.
Then you must finalize the changes and restart the controller before
continuing. For more information, see To finalize the setup, on page
11-8, and To restart the controller or service, on page 11-8.
◆ Configure entries on your Domain Name Service (DNS) server
You complete this part of the process on your network’s DNS server, not
on the FirePass controllers.
On your DNS server, create an entry that maps the FQDN of the pair to
the shared IP address, and create entries for each device using the self IP
address.
The FirePass controller creates host names for each physical device by
appending numbers. You must create a DNS entry for each of these
names using each device’s self IP address. If the FQDN you are using is
Failover, the FirePass controller assigns Failover-1 to the first redundant
system member and Failover-2 to the second one. You will need DNS
entries for each.
◆ Add and configure web services, and specify a synchronization
service
When you have configured a self IP and a shared IP address on the active
controller, you can configure web services associated with each IP
address. You also need to make some configuration changes and specify
a synchronization agent for web services on the self IP address. For more
information, see Configuring web services for the IP addresses of the
active controller, on page 11-10, and Configuring a web service as a
synchronization agent for the active controller’s self IP address, on page
11-12.
◆ Configure the heartbeat
The heartbeat is a activity indicator signal that the active controller
broadcasts to the subnet, where the standby controller receives it. For

Chapter 11
information about configuring the heartbeat, see Configuring the active

controller’s heartbeat, synchronization, and miscellaneous settings, on
page 11-13.
◆ Finalize and restart the active controller
After configuring web services, you must finalize and restart the
controller.
Restarting the controller puts the failover configuration changes into
effect and reveals additional failover screens and settings. For more
information, see To finalize the setup, on page 11-8, and To restart the
controller or service, on page 11-8.
Reviewing the configuration of the standby failover member

The second part of the failover configuration process involves setting up the
standby member of the redundant system.
◆ Enable failover
Follow the procedure steps shown in Enabling failover on the standby
This is how you configure the controller that has the failover-only
license.
◆ Configure the self IP address
Follow the procedure steps shown in Configuring the standby controller
with a self IP address, on page 11-17.
◆ Configure a shared IP address
Follow the procedure steps shown in Configuring the active controller
◆ Check the FQDN
For more information, see Enabling failover on the active controller, on
page 11-7.
◆ Configure DNS server entries
For more information, see Configure entries on your Domain Name
Service (DNS) server, on page 11-3.
service
Follow the procedure steps shown in Configuring web services for the IP
addresses of the active controller, on page 11-10, and Configuring a web
service as a synchronization agent for the active controller’s self IP
Follow the procedure steps shown in Configuring the active controller’s
heartbeat, synchronization, and miscellaneous settings, on page 11-13.
For more information, see To finalize the setup, on page 11-8, and To
restart the controller or service, on page 11-8.
11 - 4
Reviewing the verification process

When you have configured both the active and standby controllers, verify
that the configuration is working correctly. For more information, see
Verifying the failover configuration, on page 11-20.
WARNING
If you are configuring failover in a production environment, the order in
which the pair of controllers restart is very important, and can result in data
loss if the two controllers do not restart in the correct order. For more
information, see Introducing a failover member into a production
environment, following.
Introducing a failover member into a production environment

If you are creating a redundant system by configuring one new controller
and one existing controller, make sure to carefully watch when the units
restart so that you never let the new, potentially partially configured
controller take over accidentally. Restarting the active controller causes the
standby to take over, which erases all configuration on the previously active
controller.
Note
Always back up any production controller before configuring failover. You

can read more about backing up the FirePass controller in Backing up and
restoring the FirePass controller, on page 8-47.
Once you enable failover and configure the IP addresses for the active and
standby controllers, the process of restarting one controller fails over
automatically to the other one. Failover configuration requires a system
restart.
A good strategy to follow when deploying a FirePass controller high
availability configuration has three parts:
• Configure one FirePass controller for failover, typically, the existing one
you have in production, and then shut it down.
• Configure the second FirePass controller, and then shut it down.
• Restart the controller that you want to serve as the active failover
member, and then start the standby controller.

Chapter 11
You can use the backup and restore feature to set up redundant system.
Backup and restore transfers settings to a one or more FirePass controllers.
Even though you transfer settings, you must still complete other
configuration tasks. For more information, see Reviewing the configuration
process, on page 11-2.
Important
When you restore the backup, do not restore the network settings to the
standby controller.
Note
For more information on using the backup and restore feature, see Backing
up and restoring the FirePass controller, on page 8-47. For more
information about using the backup and restore feature to transfer identical
settings to a number of FirePass controllers, see the Configuring the
BIG-IP System with FirePass Controllers for Load Balancing and SSL
Offload document on the Solution Center at the F5 corporate web site,
11 - 6
Configuring the active FirePass controller

When setting up a failover configuration, your first set of tasks are
performed on the active controller.
Before configuring failover settings on the active controller, make sure both
the active and standby controllers are configured with the same FQDN.
After confirming this, enable failover on the active controller, create a
virtual IP address, and configure web services for that IP address.
You must configure the following IP addresses for each failover controller:
◆ A dedicated self IP address and port on each controller. The IP address
and port setting required is the self IP address and port of the interface or
VLAN interface on the controller. This address must be unique for each
controller in the redundant system. The self IP addresses for the two
failover controllers must be on the same IP subnet. Typically, you
configure synchronization for the same port, but using a different IP
address.
◆ At least one shared IP address for the redundant system. This shared IP
address is what establishes the association between the members of a
redundant system.
Important
If you are configuring failover in a production environment, or on an
existing FirePass controller, make a full backup of the controller before
making any configuration changes. For information about backing up a
FirePass controller, see Backing up and restoring the FirePass controller,
on page 8-47.
Enabling failover on the active controller

You need to enable failover on the active FirePass controller before
continuing with the configuration tasks. When you enable failover the
system prompts you to restart the controller. After you restart the controller,
the navigation pane and the Web Services configuration screen present
additional failover configuration screens and options.
Note
If the screen does not show the Failover tab or other failover-related menu
items after you enable failover, refresh the view in your web browser.
To enable failover on the active FirePass controller

2. Click the Hosts tab at the top of the screen.
The Hosts screen opens.

Chapter 11
3. Confirm that the name of the controller in the FQDN of the

controller box is the name you want to use for the redundant
system. These names must match on both the active and standby
controllers.
4. In the navigation pane, click Clustering and Failover.
The Clustering and Failover screen opens.
5. Scroll down to the Failover (High-Availability) Configuration area,
and make these changes:
a) Check the Enable Failover Configuration check box.
b) From the Failover Pair Member list, select First.
c) Copy the value from the Failover ID box.
Paste this value into a text file or write it down. You will need
this value for configuring the standby FirePass controller.
6. In the Clustering/Failover Global ID area, copy the value from
Cluster/Failover Global ID box.
Paste this value into a text file or write it down. You will need this
value to configure the standby FirePass controller.
7. To commit the settings, click Apply Clustering/Failover Settings.
8. Finalize the setup, and restart the controller.
For more information, see Finalizing the configuration, following,
and Restarting the controller or services after configuration,
following.
Finalizing the configuration

Many web services configuration changes require a finalize step. You can
use steps in this procedure for all finalize operations described in these
procedures.
To finalize the setup

1. Click the Finalize tab at the top of the screen.
2. Review the changes.
3. Click the Finalize Changes button.
Restarting the controller or services after configuration

Some configuration changes also require a controller restart or services
restart. You can use steps in this procedure for all restart operations
described in these procedures.
To restart the controller or service

1. Click the indicated text.
2. Confirm the restart.
11 - 8
Configuring the active controller with a self IP address

For the failover process to work, each active and standby FirePass controller
must have an IP address that it uses to communicate with the other. This IP
address, the self IP address, uniquely identifies each FirePass controller
interface or VLAN interface for the purpose of synchronization.
You created a self IP address during the initial configuration process. If you
want to use that self IP address for failover, you can skip this procedure. If
you want to use an interface other than the recommended one, you can
create a new self IP address on another interface. If you do so, you must also
connect the two FirePass controller interfaces using a separate straight or
crossover cable.
WARNING
Be extremely careful when changing the FirePass controller’s IP
configuration settings. If you enter incorrect settings, the FirePass
controller might become inaccessible from the network. If that happens, you
must have physical access to the FirePass controller device to start up the
controller again. You cannot use the browser interface to start up the
FirePass controller, you must use the Maintenance Console connected to
the device.
To configure the active controller’s self IP address

Configuration, click Network Configuration, and click the IP
Config tab.
2. Under Add New IP in the IP Address /Netmask box, type the IP
address in dotted-decimal notation, and the subnet mask in bits
notation.
In the online help for this screen, you can find a table that shows the
mapping between bits, dotted-decimal, and hexadecimal netmask.
3. In Broadcast IP, type the IP for the controller to use to send
messages to the subnet. If you do not specify a broadcast IP address,
the FirePass controller calculates a default broadcast address from
the IP address and mask.
4. From the Interface list, select the device-specific interface or
VLAN interface associated with the IP address.
You can configure web services so that all the traffic goes through a
single interface, or you can use one interface for synchronization
and another for other traffic.
For the FirePass 1000 controller, we recommend that the public
subnet be associated with the eth0 interface, and the private subnet
be associated with the eth1 interface. For the FirePass 4100 and
4300 controllers, we recommend that you associate the public
subnet with the eth1.1 interface.
5. Click Add New to add the self IP address.

Chapter 11

The Finalize Settings screen opens.
7. Review the changes, and click the Finalize Changes button.
Configuring the active controller with a shared IP address

The redundant system of failover controllers shares a virtual IP address.
Sharing this IP address makes it possible for the standby controller to take
over the network traffic in the event of a failure.
To configure a shared, virtual IP address on the active

FirePass controller
2. In the Add New IP area, in the IP Address/Netmask box, type a
new IP address and subnet mask for the shared IP address.
3. Check the Virtual check box.
The Virtual check box is present only after you have enabled the
unit for failover.
4. Leave the Broadcast IP box empty for the shared IP address.
5. Select the appropriate network interface from the Interface list.
6. Click Add New to add the shared IP address.
7. Finalize the changes, and restart if necessary.
For specific steps, see Finalizing the configuration, on page 11-8,
and Restarting the controller or services after configuration, on
page 11-8.
Configuring web services for the IP addresses of the active

controller
After adding a self IP address and a shared IP address to the active
controller, you need to configure their web services. Which services you
configure, and the ports you use, depend on how your local network and
firewall are set up, and on what FirePass controller features you use.
Configuring secure web services on port 443 for the active controller
The secure web service on port 443 is the one users log on to. In a typical
configuration, you configure web services on port 443 using SSL. Because
this unit represents one member of a redundant system, you configure web
services on the shared IP address.
11 - 10
To configure web services on port 443 of the shared IP

address for the active controller
2. Click the Web Services tab at the top of the screen.
3. In the Add new service area, from the IP list, select the shared IP
address.
4. In the Port box, type 443.
5. In the Name box, type the FQDN of the FirePass controller.
6. From the For Mode list, select ActiveOnly.
This setting causes the controller to load web services only when it
is the active controller in a redundant system.
7. Check the SSL check box.
8. To add the new service, click Add New.
The Web Service Configuration for <hostname> screen opens for
the new service.
9. From the Certificate list, select the certificate.
10. Check the User Logon check box.
11. If you want, check the Admin Logon check box.
If you check this option, you can log on to the controller’s
Administrative Console. Otherwise, you are redirected to the active
failover member.
12. Leave all other options unchecked.
13. To commit the settings, click Update.
page 11-8.
Configuring web services on port 80 for the active controller

Port 80 is not required, though you may need to configure it based on your
network configuration. Because the web service you configure on port 80 is
not secure, you should not allow communication of sensitive information on
this shared IP address.
To configure web services on port 80 of the shared IP

address for the active controller

Chapter 11

3. In the Add new service area, from the IP list, select the shared IP
address.
You can configure web services for any port, not just port 80.
6. From the For Mode list, select ActiveOnly.
This setting causes the controller to load web services only when it
is the active controller in a redundant system.
the new service.
8. In the HTTPS URL to redirect to box, type the URL of the
HTTPS Web service (port 443) on the shared IP address that you
configured in Configuring secure web services on port 443 for the
active controller, in the preceding procedure.
9. Check the User Logon check box.
10. Leave all other options cleared.
page 11-8.
Configuring a web service as a synchronization agent for the active

controller’s self IP address
After configuring web services for the active controller’s virtual IP address
you need to also configure a synchronization service for the controller’s
physical IP address.
Note
You can configure synchronization for any port, not just port 81.
To create a web service as a synchronization agent on port

81 of the self IP address for the active controller
11 - 12
3. From the IP list, in the Add new service area, select a self IP address
of the active controller.
You can configure synchronization for any port, not just port 81.
You can leave Name blank if the self IP address does not have a
domain name specified in DNS, or if you want to use the self IP
address as the name.
6. From the For Mode list, select Always.
This setting causes the controller to keep a web service active on the
self IP and port specified. You must select Always for the
synchronization service.
the new service.
8. Check the Do not redirect to HTTPS check box.
9. Check the Synchronization Agent check box.
For Synchronization Agent to be active, you must check Enable
Failover Configuration on the Device Management : Configuration :
Clustering and Failover screen.
10. Leave all other options unchecked.
page 11-8.
Configuring the active controller’s heartbeat, synchronization, and

miscellaneous settings
The active and standby controllers communicate with each other using a
heartbeat. The heartbeat is a signal sent at 100-millisecond intervals that
notifies the standby node that the active node is running. If the standby node
does not receive a heartbeat within 3 seconds of the expected arrival time,
the standby node considers its peer inactive, assumes its virtual IP address,
and becomes the active member of the redundant system.
Heartbeat settings specify the interface and port a controller uses while it is
the active member of the redundant system.
Synchronization settings consist of the self IP address of the active
controller and the self IP address of the standby controller. To use a port, it
must be configured as a synchronization service. A synchronization service
is a web service that is enabled for HTTP and configured as a
synchronization agent.

Chapter 11
For a procedure to follow, see Configuring a web service as a

synchronization agent for the active controller’s self IP address, on page
11-12.
To configure the active controller’s heartbeat,

synchronization settings, and miscellaneous settings
2. Click the Failover tab at the top of the screen.
The Failover Configuration screen opens.
3. From Network Interface to use for the heartbeat, select the
interface you want to use for transmitting the heartbeat.
4. In UDP port to use for heartbeat, specify the port number you
want to use for transmitting the heartbeat. The default is 694.
If you want to use a different port for UDP, specify that value
instead. You must specify the same value on the standby controller.
5. In IP address and port on this machine to use for
synchronization, select the self IP address and port you configured
for the active controller in Configuring the active controller with a
self IP address, on page 11-9.
6. In IP address and port on the other member of this failover pair
to use for synchronization, specify the self IP address and port of
the other member of the redundant system. You configure this
setting in Configuring the active FirePass controller, on page 11-7.
The standby controller uses this IP address and port for
synchronization with the active controller.
7. Click the Misc tab at the top of the screen.
The Misc screen opens.
8. From the Local X11 server source address list, select the shared IP
address.
9. From the NetBIOS broadcast source address list, select the shared
IP address.
10. From the Network Access source address list, select the shared IP
address.
11. From the NAS IP Address for RADIUS Requests list, select the
shared IP address.
page 11-8.
11 - 14
Configuring the standby FirePass controller

After you have configured the active FirePass controller, you must
configure the standby controller so that it can take over in the event of a
failure of the active controller.
The basic process consists of the following tasks
◆ Enable failover
Follow the procedure steps shown in Enabling failover on the standby
This is how you configure the controller that has the failover-only
license.
◆ Configure the self IP address
Follow the procedure steps shown in Configuring the standby controller
with a self IP address, on page 11-17.
◆ Configure a shared IP address
Follow the procedure steps shown in Configuring the active controller
◆ Check the FQDN
page 11-7.
◆ Configure DNS server entries
For more information, see Configure entries on your Domain Name
Service (DNS) server, on page 11-3.
service
For more information, see To finalize the setup, on page 11-8, and To
restart the controller or service, on page 11-8.
The configuration process is similar to the one you followed when you
configured the active controller, with two exceptions.
◆ Configure standby settings on the Clustering and Failover Settings
screen.
For more information, see To configure standby settings on the
Clustering and Failover Settings screen, on page 11-16.
◆ Specify the self IP address for the standby controller.
For more information, see To specify the self IP address for the standby

Chapter 11
Synchronizing re-signed client components between

cluster/failover nodes
Some organizations have policies prohibiting the use of browser add-ons or
Java applets, unless they are signed by the internal certificate. The FirePass
controller allows such organizations to pull the controls off the controller,
re-sign them, and then upload the re-signed client components. For
customers who use a custom certificate to re-sign client components, the
FirePass controller includes the option to re-sign client components to the
backup/restore package for synchronization of the cluster/failover settings.
The administrator can package the re-signed controllers into a Zip file and
upload.
To use this feature, from the Administrative Console, click Device
Management, click Customization, and select the Code Signing tab.
Important
Use this function at your own risk. F5 does not provide assistance with
signing the controls. Please refer to the appropriate developer's
documentation on Java and ActiveX. This procedure must be repeated after
each firmware upgrade.
Enabling failover on the standby controller

Enabling failover on the standby controller is almost the same as enabling
failover on the active controller, so you may find it useful to review the
procedure for configuring the active controller, Enabling failover on the
active controller, on page 11-7.
To configure standby settings on the Clustering and

Failover Settings screen
Configuration, and click Clustering and Failover.
2. From the Failover Pair Member list, select Second.
You select Second when you are configuring a failover member that
is licensed as failover only, and when you are configuring the
second fully licensed member of a redundant system.
3. In the Failover ID box, type or paste the failover ID you recorded in
step 5 of To enable failover on the active FirePass controller, on
page 11-7.
4. In the Clustering/Failover Global ID area in the Cluster/Failover
Global ID box, type or paste the Cluster/Failover Global ID you
recorded in step 6 of To enable failover on the active FirePass
11 - 16
Configuring the standby controller with a self IP address

Before continuing with this task, make sure to review the associated
procedure for configuring the active controller, Configuring the active
controller with a self IP address, on page 11-9.
To specify the self IP address for the standby controller

Configuration, and click Network Configuration, and click the
Failover tab.
The Failover Settings screen opens.
2. In the IP address and port on this machine to use for
synchronization box on the Failover Settings screen, select the self
IP address and port you configured for the standby controller in
Configuring the active controller with a self IP address, on page
11-9.
3. In IP address and port on the other member of this failover pair
to use for synchronization, specify the self IP address and port of
the other member of the redundant system. You configure this
setting in Configuring the active FirePass controller, on page 11-7.
The standby controller uses this IP address and port for
synchronization with the active controller.
Configuring a shared IP address

Follow the procedure steps shown in Configuring the active controller with
a shared IP address, on page 11-10.
Checking the FQDN

page 11-7.
Configuring DNS server entries

For more information, see Configure entries on your Domain Name Service
(DNS) server, on page 11-3.

Chapter 11
Adding and configuring web services, and specify a synchronization

service
Configuring the heartbeat

Finalizing and restarting the active controller

For more information, see To finalize the setup, on page 11-8, and To restart
the controller or service, on page 11-8.
Accessing a standby controller

If you want to log on to a standby controller that is already a member of a
redundant system, you must log on using https://standby-self-IP/admin/.
Logging on to the standby unit

The presence of the trailing /admin/ designation in the URL enables access
to the standby controller directly. If you do not specify the trailing /admin/,
you are redirected to the active failover member.
For example, to access a physical device named fail2 that has an IP address
of 10.4.1.2.198, you could specify one of the following in the browser
address bar, and then log on as usual.
https://fail2.siterequest.com/admin/
https://10.4.12.198/admin/
These examples assume that you created a DNS entry for the standby
controller using its self IP address.
Making changes on the standby unit

Although you can access the FirePass controller configured as the standby
unit, you should not make any configuration changes. The failover process
synchronizes configuration information from the active controller to the
standby controller in a redundant system.
11 - 18
On the standby member of a redundant system, you cannot use the link
Please click here to start a console session to the Maintenance Account
on the Device Management : Maintenance : Troubleshooting Tools screen.
This is to help prevent changes to the standby controller of a redundant
system.
Configuring multiple external addresses for availability testing

The External IP Address for Monitoring option enables the FirePass
controller to monitor multiple IP addresses for external monitoring. This
requires that all the IP addresses are up and running and responding to ping
queries. Otherwise, the FirePass controller declares an external link failure
and changes its state.

Chapter 11
Post-configuration tasks
After you have configured both FirePass controllers for failover, confirm
that the failover configuration is working.
Starting failover controllers

If both failover controllers are turned off, the first controller that you start
automatically assumes the role of active controller, and the second
controller you start becomes the standby controller. The two controllers
remain in this state until either the active controller fails and the standby
controller takes over, or you restart the active controller, and the standby
controller becomes the active controller.
If a pair of failover controllers is started simultaneously, the controller
configured as First on the Failover settings screen becomes the active
controller, and the controller configured as Second on the Failover settings
screen becomes the standby controller. You can determine which controller
is first and which is second by checking the value in the Failover Pair
Member box on the Clustering and Failover screen. To access the screen,
click Device Management, expand Configuration, and click Clustering
and Failover. The first one is designated First, and the second one is
designated Second.
Verifying the failover configuration

After configuring the active and standby FirePass controllers, verify that the
configuration is properly working.
To verify that your failover configuration is working

1. In the navigation pane, click Failover.
The Failover : Settings screen opens.
2. Verify that the failover controllers are properly configured:
a) Confirm that the current controller is active by looking at the
value of This node.
If the controller is active, it contains the designation (active).
b) Confirm that the two controllers are communicating by looking
at the status line that indicates how many seconds have passed
since the active controller synchronized data with the standby
controller.
If the interval has been too long, the screen displays a warning.
Synchronization might take more time if a lot of data has to be
transferred, for example, if you make significant changes on the
primary controller. If you want to perform a manual
synchronization, click Device Management, expand
Configuration, click Clustering and Failover, and select Force
Full Sync.
11 - 20
3. Restart the current, active controller so that the standby controller

fails over.
a) Click Restart This Node, Make <standby controller> Active
to restart the current controller.
The current controller restarts and becomes the standby
controller, and the standby controller takes over as the active
controller.
b) After restart, check the identity of each controller. For more
information, see Verifying controller identity, following.
Verifying controller identity

You can determine the identity of the controllers by logging on to each one.
To verify the identity of the controller

1. Log on to the active controller directly.
2. Verify that the Welcome screen indicates that the device is the
standby controller.
The screen presents the following message:
This node is in failover active mode
3. Log on to the standby controller directly.
For more information, see Configuring the standby FirePass
4. Verify that the Welcome screen indicates that the device is the
standby controller.
The screen presents the following message:
This node is in failover standby mode
Triggering manual failover

You can manually trigger a failover to verify that the configuration of the
redundant system is correct. You might also need to manually trigger a
failover if you need to make changes to your active controller.
To manually trigger a failover to a standby controller

1. In the navigation pane, click Failover, and then click Settings.
The Failover Settings screen opens.
2. Click Restart This Node, Make <standby controller> Active.
The current controller restarts and becomes the standby controller,
while the standby controller takes over as the active controller.
You can also trigger failover manually using the Restart Controller link on
the Restart Services screen. To access the screen, in the navigation pane,
click Device Management, expand Maintenance, and then click Restart
Services.

Chapter 11
11 - 22
12
• Understanding FirePass controller clusters
• Configuring FirePass controller clusters
• Enabling clustering
• Configuring clustering synchronization
• Configuring load balancing
• Verifying the load balancing configuration
• Managing a cluster configuration

Understanding FirePass controller clusters

You can set up the FirePass 4000, or 4100, or 4300 controller in a cluster
configuration to support large numbers of concurrent connections without
performance degradation. A cluster is a group of FirePass controller nodes
that provide common user services, and can distribute the load of active
sessions across all controllers in the cluster. The process the primary node
uses to distribute user sessions among all the nodes in the cluster is called
load balancing.
A cluster node represents one station in a cluster, and can consist of a single
FirePass controller, or a failover pair (redundant system) of controllers. A
cluster consists of one primary (or master) node and up to a maximum of
nine secondary (or slave) nodes. The primary node first handles incoming
connections, and then redirects each session to an available secondary node,
or services the connection itself. The primary node maintains configurations
for all user groups and user resources that the cluster supports. Each
secondary node services user sessions that are requested by the primary
node, and independently maintains its own network configuration.
Clustering is ideal for large enterprises and service providers, and allows for
easy scalability, with increased performance and fault tolerance across all
cluster nodes. For large deployments, FirePass 4100 and 4300 clusters can
contain up to ten nodes, supporting up to 20,000 concurrent connections,
though there is no limit on the number of user accounts.
As an alternative, you can specify that the user select the cluster node if you
do not want the primary node to balance the load, or you can use an external
load-balancing method. For information about using the BIG-IP Local
Traffic Manager as the load-balancing mechanism, see the associated
deployment guide on the F5 Networks web site Solution Center at
Understanding synchronization in clusters

The primary node plays the central role in a cluster for all the user-related
configuration (user groups and user resource settings). You create and
configure user groups and resource group favorites on the primary node.
When load balancing is enabled, the primary node distributes user sessions
to each secondary node, and each secondary node handles user sessions
delegated to it by the primary node of the cluster. The secondary nodes get
this information from the primary node during the synchronization process.
Synchronization is the process used by the primary node to synchronize
data with the secondary nodes of the cluster.
Load balancing operations require synchronized data on the cluster
members. The synchronization process makes it possible for any primary or
secondary controller to service a user’s logon request and subsequent
session. To synchronize resource information across all cluster nodes, the
primary node distributes configuration updates to each secondary node. Data
synchronized from the primary node to each secondary node includes: user
and group data (including authentication parameters), and favorites.

Chapter 12
Once a user is logged on, the secondary node reports its updates to the
primary node as an input to the primary node’s load-balancing decision.
Because users can perform operations that change user-specific data, the
FirePass controller synchronizes some data from the secondary nodes back
to the primary node. These updates include password changes, additions and
changes to personal favorites, and modifications to other account settings.
For more information about synchronizing web services, see Configuring
clustering synchronization, on page 12-8.
Installing FirePass controllers as a cluster

To complete procedures in this chapter, you must already have installed the
FirePass controllers and have completed the initial network and web service
configuration. For setup information, see the FirePass® Controller Getting
Started Guide, available as a separate document on the Ask F5SM web site at
https://support.f5.com. For initial network configuration information, see
Configuring web services, on page 8-20.
Important
Always back up any FirePass controller before configuring clustering. For
more information on backup operations, see Backing up and restoring the
12 - 2
Configuring FirePass controller clusters

Once you have set up each member of your cluster, you can configure the
clustering settings for each controller. The procedures in this section guide
you through the process of setting up FirePass controller cluster members.
Here are the requirements for configuring cluster members:
• You must have multiple FirePass 4000, or 4100, or 4300 systems
available.
• Each system must be running the same software version and must have
the same hot-fixes, if any, installed.
• Every cluster member must have its own individual license that supports
identical features and the same number of concurrent users, except for
any failover-only members, which should have the failover-only license
activated.
• Each node in the cluster must have a valid certificate and be publicly
accessible from outside the LAN using its own unique IP address or
fully-qualified domain name (FQDN).
To ensure the highest level of availability, you should use multiple pairs of
FirePass controllers as cluster nodes. If this is not possible, F5 Networks
recommends at a minimum, that you make the primary node a redundant
system.
Note
Any cluster node can represent a redundant system of pairs of FirePass

controllers. If you plan to use redundant systems as nodes in the cluster,
configure them before configuring clusters. For more information about
configuring redundant systems, see Chapter 11, Using FirePass Controllers
for Failover.
Making configuration changes in clusters

You can change some configuration settings only on the primary node:
• User account information and master group settings
• Favorites for Network Access, Portal Access, and Application Access
• Customization options
When you connect to a secondary node, you are limited to changing network
settings and clustering configuration options that the primary node does not
control. For example, because you cannot change user and group account
information on secondary nodes, the secondary node presents no user or
group options. These options are not available on any secondary node to
prevent conflicts during synchronization.

Chapter 12
Understanding the configuration process

To configure FirePass controllers as a cluster, you need to complete several
tasks in a specific order.
◆ Enable clustering
The first task in configuring a cluster of controllers is to enable clustering
on each node. When you configure the primary node, record the specified
Cluster ID and the Cluster/Failover Global ID for use in configuring the
secondary nodes. For more information, see Enabling clustering, on page
12-6.
◆ Specify log consolidation settings
The next task is to determine whether you want to consolidate logs for
nodes in the cluster. For more information, see Consolidating logs, on
page 12-5.
◆ Set up synchronization
The third task is to configure synchronization, which consists of two
parts:
• Create a synchronization service
In order for clustered controllers to remain synchronized, you must
configure at least one synchronization service on each controller in
the cluster. This should be a different web service from the one you
create for user access. For more information about configuring
synchronization services, see Configuring a synchronization service,
on page 12-8.
• Configure synchronization
When you configure synchronization, you associate an IP address and
port on the primary node with an IP address and port on each of the
secondary nodes. For more information on configuring
synchronization, see Configuring synchronization, on page 12-9.
◆ Verify that the cluster configuration is working
After you have configured the cluster nodes, but before allowing remote
clients to access the cluster, verify that all controllers are working
properly. For more information, see Verifying the cluster configuration,
on page 12-14.
◆ Enable Load balancing
If you want to use the cluster for load balancing, you must define at least
one user service on the primary node and at least one on each secondary
node. The user service must be configured to allow HTTP and HTTPS
access so that users can access the service from outside the network. For
more information, see Configuring load balancing, on page 12-12.
Note
As an alternative, you can use a BIG-IP Local Traffic Manager for load
balancing a cluster. For more information, see the associated deployment
guide on the F5 Solution Center at http://www.f5.com/solutions/.
12 - 4
Consolidating logs
You can use log consolidation settings to view information about all cluster
members in a single location on the primary node. Consolidating logs
simplifies the monitoring process for cluster node members. In order to have
the primary node receive log information from the secondary nodes, you
must enable log-consolidation settings on the Device Management :
Configuration : Clustering and Failover screen. For procedures containing
these steps, see Enabling clustering, following.
You can view consolidated logs on the primary node in Reports. Logs that
contain consolidated data include a Cluster Node column in the report. The
report contains data for each cluster node, including the primary node.
You can get node-specific statistics on the Device Management :
Monitoring : System Load screen by selecting an IP address from the
Cluster Node list.

Chapter 12
Enabling clustering
Enabling clustering involves specifying the number of nodes in the cluster,
designating one as the primary node, and standardizing the Cluster ID and
Clustering/Failover Global ID on each of the nodes to be used in the cluster.
After you have enabled clustering and restarted the controller, you can make
additional configuration changes on newly available clustering screens.
Tip
If you are enabling clustering on a pair of controllers in a failover
configuration, set up clustering on the active controller.
Configuring the primary node

For the primary node, complete the following procedure.
To enable clustering on the primary node

1. In the navigation pane, expand Device Management, click
Configuration, and select Clustering and Failover.
2. In the Clustering (Load-Balancing) Configuration area, check the
Enable Clustering Configuration check box.
3. In the Total Number of Cluster Nodes box, specify the number of
nodes the cluster contains.
A node can consist of a single FirePass controller or a redundant
system of a pair of controllers.
4. From the Cluster Node Master/Slave list, select Master.
5. To enable the consolidation of logs from the secondary nodes, check
Enable Log Consolidation.
To complete log consolidation, you must also check Synchronize
Log to Master on each secondary node. For more information, see
Consolidating logs, on page 12-5.
6. Copy the value from the Cluster ID box.
value to configure the secondary nodes.
7. In the Clustering/Failover Global ID area, copy the value from the
Cluster/Failover Global ID box.
value when you configure the secondary nodes.
8. To commit the settings, click the Apply Clustering/Failover
Settings button.
9. When prompted to restart the controller, click the indicated text,
here.
10. Continue with configuring the secondary nodes, following.
12 - 6
Configuring the secondary nodes

For each secondary node, complete the following procedure.
To enable clustering on a secondary node

Configuration, and select Clustering and Failover.
2. In the Clustering (Load-Balancing) Configuration area, check the
Enable Clustering Configuration check box.
3. In the Total Number of Cluster Nodes box, specify the number of
nodes the cluster contains.
4. From the Cluster Node Master/Slave list, select Slave.
5. To pass log information back to the primary node, check
Synchronize Log to master.
To complete log consolidation, you must also check Enable Log
Consolidation on the primary node. For more information, see
Consolidating logs, on page 12-5.
6. In the Cluster ID box, paste the value you copied from this box on
the primary node in step 6 in To enable clustering on the primary
node, preceding.
7. In the Clustering/Failover Global ID area, in the Cluster/Failover
Global ID box, paste the value you copied in step 7 in To enable
clustering on the primary node, preceding.
here.
Important
Whenever you activate a cluster member, always start the primary node
first. If the primary node is not available when the remaining cluster
members start up, the cluster cannot function properly. For this reason, F5
recommends that the primary node be a redundant system.

Chapter 12
Configuring clustering synchronization

After you have enabled clustering on each node, you can configure
synchronization. All traffic goes to the primary node first. The primary node
manages cluster synchronization and, if load balancing is enabled,
distributes user-session processing among the secondary nodes. For more
information about load balancing, see Configuring load balancing, on page
12-12.
Configuring a synchronization service

To configure the primary and secondary nodes of a cluster for
synchronization, you must designate a synchronization service and
configure synchronization on each node.
The following requirements affect how you configure the synchronization
service.
• The service must allow HTTP connections. For this reason, you should
not configure it on a port that is also configured for user services.
• The service cannot be redirected to another service (for example,
HTTPS).
• If the service is on a redundant system (failover pair), you should
configure it on the pair’s shared, virtual IP address.
• You can use the same synchronization port as the one configured for
failover synchronization.
Configuring the web service as a synchronization agent

The first step of synchronization configuration is to create a web service to
serve as the synchronization agent, the service that synchronizes information
on the cluster. You must complete this procedure on the primary node first,
then complete the procedure on each secondary node.
To configure a synchronization service

Configuration, and Network Configuration, and click the Web
Services tab at the top of the screen.
2. In the Add new service area, from the IP list, select an IP address:
• If the port is also configured for failover synchronization, select a
shared, virtual IP address for the failover web service.
• Otherwise, select a self IP address.
Make a note of the IP address for the primary node and for each
secondary node. You will need them for configuring
synchronization parameters.
12 - 8
3. In the Port box, type an unused port number.

For example, type 82 in the Port box.
5. If the service is to be used for controllers in a redundant system,
from the For Mode list, select ActiveOnly for the failover web
service running on the shared, virtual IP address, or Always for the
failover web service running on the dedicated, self IP address.
Selecting the ActiveOnly setting causes the controller to load web
services only when it is the active member in the redundant system.
For more information about configuring redundant systems see
Reviewing the configuration process, on page 11-2.
6. To add the service, click Add New.
The Web Service Configuration for <Hostname or IP Address>
screen opens.
7. On the Web Service Configuration for <Hostname or IP Address>
screen:
a) Check the Do not redirect to HTTPS check box.
b) Check the Synchronization Agent check box.
c) Leave all other options cleared.
8. To update the web service configuration, click Update.
Important
Although the settings do not take effect until you complete the finalize
operation and restart the controller, the FirePass controller cannot compete
the finalize operation until all clustering settings are fully configured.
Tip
You can use a single web service for both cluster synchronization and
failover synchronization. For more information about configuring a web
service for failover, see Configuring a web service as a synchronization
agent for the active controller’s self IP address, on page 11-12.
Configuring synchronization
After you configure a synchronization service, you must associate that
service on the primary node with the corresponding service on each
secondary node.

Chapter 12
Configuring synchronization on the primary node

First, you complete the procedure on the primary node.
To configure synchronization parameters on the primary

node
1. In the navigation pane, click Clustering.
The Clustering Settings screen opens.
2. Click the Please click here to set up the cluster network
configuration link.
The Device Management : Configuration : Network Configuration
screen opens with the Clustering tab selected.
3. In the Internal Synchronization area, from the Service On Master
list, select the IP address and port number of the synchronization
service you configured.
4. In Service on Slave N, type the IP address and port of the
corresponding synchronization service settings for each secondary
node.
5. To update the synchronization settings, click Update Table.
7. Click Finalize Changes to finalize the configuration.
8. When prompted, restart the controller.
Configuring synchronization on the secondary nodes

Next, you complete the procedure on each secondary node. The process is
almost the same as configuring the primary node, except for the differences
in the Internal Synchronization parameters.
To configure synchronization parameters on a secondary

node
1. In the navigation pane, expand Clustering.
configuration link.
screen opens with the Clustering tab selected.
3. In the Internal Synchronization area, from the Service On Slave list,
select the IP address and port number of the synchronization service
you configured.
4. In Service on Master, type the corresponding IP address and port of
the synchronization service on the primary node.
5. To update the synchronization settings, click Update Table.
12 - 10

Configuring a synchronization interval

If you have a large number of FirePass controllers with clustering enabled,
you can greatly reduce the clustering traffic by modifying the cluster
synchronization interval. Before synchronization can work, you must enable
clustering and configure synchronization settings.
For more information, see Enabling clustering, on page 12-6 and
Configuring clustering synchronization, on page 12-8.
To specify a synchronization interval

Configuration, and expand Clustering and Failover.
2. In Synchronization Interval, specify the length of time you want to
leave between the start of synchronization operations.
The default interval is ten seconds, which should work for most
configurations. If there is a large amount of data to synchronize, the
process might not complete in ten seconds, so you should specify a
longer interval. You can watch the Stats screen to determine how
long synchronization takes. Then you can set an interval sufficiently
large to make sure that the operation completes. We recommend
300 seconds as a reasonable interval for most configurations.
here.
5. Repeat this process for each secondary node.

Chapter 12
Configuring load balancing

For clustering to work, you must also configure the load balancing feature of
FirePass controller clusters. Balancing the load guarantees that no single
controller becomes overloaded while another controller goes under used. By
default, load balancing is turned off. With load balancing enabled, the
primary node assigns sessions randomly among the secondary controllers.
Note
As an alternative, you can use a BIG-IP Local Traffic Manager for load
balancing a cluster. For more information, see the associated deployment
guide on the F5 Solution Center at http://www.f5.com/solutions/.
Configuring load balancing on the primary node

After you enable load balancing on the primary node, you must associate its
HTTP-enabled and HTTPS-enabled user web service with the
corresponding service on each secondary node.
To configure load balancing on the primary node

1. In the navigation pane, expand Clustering, and click Settings.
configuration link.
screen opens with the Clustering tab active.
The Load Balancing table contains a row for each HTTP-enabled
and HTTPS-enabled user web service on the secondary node, and
each row contains columns representing the primary node.
• Service On Master
Represents the primary node.
• Service On SlaveN
Represents each secondary node in the cluster.
3. For each column, type the IP address and port of the HTTP-enabled
and HTTPS-enabled, User-access configured web service on the
corresponding secondary node.
4. To commit the settings, click Update Table.
12 - 12
Configuring load balancing on the secondary node

After you enable load balancing on each secondary node, you must associate
its HTTP-enabled and HTTPS-enabled user web service with the
corresponding service on the primary node.
To configure load balancing on the secondary nodes

configuration link.
screen opens with the Clustering tab active.
The Load Balancing table contains a row for each HTTP-enabled
and HTTPS-enabled, User web service on the primary node, and
each row contains columns representing each secondary node.
• Service On Slave
Represents the secondary node you are logged on to.
• Service On Master
Represents the primary node.
In this column, type the IP address and port number representing
the primary node’s web service you want to associate with the
secondary node.
3. To commit the settings, click Update Table.
Activating load balancing

Before you can activate load balancing, you must first enable clustering and
configure synchronization. For more information, see Enabling clustering,
on page 12-6 and Configuring clustering synchronization, on page 12-8.
To activate load balancing

The Clustering : Settings screen opens.
2. From the Load Balancing list, select Random.
Random represents an unstructured and irregular assignment of
user sessions among the cluster members. If you select Off, no load
balancing occurs, and the user selects a node at logon time.

Chapter 12
3. Check the Allow optional manual logon to slave nodes from

master logon page while configuring load balancing algorithm
check box to have the FirePass controller present users a list from
which they can select the node they want to log on to.
Verifying the cluster configuration

After configuring the primary and secondary nodes, you must verify
clustering functionality before allowing access to any remote users.
To verify that your cluster configuration is working

1. In the navigation pane of the primary node, expand Clustering, and
click Stats.
The Current cluster stats screen opens.
2. On the Stats screen, in the Last Sync column, verify that the primary
and secondary controllers are synchronizing using the interval you
specified in Configuring a synchronization interval, on page 12-11.
Tip
To update values on the Stats screen, click Stats in the navigation pane.
12 - 14
Verifying the load balancing configuration

After configuring load balancing on the primary and secondary nodes, you
should verify that the feature works properly before allowing access to any
remote users.
To verify that load balancing is working

1. In the navigation pane, expand Clustering, and click Stats.
The Current clustering stats screen opens.
2. Verify that the value shown in the Last Sync column does not
exceed the interval you specified in Configuring a synchronization
interval, on page 12-11.
3. Leave the administrator session active in one instance of the
browser, and use another instance of the browser to log on as a user.
4. From the Preferred Node list on the user logon page, select each
clustering node.
Make sure that the same user can log on to each node.
5. From the Preferred Node list on the user logon page, select
Autoselect, and log on and off repeatedly.
6. In the administrative session, view the statistics to determine
whether the primary controller has redirected the user session to a
randomly selected secondary node. Because the primary controller
can also serve user sessions, the user session might remain on the
primary node even when load balancing is correctly configured. If
the user session is not redirected, log on as a second user, and check
the statistics again.
7. Check the logs on the primary node for errors.
If the primary node cannot redirect the session, it creates an entry in
the system logs. You can check the system logs to determine the
error and correct it, if possible. To access the logs, in the navigation
screen, click Reports.

Chapter 12
Managing a cluster configuration

After you have configured the FirePass controller cluster and verified that it
is working properly, you can manage the cluster and make additional
configuration changes.
Accessing a secondary controller’s configuration

There are several ways to access a secondary controller.
◆ In a web browser’s address bar, type <IP address/admin/> or
<fully qualified domain name/admin/>.
◆ Select the secondary node you want to access from the Preferred node
list when you log on to the primary node.
◆ Use the logon page on the primary controller, if the Allow optional
manual logon to slave nodes from master logon page setting is
checked.
◆ Access the secondary node from within the primary node.
• In the navigation pane of the primary node, click Clustering, and then
click Slave Admin.
• Click the link for the secondary controller that you want to access, and
then log on.
Tip
To return to the primary controller, type the FQDN for the primary
controller in your web browse’s address bar, and then log on.
Once you log on to a secondary node, you can check the system logs and the
logon reports for entries that can help you troubleshoot problems. To access
the reports, in the navigation screen, click Reports.
Displaying statistics for a FirePass controller cluster

You can display operational statistics for a controller cluster in near-real
time.
To display statistics for a FirePass controller cluster

1. Log on to the primary FirePass controller in the cluster.
2. In the navigation pane, expand Clustering, and click Stats.
The Clustering : Stats screen opens.
Statistics presented include the number of sessions active on each node, the
associated CPU load, the number of TCP/IP connections, and the interval
since the most recent primary-secondary synchronization operation.
12 - 16
13
• Understanding Web Applications engine trace
• Using the Web Applications engine trace feature
• Analyzing Web Applications engine traces

Understanding Web Applications engine trace

The FirePass controller Web Applications engine trace feature provides an
easy way for you to capture logs of user sessions through the Web
Applications feature of Portal Access. You can use the trace feature when a
user has trouble using a web applications favorite or direct connection. The
logs provide detailed information about how the FirePass controller is
altering the data stream.
Situations when you would use the Web Applications engine trace feature
include the following:
• A web page does not display properly on a client computer when the user
accesses the application through a FirePass controller Portal Access
connection, but the web page does display correctly when the user
accesses the application in another way.
• Java or JavaScript does not work on a client computer when the user
accesses the application through a FirePass controller Portal Access
connection, but Java or JavaScript normally does work when the user
accesses the application in another way.
• Non-HTML elements on a web page do not work on a client computer
when the user accesses the application through a FirePass controller
Portal Access connection, and the non-HTML elements might or might
not normally work when the user accesses the application in another
way.
For example, a web page might include XML, Flash, or ActiveX
components that prevent a client computer from accessing the page.

Chapter 13
Using the Web Applications engine trace feature

The trace feature creates logs that you can use to help identify the causes of
problems with web pages.
Note
If you plan to send the logs to F5 Networks Technical Support, open the logs
in a text editor, review them, and delete passwords and sensitive
information. For more information about reviewing Web Applications
engine trace logs, see Analyzing Web Applications engine traces, on page
13-5.
Important
Dynamic caching on the FirePass controller must be disabled when using
the Web Applications engine trace, unless you are troubleshooting a
problem with the dynamic cache. If dynamic caching is not disabled, items
that are served out of the cache are not included in the backend trace and
you will be unable to compare the response received from the backend to the
response sent to the client. You should also ask the user to clear the browser
cache first, unless the problem occurs only when content is already cached
by the browser.
To use the Web Applications engine trace

1. Have the user who is experiencing problems log on to the controller,
but do not have the user access the problematic web application yet.
2. Connect to the FirePass controller’s Administrative Console using a
web browser, and log on.
The Device Management Welcome screen displays.
Maintenance, and click Troubleshooting Tools.
The Troubleshooting Tools screen displays.
4. In the User box in the Web Applications engine trace area, type the
user’s name whose session you want to trace.
5. To get a list of active sessions for the user, click Get user sessions.
The user’s session ID and status information display in the table.
6. Begin the trace operation by clicking the Connect link that is
associated with the user session.
The trace begins, and the Connect link changes to a Download link.
7. Have the user start a Web Application session and navigate to the
web page that manifests the problem.
8. After the user experiences the problem and the screen finishes
loading, click Download and save the trace file to your local hard
drive.
13 - 2
Note: If the web page does not fully load, the trace file may be
empty. To capture content, be sure to connect to the user session,
then have the user perform the actions you want to trace, and wait
for the user’s browser to finish loading the content or time out.
You can alternatively click Get user sessions again and browse the
trace log files within the current Administrative console window
using the Browse link.
Understanding trace files

The Web Applications engine trace creates a zipped file with a default name
of ur_debug.zip. Table 13.1 lists the files contained in the zipped file.
File name Contents
<nnn>.log Messages from the web applications modules on the FirePass controller itself.
Content in these files is intended for use by F5 Networks Technical Support, and
probably is of limited value for non-F5 personnel.
backend_<nnnn>.html Messages representing the request and response exchange between the
FirePass controller and the web server containing the request for the page, and
the content before web applications engine parses the content.
backend_<nnnn>.(gif | jpg | ...) Images referenced in the associated backend_<nnnn>.html file, received by the
FirePass controller from the application’s web server.
frontend_<nnnn>.html Messages representing the request and response exchange between the
FirePass controller and the client requesting the page.
This is the data from the application’s web server accessed by the user session,
after the FirePass controller has processed it and added state-change information.
frontend_<nnnn>.(gif | jpg | ...) Images referenced in the associated frontend_<nnnn>.html file, sent to the client
by the FirePass controller.
https.extra-error_log Messages from the web applications modules on the FirePass controller itself.
Content in these files is intended for use by F5 Networks Technical Support, and
probably is of limited value for non-F5 personnel.
index.html Content that formats the data for presentation in a browser window. Each file
represents one specific client request.
The .zip file contains one summary index.html, and one index.html file
representing each client request in the trace. After extraction, you can find the
summary file in the root extraction directory, and each client-request specific file in
its associated directory.
list.html Content representing each client request in the trace.

The web applications trace engine generates the content of this file during the
active trace operation.
Table 13.1 Contents of the Web Applications engine trace .zip file

Chapter 13
File name Contents
log.html Data that the content processing engine and content processing scripts changed.
This is a commented list of the reverse-proxy actions the FirePass controller
performed on the associated client request.
ur_debug.log This is a flag file and it is always empty.
Table 13.1 Contents of the Web Applications engine trace .zip file
Extracting these files results in a directory structure that contains a summary

index.html and the list.html at the top, with each client request extracted
into a unique directory, named using a sequence number assigned by Web
Applications engine trace. For example:
• REQ_00000000
• REQ_00000001
• … REQ_nnnnnnnn
where nnnnnnnn represents the number of client requests recorded in the
web trace.
At a minimum, each client request directory contains the following files:
• backend<nnnn>.html
• frontend<nnnn>.html
• index.html
• log.html
Each of the files in the client request directory is associated with one
specific client request.
The browser loads these files into different frames in the window,
depending on how you open the files. For more information, see Analyzing
Web Applications engine traces, on page 13-5.
13 - 4
Analyzing Web Applications engine traces

The files created by the Web Applications engine trace contain data you can
look at using a web browser. Many of the files contain only unreadable code
or image data, but one or more should contain content that might help in
troubleshooting issues. For example, you can debug a connection problem
by comparing the backend<nnnn>.html file (data coming into the FirePass
controller from the accessed web server) and the frontend<nnnn>.html file
(the same data after the FirePass controller has processed it), locating the
place at which processing fails, and repairing it.
When you open the summary index.html file (the index.html file in the
top-level directory), the browser loads list.html into the top frame of the
browser window. Then, depending on which link you select in the top
frame, the browser loads the associated files into the appropriate frame in
the browser window.
When you open an index.html that resides in a client-request directory, the
browser loads the associated files into the appropriate frame in the browser
directory.
• Loads log.html into the top frame
If you are viewing the window from the summary index.html, the
browser loads log.html in the second horizontal frame.
• Loads frontend<nnnn>.html into the lower-left frame
• Loads backend<nnnn>.html into the lower-right frame
For more information about the extracted Web Applications engine trace
files, see Understanding trace files, on page 13-3.
You can also open these files in any text editor.
Tip
We recommend using Internet Explorer as the browser because it shows
data with additional highlighting that can help you as you debug the
problem.
To compare trace file content

The FirePass controller processing converts all URLs and anchor tags.
Processed URLs contain the host name of the FirePass controller, as well as
converted paths. The paths are converted to hide their true locations. A
converted path starts with f5-w-.
1. Open the summary index.html or an index.html that resides in a
client-request directory.
2. Compare the incoming data (the backend<nnnn>.html file) with
the processed data (frontend<nnnn>.html), focusing on URLs and
anchor tags (<a href=...>).
3. Find the point at which the FirePass controller stops processing
URLs or paths.
The problematic code usually exists immediately prior to this point.

Chapter 13
Once you have made this comparison, and located the point where controller
processing stops, you can use this information to find and fix several types
of problems.
Fixing common problems

If you are able to identify the place in the trace where the problem occurs,
you may be able to fix the problem.
Most problems are caused by one of three things:
• HTML syntax errors
For more information, see Fixing HTML syntax errors, following.
• Complex Java applet code
For more information, see Java applet code issues, on page 13-9.
• JavaScript restrictions
For more information, see JavaScript restrictions, on page 13-9.
Fixing HTML syntax errors

HTML syntax errors are common. Frequently they are invisible or cause
only minor problems with a web page’s appearance, but web pages with
syntax errors can also result in significant problems in certain browsers or
when accessed through a Portal Access favorite.
To find HTML syntax errors

1. Start with the comparison you made of the frontend<nnnn>.html
and backend<nnnn>.html in Analyzing Web Applications engine
traces, preceding, locating the point at which the FirePass controller
stopped converting the URLs.
2. Look at the HTML source code immediately preceding the error
point.
This is where you find HTML syntax errors that can cause
problems.
If you find an HTML syntax error, you can correct it in one of several ways:
• Edit the source HTML directly on the web page
For more information, see Fixing HTML syntax errors by editing the
source HTML, following.
• Use the FirePass controller’s content cleaning feature
For more information, see Using the Web Applications content cleaning
feature to fix HTML syntax errors, on page 13-7.
• Use a SED script to correct the HTML error
For more information, see Using Web Applications content processing
scripts to fix HTML syntax errors, on page 13-7.
13 - 6
Fixing HTML syntax errors by editing the source HTML

The easiest way to fix HTML syntax errors is to correct them on the web
page at its source. To do this you need access to the web server and the
source web pages. If you have this access, correct the error directly on the
page.
Errors include:
• Missing quotation marks
• Doubled quotation marks
• Tags that have no corresponding close tag
Using the Web Applications content cleaning feature to fix HTML syntax errors
If you cannot correct the syntax error on the source HTML page, you can
use the FirePass controller content cleaning feature to fix the syntax error.
The content cleaning feature only works on HTML and plain text.
To use the content cleaning utility

1. In the navigation pane, click Portal Access, and click Content
Processing.
The Content Processing screen opens with the Preprocessing Scripts
tab selected.
2. In the Web Applications Content Cleaning area, type the URL for
the page that contains the HTML syntax error.
You can specify a comma-separated list of URLs to process for
content cleaning. You can use the wildcard characters asterisk ( * ),
represents a single character. An empty list means that the content
cleaning functionality does not clean any content.
3. Click Update.
The URL’s patterns are saved.
4. To verify that the cleaning utility worked, compare front-end
response files from before and after using the cleaning utility.
Tip
For a faster way to test content cleaning, type the complete URL of the web
application page into the text box under Test Content Processing Settings,
and click the Test button. This runs content cleaning on the page, and
returns four pieces of data: original URL source, content cleaning warnings
and errors, modified URL source, and modified URL source difference.
Using Web Applications content processing scripts to fix HTML syntax errors
If the problem continues after you use the content cleaning feature, you can
create a SED script to fix specific HTML errors dynamically. SED is a
scripting language that you can use to locate a pattern in an incoming web
page, and modify the match before sending the web page to the client. For

Chapter 13
more information about content processing, see Configuring processing

scripts for content processing, on page 7-19, and Adding a SED script, on
page 7-20.
Note
The web applications module processes the list of content processing scripts
until it finds a match. After that, it stops examining scripts. To replace
several things on one page, you must replace all content in a single content
processing script.
To fix an HTML error using a SED script

1. In the navigation pane, click Portal Access, and click Content
Processing.
The Content Processing screen opens with the Preprocessing Scripts
tab selected.
2. In the Web Applications Content Processing Scripts area, click Add
New Favorite to add a new SED script.
The editing boxes for the SED script display.
3. In the Processing script name box, type a name that identifies the
script.
4. In the URL match patterns box, type a URL for the web page that
is causing problems.
You can specify a comma-separated list of URLs to process for
content processing. You can use the wildcard characters asterisk (*),
represents a single character, for example,
http://*.siterequest.com/*. An empty list means that the content
processing functionality does not process any content.
5. If you want your script to process content other than text-based
(plain text, HTML), type the additional content type in the Content
Type box. For example, you could type application/javascript.
An empty box indicates a text file.
6. In the Sed processing script box, type the script.
7. From the Processing list, select an option.
The option specifies when the script will run to process the content.
For more information, see Configuring content processing for web
applications, on page 7-19.
8. To add the new SED script and processing configuration, click Add
New.
Using SED scripts: recommendations and other considerations

Once a particular SED script pattern match has been made, only the
associated SED script run. No SED scripts that follow will run.
13 - 8
SED scripts are most easily written with an exclamation point ( ! ) as a

separator, since this greatly reduces the need to escape characters in the
script.
Start with a single SED script that makes a minor change to content first.
Then modify from there. The SED script test button is useful as is a Linux
system with SED for testing.
Java applet code issues

A signed Java applet is an applet containing a signature that verifies the
source of the applet. If a signed Java applet refers to an Internet site other
than the one the applet came from, the FirePass controller cannot make the
appropriate host name or path substitutions in the URL, because making
substitutions invalidates the applet signature. For more information about
Java applet resigning, see Preventing Java byte code rewriting, on page
7-27.
In these situations, you cannot use a Portal Access connection to access the
web site. Instead, use Application Access (App Tunnels) or Network
Access.
JavaScript restrictions
Web pages can have JavaScript programs embedded in them. Sometimes
JavaScript programs have requirements that do not work inside a FirePass
controller Web Application connection.
For example, if a JavaScript program tests URLs to verify that they begin
with http://, this can cause a problem for a Web Application connection
because every URL that goes through the connection goes over a secure
connection, and a secure connection requires that URLs start with https://.
If you identify a JavaScript problem caused by a requirement such as this,
you can use a SED script to modify the JavaScript. Or, you can use
Application Access (App Tunnels) or Network Access instead of a Portal
Access connection.
For more information about Java script issues, see Scanning for embedded
script code, on page 7-44.
For detailed instructions on how to identify and respond to specific
problems you encounter, see Solution SOL3084 on the Ask F5sm technical
support site.

Chapter 13
13 - 10
A
How-To Examples
• Introducing how-to scenarios
• Denying access to users running Google Desktop

Search
• Denying and allowing logons from specific operating

systems and requiring certificates
How-To Examples
Introducing how-to scenarios

The how-to scenarios covered in this appendix are based on real-world use.
You can find a description of the how-to scenario at the beginning of each
section.
Each scenario covers one step-by-step operation, and each one can stand on
its own (that is, the scenarios do not build on each other), so you can start
anywhere.
Note
Although each section can stand alone, the more complex scenarios might
require existing knowledge. In that case, the content points you to either the
appropriate sections in this guide, or pages in the FirePass controller
online help.
You can check your progress against screenshots provided at a number of

steps. The intention is to keep you on track without overburdening you with
screenshots.
When you complete the steps, you will have a working version of the
functionality the scenario covers. All information you need to deploy the
working model is provided, including any hints, best practices,
requirements, or warnings.
FirePass® Controller Administrator Guide A-1

Appendix A
Denying access to users running Google Desktop

Search
This how-to scenario describes, step-by-step, creating a pre-logon sequence
to manage inbound access to the FirePass controller. This is a relatively
simple pre-logon sequence. For steps on creating a more complex pre-logon
sequence, see Denying and allowing logons from specific operating systems
and requiring certificates, on page A-11.
Google Desktop Search lets users search documents, spreadsheets, email,
instant messages, and web pages that have been visited by that PC. To
enable this, the software creates cached versions of the content. Depending
on the rights of the user accessing the information, this can include
corporate information stored on servers accessed using a web browser.
Although Google Desktop Search is not intended to be used in a
shared-computer environment, the software may be running on publicly
available computers. This scenario describes how to create a pre-logon
sequence that blocks logons from computers running the Google Desktop
Search engine.
Creating the Google Desktop Check pre-logon sequence

A sequence is a set of actions and rules that act in concert to collect
information about the end-user's system before granting or denying access to
the FirePass controller. Inspectors activated in the sequence perform the
functionality of gathering the information when a user attempts to log on.
You can read more about sequences and inspectors in Creating pre-logon
sequences to protect resources, on page 3-15.
In this example, we create a pre-logon sequence called Google Desktop
Check that tests for the presence of the Google Desktop Search software
prevents logon from any computer running Google Desktop Search.
To create a new sequence

1. Log on to the FirePass controller using an administrative account.
then click Pre-Logon Sequence.
The Pre-Logon Sequence screen opens, as shown in Figure A.1, on
page A-3.
A-2
How-To Examples
Figure A.1 FirePass controller Pre-Logon Sequence screen
3. In the New Sequence section in the Create new sequence box, type
Google Desktop Check.
4. From the Based on list, select template: Empty.
The screen should look similar to Figure A.2, on page A-4.

Appendix A
Figure A.2 Creating the Google Desktop Search sequence
5. Click Create.
6. Under Select Sequence to Use, click the edit link for Google
Desktop Check.
The visual policy editor opens, as shown in Figure A.3.
Figure A.3 The visual policy editor, for creating pre-logon sequences
A-4
How-To Examples
Adding the Google Desktop Check action to the pre-logon

sequence
Now that the pre-logon sequence exists, it needs an action to check for and
act on Google Desktop Search. Before you can add an action, you must
make the Add Action button visible. To make the Add Action button visible,
you position the cursor along the connecting line of the sequence elements.
Figure A.4 shows the cursor positioned so that the Add Action button is
visible.
Figure A.4 Cursor positioned on the connecting line, with Add Action
button visible
To check for the presence of Google Desktop Search

1. On the screen containing the Google Desktop Check sequence you
created, position the cursor on the connecting line between
Sequence Start and Logon Allowed Page.
The Add Action button appears, as shown in Figure A.4.
3. The CHANGE SEQUENCE panel opens in the visual policy editor.
4. Under Predefined actions, select Check for Google Desktop.
5. Click the Apply changes button at the bottom of the panel.
The visual policy editor adds Check for Google Desktop to the
sequence, as shown in Figure A.5.

Appendix A
Figure A.5 The visual policy editor after adding the Check for Google Desktop action.
The Check for Google Desktop action contains a predefined rule that, by
default, prevents access to users running Google Desktop Search. The rule
uses the value returned from the check operation to determine access. To
open the rule, click the link named Click here to show rules. The Edit rules
area opens, as shown in Figure A.6.
A-6
How-To Examples
Figure A.6 The visual policy editor with the Edit rules section open
In this case, the rule uses the value in session.google_desktop_check.result

!= 1 to prevent access to users running Google Desktop Search.
Tip
You can force Google Desktop Search to close but still allow logon by
changing the end page to Logon Allowed Page.
You can click the Inspector Details button next to Checks for presence
of Google Desktop Search product under Inspectors in the Edit Action
panel to open the details page, as shown in Figure A.7.

Appendix A
Figure A.7 The Google Desktop Search inspector details page
Informing users of the reason that they are prevented from logging on helps
them correct the condition and try logging on again. The next step guides
you through the process of creating a logon-denied message.
Customizing the Google Desktop Check logon-denied message

In this step, we create a message to present to users who are denied access
because they have Google Desktop Search running.
To create a logon-denied message

1. Click the Logon Denied Page box.
The END PAGE PROPERTIES panel opens in the visual policy
editor, as shown in Figure A.8.
Figure A.8 The End Page Properties panel open in the visual policy editor
A-8
How-To Examples
2. Into the Message for failed logons box, type the following text for
the message:
The FirePass controller cannot log you on because you
have Google Desktop Search running. Halt the software and
try logging on again.

4. In the upper right corner, click the Back to console link to return to
the Pre-Logon Sequence Page.
5. Under Select Sequence to Use, select Google Desktop Check and
click the Apply button, as shown in Figure A.9.
Figure A.9 Pre-Logon Sequence screen with Google Desktop Check selected and applied

Appendix A
You have created a pre-logon sequence that checks for and prevents logon
by users running Google Desktop Search. As long as you keep the Google
Desktop Check pre-logon sequence selected, users who are running Google
Desktop Search cannot log on to the associated FirePass controller.
Note
You can modify any pre-logon sequence to contain different functionality. If

you do, you should also change the sequence name to reflect any changes
you make. You can change the name by selecting the sequence from the
Rename sequence box, typing the new name, and clicking the Rename
button.
A - 10
How-To Examples
Denying and allowing logons from specific operating

systems and requiring certificates
This how-to scenario describes, step-by-step, creating a pre-logon sequence
to manage inbound access to the FirePass controller. This is a relatively
complex pre-logon sequence, For steps on creating a simpler pre-logon
sequence, see Denying access to users running Google Desktop Search, on
page A-2.
The pre-logon sequence created meets the following requirements:
• Denies logon from Windows 95, Windows 98, and Windows Me
connections.
• Requires Windows NT and Windows 2000 users to log on using the
virtual keyboard.
• Allows connection only from Windows XP, Linux, Pocket PC, and
Macintosh systems that have a valid client certificate.
Rule 1: Deny Windows 95, Windows 98, and Windows Me

connections
For the purpose of this how-to scenario, we create a pre-logon sequence that
tests for the client’s operating system and prevents logon from computers
running Windows 95, Windows 98, and Windows Me. We also create a
logon-denied message to inform users of the cause of the denial of logon.
Creating the Corporate Access Check pre-logon sequence

In this example we create a pre-logon sequence called Corporate Access
Check that prevents logon from any computer running Windows 95,
Windows 98, or Windows Me.
To create a new sequence

1. Log on to the FirePass controller using an administrative account.
2. In the left navigation pane, click Users, expand Endpoint Security,
and then click Pre-Logon Sequence.
The Pre-Logon Sequence screen opens, as shown in Figure A.10.
FirePass® Controller Administrator Guide A - 11

Appendix A
Figure A.10 FirePass controller Pre-Logon Sequence screen
3. Under the New Sequence section, in the Create new sequence box,
type Corporate Access Check.
4. From the Based on list, select template : Empty.
5. Click Create.
6. Under Select Sequence to Use, click the edit link for Corporate
Access Check.
The visual policy editor opens, as shown in Figure A.11.
A - 12
How-To Examples
Figure A.11 The visual policy editor, for creating pre-logon sequences
Adding the Check OS action to the pre-logon sequence

Now that the pre-logon sequence exists, it needs an action to check for the
operating systems of clients logging on. Before you can add an action, you
must make the Add Action button visible. To make the Add Action button
visible, you position the cursor along the connecting line of the sequence
elements. Figure A.12 shows the cursor positioned so that the Add Action
button is visible.
button visible
To check the client operating system

1. On the screen containing the Corporate Access Check sequence you
created, position the cursor on the connecting line between
Sequence Start and Logon Allowed Page.
4. Under Predefined actions, select Check OS.
The visual policy editor adds Check OS to the sequence, as shown
in Figure A.13.

Appendix A
Figure A.13 The visual policy editor after adding the Check OS action
The default Check OS action denies access to users logging on using the
associated operating systems.
Informing users of the reason that they are prevented logon helps them
correct the condition and try logging on again. The next step guides you
through the process of creating a logon-denied message.
Customizing the Windows 9.x logon-denied message

In this step, we create a message to present to Windows 95, Windows 98,
and Windows Me users who are denied logon access.

1. Click the Logon Denied Page box to the right of Windows 9x
family.
editor.
the message:
This FirePass controller does not support client
computers running Windows 98, Windows 95, or Windows Me.
Supported client operating systems include Windows 2000,
Windows NT, Windows XP, and Windows 2003.
Contact the help desk for more information.

The visual policy editor should now appear similar to the screen
shown in Figure A.14.
A - 14
How-To Examples
Figure A.14 The END PAGE PROPERTIES panel with the logon-denied message for Windows 9.x users
Rule 2: Require Windows NT and Windows 2000 clients to log on

using the virtual keyboard
Next we modify the Windows NT Based action so that it requires Windows
NT and Windows 2000 clients to logon using the virtual keyboard.
The virtual keyboard is a floating keyboard that requires mouse clicks to
enter a password. After each click, the virtual keyboard repositions itself on
the screen. Use of the virtual keyboard aids in preventing unauthorized
recording of logon information by key loggers and other software.
Changing the Windows NT based action

Because the rule we are creating should apply only to clients logging on
using Windows NT and Windows 2000, the first step is to change the
Windows NT Based action to remove the occurrence of Windows XP.
To modify the Windows NT based action

1. Click Windows NT based link in the Corporate Access Check
sequence.
The UPDATE RULE panel opens in the visual policy editor, as

Appendix A
Figure A.15 The UPDATE RULE panel for the Windows NT Based action
2. Delete the session.os.platform == "WinXP" OR condition.

3. In Name, type Windows NT and 2000.
4. Click Update.
You can find a complete set of the session variables generated by inspectors
for action rule expressions in the online help for Users : Endpoint Security :
Pre-Logon Sequence.
Adding the Show Virtual Keyboard action

Now we add the action to require use of the virtual keyboard for Windows
NT and 2000 connections.
To add the Show Virtual Keyboard action

1. On the sequence containing the Corporate Access Check sequence
you created, position the cursor on the connecting line between
Windows NT Based and Logon Allowed Page.
button visible
A - 16
How-To Examples

4. Under Predefined actions, select Show Virtual Keyboard.
The visual policy editor adds Show Virtual Keyboard to the
sequence, as shown in Figure A.17.
Figure A.17 The visual policy editor after adding the Show Virtual Keyboard action
Now, any users who are running Windows NT or Windows 2000 must use
the virtual keyboard to enter their password when they log on to the FirePass
controller.
Rule 3: Allow logons only from Windows XP, Linux, Pocket PC,
and Macintosh computers that have a valid certificate
Next, we want to allow logon only when the connecting client operating
system is of a certain type and that has a specified client certificate. To
accomplish that, we use the subsequence feature in the visual policy editor.
Creating a subsequence for Corporate Access Check

For this rule, we create a subsequence that maps several conditions in the
Check OS action. Subsequences are sequences that perform self-contained
actions. You can use subsequences to refine what actions occur in response
to certain conditions.

Appendix A
To create a subsequence for Corporate Access Check

1. Click the Open subsequences management link in the
Subsequences area of the screen.
The SUBSEQUENCES panel opens in the visual policy editor, as
Figure A.18 The visual policy editor with the SUBSEQUENCES panel open
2. In the box under Add new subsequence in the SUBSEQUENCES

panel, type Certificate Check to name the subsequence.
3. Click the Add subsequence button.
The Subsequence:certificate check appears in the visual policy
editor, as shown in Figure A.19.
A - 18
How-To Examples
Figure A.19 The visual policy editor after adding the certificate check subsequence
Adding the Client certificate check action

Next, we add the Client certificate check action to the certificate check
subsequence. The Client certificate check gathers information about
certificates on client computers and compares that information with the
configuration that you specify in the rule.
Note
You must configure and enable client certificate checking before the
FirePass controller can request and check users’ client certificates. For
more information, see Setting up client-certificate-based authentication, on
page 2-85.
To add the Client certificate check action

1. On the certificate check subsequence you created, position the
cursor on the connecting line between Subsequence:certificate
check and Logon Denied Page.
button visible

Appendix A

4. Under Predefined actions select Check client certificate.
The visual policy editor adds Check client certificate to the
subsequence, as shown in Figure A.21.
Figure A.21 The visual policy after adding the Check client certificate action to the subsequence
Changing the end page for the subsequence

To complete the certificate check subsequence, we change the final action to
allow logons when the client computer has a valid certificate. In this case,
we change Logon Denied Page to Logon Allowed Page.
To change the subsequence’s final action

1. Click the top Logon Denied Page box for the certificate check
subsequence.
editor.
2. In the Type box in the END PAGE PROPERTIES panel, select
Logon Allowed Page.
A - 20
How-To Examples

The end page changes to Logon Allowed Page, as shown in Figure
A.22.
Figure A.22 The subsequence after changing the final action to Logon Allowed Page.
Informing users of the reason that they are prevented from logging on helps
them correct the condition and try logging on again. The next step guides
you through the process of creating a logon-denied message.
Customizing the logon-denied message for the subsequence

In this step, we create a message to present to Windows XP, Linux, Pocket
PC, and Macintosh users who are denied logon access because they lack a
client certificate.

1. Click the Logon Denied Page box to the right of the fallback rule in
the subsequence.
The UPDATE RULE panel opens in the visual policy editor.
the message:
The FirePass controller cannot log you on because you do
not have a valid client certificate.
Contact the help desk to get a valid client certificate,
and try to log on again.

Appendix A
3. Click the Update button:

Figure A.23 The END PAGE PROPERTIES panel with the logon-denied message for users without valid
certificates
A - 22
How-To Examples
Adding a Windows XP rule to the sequence

In this step, we create a Windows XP-related rule and map the Windows
XP, Pocket PC, and Mac OS rules to the Certificate Check subsequence.
Before you can add a rule, you must make the Add Rule button visible. To
make the Add Rule button visible, you position the cursor along the
connecting line of the sequence elements. Figure A.12 shows the cursor
positioned so that the Add Action button is visible.
To create the Windows XP-related rule

1. On the sequence, position the cursor on the connecting line between
Windows 9x family and Linux.
The Add Rule button appears, as shown in Figure A.24.
Figure A.24 Cursor positioned on the connecting line, with Add Rule
button visible
2. Click the Add Rule button .

3. The INSERT RULE panel opens in the visual policy editor.
4. In Name, type Windows XP.
5. In the box under Name, type session.os.platform == "WinXP".
6. Click the Insert Rule button.
shown in Figure A.25, on page A-24.
You can find a complete set of the session variables generated by inspectors
for action rule expressions in the online help for Users : Endpoint Security :
Pre-Logon Sequence.

Appendix A
Figure A.25 The sequence after adding the Windows XP file.
Next, we map the Windows XP, Pocket PC, and Mac OS rules to the
Certificate Check subsequence.
To map the Windows XP rule to the subsequence

1. On the sequence, position the cursor on the connecting line between
Windows XP and Logon Denied Page.
button visible

A - 24
How-To Examples
4. In the CHANGE SEQUENCE panel in the Change sequence box,

select Replace action (deletes branch after).
Options in CHANGE SEQUENCE update to include a
Subsequences section.
5. In Subsequences, select Subsequence: certificate check.
The visual policy editor adds Check client certificate to the
subsequence, as shown in Figure A.27.
Figure A.27 The sequence after adding Check client certificate.
7. Repeat the steps in this procedure to map Linux, Pocket PC, and
Mac OS to the subsequence.
The final Corporate Access Check pre-logon sequence screen
should appear similar to Figure A.28, on page A-26.

Appendix A
Figure A.28 The final visual policy editor for the Corporate Access Check pre-logon sequence
Activating the Corporate Access Check pre-logon sequence

In this step, we activate the pre-logon sequence we just created.
To activate the pre-logon sequence

1. From the visual policy editor, click the Back to console link in the
upper right of the screen.
2. Under Select Sequence to Use, select Corporate Access Check and
click the Apply button, as shown in Figure A.29, on page A-27.
A - 26
How-To Examples
Figure A.29 The Pre-Logon Sequence screen with Corporate Access Check selected and applied
You have now completed creating a pre-logon sequence that checks for and
prevents logon by users running Windows 95, Windows 98, and Windows
Me, requires virtual keyboard for logon from Windows NT- and Windows
2000-based clients, and requires a valid certificate for logon from Windows
XP, Linux, Pocket PC and Macintosh computers.
Tip
You can modify any pre-logon sequence to contain different functionality. If
you do, you should also change the sequence name to reflect any changes
you make. You can change the name by selecting the sequence from the
Rename sequence box, typing the new name, and clicking the Rename
button.

Appendix A
A - 28
Glossary
Glossary
access control list (ACL)

The ACL is a set of restrictions associated with a resource or favorite that
defines access for users and groups.
action
In the pre-logon sequence editor, an action, depicted by a rectangle, is an
ordered set of rules for evaluating a remote system. Each action invokes one
or more inspectors. The action then uses rules to test the inspectors’
findings.
action pane
The action pane is the pane in the visual policy editor where you can type a
description for the action, add and modify the action’s inspectors, and define
rules for the action to use.
active controller/active unit

In a redundant system, the active unit is the system that currently load
balances connections. If the active unit in the redundant system fails, the
standby unit assumes control and begins to load balance connections. See
also redundant system.
Active Directory
The Active Directory is a network structure supported by Windows® 2000,
or later, that provides support for tracking and locating any object on a
network.
The Administrative Console is the browser-based application that you use to
configure the FirePass controller.
Application Access
Application Access is a FirePass controller feature that provides remote
users with web-based remote access to email servers, intranet servers, file
servers, terminal services, and legacy mainframe, character-based, terminal
applications. See also Network Access and Portal Access.
App Tunnel
An App Tunnel is a secure, application-level TCP/IP connection from the
client to a specific set of IP addresses and ports on the network.
authentication
Authentication is the process of verifying the identity of a user logging on to
a network.
FirePass® Controller Administrator Guide Glossary - 1

Glossary
authorization
Authorization is the process of enabling user access to resources,
applications, and network shares.
certificate
A certificate is an online credential signed by a trusted certificate authority
and used for SSL network traffic as a method of authentication.
client certificate
A client certificate enables the FirePass controller to verify the identity of a
user’s computer, and to control access to specific resources, applications,
and files.
client components
A client component is a control downloaded from the FirePass controller
that enables the various features of FirePass controller functionality.
clientless mode
Clientless mode is an endpoint security mode that the FirePass controller
uses, when the inspection process for a client does not download any
controls or plug-ins. In clientless mode, the endpoint security process
inspects HTTP headers to gather information.
cluster
A cluster is a group of FirePass controller nodes that provide common user
services, and can distribute the load of active sessions across all controllers
in the cluster. See also cluster node, primary node, and secondary node.
cluster node
A cluster node represents one station in a cluster, and can consist of a single
FirePass controller, or a redundant system. See also cluster, primary node,
redundant system, and secondary node.
domain name
A domain name is a unique name that is associated with one or more IP
addresses. Domain names are used in URLs to identify particular Web
pages. For example, in the URL http://www.siterequest.com/index.html,
the domain name is siterequest.com.
Domain Name System (DNS)

The Domain Name System (DNS) is a system that stores information
associated with domain names, making it possible to convert IP addresses
such as 192.168.16.8, into more easily understood names such as
www.siterequest.com.
Glossary - 2
Glossary
dynamically mapped resource group

A dynamically mapped resource group is a resource group to which the
FirePass controller grants access based on the resource mapping table.
dynamic group mapping

In dynamic group mapping, the FirePass controller associates a user with a
master group and with resource groups dynamically at user logon time. See
also master group and resource group.
Dynamic Host Configuration Protocol (DHCP)

DHCP is a protocol for assigning dynamic IP addresses to devices on a
network. With dynamic addressing, a device can be assigned a different IP
address every time it connects to the network.
dynamic tunnel
A dynamic tunnel is a connection that the FirePass controller establishes to a
set of dynamic IP addressees and ports, in response to an application
request. See also tunnel and static tunnel.
endpoint security
Endpoint security is a centrally managed method of monitoring and
maintaining client-system security. See also pre-logon sequence, protected
configuration, and resource protection.
failover
Failover is the process whereby a standby unit in a redundant system takes
over when a software failure or a hardware failure is detected on the active
unit. See also active controller/active unit and standby controller/standby
unit.
failover pair
See redundant system.
favorite
A favorite is a webtop link defined by the FirePass controller administrator
or the user that contains all of the information needed for the client
computer to access a location, file share, or application on the company
network. See also webtop.
FIPS compliant
Federal Information Processing Standards (FIPS) are publicly announced
standards developed by the U.S. Federal government for use by all
(non-military) government agencies and by government contractors. The
FirePass controller can be configured with FIPS 140-encryption hardware,
which stores all certificates and private keys in the FIPS hardware.

Glossary
FQDN
See fully qualified domain name.
Full Access
Full Access is the realm that gives superusers complete access to
realm-configuration. See also realm administrator and superuser.
fully qualified domain name

The fully qualified domain name (FQDN) is an unambiguous domain name
that specifies a node’s position in the DNS tree hierarchy absolutely, for
example, myfirepass.siterequest.com. See also domain name.
group mapping
See dynamic group mapping.
heartbeat
The heartbeat is a activity indicator signal that the active controller sends to
notify the standby controller that the active controller is running See also
active controller/active unit and standby controller/standby unit.
high availability
High availability is the process of ensuring access to resources despite any
failures or loss of service in the setup. For hardware, high availability is
ensured by the presence of a redundant system. See also redundant system.
HTTP (HyperText Transport Protocol)

HTTP is the method that is used to transfer information on the Internet and
on intranets.
HTTPS (HyperText Transport Protocol (Secure))

HTTPS is HyperText Transport Protocol (Secure), or secure HTTP. See also
HTTP (HyperText Transport Protocol).
inspector
An inspector is an ActiveX control or Java plug-in that gathers information
about the user’s computer, evaluating factors such as the presence of viruses
or antivirus software, operating system version, running processes, and
others.
interface
A physical port on an F5 system is called an interface.
Glossary - 4
Glossary
IP address
An IP address (Internet Protocol address) is a unique number that identifies
a single device and enables it to use the Internet Protocol standard to
communicate with another device on a network. See also self IP address and
virtual IP address.
IPsec
IPsec (Internet Protocol Security) is a communications protocol that
provides security for the network layer of the Internet without imposing
requirements on applications running above it.
load balancing
The process the primary node uses to distribute user sessions among all the
nodes in the cluster is called load balancing. See also cluster and primary
node.
local traffic management

Local traffic management refers to the process of managing network traffic
that comes into or goes out of a local area network (LAN), including an
intranet.
Maintenance Console
The Maintenance Console is a utility that provides administrative access to
the FirePass controller. You can access the Maintenance Console from the
Administrative Console or from a workstation that is directly connected to
Management interface
The Management interface is a port on the FirePass 4100 and 4300 models
that is intended solely for administrative operations performed from a
workstation that is directly connected to the FirePass controller.
master group
A master group is a collection of users that contains authentication settings,
overall security configuration settings for groups of users, network access
filtering policies, user experience, and user accounts.
name resolution
Name resolution is the process by which a name server matches a domain
name request to an IP address, and sends the information to the client
requesting the resolution.
NAT (Network Address Translation)

A NAT is an alias IP address that identifies a specific node managed by the
FirePass system to the external network.

Glossary
Network Access
Network Access is a FirePass controller feature that provides secure access
to corporate applications and data using a standard web browser. See also
Portal Access and Application Access.
network configuration
Network configuration is the process of setting up the FirePass controller’s
web services on network interfaces. See also web service.
port
A port is a number that is associated with a specific service supported by a
host.
Portal Access
Portal Access is a FirePass controller feature that provides users access to
network resources without requiring the download of any controls to the
client machine. See also Network Access and Application Access.
pre-logon sequence
A pre-logon sequence defines a set of actions that need to be taken in order
to evaluate the client system or device.
primary node
The primary node in a cluster (also known as the master) first handles
incoming connections, and then redirects each session to an available
secondary node, or services the connection itself. The primary node
maintains configurations for all user groups and user resources the cluster
supports. See also cluster, cluster node, load balancing, and secondary
node.
protected configuration
A protected configuration is a collection of safety measures or checks that
guard the connection and client system against various kinds of attacks or
threats. The protected configuration takes information gathered by the
pre-logon sequence and instructs the system to respond based on the result.
protected workspace
The protected workspace is a temporary user environment, containing a new
temporary folder, Desktop folder, My documents folder, and some
temporary registry keys. When the user returns from the protected
workspace, the system deletes all temporary files and keys.
Quick Setup
The Quick Setup wizard is a program that you can run from the
Administrative Console that guides you through the initial configuration
tasks for the FirePass controller.
Glossary - 6
Glossary
realm
A realm is a complete set of roles, master groups, and resource groups.
realm administrator
Realm administrators are users who can create their own hierarchy of access
to the groups and resources inside their realm. In a typical setup, the master
and resource groups of one realm are not accessible to administrators of
another realm, although superusers or realm administrators can grant access
across realms. See also superuser.
redundant system
Redundant system refers to a pair of units that are configured for failover. In
a redundant system, there are two units, one running as the active unit and
one running as the standby unit. If the active unit fails, the standby unit takes
over and manages connection requests.
resource
A resource is an application, a file, or a server on your network to which you
want users to have secure access.
resource group
A resource group is a collection of resources, access control lists, and
protection criteria, which includes your company intranet servers,
applications, and network shares.
resource protection
Resource protection is the process of using a defined protected configuration
to protect a set of resources. See also protected configuration.
rule
Rules test the inspectors’ findings about a client system. The order of rules
in a pre-logon sequence determines the flow of action.
sandbox
The WebDAV sandbox is a directory you can enable on the FirePass
controller. In this directory you can place any content that you want to
reference on user screens, and you can create specific files to modify the
user experience.
secondary node
Each secondary node in a cluster (also known as a slave) services user
sessions as requested by the primary node, and independently maintains its
own network configuration. See also cluster, cluster node, load balancing,
and primary node.

Glossary
SED (Stream EDitor)

SED is a scripting language that you can use to locate a pattern in an
incoming web page, and modify the match before sending the web page to
the client.
self IP address
A self IP address is an IP address that uniquely identifies each FirePass
controller interface or VLAN interface. See also IP address and virtual IP
address.
sequence
See pre-logon sequence.
server certificate
A server certificate verifies the server’s identity to a user’s computer
session variable
A session variable contains a number or string that represents a specific
piece of information about the client system, the FirePass controller, or
another piece of information.
SFP (Small Form-Factor Pluggable)

A small form-factor pluggable transceiver is used in optical communication
for both telecommunications and data communications applications. It
connects a network device, such as a switch or a router, to a fiber optic
networking cable.
signup template
A signup template is a form that the FirePass controller presents to users at
initial logon time that automatically adds the user to the group on the
external server.
snapshot
A snapshot is a compressed set of files that represent the FirePass
controller’s system settings. You can create and restore a snapshot using the
Maintenance Console. See also Maintenance Console.
split tunneling
Split tunneling is a process that directs through the Network Access tunnel
or App Tunnel all network traffic that is not destined for the address
specified.
SSL (Secure Sockets Layer)

SSL is a network communications protocol that uses public-key technology
as a way to transmit data in a secure manner.
Glossary - 8
Glossary
standby controller/standby unit

A standby unit in a redundant system is a unit that is always prepared to
become the active unit if the active unit fails.
static resource group

A static resource group is a resource group that is explicitly assigned to a
master group or to an internally managed user.
static tunnel
A static tunnel is a connection that the FirePass controller establishes to a
specific set of IP addresses and ports on the network. when the client clicks
to run a favorite, before the application starts. See also tunnel and dynamic
tunnel.
strong password
A strong password is one that is difficult to detect by both humans and
computer programs, which effectively protects data from unauthorized
access. A strong password typically consists of a specific number of
alphanumeric characters of differing case as well as certain punctuation
characters.
subsequence
Subsequences are defined sets of actions that run when processing
encounters a branch in the pre-logon sequence. See also pre-logon sequence.
superuser
Superusers are users who have cross-realm access to all groups and features.
A superuser creates realm administrators, upgrading them from FirePass
controller users, and delegating full or restricted access to FirePass
controller functionality or groups. See also realm administrator.
synchronization
Synchronization is the process used by the primary node to synchronize data
with the secondary nodes of a cluster. See also cluster, primary node, and
secondary node.
terminal server
A terminal server is a connection to a Microsoft Terminal Server, Windows
XP® desktop, Citrix MetaFrame® server, or VNC server.
trace
The trace feature provides an easy way for you to capture logs of user
sessions through the Web Applications feature of Portal Access.

Glossary
tunnel
A tunnel is a secure connection between computers or networks over a
public network.
URI (Uniform Resource Identifier)

A URI is a Uniform Resource Identifier. In the FirePass controller context,
URI means the fully-qualified domain name, followed by the path
designator /<uri-specific_path>.
virtual host
In the FirePass controller context, a virtual host means the domain name or
IP address that users specify when logging on to a web service you create on
a virtual IP. See also virtual IP address.
virtual IP address
A virtual IP address is an IP address that identifies a virtual (that is,
non-physical) network location. The FirePass controller uses virtual IP
addresses for redundant systems. See also IP address, redundant system,
and self IP address.
visual policy editor

The visual policy editor consists of a graphical area in which you create a
pre-logon sequence by clicking to add and delete actions and rules. See also
pre-logon sequence, action, and rule.
webifyer
A webifyer is a FirePass controller feature that uses a browser to provide
nonbrowser-based application functionality. The FirePass controller uses
webifyers to present the Portal Access applications Windows Files and
Mobile E-Mail, as well as the Application Access applications Legacy
Hosts, Terminal Servers, and more.
web service
A web service is a method of communication that applications written in
various programming languages and running on various platforms can use to
exchange data over networks, such as the Internet or an intranet.
webtop
The webtop is the user’s home page, which contains links that are
configured as favorites for that user’s master group. Along the left side of
the webtop are icons representing various functionality. Depending on how
the webtop is configured, users may be able to add their own favorites by
clicking an icon and adding links.
Glossary - 10
Index
Index
A and RSA SecurID authentication server 8-37

access control agent host records 8-36
and examples 3-32 alias to a favorite
configuring scope 7-16 See favorites.
access control lists 8-26 allow list 8-26
accessibility allow local subnet 5-20
and full network access 1-6 alternate webtop
and options 1-6 establishing 6-14
action pane Alternative Host/Port-based bypass
described 3-21 configuring 7-13
action-checking operation and requirements for cluster setup 12-2
and action pane 3-21 antivirus
actions and content inspection 7-43
and internal structure for 3-19 and endpoint security 3-8
and pre-logon sequence 3-15 scanning in Portal Access 7-48
and rules 3-23 App Logs report
using in pre-logon sequences 3-19 described 10-1
active connections understanding entries 10-2
and Complete history log 10-14 using 10-2
and Currently active log 10-13 App Tunnels
and Session summary log 10-15 and best practices for customizing 6-16
and Today’s sessions log 10-14 and configurable applications 6-2
active controller and IPsec VPN clients 6-2
and synchronization 11-12 and Network Access 6-2
configuring heartbeat synchronization 11-14 and Portal Access 7-1
defined 11-1 configuring master group settings 6-23
See also failover. configuring settings for status 6-24
See also redundant system. configuring to open automatically 6-17
verifying identity 11-21 customizing 6-16
Active Directory defined 2-95
and authentication 2-82 defining access control 8-26
and mapping groups dynamically 2-27 defining favorites 6-7
defined 2-82 establishing with alternate webtop 6-14
using nested groups 2-83 for resource groups 2-98
active failover members mapping network drive 6-18
reviewing configuration 11-2 understanding 6-2
ActiveX controls understanding master group settings for 6-23
and inspectors 3-10 appearance of home page, customizing 8-70
activity reports 10-16 Application Access
Admin E-mail configuring legacy hosts keyboard mapping 6-30
configuring 8-34 defining legacy host favorites 6-27
administrative privileges introducing 6-1
assigning to users 8-32 application access
administrators and Portal Access 7-2
and full access 8-30 application launch
and realm-level configurations 8-30 configuring for Macintosh or Linux 9-17
configuring administrator-specific access 8-32 Application Logs report
advanced customization See App Logs report.
about logon.denied file 2-55 application tunnel access
disabling popup blockers 2-54 described 1-6
using logon_failed file 2-55 See also App Tunnels.
using logout.inc file 2-55 applications
using resetpass.inc file 2-55 and App Tunnels 6-2
advanced routing mode Ask F5
See Routing screen modes. and support 1-15
agent host attempts to log on, report 10-10
FirePass® Controller Administrator Guide Index - 1

Index
authentication for specifying ports 8-7

and available methods 2-4 for upgrades 8-47
and dynamic group mapping 2-88 BIG-IP system
and external user management 2-6 and offloading SSL processing 8-25
and extra policy layer of protection 2-87 and virtual servers 8-25
and master groups 2-12, 2-67 described 8-24
and NTLM 7-14 integrating with FirePass controller 1-2
and passwordless auto-login 2-88 bitrate
and pre-logon sequences 2-88 configuring parameters for bitrate evaluator 5-18
and resource protection 2-88 determining value 5-18
and two-factor authentication 2-87 box on logon page 2-51
choosing an authentication method 2-67 browser definitions, adding 8-35
configuring a RADIUS server 2-72 browser usage
configuring a Windows domain server 2-82 See Summary reports.
configuring Active Directory 2-82 browsers
configuring client certificates 2-87 adding definitions for 8-35
configuring HTTP for 2-85 and requirements for endpoint security 3-25
configuring internal 2-72 installing certificates 4-10
configuring LDAP server 2-74 using to upgrade 8-50
configuring passwordless automatic-login 2-89 buffer overflow and content inspection 7-43
configuring RSA SecurID authentication server 8-36 buffer overflow attacks
converting the method for master group 2-71 and exploited inputs 7-47
determining a method 2-68 and options 7-47
overview 2-67
specifying a method for a group 2-68
authentication settings for a group of users C
See master groups. cache and compression
authorization 2-67 configuring 7-31
autolaunch of web applications configuring global settings 7-32
feature 5-40 CA-signed certificates
automated service deployment See also certificates.
using component installer 9-5 submitting a CSR 4-8
availability understanding 4-2
testing 11-19 using 4-2
Cavium RoHS card 8-48
cert.zip file
B and self-signed certificate 4-8
backend server certificate revocation list
and SSL certificate 4-2 and best practices 4-14
backups and limitation 4-14
and automatic 8-48 described 4-13
and manual 8-48 Certificate Signing Request
and restoring configurations 8-48 and CertRequest.zip files 4-7
best practices sending as an email attachment 4-8
and client certificates 4-14 specifying type 4-8
and clustered controllers 12-2, 12-7 submitting 4-7
and dynamic group mapping 2-16 certificate store 9-5
for certificate revocation lists 4-14 certificates
for certificates 4-2 accessing server certificate information 4-5
for customizing App Tunnels 6-16 and best practices 4-2
for external authentication 2-6, 2-14 and browser warnings 4-1
for LDAP authentication 7-40 and extra policy layer of protection 2-87
for managing users 2-3 and FIPS hardware 4-9
for Online Certificate Status Protocol 4-15 and Online Certificate Status Protocol 4-15
for protected configurations 3-7, 3-31 and status 4-5
for RSA authentication 8-44 and types of 4-8
Index - 2
Index
associating with a web service 4-10 using 2-85

deleting 4-12 client components
generating Certificate Signing Request 4-6 and security policy 9-1
generating self-signed certificates 4-8 downloading 9-1
installing a signed server certificate 4-8 synchronizing 11-16
installing on client browser 4-10 troubleshooting 9-36
installing self-signed certificates 4-8 client connections
overview 4-1 establishing 9-19
sending a CSR as an email attachment 4-8 client cookies
specifying type for Certificate Signing Request 4-8 See cookies.
submitting a Certificate Signing Request 4-7 Client for Microsoft Networks 5-21
understanding CA signed certificates 4-2 client root certificates
understanding self-signed certificates 4-2 overview 4-13
understanding SSL server certificates 4-1 client system checking
updating server certificates 4-11 implementing 3-14
using client certificates 2-85 clientless mode 3-1
using self-signed certificates 4-2 cluster controllers
viewing 4-5 requirements for setup 12-2
CertRequest.zip files clustered controllers
and Certificate Signing Request 4-7 accessing secondary from primary 12-16
chaining certificates and benefits 12-1
See also intermediate certificates. and best practices 12-2, 12-7
See CA-signed certificates. and certificates 12-3
Citrix ICA and domain names 12-3
and session reliability 6-39 displaying operational statistics 12-16
specifying client location 6-37 overview of 12-1
specifying client version 6-38 starting 12-7
Citrix JICA client synchronizing 12-1
specifying 6-39 clustered servers
Citrix MetaFrame servers synchronizing 12-8
and session reliability 6-39 clustering
and Terminal Server favorites 6-33 See clustered controllers.
Citrix session reliability clusters
defined 6-39 See clustered controllers.
enabling 6-40 collection of resources
Clam AntiVirus See also master groups.
configuring for automatic update 7-49 See resource groups.
configuring for manual update 7-49 command line
enabling 7-49 using to upgrade 8-50
client applications command syntax conventions 1-13
and Network Access 5-4 common operations, following recommended path 1-9
and Portal Access 5-4 common problems
client browsers fixing with Web Applications engine trace 13-6
installing certificates 4-10 troubleshooting 8-61
client certificates Complete history logs
and best practices 4-14 understanding 10-14
and certificate revocation list updates 4-14 component installer service
and dynamic group mapping 2-88 and automated service deployment 9-5
and Online Certificate Status Protocol 4-15 configuration of failover 11-5
and passwordless auto-login 2-88 configuration settings for a group of users
and pre-logon sequences 2-88 See master groups.
and resource protection 2-88 configurations
and two-factor authentication 2-87 and scenarios 1-10
authenticating users 2-88 backing up and restoring 8-47
configuring for authentication 2-87 restoring FIPS systems 8-48
requesting during logon 2-86 console, accessing 8-62

Index
content inspectors understanding options 5-23

and types 7-43 domain scripts
configuring 7-43 running 5-26
content processing dynamic caching
configuring for web applications 7-19 and Web Applications engine trace 13-2
configuring global settings 7-25 dynamic group mapping
configuring scripts for 7-19 and authentication 2-88
testing settings 7-23 and best practices 2-16
context-sensitive online help 1-15 and client certificates 2-88
control restrictions 8-26 and master mapping table 2-22
controller clusters and related request configurations 2-26
See clustered controllers. and resource mapping tables 2-22
cookies and tasks for configuring 2-22
and Portal Access 7-5 configuring 2-25
specifying cookie passthrough 7-5 enabling 2-23, 2-24
Corporate Access Check pre-logon sequence 3-11 optimizing 2-16
CRL See also group mapping.
See certificate revocation list. understanding 2-16
cross site scanning dynamic master group mapping
excluding sites from 7-45 and examples 2-20
cross site scripting dynamic resource groups
configuring 7-43 See resource groups.
CSR dynamically mapped resource group
See Certificate Signing Request. defined 2-96
CSS scripting See also resource groups.
See cross site scripting.
Currently active log, understanding 10-13
custom messages E
and options 5-32 elements of pre-logon sequences 3-13
custom variables email
creating 3-9 and security alerts and notifications 8-34
configuring Admin E-mail 8-34
configuring LDAP as email address source 7-41
D configuring system health notifications 8-67
date format, specifying 8-44 disabling email attachments 7-42
default gateway See also Mobile E-Mail.
modifying using light mode 8-11 email address for user name 2-50
default group email notification for system health, configuring 8-67
See also default master groups. email server, specifying 8-40
default keyboard mapping 6-31 endpoint security
default master groups and actions 3-15
deleting 2-12 and actions to correct client computer 3-6
See also master groups. and antivirus detection 3-8
using 2-8 and browser requirements 3-25
default server certificate 4-5 and clientless mode 3-1
definitions for browsers, adding 8-35 and extra policy layer of protection 2-87
deployment solutions and file version 3-8
connecting FirePass controller to internal LAN 5-9 and implementation tasks 3-14
connecting FirePass controller to separate LAN and inspectors 3-8
5-10 and internal structure for an action 3-19
DHCP server 5-29 and JavaScript 3-9
DMZ subnet and Linux 3-1
and NAPT communication 5-10 and MacOS X 3-1
and static routes 5-10 and McAfee 3-8
DNS and MD5 signature 3-8
configuring 8-18 and Norton AntiVirus 3-8
Index - 4
Index
and operating system detection 3-8 and shared IP addresses 11-7

and pre-logon sequence 3-12 configuring active controller 11-7
and pre-logon sequences 2-88 enabling on active controller 11-7
and protected configurations 3-7, 3-10 See also redundant system.
and resource protection 2-88 switching to standby controller 11-21
and risk-factor/safety feature associations 3-27 triggering manually 11-21
and rule examples 3-23 failover configuration
and rule syntax 3-23 configuring 11-7
and scans 3-8 verifying 11-20
and session variables 3-24 failover configuration strategy 11-5
and visual policy editor 3-10 failover controllers
assigning protected configurations to favorites 3-18 installing 11-1
collecting information 3-1 overview 11-1
configuring post-logon protection 3-33 starting 11-20
creating a pre-logon sequence 3-15 failover member
creating a pre-logon sequence rule 3-24 introducing into production 11-5
creating protected configurations 3-27 failover shared IP address 11-7
creating subsequent pre-logon sequence 3-25 failover-only controller 11-2
defining rules and actions in sequences 3-23 fake status, for certificates 4-5
exempting master groups from safety checks 3-27 fallback
implementing access control example 3-32 for rules 3-19
implementing client system checking 3-14 favorites
performing remediation 3-6 assigning protected configurations to 3-18
protecting resources 3-7 configuring for resource groups 2-97
understanding 3-1 configuring for terminal servers 6-33
understanding protection limitations 3-9 defined 2-1
understanding protection options 3-8 defining for App Tunnels 6-7
endpoint security configuration 3-13 defining for legacy hosts 6-27
error screens defining Portal Access 7-6
customizing with WebDAV 2-63 using a SED script 7-20
External addresses file and printer sharing option 5-21
configuring multiple 11-19 file names
external groups for log files 8-52
importing 2-13 file shares
mapping 2-13 mapping App Tunnels 6-18
external user management file version
authentication 2-6 and endpoint security 3-8
external users and inspectors 3-8
configuring master groups for 2-6 files
maintaining 2-6 configuring antivirus scanning 7-48
extra box on logon page 2-51 FIPS
extra policy layer of protection and certificates 4-9
and client 2-87 FIPS accreditation cards
extra-access log and RoHS support 8-48
See Server access log (http). FIPS systems
extra-error log and backups 8-48
See Server error log (http). FirePass 1000
described 1-3
specifying ports 8-8
F FirePass 4000
F5 Technical Support, contacting 1-15 specifying ports 8-8
F5FirePassRoot certificate store 9-5 FirePass 4100 and 4300
failover described 1-3
and clustered controllers 12-7 specifying ports 8-7
and fully qualified domain names 11-7 FirePass controller
and RSA SecurID 8-39 finding software version 1-4

Index
overview 1-1 and master groups 2-11

FirePass models 1-3 Group report
FIREPASS-SYSTEM-MIB described 10-1
and controller-specific features 8-41 understanding entries 10-4
firewall detection using 10-4
and endpoint security 3-8 group-based averages report
Flash rewriting See Group report.
and Flash files 7-28 group-level packet filtering rules
understanding 7-28 applying for specific resource groups 5-27
FlashActionScript 7-28 groups
FQDN and default master group 2-14
configuring in failover 11-7 and Group report 10-4
specifying 8-4 authenticating externally 2-6
full access realm administrator overview 2-1
and tasks 8-30 See also master groups and resource groups.
full network access
described 1-6
fully qualified domain names, See FQDN. H
hardware
monitoring load 8-67
G restarting 8-59
general master group settings shutting down 8-60
and App Tunnel connections 6-23 health
for legacy host connections 6-31 monitoring 8-67
for terminal server connections 6-36 heartbeat
global packet filter rules configuring for active controller 11-14
applying to Network Access traffic 5-10 configuring for standby controller 11-18
global packet filters defined 11-13
See global packet filter rules. for redundant systems 11-13
global settings help
and Windows files 7-36 finding 1-15
configuring for cache and compression 7-32 locating online help 1-15
configuring for content processing 7-25 high availability
configuring for web applications 7-29 accessing standby controller 11-18
for FirePass controller 8-2 and failover configuration 11-1
Google Desktop Search and heartbeat 11-13
denying access to users of A-2 configuring active controller 11-7
described A-2 configuring heartbeat synchronization for active
group mapping controller 11-14
adding mapping table resources 2-96 configuring heartbeat synchronization for standby
and master mapping table 2-22 controller 11-18
and related request configurations 2-26 configuring standby controller 11-15, 11-16
and resource groups 2-96 enabling failover on active controller 11-7
and resource mapping tables 2-22 introducing failover member 11-5
associating your local network groups 2-6 reviewing active failover member configuration
mapping based on landing URI 2-43 11-2
mapping based on RADIUS groups 2-40 reviewing active standby member configuration
mapping based on session variables 2-47 11-4
mapping based on virtual host 2-45 See also redundant system.
optimizing 2-16 triggering manual failover 11-21
See also dynamic group mapping. understanding
setting and changing priority 2-52 verifying controller identity 11-21
specifying a method 2-26 verifying failover configuration 11-20
understanding 2-17 home page appearance, customizing 8-70
Group Names host names
and authentication 2-12 adding a static host name 8-20
Index - 6
Index
configuring 8-4 and scans 3-8

preserving 7-18 creating custom variables 3-9
See also FQDN. See also content inspectors.
host names, static 8-19 See also pre-logon sequence.
how-to understanding protection limitations 3-9
creating a subsequence A-17 installed certificates
denying access to Google Desktop Search users viewing 4-5
A-2 integrated IP filter 5-29
denying access to Windows users A-11 intermediate certificates 4-9
requiring log on using virtual keyboard A-15 internal authentication 2-72
HTML syntax errors internal LAN
and options for fixing 13-6 and NAPT communication 5-9
and Web Applications engine trace 13-6 and static routes 5-9
fixing with content cleaning feature 13-7 internal user management 2-8
fixing with SED scripts 13-7 configuring 2-8
HTTP activity IP addresses
and HTTP Log report 10-6 adding on the FirePass controller 8-10
HTTP and HTTPS Log report changing for DNS 8-18
described 10-1 changing on the FirePass controller 8-10
HTTP basic authentication 2-4 configuring for NetBIOS broadcasts 8-25
HTTP form-based communication configuring for standby controller 11-17
using for authentication 2-4 configuring for the FirePass controller 8-10
HTTP Log report configuring NAS IP addresses for RADIUS requests
and options 10-6 8-25
understanding entries 10-7 configuring overlapping IP address pools 5-12
using 10-6 deleting from the FirePass controller 8-10
HTTP proxies IP filtering engine 5-29
using 8-42 IP Group Filters
HTTPS and options 5-26
and Network Access 5-3 understanding 5-26
https.extra-access log IPsec VPN clients
See Server access log (https). and App Tunnels 6-2
https.extra-error_log file
See Server error log (https).
J
Java applets
I and Portal Access 13-9
ICAP Java plug-ins
described 7-48 and inspectors 3-10
index.htm file JavaScript
creating 2-56 and endpoint security 3-9
example 2-56 and Portal Access 13-9
input box on logon page 2-51
inspectors
and ActiveX controls 3-10 K
and antivirus detection 3-8 Kerberos
and browser requirements for endpoint security See Active Directory.
3-25 kernel
and endpoint security 3-8 and reserved routing tables 8-15
and file version checking 3-8 keyboard map
and firewall detection 3-8 and default 6-31
and Java plug-ins 3-10 defined 6-30
and MD5 signature 3-8 keyboard redirection
and operating system detection 3-8 configuring 6-41
and pre-logon sequences 3-10
and protected configurations 3-27

Index
L and RADIUS 8-58

LAN and Session summary log 10-15
connecting FirePass controller to internal 5-9 and shared variables 8-54
connecting FirePass controller to separate 5-10 and Summary report 10-16
landing URI and System Logs reports 10-18
and logon customization 2-48 and typical name 8-53
and mapping 2-43 managing 8-51
LDAP transferring 8-52
configuring as email address source 7-41 understanding 8-52
mapping based on group object 2-34 understanding format 8-53
mapping based on user object 2-27, 2-33 Logging options
mapping groups dynamically 2-32 understanding 10-20
using for authentication 2-4, 2-74 logon page input box 2-51
LDAP authentication logon with email address 2-50
and best practices 7-40 logon-denied messages
LDAP query customizing A-8, A-14
configuring 7-40 Logons report
legacy host connections and options 10-10
and master group settings 6-31 described 10-1
legacy hosts understanding 10-10
and Application Access 6-26 understanding entries 10-10
and general master group settings 6-31 logos
and supported terminal types 6-26 customizing webtop to display 8-70
configuring access to 6-26 LTM
configuring mapping 6-30 See local traffic management.
creating favorites for resource groups 2-98
defining favorites for 6-27 M
understanding 6-26
MAC addresses
license
and shared 8-6
adding features 8-46
for FirePass platforms 8-7
installing 8-46
Mac OS X and endpoint security 3-1
license request
Macintosh
generating 8-46
and supported Network Access features 9-16
licenses
configuring application launch 9-17
managing 8-45
maintenance 8-45
light mode
Maintenance Console 8-11, 8-62
See Routing screen modes.
mapping methods
Linux
See dynamic group mapping.
and endpoint security 3-1
mapping tables
and supported Network Access features 9-16
adding or modifying 6-30
configuring application launch 9-17
See also master mapping table.
installing client on 9-18
See also resource mapping tables.
load balancing
understanding 6-30
activating 12-13
master controllers
and random mode 12-13
See primary controllers.
deactivating 12-13
master group settings
load statistics 8-67
configuring App Tunnel status settings 6-24
local traffic management
configuring for legacy host connections 6-31
described 8-24
configuring for terminal server connections 6-36
See also BIG-IP system.
configuring Terminal Servers status 6-42
log files
for the Legacy Hosts webifyer status 6-32
and App Logs report 10-2
specifying split tunneling options 6-24
and Complete history log 10-14
understanding 6-23
and Currently active log 10-13
master groups
and Group report 10-4
and access control lists 7-16
and HTTP Log report 10-6
Index - 8
Index
and authentication 2-12 See browsers.

and authentication settings 2-14 minimal content rewriting
and default 2-14 configuring 7-10
and general master group settings 6-23 Mobile E-Mail
and Group Names 2-11 and Portal Access
and group report 10-4 configuring 7-39
and max concurrent sessions 2-12 configuring LDAP as email address source 7-41
and passwordless auto-login 2-88 disabling email attachments 7-42
and resource groups 2-12 monitoring server 8-66
and resource mapping tables 2-22
and routing tables 2-12
and signup template 2-12 N
and two-factor authentication 2-87 NAPT communication
and users 2-12 and routing 5-9
and Windows Files 7-37 choosing 5-6
associating routing tables 5-15 enabling 5-8
configuring 2-11, 5-15 using to connect to internal LAN 5-9
configuring for external users 2-6 using to connect to separate network 5-10
configuring for internal users 2-8 NAS IP addresses
configuring Network Access settings 5-39 for RADIUS requests 8-25
configuring routing for 5-15 Native RSA authentication
configuring settings for App Tunnels 6-23 See RSA SecurID authentication server.
converting the authentication method 2-71 nested groups
creating on the FirePass controller 2-8 using during authentication 2-83
defined 2-1 NetBIOS broadcasts
defining 5-16 and IP address to use 8-25
determining authentication method 2-68 Network Access
exempting from safety checks 3-27 adding group-level packet filtering rules 5-27
managing 2-13 and allow local subnet option 5-20
managing internally 2-8 and Application Tunnels 6-2
mapping based on Active Directory groups 2-27 and client customization 5-31
mapping based on landing URI 2-43 and favorites 5-19
mapping based on LDAP group object 2-34 and file and printer sharing option 5-21
mapping based on LDAP information 2-32 and functionality supported 5-1
mapping based on LDAP user object 2-27, 2-33 and IP Group Filters 5-26
mapping based on RADIUS groups 2-40 and Linux support 9-16
mapping based on session variables 2-47 and Macintosh support 9-16
mapping based on virtual host 2-45 and Microsoft Networks client 5-21
mapping based on Windows domain groups 2-27, and point-to-point protocol 5-3
2-30 and Portal Access 7-1
populating with users 2-13 configuration overview 5-6
preserving host names 7-18 configuring bitrate evaluator parameters 5-18
settings for App Tunnels 6-23 configuring favorites for resource groups 2-98
specifying an authentication method 2-68 configuring global settings 5-3
using list screen 2-11 configuring master group settings 5-39
master mapping table configuring policy-fallback rules 5-28
defined 2-22 configuring resource settings 5-19
max concurrent sessions establishing client connections 9-19
and master groups 2-12 overview 5-1
McAfee, and endpoint security 3-8 understanding 5-3
MD5 signature using client applications with 5-4
and endpoint security 3-8 using Windows power management 5-32
and inspectors 3-8 Network Address Port Translation
Microsoft Terminal Servers See NAPT communication.
and Terminal Server favorites 6-33 network configuration settings
mini-browsers and web services 8-3

Index
defined 8-3 policy checks

maintaining 8-3 and policy fallback rules 5-28
network drives policy fallback rules 5-28
mapping for App Tunnels 6-18 port 443
network file shares and web services on active controller 11-10
mapping App Tunnels for 6-18 port 80
network files and web services on active controller 11-11
configuring access to users 7-36 Portal Access
network packets and App Tunnels 7-1
capturing 8-63 and client applications 5-4
network resources and default virus scanner 7-49
controlling access to 3-31 and features 7-1
network settings and Java applets 13-9
and NAS IP addresses for RADIUS request 8-25 and JavaScript 13-9
Network Time Protocol Server and Network Access 7-1
See NTP server. and security 7-1
Norton AntiVirus, and endpoint security 3-8 and Windows Files 7-37
NTLM blocking suspicious characters in web content 7-46
and support for version 2 7-15 configuring access control 7-16
configuring 7-14 configuring Alternative Host/Port-based bypass
NTP server 7-13
and best practices for RSA authentication 8-44 configuring antivirus scanning 7-48
specifying for controller 8-43 configuring Clam AntiVirus for automatic update
specifying time zone 8-43 7-49
configuring Clam AntiVirus for manual update 7-49
configuring minimal content rewriting 7-10
O configuring Mobile E-Mail 7-39
OCSP configuring SSL injection scanning 7-45
See Online Certificate Status Protocol. configuring WebAccess ByPass 7-12
one-click logon 2-89 defining favorites 7-6
Online Certificate Status Protocol enabling ICAP client 7-48
and best practices 4-15 enabling standalone virus scanner 7-49
described 4-14 excluding sites from XSS scanning 7-45
using 4-15 filtering suspicious characters in web content 7-46
online help 1-15 introducing 7-1
online updates protecting against buffer overflow attacks 7-47
See upgrades. scanning for embedded script code 7-44
operating system detection scanning for suspicious characters 7-44
and endpoint security 3-8 specifying user-agent strings 7-8
and inspectors 3-8 updating virus scanning files 7-49
operating system usage working with URL variables 7-7
See Summary reports. Portal Access access control 8-26
overlapping IP address pools portal access screen
and special considerations 5-12 creating 2-58
configuring 5-12, 5-14 ports
and best practices for specifying 8-7
P configuring ports for Synchronization Agent 8-23
specifying for FirePass 1000 8-8
password
specifying for FirePass 4000 8-8
setting a strong password 2-81
specifying for FirePass 4100 and 4300 8-7
passwordless auto-login
specifying range for App Tunnels 6-16
and client certificates 2-88
post-configuration tasks 11-20
phone browsers
post-logon protection
See browsers.
configuring 3-33
point-to-point protocol (PPP)
PPP
and Network Access 5-3
See point-to-point protocol.
policy check messages, configuring 5-32
Index - 10
Index
pre-logon sequence protection options

and actions 3-15, 3-19 understanding 3-8
and ActiveX controls 3-10 proxies
and client certificates 2-88 and HTTP and SSL 8-42
and Corporate Access Check 3-11 configuring options 7-34
and inspector 3-27 locating conflicts 7-19
and internal structure for an action 3-19 requirements for FirePass controller 7-34
and Java plug-ins 3-10 specifying HTTP or SSL 8-42
and protected configurations 3-7, 3-10, 3-14, 3-27, specifying settings 7-34
3-31
and protecting resources 3-7
and rule examples 3-23 R
and rule syntax 3-23 RADIUS
and visual policy editor 3-10 and NAS IP addresses 8-25
checking for Google Desktop Search A-5 and RADIUS accounting server 8-58
checking user operating system A-13 configuring accounting for 8-58
creating 3-15 parsing for attribute-specific values 2-41
creating a rule for 3-24 RADIUS groups
creating a subsequence A-17 mapping 2-40
creating subsequences 3-25 RADIUS server
defining rules and actions 3-23 setting up 2-72
described 3-10 RADIUS server query
determining protected workspace use 3-16 using for authentication 2-4
exempting master groups from safety checks 3-27 random load balancing mode 12-13
identifying sequence elements 3-13 realm administrators
understanding 3-12 adding 8-32
understanding the flow 3-11 deleting 8-33
using visual policy editor 3-12 overview 8-30
primary controllers realm-based operations
defined 12-1 and tasks 8-30
synchronizing 12-4 realm-level
primary node configuring access for a group 8-31
See primary controllers. configuring access to features 8-31
protected configuration configuring administrator access for users 8-32
and extra policy of protection 2-87 redundant pair
described 3-15 definition 11-1
protected configurations redundant system
and associated protection criteria 3-27 accessing standby controller 11-18
and best practices 3-7, 3-31 and shared IP address 11-7
and pre-logon sequence 3-14 configuring active controller 11-7
and risk factors 3-27 configuring heartbeat synchronization 11-18
and risk-factor/safety feature associations 3-27 configuring heartbeat synchronization for active
assigning 3-18 controller 11-14
assigning to favorites 3-18 configuring manual failover 11-21
configuring post-logon protection 3-33 configuring standby controller 11-15, 11-16
creating 3-17 configuring standby controller with self IP address
defined 3-27 11-17
described 3-7, 3-10, 3-31 configuring synchronization service on active
exempting master groups from safety checks 3-27 controller 11-12
implementing access control example 3-32 configuring web services on active controller 11-10
using data collected 3-17 enabling failover on active controller 11-7
protected workspace heartbeat 11-13
and creating a pre-logon sequence for 3-16 introducing failover member 11-5
protection assignment overview 11-1
understanding 3-32 reviewing active failover member configuration
protection limitations 3-9 11-2

Index
reviewing standby failover member configuration risk-factor/safety feature associations 3-27

11-4 RoHS card 8-48
verifying controller identity 11-21 routing
verifying failover configuration 11-20 adding and editing rules 8-16
redundant system heartbeat 11-13 configuring for master groups 5-15
regex configuring rules 5-17
See standard regular expression. understanding 5-9
release notes 1-15 Routing screen modes
remote user access adding a single route in advanced mode 8-14
using Application Access 6-1 adding a single route in light mode 8-11
remote-access technologies 1-1 adding multiple routes in advanced mode 8-15
reports adding multiple routes in light mode 8-13
and Complete history log 10-14 adding routing rules in advanced mode 8-16
and Currently active log 10-13 defined 8-11
and Group report 10-4 deleting routing tables in advanced mode 8-15
and HTTP Log report 10-6 editing multiple routes in advanced mode 8-15
and Logons report 10-10 routing tables
and Server access log (https) 10-8 and kernel 8-15
and Server error log (http) 10-7 and master groups 2-12
and Session summary log 10-15 associating with master groups 5-15
and Sessions report 10-12, 10-13 configuring in advanced mode 8-15
and SSL engine log 10-9 configuring in light mode 8-11
and Summary report 10-16 RSA authentication
and System Logs report 10-18 and best practices 8-44
and the App Logs report 10-2 RSA SecurID authentication server
and Today’s sessions log 10-14 configuring 8-36
overview 10-1 configuring FirePass controller as agent host 8-37
saving 10-1 RSA SecurID technology
resource groups troubleshooting on Windows 2-72
and master groups 2-12 using for authentication 2-3, 2-4, 2-72
applying group-level packet filtering rules 5-27 using on FirePass controllers 8-39
assigning a resource groups 2-96 rules
creating App Tunnel favorites 2-98 and actions in pre-logon sequence 3-19
creating legacy host favorites 2-98 and examples 3-23
creating Network Access favorites 2-98 and fallback 3-19
creating Terminal Server favorites 2-98 and policy fallback 5-28
creating Web Application favorites 2-97 and session variables 3-24
creating Windows Files favorites 2-97 and syntax elements 3-23
editing 2-97 checking for Google Desktop Search A-5
mapping dynamically 2-96 creating a pre-logon sequence rule 3-24
mapping dynamically based on Active Directory See also sequence rules.
controllers 2-27 using 3-23
mapping dynamically based on Windows domain
controllers 2-27
mapping statically 2-96 S
understanding 2-1 sandbox
resource mapping tables and files 2-54
defined 2-22 using directory 2-54
resource protection saving reports 10-1
and client certificates 2-88 scans
and levels of 3-31 and endpoint security 3-8
understanding protection assignment 3-32 and inspectors 3-8
resources scenarios
and IP Group Filters 5-26 creating a subsequence A-17
and users accessing 3-14 denying access to Google Desktop Search users
protecting 3-31 A-2
Index - 12
Index
denying access to Windows users A-11 Server access log (https)

requiring log on using virtual keyboard A-15 and extra.https.extra-access log 10-8
screen resolution 6-40 understanding 10-8
secondary controller 12-1 server certificates
secondary node and default 4-5
See secondary controller. installing 4-8, 4-11
secure remote access 1-1 See also certificates.
security See also self-signed server certificates.
and cross site scripting 7-43 viewing 4-5
and default virus scanner 7-49 Server error log (http)
and endpoint security 3-1 understanding 10-7
and ICAP 7-48 Server error log (https)
and Portal Access 7-1 and https.extra-error_log file 10-8
and risk-factor/safety feature associations 3-27 understanding 10-8
and self-signed certificates 4-8 services
blocking Portal Access 7-47 restarting 8-59
blocking SQL injection attacks 7-47 Session summary logs
blocking suspicious characters in web content 7-46 understanding 10-15
configuring antivirus scanning 7-48 session updates
configuring Clam AntiVirus for automatic update preventing 7-26
7-49 session variables
configuring Clam AntiVirus for manual update 7-49 and RADIUS attributes 2-48
configuring email for alerts and notifications 8-34 described 3-24
configuring post-logon protection 3-33 mapping based on 2-47
configuring SSL injection scanning 7-45 Sessions report
enabling standalone virus scanner 7-49 and options 10-12
excluding sites from XSS scanning 7-45 described 10-1
filtering suspicious characters in web content 7-46 understanding entries 10-13
for user accounts 2-3 using 10-12
implementing client system checking 3-14 viewing 10-12
protecting against buffer overflow attacks 7-47 shared files
restricting input to allowed character set 7-44 configuring access to users 7-36
scanning for embedded script code 7-44 shared IP addresses
scanning for suspicious characters 7-44 and failover pair 11-7
scanning sites for SQL injection attacks 7-47 shared MAC addresses 8-6
supported by FirePass controller 1-5 signed server certificate
updating virus scanning files 7-49 See self-signed server certificate.
SED scripts signup templates
adding 7-20 and master groups 2-12
and examples 7-21, 7-22, 7-23 using to add users 2-14
troubleshooting failures 7-24 using when managing users locally 2-14
using to fix HTML syntax errors 13-7 Simple Mail Transfer Protocol
self-signed certificates See SMTP email server.
and cert.zip file 4-8 Simple Network Management Protocol
installing 4-8 See SNMP agent.
understanding files generated by 4-8 single-click logon
self-signed server certificates, using 4-2 See one-click logon.
sequence elements 3-13 slave controller
sequence rules See secondary controller.
defining 3-23 SMTP email server
using session variables 3-24 configuring for FirePass controller 8-40
server SNMP agent
monitoring, statistics, health 8-66 configuring for FirePass controller 8-41
Server access log (http) software upgrades
and http.extra-access_log 10-7 See upgrades.
understanding 10-7 software version, finding 1-4

Index
split tunneling and Summary report 10-16

configuring for Portal Access 7-15 displaying 8-66
defined 5-19 for clustered controllers 12-16
setting for Dynamic Tunnels 6-24 system load 8-67
SQL injection strategy for configuring failover 11-5
and content inspection 7-43 streaming video
blocking attacks 7-47 and Flash rewriting 7-28
SQL injection attacks strong password
specifying sites to scan 7-47 and LDAP directory 2-81
SQL injection scanning described 2-81
configuring 7-45 stylistic conventions 1-12
SSL engine log subnets
understanding 10-9 configuring for the FirePass controller 8-10
SSL processing subsequences
offloading to a BIG-IP system 8-24 and visual policy editor 3-25
SSL proxies creating to map to several conditions A-17
See also proxies. described 3-25
using 8-42 Summary reports
SSL server certificates activity 10-16
and backend servers 4-2 and browser type usage 10-16
associating with a web service 4-10 and operating system usage 10-16
See also server certificates. and options 10-16
understanding 4-1 described 10-1
ssl_engine log understanding entries 10-16
See SSL engine log. using 10-16
standalone secure access client viewing 10-16
installing 9-7 superuser
using to remotely access corporate LAN 9-7 and tasks 8-30
standalone VPN Client support
installing 9-11 and Ask F5 1-15
supported features 9-11 contacting F5 Networks Technical Support 1-15
standalone VPN client emailing collected data 8-63
using to remotely access corporate LAN 9-11 suspicious characters in web content
standard regular expression blocking 7-46
and blocking suspicious web site input 7-47 filtering 7-46
standby controller synchronization
accessing 11-18 configuring addresses and ports 8-20
configuring 11-15 described 12-1
configuring heartbeat synchronization 11-18 Synchronization Agent
defined 11-1 configuring 8-20
enabling failover 11-16 configuring ports for 8-23
See also failover. synchronization service
See also redundant system. and requirements 12-8
verifying identity 11-21 configuring on active controller 11-12
standby failover member 11-4 system health
static host configuring email notification 8-67
adding 8-20 viewing 8-67
configuring names 8-19 system load 8-68
understanding options 5-24 System Logs reports
static resource groups and options 10-18
defined 2-96 described 10-1
See also resource groups. understanding entries 10-18
static routes using 10-18
using to connect to internal VLAN 5-9 system, redundant
using to connect to separate network 5-10 See redundant system.
statistics
Index - 14
Index
T authenticating with 2-83

Technical Support at F5, contacting 1-15 URI landing settings
templates, signup 2-14 and during logon 2-49
terminal server connections URL variables and Portal Access 7-7
configuring master group settings for 6-36 user accounts
specifying screen resolutions 6-41 assigning administrative privileges 8-32
understanding master group settings for 6-36 configuring signup templates 2-14
Terminal Servers searching for 2-15
and application access 2-95 working with 2-3
configuring favorites 6-33 user activity reports 10-16
configuring favorites for resource groups 2-98 user agent strings
configuring status 6-42 configuring per host 7-26
terminals user authentication with client certificates 2-88
supported by Legacy Hosts feature 6-26 user groups
time and date format, specifying 8-44 determining requirements 2-9
time and time zone See also master groups.
specifying for NTP server 8-43 See also resource groups.
Today’s sessions logs user name as email address 2-50
understanding 10-14 user sessions
token-based authentication ending 8-49
See two-factor authentication. locking 8-49
tools for troubleshooting 8-61 user sessions, report 10-12
troubleshooting user-agent strings
and Java applet code 13-9 specifying for Portal Access 7-8
and JavaScript 13-9 user-group distribution report
and tools 8-61 See Group report.
and Web Applications engine trace 13-2 users
capturing network packets 8-63 accessing network remotely 6-1
identifying problems with engine trace 13-6 accessing resources 3-14
using Web Applications engine trace for 8-64 activating 2-15
troubleshooting tools and best practices for managing 2-3
accessing Maintenance Console 8-62 and master groups 2-9, 2-12
using the F5 Support Diagnostic tool 8-62, 8-63 and resource mapping tables 2-22
trusted certificates, adding your own 9-5 associating with a resource group 2-96
two-factor authentication authenticating externally 2-6
and client certificates 2-87 configuring user access to resources 2-15
and features for FirePass controller 1-1 creating 2-15
using with RSA SecurID 1-6 deactivating 2-15
deleting 2-15
exporting user information to a file 2-15
U importing groups of users 2-15
UDP application traffic and App Tunnels 6-2 maintaining on an external server 2-6
unsuccessful attempts to log on, reports 10-10 managing in master groups 2-8
updates managing locally 2-15
See upgrades. monitoring activity 10-2
upgrades moving to another group 2-15
and FirePass controller 8-48 See also master groups.
backing up and restoring 8-47
ending user sessions 8-49
from a downloaded file 8-50 V
from the command line 8-50 valid status, for certificates 4-5
getting online 8-51 version of software, finding 1-4
locking user sessions 8-49 VHOST settings
preparing for 8-49 and during logon 2-49
using a browser 8-50 for client certificate request 2-91
UPN names virtual host

Index
customizing logon 2-48 associating with an SSL server certificate 4-10

mapping based on 2-45 configuring a service 8-22
virtual IP address on active controller 11-10 configuring as synchronization agent 11-12
viruses configuring for standby controller 11-18
and default virus scanner 7-49 configuring on active controller 11-10
configuring antivirus scanning 7-48 configuring on port 80 for active controller 11-11
configuring Clam AntiVirus for automatic update configuring port 443 for active controller 11-10
7-49 understanding configuration options 8-20
configuring Clam AntiVirus for manual update 7-49 WebAccess Bypass 7-12
enabling standalone virus scanner 7-49 WebDAV
updating virus scanning files 7-49 accessing WebDAV sandbox from a browser 2-54
visual policy editor and logon_denied.inc file 2-55
and pre-logon sequence 3-12 and logon_failed.inc file 2-55
and subsequences 3-25 and logout.inc file 2-55
described 3-10 and resetpass.inc file 2-55
understanding 3-11 blocked_popups_warning.htm file 2-54
VLAN settings creating an index.htm file 2-56
configuring 8-9 creating custom portal access page 2-58
segmenting computers 8-9 customizing error screens 2-63
VNC servers and Terminal Server favorites 6-33 customizing with 2-63
enabling customization 2-53
using for advanced customization 2-53
W webifyers, customizing available features 8-70
web applications webtop
and Portal Access 7-2 and favorites 2-1
and special access mode 7-28 changing where Mobile E-Mail links appear 7-42
cleaning content 7-24 configuring intranet options 7-33
configuring 7-4 customizing 8-70
configuring content processing for 7-19 specifying name for user 5-42
configuring favorites for resource groups 2-97 Windows Active Directory server query
configuring global settings 7-29 using for authentication 2-3, 2-4
troubleshooting failures 7-24 Windows domain
Web Applications access control 8-26 mapping based on Windows domain 2-30
Web Applications content cleaning feature mapping groups dynamically 2-27
fixing HTML syntax errors 13-7 Windows domain server
Web Applications engine trace configuring for authentication 2-82
analyzing traces 13-5 using query for authentication 2-3, 2-4
and dynamic caching 13-2 Windows Files
and HTML syntax errors 13-6 configuring favorites for resource groups 2-97
and Internet Explorer 13-5 configuring master group settings for 7-37
and Portal Access 13-1 providing access to users 7-36
and when to use 13-1 Windows key combinations
comparing trace file content 13-5 configuring keyboard redirection 6-41
fixing common problems 13-6 Windows power management
overview 8-64, 13-1 configuring Network Access for 5-32
sending files to F5 Networks Technical Support Windows users
13-2 denying access A-11
understanding files 13-3 requiring log on using virtual keyboard A-15
using 13-2 Windows XP desktops
using with Web Applications engine trace 13-5 and Terminal Server favorites 6-33
Web browser definitions, adding 8-35
web services
and classes of operation 8-20 X
and codes 8-21 XSS scanning
and network configuration settings 8-3 excluding sites from 7-45
and synchronization agent 11-12 XSS scripting
Index - 16
Index
and content inspection 7-43

See cross site scripting.
Z
zero-click logon 2-89

FirePass Controller Administrator Guide, Version 7.0.0

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

FirePass Controller Administrator Guide, Version 7.0.0

Diunggah oleh

Hak Cipta:

Format Tersedia

FirePass® Controller Administrator Guide

Export Regulation Notice

Canadian Regulatory Compliance

FirePass® Controller Administrator Guide i

FirePass® Controller Administrator Guide v

Installing a server certificate ................................................................................................4-8

FirePass® Controller Administrator Guide vii

FirePass® Controller Administrator Guide ix

Using the Component Installer ..........................................................................................9-4

FirePass® Controller Administrator Guide xi

• Introducing the FirePass controller

• Getting started with the FirePass controller

• Using this guide

• Finding help and technical support resources

Introducing the FirePass controller

Introducing FirePass controller features

FirePass® Controller Administrator Guide 1-1

integration with single sign-on (SSO) systems such as Oracle® COREid®,

◆ Integration with BIG-IP system

Reviewing the FirePass controller models

FirePass® Controller Administrator Guide 1-3

Figure 1.1 The FirePass 1000

Figure 1.2 The FirePass 1200

Figure 1.3 The FirePass 4100 and 4300

Finding the FirePass controller software version number

Understanding the FirePass controller

FirePass® Controller Administrator Guide 1-5

As an administrator, you can choose to require different authentication

Each application was specifically developed for use on the FirePass

Ease of use, deployment, maintenance, and management

Determining security requirements for users

FirePass® Controller Administrator Guide 1-7

and keystroke loggers. For each criterion, the FirePass controller

Getting started with the FirePass controller

The recommended path

FirePass® Controller Administrator Guide 1-9

• Configuring global Network Access settings, on page 5-6

Possible configuration scenarios

◆ To configure the resources, applications, and functionality you want

FirePass® Controller Administrator Guide 1 - 11

Using this guide

Stylistic conventions in this document

Using the solution examples

Identifying new terms

Identifying references to objects, names, and commands

Identifying references to other documents

Identifying command syntax

Item in text Description

Table 1.1 Command line conventions used in this manual

A Note provides supplemental, helpful information. For example:

FirePass® Controller Administrator Guide 1 - 13

An Important note contains important information. For example:

Finding help and technical support resources

FirePass® Controller Administrator Guide 1 - 15

• Introducing master groups and resource groups

• Managing user information in an external data store

• Managing users in the FirePass controller data store

• Setting up master groups and users

• Setting up dynamic group mapping

• Working with resource groups

Introducing master groups and resource groups

Understanding master groups

Understanding resource groups