Array User Guide PDF

ArrayOS AG 9.
3
User Guide
Copyright Statement
Copyright Statement
Copyright©2015 Array Networks, Inc., 1371 McCarthy Blvd, Milpitas, California 95035, USA.
All rights reserved.
This document is protected by copyright and distributed under licenses restricting its use, copying,
distribution, and compilation. No part of this document may be reproduced in any form by any
means without prior written authorization of Array Networks. Documentation is provided “as is”
without warranty of any kind, either express or implied, including any kind of implied or express
warranty of non-infringement or the implied warranties of merchantability or fitness for a
particular purpose.
Array Networks reserves the right to change any products described herein at any time, and
without notice. Array Networks assumes no responsibility or liability arising from the use of
products described herein, except as expressly agreed to in writing by Array Networks. The use
and purchase of this product does not convey a license to any patent copyright, or trademark rights,
or any other intellectual property rights of Array Networks.
Warning: Modifications made to the Array Networks unit, unless expressly approved by
Array Networks, could void the user’s authority to operate the equipment.
Declaration of Conformity
We, Array Networks, Inc., 1371 McCarthy Blvd, Milpitas, CA 95035, 1-866-692-7729; declare
under our sole responsibility that the product(s) Array Networks, Array Appliance complies with
Part 15 of FCC Rules. Operation is subject to the following two conditions: (1) this device may
not cause harmful interference, and (2) this device must accept any interference received,
including interference that may cause undesired operation.
Warning: This is a Class A digital device, pursuant to Part 15 of the FCC rules. These
limits are designed to provide reasonable protection against harmful interference when the
equipment is operated in a commercial environment. This equipment 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. In a
residential area, operation of this equipment is likely to cause harmful interference in
which case the user may be required to take adequate measures or product. In a domestic
environment this product may cause radio interference in which case the user may be
required to take adequate measures.
2015 Array Networks, Inc. I

All Rights Reserved.
About Array Networks
About Array Networks

Array Networks is a global leader in networking solutions for connecting users and applications
while ensuring performance, availability and security. Using Array, companies can provide access
for any user, anywhere, on any device to applications, desktops and services running in either the
cloud or the enterprise data center. From Web sites to e-commerce to enterprise applications to
cloud services, Array solutions deliver a premium end-user experience and demonstrable security
while ensuring that revenue and productivity gains always outweigh CAPEX and OPEX.
Engineered for the modern data center, Array Networks application, desktop and cloud service
delivery solutions support the scalability, price-performance, software agility and leading-edge
feature innovation essential for successfully transforming today’s challenges in mobile and cloud
computing into opportunities for mobilizing and accelerating business.
Contacting Array Networks

Please use the following information to contact us at Array Networks:
Website:
http://www.arraynetworks.com/
Telephone:
Phone: (408)240-8700
Toll Free: 1-866-692-7729 (1-866-MY-ARRAY)
Support: 1-877-992-7729 (1-877-99-ARRAY)
Fax: (408)240-8754
Telephone access to Array Networks is available Monday through Friday, 9 A.M. to 5 P.M. PST.
Email:
info@arraynetworks.com
Address:
1371 McCarthy Boulevard
Milpitas, California 95035, USA
2015 Array Networks, Inc. II

Revision History
Revision History
Date Description
January 10, 2014 GA release.
March 31, 2014 Updated for ArrayOS AG 9.3.0.47 patch release.
April 4, 2014 Updated for ArrayOS AG 9.3.0.55 patch release.
June 6, 2014 Updated for ArrayOS AG 9.3.0.79 patch release.
June 30, 2014 Updated for ArrayOS AG 9.3.0.91 patch release.
July 31, 2014 Updated for ArrayOS AG patch release in July.
August 8, 2014 Updated for ArrayOS AG 9.3.0.110 patch release.
August 18, 2014 Updated for ArrayOS AG 9.3.0.115 patch release.
October 8, 2014 Updated for ArrayOS AG 9.3.0.133 patch release.
December 2, 2014 Updated for ArrayOS AG 9.3.0.153 patch release.
January 16, 2015 Updated for ArrayOS AG 9.3.0.160 patch release.
May 1, 2015 Updated for ArrayOS AG 9.3.0.186 patch release.
July 1, 2015 Updated for ArrayOS AG 9.3.0.203 patch release.
2015 Array Networks, Inc. III

Table of Contents
Table of Contents
Copyright Statement ......................................................................................................................... I
Declaration of Conformity ................................................................................................................ I
About Array Networks ..................................................................................................................... II
Contacting Array Networks ............................................................................................................. II
Revision History ............................................................................................................................. III
Table of Contents ............................................................................................................................IV
Chapter 1 Array AG Functionality Overview ................................................................................... 1
1.1 Introduction to the Array AG .............................................................................................. 1
1.2 Quick Start for Array AG.................................................................................................... 3
Chapter 2 Initial System Setup & Configuration .............................................................................. 6
2.1 Connecting to AG ............................................................................................................... 6
2.1.1 Console Connection ................................................................................................. 6
2.1.2 SSH Connection ....................................................................................................... 6
2.1.3 WebUI Connection................................................................................................... 7
2.1.4 Reading the LED ...................................................................................................... 8
2.2 AG Command Line Interface Structure .............................................................................. 9
2.2.1 Command Usage Breakdown ................................................................................... 9
2.2.2 Levels of Global Access Control ........................................................................... 10
2.2.3 Levels of Virtual Site Access Control .................................................................... 11
2.2.4 Switching between Global and Virtual Site ........................................................... 12
2.3 Initial Network Setup ........................................................................................................ 13
2.3.1 Basic Network Topology ....................................................................................... 13
2.3.2 Initial Setup Guidelines .......................................................................................... 15
2.3.3 Configuration Example for Initial Setup ................................................................ 15
2.4 DNS Configuration on AG................................................................................................ 20
2.4.1 Introduction to DNS ............................................................................................... 20
2.4.2 Understanding AG DNS ........................................................................................ 21
2.4.3 Configuration Example for DNS............................................................................ 22
2015 Array Networks, Inc. IV

Table of Contents
Chapter 3 Virtual Site ..................................................................................................................... 29
3.1 Virtual Site ........................................................................................................................ 29
3.1.1 Introduction ............................................................................................................ 29
3.1.2 Different Virtual Site Types ................................................................................... 29
3.1.3 Configuration Example .......................................................................................... 30
3.2 SSL.................................................................................................................................... 34
3.2.1 Cryptography ......................................................................................................... 34
3.2.2 Digital Signature .................................................................................................... 35
3.2.3 Certificate ............................................................................................................... 35
3.2.4 SSL Certificates and Authentication ...................................................................... 36
Chapter 4 AAA (Authentication, Authorization, Accounting) ....................................................... 47
4.1 Introduction ....................................................................................................................... 47
4.1.1 Authentication ........................................................................................................ 47
4.1.2 Authorization ......................................................................................................... 47
4.1.3 Accounting ............................................................................................................. 47
4.2 AAA in AG ....................................................................................................................... 48
4.2.1 AAA Server............................................................................................................ 48
4.2.2 AAA Method.......................................................................................................... 72
4.2.3 AAA Method Rank ................................................................................................ 74
4.2.4 Accounting ............................................................................................................. 76
4.3 Configuration Example ..................................................................................................... 77
4.3.1 Enable AAA ........................................................................................................... 77
4.3.2 Configure AAA Servers ......................................................................................... 77
4.3.3 Configure AAA Methods ....................................................................................... 78
4.3.4 Configure AAA Method Rank ............................................................................... 79
Chapter 5 User Policy ..................................................................................................................... 80
5.1 Role ................................................................................................................................... 80
5.1.1 Role, Qualification and Condition ......................................................................... 80
2015 Array Networks, Inc. V

Table of Contents
5.1.2 Role Resources ....................................................................................................... 81
5.1.3 Working Process of User Role ............................................................................... 84
5.2 ACL................................................................................................................................... 91
5.2.1 ACL........................................................................................................................ 91
5.2.2 ACL Resources ...................................................................................................... 91
5.2.3 External ACL ......................................................................................................... 92
5.2.4 Dynamic ACL ........................................................................................................ 94
5.3 User Session Management ................................................................................................ 98
5.3.1 Session Statistics .................................................................................................... 99
5.3.2 Session Timeout ..................................................................................................... 99
5.3.3 Session Timeout Warning .................................................................................... 100
5.3.4 Session Reuse ....................................................................................................... 100
5.3.5 Session Limit........................................................................................................ 101
5.3.6 Configuration Example ........................................................................................ 101
Chapter 6 Access Method ............................................................................................................. 104
6.1 Web Access ..................................................................................................................... 104
6.1.1 QuickLink ............................................................................................................ 105
6.1.2 WRM (Web Resource Mapping) ......................................................................... 108
6.1.3 Custom Rewrite.................................................................................................... 110
6.1.4 URL Policy .......................................................................................................... 110
6.2 Network Access and Array Client................................................................................... 119
6.2.1 Overview .............................................................................................................. 119
6.2.2 Web Launch and Standalone Launch ................................................................... 119
6.2.3 Network Mode and TCP Application Mode ........................................................ 120
6.2.4 VPN Resource ...................................................................................................... 127
6.2.5 Mobile VPN ......................................................................................................... 129
2015 Array Networks, Inc. VI

Table of Contents
6.3 File Share ........................................................................................................................ 145
6.3.1 Overview .............................................................................................................. 145
Chapter 7 Web Portal .................................................................................................................... 148
7.1 Default Portal .................................................................................................................. 148
7.1.1 Understanding the Virtual Portal.......................................................................... 148
7.1.2 Defining the Virtual Portal Appearance ............................................................... 149
7.2 Portal Custom.................................................................................................................. 150
7.3 Portal Theme ................................................................................................................... 150
7.4 Special Type of Portal Links ........................................................................................... 161
7.5 User Resource ................................................................................................................. 161
7.6 DesktopDirect Integration ............................................................................................... 162
7.7 Bookmark ........................................................................................................................ 163
7.8 Configuration Example ................................................................................................... 163
7.8.1 Default Portal Theme ........................................................................................... 163
7.8.2 Virtual Portal Custom .......................................................................................... 165
7.8.3 Custom Portal Theme ........................................................................................... 166
7.8.4 User Resource ...................................................................................................... 168
7.8.5 DesktopDirect Integration .................................................................................... 169
7.8.6 Bookmark ............................................................................................................. 169
7.9 Single Sign-On (SSO) ..................................................................................................... 171
7.9.1 Single Sign-On (SSO) .......................................................................................... 172
7.9.2 Application SSO................................................................................................... 173
7.9.3 Configuration Examples....................................................................................... 173
Chapter 8 High Availability .......................................................................................................... 180
8.1 Clustering ........................................................................................................................ 180
8.1.1 Overview .............................................................................................................. 180
8.1.2 Understanding Clustering..................................................................................... 180
2015 Array Networks, Inc. VII

Table of Contents
8.1.3 Configuration Synchronizing ............................................................................... 181
8.1.4 Failover ................................................................................................................ 181
8.1.5 Advanced Configuration ...................................................................................... 182
8.2 High Availability (HA) ................................................................................................... 182
8.2.1 Overview .............................................................................................................. 182
8.2.2 Multiple Communication Links ........................................................................... 183
8.2.3 Floating IP Group................................................................................................. 184
8.2.4 Failover Rule ........................................................................................................ 185
8.2.5 Configuration Synchronization ............................................................................ 187
8.2.6 Session Stateful Failover (SSF)............................................................................ 191
8.2.7 HA Deployment Scenarios ................................................................................... 192
8.2.8 Configuration Examples....................................................................................... 192
Chapter 9 WebWall....................................................................................................................... 203
9.1 Understanding WebWall ................................................................................................. 203
9.2 WebWall Configuration .................................................................................................. 204
9.2.1 Configuration Guidelines ..................................................................................... 204
9.2.3 Verification and Troubleshooting of the WebWall .............................................. 207
Chapter 10 Client Security ............................................................................................................ 211
10.1 Device Class.................................................................................................................. 211
10.2 Host Integrity ................................................................................................................ 212
10.3 Cache Cleaner ............................................................................................................... 213
10.4 Two-stage Security ....................................................................................................... 213
10.5 Configuration Example ................................................................................................. 213
10.5.1 General Settings ................................................................................................. 213
10.5.2 Basic Device Class Configuration...................................................................... 215
10.5.3 Advanced Device Class Configuration .............................................................. 218
Chapter 11 System Monitoring ..................................................................................................... 229
11.1 Logging ......................................................................................................................... 229
2015 Array Networks, Inc. VIII

Table of Contents
11.1.1 Logging Type ..................................................................................................... 229
11.1.2 Log Host & Log Filtering .................................................................................. 230
11.1.3 Disabling the System Log .................................................................................. 231
11.1.4 Email Alert ......................................................................................................... 231
11.1.5 Configuration Example ...................................................................................... 231
11.2 SNMP ............................................................................................................................ 234
11.3 Troubleshooting ............................................................................................................ 238
Chapter 12 Admin Tools ............................................................................................................... 243
12.1 Administrators ............................................................................................................... 243
12.1.1 Admin User ........................................................................................................ 243
12.1.2 Admin Role ........................................................................................................ 243
12.1.3 WebUI Admin Role ........................................................................................... 246
12.1.4 Admin AAA ....................................................................................................... 247
12.1.5 Source IP Login Authorization .......................................................................... 248
12.2 System Access Control ................................................................................................. 255
12.2.1 WebUI Access.................................................................................................... 255
12.2.2 SSH Access ........................................................................................................ 256
12.2.3 XML-RPC Access.............................................................................................. 257
12.3 System Management ..................................................................................................... 260
12.3.1 System Reboot and Shutdown............................................................................ 260
12.3.2 System Update ................................................................................................... 261
12.3.3 Component Update............................................................................................. 262
12.3.4 System License................................................................................................... 262
12.4 Configuration Management .......................................................................................... 263
12.4.1 Startup Configuration and Running Configuration ............................................ 263
12.4.2 Configuration Backup ........................................................................................ 264
2015 Array Networks, Inc. IX

Table of Contents
12.4.3 Configuration Import ......................................................................................... 266
12.4.4 Configuration Clearance .................................................................................... 266
12.4.5 Configuration Synchronization .......................................................................... 267
Chapter 13 Advanced System Operations..................................................................................... 271
13.1 RTS ............................................................................................................................... 271
13.2 Bond .............................................................................................................................. 271
13.3 NAT .............................................................................................................................. 272
13.4 HTTP Compression....................................................................................................... 274
13.5 NDP............................................................................................................................... 274
13.6 Configuration Example ................................................................................................. 275
13.6.1 RTS .................................................................................................................... 275
13.6.2 Bond ................................................................................................................... 275
13.6.3 NAT ................................................................................................................... 277
13.6.4 HTTP Compression ............................................................................................ 278
13.6.5 NDP.................................................................................................................... 281
Chapter 14 IPv6 Support ............................................................................................................... 282
14.1 AG Management via IPv6 ............................................................................................. 282
14.2 IPv6 Access Method ..................................................................................................... 282
14.3 HA Support for IPv6 ..................................................................................................... 282
Appendix I Array Networks Product Registration ........................................................................ 283
Appendix II Abbreviations and Acronyms ................................................................................... 285
Appendix III SNMP OID List ....................................................................................................... 287
2015 Array Networks, Inc. X

Chapter 1 Array AG Functionality Overview
1.1 Introduction to the Array AG

The Array AG appliance is an SSL-based VPN platform that offers fast, secure, and scalable
remote access to Web and non-Web applications. The Array AG appliance increases speed with
SSL acceleration, establishes security with AAA and user policy, provide access methods for web,
mail, file and native application servers, and assures scalability with the Array virtual site and HA
technology. By integrating these features into a single appliance, the Array AG delivers secure
Intranet access to trusted employees, customers, and partners around the world - all with the ease
of Web-based and common legacy applications while protecting the specific details of the internal
network.
Note: The Array AG appliance is also an SSL-based secure application platform. Basing
on this platform, the Array AG appliance provides the other two solutions: DesktopDirect
and MotionPro. This document focuses on the SSL-based VPN (AccessDirect) solution.
For more information on DesktopDirect and MotionPro, please refer to the DesktopDirect
Administration Guide and MotionPro Administration Guide respectively.
The following figure illustrates a typical application scenario of an AG appliance.
2015 Array Networks, Inc. 1

Figure 1–1 AG Application Scenario
This figure mentions the following important concepts of AG:
SSL Encryption: The Array AG supports transmitting data encrypted with

SSLv3/TLSv1/TLSv1.2/DTLS. Based on the ArrayOS and SSL hardware architecture, AG
provides best SSL performance. In addition, AG can fully support integration with the PKI and
CA server.
Virtual Site: is a manageable and configurable unit that includes client secure connection, user
access control, enterprise resources and the relationships between users and resources. Array AG
could support a maximum of 256 virtual sites.
AAA: provides Authentication, Authorization, and Accounting to all transactions carried out
across the network. This enables administrators to tightly control user access to contents and to
provide accurate audit logs. Array AG uses one or several available AAA servers to verify the
identity of end users who are seeking access to the network. These servers include LocalDB,
LDAP, RADIUS, Client Certificate, SMX and SMS. Once the end user has been authenticated,
Array AG will present that end user with a web portal page with authorized resources list.

User Policy: The user policy of AG includes user role, access control list and user session
management. User roles are used to authorize authenticated users with resources based on specific
qualifications, such as login time, username, group name, source IP address and selected AAA
method, thus achieving accurate, fine-grained and flexible resource assignment. Access control list
specifies which users, groups or role are granted to access to specific resources. These ACL rules
are applied to a user as the user accesses contents through the virtual site. Session management is
used to control all the active users.
Access Method - Web Access: Array AG provides different methods to access different types of
application servers. For Web applications, AG provides the QuickLink and Web Resource
Mapping methods. QuickLink is a clientless access method that allows AG users to instantly
access Web contents originating from the internal network, mostly from servers that are not
exposed to be accessed from the outside. Rather than doing full content parsing and rewriting,
QuickLink uses a unique hostname or port to represent the backend Web server. In this way,
parsing and rewriting are greatly simplified and streamlined. When backend Web contents are
going through AG, only absolute paths with hostnames are rewritten to the configured unique
hostname, port or path. This feature is a pure Web-based SSL VPN solution requiring no plug-in
or client. Therefore, this feature is platform and browser neutral. Web Resource Mapping is
capable of unifying the URLs generated by Web applications. This allows users, regardless of
their locations, to use the Web applications. If deployed on a secure Web traffic manager such as
the Array AG appliance, the conversion happens transparently and the Web application
administrator does not need to do any intervention. WRM dynamically rewrites all embedded
URLs in Web contents so that they refer to the AG appliance, and encodes the necessary internal
network information inside of each URL. When the Array AG receives a request for a specific
URL, it uses the network information encoded in the URL to contact the correct backend server.
Access Method - Network Access: It is the universal solution for both network and application
access on Array AG, widely used to provide secure remote access to internal network resources
that allow mobile users, telecommuters, partners and customers to access applications hosted on a
secured internal network. It is designed to maximize security for the company’s network and
application servers.
Web Portal: When users use browsers to access the virtual site, all the Web pages users can see
are called “Web Portal”. AG provides a set of default portal pages for customers. To meet
customer’s special requirements, AG supports portal customization using portal custom or portal
theme.
1.2 Quick Start for Array AG

The following figure shows a typical deployment scenario of Array AG.

Figure 1–2 Deployment of AG
In the preceding figure, Enterprise A uses Array AG to provide remote office access for all
employees and managers. Employees can use only the OA (Office Automation) system while
managers can use both the OA and ERP (Enterprise Resource Planning) systems.
Enterprise A can easily achieve the preceding objectives by following the following quick start
steps:
1. Set up the initial network for Array AG. For example, set the interface IP address of port1 to
10.10.0.2 and set the default gateway to 10.10.0.1. For more information, refer to 2.3 Initial
Network Setup.
2. Create the virtual site. For example, configure a virtual site with the site IP address as
10.10.0.2 and the port as 443 and import a valid certificate for this virtual site. For more
information, refer to Chapter 3 Virtual Site.
3. Configure AAA. For example, use LocalDB as the AAA server and add LocalDB accounts
for employees and managers and add them into the employee and manager groups
respectively. For more information, refer to Chapter 4 AAA (Authentication, Authorization,
Accounting).
4. Configure the Access Method. Because all the applications are Web-based, choose to use and
QuickLink access method and add the OA portal (http://10.10.0.3) and the ERP server
(http://10.10.0.4) as resources. For more information, refer to Chapter 6 Access Method.
5. Configure the User Policy. For example, define two roles employee and manager and make
sure that employees in the employee group obtains the employee role and managers in in the
manager group obtains the manager role. Assign the resource OA portal to the employee role
and resources OA portal and ERP server to the manager role. For more information, refer to
Chapter 5 User Policy.
6. Configure the Web Portal. For example, change the company icon to the Enterprise A’s logo
using the Portal Custom function. For more information, refer to Chapter 7 Web Portal.

Besides, please add the port-mapping rule on the firewall for the remote access service:
2.0.0.1:443 to 10.10.0.2:443.
After the preceding configurations are completed, all employees and managers of Enterprise A can
start to access remote offices:
1. Open a browser and type the URL https://2.0.0.1:443.
2. Enter the user and password and click the login.
3. Click the link to OA portal or ERP server to access the remote server.

Chapter 2 Initial System Setup & Configuration

This section will outline the initial connection, basic setup and configuration of the AG appliance.
The easy-to-follow setup steps are introduced below.
2.1 Connecting to AG
There are three ways to connect to the AG appliance in order to begin the configuration:
 Console
 SSH
 WebUI
2.1.1 Console Connection

If you choose the console connection, first connect the console cable (supplied) to the System
Console Port on the AG appliance. Then, set up your console as follows:
Table 2–1 Console Setup
Setting Value
Emulation VT 100
Baud 9600
Number of Bits 8
Parity No
Stop Bits 1
Flow Control No
Open a connection between the console and the AG appliance. Once this connection is opened, the
administrator will see the AG appliance prompt and may begin the configuration process.
2.1.2 SSH Connection

Once the interface IP parameters are configured and the SSH service is activated, the AG
appliance is ready for custom configuration. You may access the command line interface (CLI)
using SSH connection. Below gives an example.
Note: If you require SSH software for Windows, MacOS or UNIX, it is available on-line
at http://www.openssh.com. Freeware and links to other support sites can be found here.
To establish an SSH connection:
1. Run the SSH program on your workstation.
>> # ssh array@10.3.55.251

10.3.55.251 is one IP address configured on the AG appliance.
2. After you establish a connection, the AG appliance will prompt you for a password.
>> # ssh array@10.3.55.251

>> # array@10.3.55.251's password:
The default username is “array”. The default password is “admin”.
Note: You must have the IP information setup and basic network connectivity in order to
access the box through SSH.
3. You can configure the appliance to be accessed via SSH only at one specified IP address
among all IP addresses of the appliance. For example:
AN(config)#ssh ip 10.10.0.2
If the SSH IP address is not specified, administrators can access the AG appliance via SSH at any
available IP address (including virtual site IP addresses) on the AG appliance.
2.1.3 WebUI Connection

This section introduces the connection method via AG WebUI (Web User Interface). The AG
WebUI can:
 Improve user experience with fast response time
 Maximize the functionality and performance of the AG appliance
 Simplify system management
You can assign a valid unique IP address and port number to the WebUI to allow administrators to
access AG WebUI only via the specified IP address and port. For example:
AN(config)#webui ip 10.10.0.2
AN(config)#webui port 8088
If WebUI IP and port are not specified, administrators can use any interface or virtual IP and the
default port 8888 to access AG WebUI.
Then, turn on the WebUI function:
AN(config)#webui on
It’s time to open your browser of choice and connect to the AG appliance. To do this, simply enter
the WebUI IP address and port in the browser’s address bar. For example:
https://10.10.0.2:8088
The welcome login screen should appear in your browser’s window. For logging on, the default
username and password is array and admin. If this screen does not appear, verify the address and
port designations for both the port1 interface and WebUI.

The AG WebUI supports IE 8~11 and Firefox 3.6~25 browsers (with display resolution set to
1024×786 or higher). Besides, Chrome 16.0 and later are supported for certain steps, such as
clicking the Go to DD Pilot action link in the home page of the AG WebUI to switch to DD Pilot.
It is recommended to use IE 10 or Firefox 25 to access the AG WebUI.
2.1.4 Reading the LED
2.1.4.1 LEDs in the Front Panel
The AG appliance has 3 LEDs in the front panel: one yellow, one green and one blue. The
following table describes the usage of each LED in the front panel.
Table 2–2 LED in the Front Panel
Color Meaning Description

This light is always off when the AG appliance is running normally.
When it turns on, it means that the AG may be experiencing one or
more of the following problems:
 The CPU fan stops working.
 The CPU is overheated.
Yellow Fault
 The system is overheated.
Some AG appliances come with a dual power supply. On these
appliances, if one of the power supply modules breaks down the
redundant power supply module will turn on the Buzzer at the same
time.
The green LED should blink each second when system is idle. CPU
Green Run activity will be indicated by the blinking of this light; the faster the
rate, the higher the CPU activity.
Blue Power Indication of power and the active state (off|on) of the AG appliance.
Note: If the yellow LED turns on, please contact Customer Support. You can view system
logs to get more information about the problem.
2.1.4.2 LEDs in the Rear Panel
The AG appliance provides two LEDs for every Ethernet port in the rear panel:
 Link LED: indicates the speed mode of the link, which can be 1 Gbps, 10 Mbps or 100 Mbps.
 Activity LED: indicates the activity status of the network port.
The following table describes the meaning of each LED on the onboard and add-on NICs of the
AG appliance.

Table 2–3 LED for Ethernet Ports in Rear Panel
NIC Type LED Name Description

The Link LED has the following indicator colors:
 Amber: The speed mode is 1 Gbps.
Link LED
 Green: The speed mode is 100 Mbps.
Onboard NIC  Off: No Connection or the speed mode is 10 Mbps.
The Activity LED has the following indicator colors:
Activity
 Yellow and blinking: Active
LED
 Off: Inactive
The Link LED has the Yellow indicator color, indicating 1 Gbps,
Link LED
10 Mbps or 100 Mbps speed mode.
Add-on NIC The Activity LED has the following indicator colors:
Activity
 Green and blinking: Active
LED
 Off: Inactive
2.2 AG Command Line Interface Structure

This section provides an overview of the AG Command Line Interface (CLI) and covers the
following topics:
 Command Usage Breakdown
 Levels of Global Access Control
 Levels of Virtual Site Access Control
 Switching between Global and Virtual Site
2.2.1 Command Usage Breakdown

The CLI allows you to configure and control key functions of the AG appliance to better manage
the performance of your servers and the accessibility to the contents therein.
The AG appliance software has been designed with specific enhancements to make interaction
with the Appliance more user friendly, such as Shorthand. Shorthand is the intuitive method by
which the Appliance completes CLI commands based on the first letters entered. Other user
shortcuts are listed below:
Table 2–4 List of Shortcuts
CLI Shortcuts Operation

â/ê Move the cursor to the beginning/end of a line.
^f/^b Move the cursor forward/backward one character.
Esc-f Move the cursor forward one word.
Esc-b Move the cursor backward one word.
^d Delete the character under the cursor.
^k Delete from the cursor to the end of the line.

CLI Shortcuts Operation

û Delete the entire line.
Note: The symbol “^” indicates holding down the Control (Ctrl) Key while pressing the
letter that appears after the symbol.
The AG CLI commands will generally adhere to the following style conventions:
Table 2–5 AG CLI Style Conventions
Style Convention
Bold The body of a CLI command is in Boldface.
Italic CLI parameters are in Italic.
<> Parameters in angle brackets < > are required.
Parameters in square brackets [ ] are optional.
[]
Subcommand such as “no”, “show” and “clear” commands.
Alternative items are grouped in braces and separated by vertical bars.
{x|y|…}
At least one should be selected.
Optional alternative items are grouped in square brackets and
[x|y|…]
separated by vertical bars. One or none is selected.
Note: It is recommended to enclose the string-type parameter value by double quotes to

make sure that the appliance can execute the command correctly.
For example:
ip address {system_ifname|vlan_ifname|bond_ifname} <ip_address> <netmask>
2.2.2 Levels of Global Access Control

The AG appliance offers three levels for global configuration and access to the ArrayOS. The CLI
prompt of each level consists of the host name of the AG appliance followed by a unique cursor
prompt, either “>”, “#” or “(config)#”.
The first level of administration is the User level. At this level, the administrator is only authorized
to operate some very basic troubleshooting commands and non-critical functions such as ping and
traceroute. Here is how the User level prompt appears in the CLI.
AN>
The second level of administration is the Enable level. At this level, administrators have (in
addition to User level permissions) access to a majority of view only commands such as “show
version”. In order to gain access to this level of appliance management, the user must run the
“enable” command and supply a special “enable” password. If correct password is entered, the
CLI prompt will change from “AN>” to “AN#”, which means the administrator has been granted
access to the Enable level. The default password for the Enable level is null (i.e., leave the
password blank/empty).

AN>enable
Enable password:
AN#
The third level of administration is the Config level. At this level, the administrator can make
changes to the configuration of the AG (in addition to all User and Enable level permissions). To
gain full configuration access of the AG appliance, the administrator must use the following
command:
AN#config terminal
Once this command is entered, the CLI prompt will change to:
AN(config)#
No two administrators may access the Config level at the same time (whether they are in global or
virtual site shell). In the event that another administrator is already in the Config level, the
following command can be run to kick that administrator out of Config level:
AN#admin reset configmode
At any level, the administrator can type “?” to view the currently available commands. For
example, entering “AN(config)#system ?” will display all the commands starting with “system”
in the Config level.
AN(config)#system ? [enter]
command Set command execution timeout when loading configurations
component Component update commands
console Console operation
date Set system date
dump Determine whether system should do sysdump when panic
fallback Set fallback software version to boot if available
flexlicense Disable/enable Array Appliance pre-paid Flex License
interactive Set system interactive mode to control command output messages
license Setting Appliance License Key
mail System mail configuration
reboot Reboot the system
shutdown Shut down system
…
2.2.3 Levels of Virtual Site Access Control

For virtual sites, the AG appliance offers three levels of administrative access control. The CLI
prompt of each level consists of the virtual site name followed by a unique cursor prompt, either
“%”, “$” or “(config)$”.
The first level of administration is the User level. At this level, administrators are only authorized
to operate some very basic commands. Here is how the User mode prompt appears in the CLI.

demo_portal%
The second level of administration is the Enable level. At this level, administrators have access to
a majority of view only commands such as “show user”. The cursor will display the
pre-configured name of the virtual site followed by “$” as such.
demo_portal$
The third level of administration is the Config level. At this level, administrators can make
changes to the configuration of the virtual site. No two administrators may access the Config level
at the same time (whether they are in global or virtual site shell). To gain full configuration access
for a specific virtual site of the AG appliance, the administrator must run the following command:
demo_portal$config terminal
demo_portal(config)$
Note: The global administrators have the ability to access to all virtual sites and global
configuration features and functionality.
2.2.4 Switching between Global and Virtual Site

The AG appliance allows the administrator to switch between the global scope and the virtual site
scope via the following command:
switch <global|virtual_site_name> [enable|config]
For example, the administrator can switch from global scope to demo_portal scope (for example, a
virtual site named “demo_portal”) by running the following command:
AN#switch demo_portal
demo_portal$
To switch back to the global scope, the administrator can run the following command:
demo_portal$switch global
AN#
By default, when switching between the global scope and virtual site scope the administrator
privilege level (for example, Enable level or Config level) will stay the same. However, if the
“enable|config” parameter is specified during the switch, the administrator’s privilege level will be
explicitly set accordingly.
For example, the administrator executes the following command:

AN#switch demo_portal config
demo_portal(config)$
2.3 Initial Network Setup
2.3.1 Basic Network Topology

To better understand the configuration strategies that maximize the power of the Array AG
appliance, please take a moment to become familiar with some basic network architecture.
The Array AG appliance may be installed into three traditional network topologies:
“One-Arm” deployments utilize just the one interface on AG. This deployment is typical of DMZ
and testing environments. While using this method, both encrypted and unencrypted traffic shares
the same network. So it is strongly recommended to position AG behind a firewall.
Figure 2–1 One-Arm Topology
“Two-Arm Parallel” deployments utilize two interfaces of the AG. In this scenario, one interface
connects to the Internet (or to some other outbound device such as a gateway router, a firewall,
etc.) and the other interface connects to the secured internal network. Within this network
topology, remote traffic (like from an off-site user) is directed from the gateway through the AG
to the internal network resources while local user traffic (originating from the internal network) is
sent through a secondary access point/device to the Internet.

Figure 2–2 Two-Arm Parallel Topology
“Two-Arm Serial” deployments utilize two interfaces of the AG to handle all inbound and
outbound traffic. In this scenario, one interface connects to the Internet (or to some other outbound
device such as a gateway router, a firewall, etc.) and another interface connects to the secured
internal networks. This is the most common network deployment for the AG.

Figure 2–3 Two-Arm Serial Topology
2.3.2 Initial Setup Guidelines

For the initial setup of the AG, there are some basic settings that the administrator will need to
configure (for example, hostname, time, default route, IP addresses, WebUI, etc.). The following
topology will be used to illustrate the configuration examples further down below.
Figure 2–4 Initial Setup Topology
The following table summarizes the suggested operational steps and CLI commands used to
complete the initial setup for the AG (some of them are optional):
Table 2–6 Initial Setup
Operation Command
Set the interface IP ip address {system_ifname|vlan_ifname|bond_ifname} <ip_address>
address <netmask>
Set the default route ip route default <gateway_ip>
ip route static <destination_ip> <destination_netmask>
Set the static route
<gateway_ip>
webui {on|off}
Set up WebUI webui port <port>
webui ip <ip_address>
2.3.3 Configuration Example for Initial Setup

To complete the initial setup for the AG appliance, the administrator has to first access the CLI to
make the following configurations.
 Define the IP address for the interface “Port1”
Assign an IP address and netmask for the Port1 interface. The WebUI will use this address as the
default IP address if not changed at Step 7. If the AG is deployed in the “one-arm” scenario (such
as a DMZ or testing environment), this will be the only interface required.
AG_a(config)#ip address port1 10.10.0.2 255.255.255.0
 Define the IP address for the interface “Port2”

Assign an IP address and netmask for the Port2 interface. If the AG is deployed in the “one-arm”
scenario (such as a DMZ or testing environment), administrators can skip this step altogether.
AG_a(config)#ip address port2 192.168.10.1 255.255.255.0
 Set the network default route
Configure the network’s default route/gateway IP address (i.e. gateway router IP address) that
serves as the access point to the Internet.
AG_a(config)#ip route default 10.10.0.1
 Set the network static route
Configure the network’s static route IP address for the internal network.
AG_a(config)#ip route static 192.168.10.2 255.255.255.0 10.10.0.1
 Set and enable the Web Users Interface (WebUI) function
Set the IP address that the AG will accept Web User Interface commands from. By default, the
WebUI is set on the interface until explicitly changed. It is recommended that a management IP
and port are used for the WebUI address. Use the following commands to set and enable this
function.
On the AG appliance, we use interface IP address as the default WebUI IP address and the port
8888 as the default WebUI port.
You can assign a valid unique IP address and port number to the WebUI. Once an explicit IP is
assigned to the WebUI, it is only accessible from that IP.
Then, turn on the WebUI function by running the command “webui on”.
AG_a(config)#webui ip 192.168.20.5
AG_a(config)#webui port 8088
AG_a(config)#webui on
After the WebUI function is set and enabled, the administrator can complete the following steps
via WebUI with the configured IP address and port (https://192.168.20.5:8088 in this example).
 Set the network port speed
The speeds between the AG’s ports and the ports it is connected to on the switch or hub should
match with each other. This is extremely important for proper network performance. A port speed
mismatch will degrade the network’s performance.
The speed on an AG port can be set to one of the several fixed speeds (10half, 100half, 100full,
1000full) or to auto-detect. When setting the port speed to one of the fixed values it is very
important to assure that the port that the AG is connected to is set to the same speed. In auto-detect
mode the AG port will negotiate with the port on the other end to determine what is the best speed
possible.

By default, all AG port speeds are set to “auto”. This automatic setting allows the AG to audit the
speed of other network devices and adopt the optimum speed setting to match the rest of the
network. Administrators may set a specific port speed to match other network devices that have a
fixed communication speed but caution is recommended.
Administrators can set the network port speed by selecting System Configuration > Basic
Networking > Interface > Port under the global scope. Please select the radio button of the target
port speed, e.g. 100full, and click the Apply Changes button on the upper right corner to save the
changes as running configurations, as shown in Figure 2–5.
Figure 2–5 Network Port Speed
Note:
The administrator needs to click the Apply Changes button to save the changes as
running configurations. To write current running configurations into memory, the
administrator needs to click the Save Configuration action link on the toolbar (see the
step Save the configuration). If these configurations are not written into memory, they
will be cleared after system reboot or system upgrade.
 Set the host name
This is a recommended step if configuring multiple AG appliances within a single network,

otherwise it is optional. The default host name of the AG appliance is “AN”. To change the host
name, enter the new host name by selecting System Configuration > General Settings > Host
Setting under the global scope and clicking the Apply Changes button on the upper right corner
to save the change, as shown in Figure 2–6.

Figure 2–6 Host Setting
 Set the date and time
Enter the target date and time in the text boxes after selecting System Configuration > General
Settings > Date/Time under the global scope. Then click the button Apply Changes on the upper
right corner to save the configurations, as shown in Figure 2–7.
Figure 2–7 Set Date/Time
 NTP Time Synchronizer
NTP (Network Time Protocol) time synchronizer keeps the system time synchronized with the
specified NTP server.
After NTP time synchronizer is enabled, the system time will be automatically synchronized with
the NTP server for every approximate 15 minutes.
Note: For the first time the offset between the system time and the NTP server exceeds
1000s (approximately 17 minutes), the system clock will be synchronized with the NTP
server. However, for the second time the limit is exceeded, NTP time synchronizer will
exit and the system clock will not be synchronized with the NTP server any more. That is
to say, if NTP time synchronizer is enabled, users should not set the system clock
manually; otherwise, NTP time synchronizer doesn’t work.
If multiple NTP servers are configured, the AG appliance will calculate the round-trip delay
according to the timing information in the response from each NTP server, and synchronize its
system time with the one with the minimum delay.
1. Add an NTP Server
Under the global scope, select System Configuration > General Settings > NTP, and then click
the Add button on the upper right corner of the NTP Servers table, as shown in Figure 2–8.

Figure 2–8 Add an NTP Server
A new page Add NTP Server will appear. On the page, enter the IP address in the NTP Server
IP text box and select the server version from the NTP Server Version drop-down list. Then click
the Save button on the upper right corner to save the configurations, as shown in Figure 2–9.
Figure 2–9 Set the NTP Server IP and Version
2. Enable NTP
After the definition of NTP server, check the check box of Enable NTP, and then click the button
Apply Changes on the upper right corner to save the configurations, as shown in Figure 2–10.
Figure 2–10 Enabling NTP
 Save the configuration
It is imperative that administrators save all configuration changes to the AG appliance. Especially
during complex or detailed configurations, administrators should save the configuration changes
often throughout the entire configuration process.
To save your configurations, click the Save Configuration button on the upper right hand of the
top bar, as shown in Figure 2–11.

Figure 2–11 Save Configuration Button
After clicking the Save Configuration button, a new window Save Configuration will pop up.
If you are in the global scope, choose Save Global Config Only or Save Global And All Virtual
Site Config in the popup window, as shown in Figure 2–12
Figure 2–12 Global-Scope Save Configuration Window
If you are in the virtual site scope, click the OK button to save your changes in the popup window,
as shown in Figure 2–13.
Figure 2–13 Virtual-Site-Scope Save Configuration Window
Note:
 Each time you log out the system, please save configuration first.
 To successfully log out the system, you need to first click the Log Out button, and
then close all the browser windows for AG management.
2.4 DNS Configuration on AG
2.4.1 Introduction to DNS

Domain name resolution is the function of converting a file or network location name into the
corresponding network address used by administrators for maintaining network security and
accessibility. DNS system converts names to IP addresses automatically. The AG appliance
attempts to resolve both forward and reverse lookups via the following order:
1. Local DNS cache
2. DNS servers

Figure 2–14 DNS Process
2.4.2 Understanding AG DNS

The Array AG appliance has the ability to function as a local DNS server.
When a user types a URL in the browser, the client will first look up its local DNS cache. If the
cache entry which contains the target domain name and the related IP address does not exist, the
client will send the request to the local DNS server.
If the VPN connection between the client and the AG has already been established, the AG will
receive the DNS lookup request.
The administrator can define the DNS record manually. The AG will respond to the DNS lookup
request based on these static DNS records.
The administrator can also define an external DNS server. If the related DNS record does not exist
on the AG, the AG will send the DNS request to the defined external DNS server.
By default, the DNS cache is enabled. With DNS cache enabled, the AG appliance will save DNS
query responses and use them for subsequent DNS queries. The AG appliance will attempt to
contact each DNS server up to three times with one second timeout for each request. If the active
DNS server fails to respond within this period, it will be considered “down” and the next
configured DNS server (or the current one, if only one is configured) will become the active
server. You may configure the Min and Max parameters to control how long a DNS query
response can be stored in the DNS cache before it becomes stale (and is removed from the cache).
Each DNS query response has an associated Time to Live (TTL) that is assigned by the
originating DNS server. The following diagram illustrates the AG DNS functionality:

Figure 2–15 AG DNS Cache
As shown in the above figure, Client1 and Client2 are requesting for the same Web service.
1. Client1 first sends the DNS request for the Web service to the AG appliance.
2. If the related static record and the cache record do not exist on AG, the AG will send the
DNS request to the defined DNS server.
3. The DNS server responds to the request.
4. The AG will cache the DNS response.
5. The AG sends the DNS response to Client1.
6. Client2 then sends the DNS request for the same domain name.
7. The AG will send the cached record to Client2.
2.4.3 Configuration Example for DNS

This section covers the DNS configuration examples.
 Global DNS Configuration
1. Configure the DNS server
AG supports up to three separate DNS servers for the global scope.
Under the global scope, select System Configuration > Basic Networking > DNS, and click the
Add Name Server IP Address button on the upper right corner, as shown in Figure 2–16.

Figure 2–16 DNS in the Global Scope
In the new configuration window, enter the IP address in the text box and click the Save button to
save the configuration, as shown in Figure 2–17.
Figure 2–17 Add the Name Server IP Address in the Global Scope
2. Configure the search domain
Assign the search path to resolve non-qualified host names. Up to six paths can be configured.
Under the global scope, select System Configuration > Basic Networking > DNS, and click the
Add Search Path button on the middle right part, as shown in Figure 2–16.
In the new configuration window, enter the Search Path in the text box and click the Save button
to save the configuration, as shown in Figure 2–18.
Figure 2–18 Add the Search Path in the Global Scope
3. Set the DNS cache expiration time

The administrator can define the expiration time of DNS cache.
Under the global scope, select System Configuration > Basic Networking > DNS. In the DNS
Cache area, please enter the Minimum Expiration Time and Maximum Expiration Time in the
text boxes as required, as shown in Figure 2–19. Then click the Apply Changes button on the
upper right corner to save the change.
Figure 2–19 Set the DNS Cache Expiration Time in the Global Scope
If TTL (Time to Live) of DNS response is shorter than the Minimum Expiration Time, the
expiration will take place after the Minimum Expiration Time. If TTL of DNS response is longer
than the Maximum Expiration Time, DNS cache will expire after the Maximum Expiration Time.
4. Set the static DNS records
Under the global scope, select System Configuration > Basic Networking > Name Resolution
Host, and click the Add Static Host button on the upper right corner, as shown in Figure 2–20.
Figure 2–20 Name Resolution Host
In the new configuration window, enter the Host Name and Host IP in the text boxes and click
the Save button to save the configuration, as shown in Figure 2–21. The configured static hosts
will be displayed in the Static Hosts sort-ready table in Figure 2–20.

Figure 2–21 Add the Static Host in the Global Scope
The administrator can follow this step to add multiple static DNS records.
5. Set the Expiration Time of the DNS hosts.
Administrators may configure a “time to live” for DNS responses that the AG appliance sends for
statically configured DNS hosts.
To do this, simply enter the DNS Response TTL in the text box at the bottom of the Name
Resolution Host page, as shown in Figure 2–20. Then click the Apply Changes button on the
upper right corner to save the change.
 Virtual Site Scope DNS Configuration
1. Disable Global DNS/WINS Settings
To use the virtual site scope DNS server, please select Site Configuration > Networking >
General Settings under the virtual site scope, and uncheck the Use Global DNS/WINS
Configuration check box, as shown in Figure 2–22.
Figure 2–22 Disabling Global DNS/WINS Settings
2. Add Static Host
Click the Add button in the Static Hosts area, as shown in Figure 2–23.
Figure 2–23 Static Hosts in the Virtual Site Scope
In the Add Host configuration window, enter the Host Name and Host IP, and click the Save
button, as shown in Figure 2–24.

Figure 2–24 Add a Static Host in the Virtual Site Scope
3. Set the Expiration Time of the DNS hosts.
Administrators may configure a “time to live” for DNS responses that the AG appliance sends for
statically configured DNS hosts.
To do this, simply enter the DNS Response TTL in the text box at the bottom of the General
Settings page, as shown in Figure 2–25. Then click the Apply Changes button on the upper right
corner to save the change.
Figure 2–25 DNS Response TTL in the Virtual Site Scope
4. Configure the DNS server
Under the virtual site scope, select Site Configuration > Networking > DNS, and click the Add
button in the Name Server IP Address area, as shown in Figure 2–26.
Figure 2–26 DNS in the Virtual Site Scope
In the Add Name Server IP Address configuration window, enter the IP address in the text box
and click the Save button to save the configuration, as shown in Figure 2–27.

Figure 2–27 Add the Name Server IP address in the Virtual Site
5. Enable DNS server redundancy
AG supports the DNS server redundancy function for every virtual site. This function must be
enabled or disabled globally for every virtual site. When this function is enabled, if a virtual site is
configured to use the custom DNS settings to resolve the DNS query, the system will first try to
use the virtual site’s DNS server with the highest priority to resolve the DNS query; if this DNS
server fails to resolve the DNS query, the system will then try to use the virtual site’s DNS server
with the second highest priority to resolve the DNS query; if the second DNS server still fails to
resolve the DNS query, the system at last will try to use the virtual site’s DNS server with the
lowest priority to resolve the DNS query. The earlier the DNS server is configured for the virtual
site, the higher the priority of the DNS server will be. By default, this function is disabled and
only the virtual site’s DNS server with the highest priority can be used to resolve the DNS query.
Under the global scope, select System Configuration > Basic Networking > DNS, select the
Enable DNS Server Redundancy check box and click the Apply Changes button, as shown in
Figure 2–28.
Figure 2–28 Enable DNS Server Redundancy
6. Configure the search domain

Assign the search path to resolve non-qualified host names. Up to six paths can be configured.
Under the virtual site scope, select Site Configuration > Networking > DNS, and click the Add
button in the Search Paths area, as shown in Figure 2–26.
In the Add Search Path configuration window, enter the Search Path in the text box and click
the Save button to save the configuration, as shown in Figure 2–29.
Figure 2–29 Add the Search Path in the Virtual Site Scope
7. Set the DNS cache expiration time
The administrator can define the expiration time of DNS cache.
Under the virtual site scope, select Site Configuration > Networking > DNS. In the DNS Cache
area, please enter the Minimum Expiration Time and Maximum Expiration Time in the text
boxes as required, as shown in Figure 2–30. Then click the Apply Changes button on the upper
right corner to save the change.
Figure 2–30 Set the DNS Cache Expiration Time in the Virtual Site Scope
If TTL (Time to Live) of DNS response is shorter than the Minimum Expiration Time, the
expiration will take place after the Minimum Expiration Time. If TTL of DNS response is longer
than the Maximum Expiration Time, DNS cache will expire after the Maximum Expiration Time.

Chapter 3 Virtual Site
3.1 Virtual Site
3.1.1 Introduction
The VPN proxy server is often used to provide virtual services for users. These virtual services
mainly include client secure connection, user access control and backend resource management.
When customers want to enforce different secure connection policies, provide access control
methods and/or achieve resource management, they have to purchase more and more VPN proxy
servers. To enhance scalability and cost effectiveness, Array introduces the concept of “virtual
site”.
Virtual site is a manageable and configurable unit that provides the administrators with various
services including client secure connection, user access control, backend resource management
and so on.
When customers need to provide different services for specific users or groups, they can achieve
this goal easily by creating independent virtual sites on the AG appliance instead of purchasing a
VPN proxy server for each user or group, thus realizing high scalability and cost effectiveness.
The AG appliance can support at most 256 virtual sites.
Figure 3–1 Virtual Site
3.1.2 Different Virtual Site Types

AG provides three types of virtual sites: exclusive, shared and alias.
Exclusive virtual site is the basic manageable and configurable unit mentioned in section 3.1.1
Introduction.

For customers want to set up multiple virtual sites using a single SSL certificate and/or IP address
to reduce their expense, shared/alias virtual site is introduced. Shared virtual site and alias virtual
site(s) are paired concepts. Shared virtual site is parent node for alias virtual sites. Shared virtual
site holds the SSL configurations and IP address and all alias virtual sites inherit SSL
configurations and IP address from their shared virtual site.
Shared virtual site does not provide services or resources for the users and is only functioning as
the unified portal for its multiple alias virtual sites. After users successfully log into the shared
virtual site, the shared virtual site provide a choose_site option for users to choose the desired alias
sites to access. For this, the administrator needs to configure the “Choose a Virtual Site” page for
the shared virtual site.
Alias virtual site can supports all configurations of the exclusive virtual site except the SSL
configurations and IP address. Alias virtual sites are independent from each other no matter
whether they belong to the same shared virtual site. To access an alias virtual site, users need to
first log into its shared virtual site and choose this alias virtual site. To reduce the users’ burden to
choose the alias virtual site each time the user visits the alias virtual site, AG provides the option
to bookmark the login page of the alias virtual site by clicking the hyperlink on the alias virtual
site’s login page.
Note:
 The alias virtual site does not support certificate authentication for now.
 The combination of the shared and alias virtual sites cannot provide the MotionPro
solution.
3.1.3 Configuration Example

Under the global scope, select Virtual Sites > Virtual Sites > Virtual Sites, and click the Add
action link, as shown in Figure 3–2.
Figure 3–2 Add a Virtual Site
 Add an exclusive virtual site
To add an exclusive virtual site, set the Virtual Site Type parameter to “exclusive”, and specify
the parameters Site Name, Site FQDN and IP Address in the Add a New Virtual Site
configuration window, as shown in Figure 3–3.

Figure 3–3 Add an Exclusive Virtual Site
Note:
 More than one IP:port pair can be associated with the same virtual site. This feature
allows, for example, an administrator to associate both an internal and external (or
public) IP address to the same virtual site. Multiple domain names (FQDN) can also
be assigned to a virtual site.
 After configuring a virtual site, the administrator needs to click the Save
Configuration action link to save the configurations made under the global scope.
Otherwise, the virtual site will be missing after the system reboot.
For the functioning of the exclusive virtual site, the administrator need to generate or import an
SSL certificate, configure AAA, configure L3VPN and Web Access, and add user role and role
resources.
To generate/import an SSL certificate, please refer to section 3.2.5 Configuration Example.
To configure AAA, please refer to section 4.3 Configuration Example.
To configure Web Access, please refer to section 6.1.5 Configuration Example.
To configure L3VPN, please refer to section 6.2.6 Configuration Example.
To add user role and role resources, please refer to section 5.1.4 Configuration Example.
Alternatively, the administrator can use the AccessDirect Deployment action link as shown in
Figure 3–2 to quickly create an exclusive virtual site for AccessDirect, generate or import an SSL

certificate, configure AAA, configure L3VPN and Web Access, and add user role and role
resources, as shown in Figure 3–4.
Figure 3–4 AccessDirect Deployment
 Add a shared virtual site

To add a shared virtual site, set the Virtual Site Type parameter to “shared”, and specify the
parameters Site Name, Site FQDN and IP Address in the Add a New Virtual Site configuration
window, as shown in Figure 3–5.
Figure 3–5 Add a Shared Virtual Site
 Add an alias virtual site
To add a shared virtual site, set the Virtual Site Type parameter to “alias”, and specify the
parameters Shared Site and Alias Site Name in the Add a New Virtual Site configuration
window, as shown in Figure 3–6.
Figure 3–6 Add an Alias Virtual Site
Note: To recreate the virtual site after it is removed, the administrator needs to execute the
command “clear config all” or “clear config factorydefault” first before using the same
virtual site name. Alternatively, the administrator can create the virtual site with another
name.

3.2 SSL
SSL (Secure Sockets Layer) is utilized on the AG appliance to provide security for Web traffic.
Security includes confidentiality, message integrity, and authentication. SSL achieves these
elements of security through the use of cryptography, digital signatures, and certificates.
3.2.1 Cryptography
SSL protects confidential information through the use of cryptography. Sensitive data is encrypted
across public networks to achieve a level of confidentiality. There are two types of data encryption:
secret key cryptography and public key cryptography.
Secret key cryptography – Also known as symmetric cryptography, it uses the same key for
encryption and decryption. An example of symmetric cryptography is a decoder ring. Alice has a
ring and Bob has the same ring. Alice can encode messages to Bob using her ring as the cipher.
Bob can then decode the sent message using his ring. In cryptography, the “decoder ring” is
considered as a pre-shared key. The key is agreed upon by both sides and can remain static. Both
sides must know each other already and have agreed upon what key to use for the encryption and
decryption of messages.
Figure 3–7 Secret Key Encryption/Decryption
Public key cryptography – This method uses one key for encryption of data, and then a separate
key for decryption.

Figure 3–8 Public Key Encryption/Decryption
3.2.2 Digital Signature

To ensure the integrity of messages transmitted via the Internet, each message exchanged via SSL
has a digital signature attached to it. A digital signature is a hashed message digest which is
encrypted by hash algorithm and contains public key information. The message digest is generated
based on the checksum results on the message itself. The message digest cannot be reversed by
any algorithm. Thus, both parties will compute the message digest separately and then compare
the hashed results. If their computing results match, it means the message has not been altered
during transmission on Internet, which minimizes the chances of information leakage.
Figure 3–9 Digital Signatures
3.2.3 Certificate
Certificates contain information identifying the user/device. They are digital documents that
validate the binding of a public key to an individual or other entity (for example, they verify that a
specific public key does, in fact, belong to the specified entity). Certificates help prevent someone
from impersonating the server with a false key. SSL uses X.509 standard certificates to validate
identities. X.509 standard certificates contain information about the entity, including public key
and name. These certificates are validated by a certificate authority.
Table 3–1 X.509 Certificate
Certificate Information
Algorithm Identifier
Serial Number
Version
Issuer
Period of Validity
Subject
Subject’s Public Key
Issue Unique ID
Subject Unique ID
Extensions

Certificate Information
Signature
Client Certificate Parse
An authentication service (for example LocalDB) needs information from a client certificate in
order to authenticate the user. But, the authentication service itself cannot recognize and analyze a
raw SSL certificate. To resolve this issue, the AG uses the Array certificate parser (Array
Networks patent) to quickly extract the client certificate data into many fields which can then be
transferred to the authentication service through HTTP URL request parameters or HTTP headers.
3.2.4 SSL Certificates and Authentication

The AG appliance has three kinds of SSL certificates authentication:
One-way Handshake
If the user does not require the certificate authentication, the AG appliance will use the One-way
Handshake. In this case, the client first sends a “Hello” message to the AG appliance. Then, the
AG appliance returns a “Hello” message (with an attached certificate) to the client. After some
handshake steps, the AG appliance sends an encrypted “finished” message to the client. At this
point, the SSL tunnel is created successfully. And, the client can exchange encrypted application
data with the AG appliance through this SSL tunnel.
The following figure shows the process of the One-way Handshake:
Figure 3–10 One-way Handshake
Two-way Handshake

If a higher security level is required, the AG appliance may be configured to use Two-way
Handshake for certificate authentication. In this case, the client first sends a “Hello” message to
the AG appliance. Then, the AG appliance returns a “Hello” message (with an attached certificate)
to the client followed by a “CertificateRequest” message to ask the client for a client certificate.
After the client sends its certificate to the AG appliance, the AG appliance attempts to authenticate
the client based on information in the client certificate. Finally, after some handshake steps, the
AG sends an encrypted “Finished” message to the client. At this point, the SSL tunnel is created
successfully. And, the client can exchange the encrypted application data with the AG appliance
through this SSL tunnel.
The following figure shows the process of the Two-way Handshake:
Figure 3–11 Two-way Handshake
Renegotiation
In the case of a one-way handshake connection, if the user successfully connects to the login page
and chooses “Client Certificate” as his authentication method, then the AG will proceed to initiate
a “Renegotiation” sequence to request the client certificate. The AG appliance allows the user to
choose the authentication method after the One-way Handshake has already been completed and
the SSL tunnel has already been created. This method is called “Renegotiation”.
During “Renegotiation”, the AG appliance sends a “HelloRequest” to the client. Then, the client
sends a “Hello” message to the AG appliance. Then, the AG appliance sends a “Hello” message to
the client followed by a “CertificateRequest” message to ask the client for a client certificate.
After the client sends its certificate to the AG appliance, the AG appliance attempts to authenticate

the client based on information in the client certificate. Finally, after some handshake steps, the
AG sends an encrypted “Finished” message to the client. At this point, the SSL tunnel is created
successfully. And, the client can exchange the encrypted application data with the AG appliance
through this SSL tunnel.
The following figure shows the process of the Renegotiation:
Figure 3–12 Renegotiation
The following table displays the SSL protocol versions supported by the AG appliance, and cipher
suites supported by each SSL protocol version.
Table 3–2 Supported SSL Protocol Versions and Cipher Suites
Cipher Suite Bits SSLv3 TLSv1 TLSv1.2

RC4-MD5 128 √ √ √
RC4-SHA 128 √ √ √
DES-CBC-SHA 64 √ √ x
DES-CBC3-SHA 192 √ √ √
AES128-SHA 128 √ √ √
AES256-SHA 256 √ √ √
AES128-SHA256 128 x x √
AES256-SHA256 256 x x √

Cipher Suite Bits SSLv3 TLSv1 TLSv1.2

EXP-RC4-MD5 40 √ x x
EXP-DES-CBC-SHA 40 √ x x
The AG appliance supports only the following key exchange mechanisms:
 RSA (1024)
 RSA (2048)
 RSA (4096)

Before we get started, let’s explain the terminologies used extensively throughout this chapter.
Key (private): A private key that is stored on the AG appliance for PKI (Public Key
Infrastructure) authentication purposes. The AG appliance supports RSA keys up to 4096 bits in
size.
Certificate: This is used for authentication purpose and to help set up secure communications
between the appliance and the browser.
Certificate Authority (CA): A certificate authority is an entity that will create a certificate from a
CSR (Certificate Signing Request).
Trusted Certificate Authority: Current Web Browsers have a list of known CA’s public keys
that are used to verify certificates authenticity. If the browser cannot identify the CA it will inform
the user as such. In a similar manner the AG appliance also maintains a list of Trusted Certificate
Authorities to verify certificates.
Now, follow the steps below to complete the basic configurations for SSL.
 (Optional) Step 1: Generate an SSL Certificate/Key Pair
You can use the AG appliance to generate a certificate/key pair for the virtual site. However, this
certificate/key pair can only be used for test. For production, you need to import and activate a
certificate/key pair issued by trusted CA.
To do this, when adding a virtual site by selecting Virtual Sites > Virtual Sites > Virtual Sites
under the global scope, you can select the Generate radio button in the SSL Certificate area in
the middle part of the page, as shown in Figure 3–13.

Figure 3–13 Generating a Certificate/Key Pair
Note:
 Entered characters for the subject fields Country Code, State/Province, City/Locality,
Organization, Organizational Unit, and Common Name (available when Site FQDN
as Common Name is set to No) can only be A-Z, a-z, numbers, space, or characters '
()+,-./:=?
 The subject field Administrator's Email cannot contain any of characters ! # $ % ^ *

()~?><&/\,"'
 Step 2 Import SSL Certificate/Key Pairs
There are two methods for importing certificate/key pairs while defining a virtual site. A
maximum of three certificate/key pairs can be imported to the AG appliance.
 Import certificate/key pairs into the AG appliance via copy-n-paste
If you already have certificate/key pairs from a trusted certificate authority, you can easily import
them into the AG appliance.
Under the global scope, select Virtual Sites > Virtual Sites > Virtual Sites, and select the
Import radio button in the SSL Certificate area in the middle part of the page. Then paste your
existing certificate and key respectively into the Paste SSL Certificate Here and Paste SSL Key
Here text boxes, as shown in Figure 3–14.

Figure 3–14 Import the SSL Certificate/Key Pair via Copy-n-Paste
 Import certificate/key pairs into the AG appliance via TFTP
You can also import a key file from a remote machine running the TFTP service. The file name
defaults to <Host name>.key. In our case, the Site FQDN is “www.demo.com” and the file name
is “www.demo.com.key”. Likewise you can import the certificate from TFTP server with the
filename “www.demo.com.crt”.
Under the global scope, select Virtual Sites > Virtual Sites > Virtual Sites, and select the
Import via TFTP radio button in the SSL Certificate area in the middle part of the page. Then
specify the parameters TFTP Server IP for SSL Cert, File Name, TFTP Server IP for SSL
Key and Key Password properly, as shown in Figure 3–15.
Figure 3–15 Import the SSL Certificate/Key Pair via TFTP
 Step 3: Activate an Imported SSL Certificate/Key Pair
To use an imported SSL certificate/key pair, you must activate it first. By default, the
certificate/key pair generated by AG is active. You can activate another imported certificate/key
pair. To activate an imported certificate/key pair, select Site Configuration > SSL/DTLS
Certificates > Certificates/Key under the virtual site scope, check the radio button of desired
certificate/key pair and click the Set Active action link to activate it, as shown in Figure 3–16.

Figure 3–16 Activate an Imported SSL Certificate/Key Pair
After the SSL Certificates are generated or imported, you can check the SSL certificate
information of the virtual site by selecting Virtual Sites > Virtual Sites > Certificate Info under
the global scope. Choose the desired virtual site from the Virtual Site Name drop-down list, and
the status of the SSL certificates will be displayed in the table, as shown in Figure 3–17.
Figure 3–17 Display the SSL Certificate Information of a Virtual Site
 Step 4 Enable SSL for the Virtual Site
By default, SSL is disabled. To enable the feature, select Site Configuration > SSL/DTLS
Certificates > SSL Settings > General under the virtual site scope, select the Enable SSL check
box, and then click the Apply Changes button on the upper right corner to save your
configuration, as shown in Figure 3–18.
Figure 3–18 Enable SSL
 Step 5 Configure SSL Protocol Version for the Virtual Site
The AG appliance supports the SSL protocols SSLv3, TLSv1 and TLSv12. You may use one, two
or three of these protocols.

Select Site Configuration > SSL/DTLS Certificates > SSL Settings > General under the virtual
site scope, select the SSLv3, TLSv1 or TLSv12 check boxes, and then click the Apply Changes
button on the upper right corner to save your configuration, as shown in Figure 3–18.
 Step 6 Configure Session Reuse for the Virtual Site
This allows you to enable the SSL session reuse feature for a virtual site.
Select Site Configuration > SSL/DTLS Certificates > SSL Settings > General under the virtual
site scope, select the Enable SSL Cache check box, and then click the Apply Changes button on
the upper right corner to save your configuration, as shown in Figure 3–18.
The feature is enabled by default.
 Step 7 Configure OCSP to Check the Certificate Validation Online
The AG appliance supports the OCSP (Online Certificate Status Protocol) protocol. You may
configure the AG appliance to validate the certificate on an OCSP server online.
For our example, to configure an OCSP server (e.g. ocsp.crldp.com:8888) for validating the
certificate online, you may input “ocsp.crldp.com:8888” in the OCSP URL text box, as shown in
Figure 3–18.
Note: The OCSP validation has top priority. Once configured, the OCSP will validate the
certificate by only checking the OCSP server.
 Step 8 Enable Client Authentication for the Virtual Site
The AG appliance supports the SSL-based client authentication. You can enable client
authentication for a virtual site. If enabled, the AG appliance will require each client to present an
SSL certificate for authorization, before the client can access the virtual site.
Select Site Configuration > SSL/DTLS Certificates > SSL Settings > Client Authentication
under the virtual site scope, and select the Enable Client Authentication check box to enable the
client authentication feature.
Note: If you enable SSL client authentication for a virtual site, you must provide a trusted
CA certificate. This will be used by the AG appliance to verify client certificates.
Client certificate authentication is extended to filter the client certificate “Subject” fields. A client
certificate will be checked against the configured filter information. If no match is made, the client
access will be rejected.
The filter rules can be configured with any of the supported RDNs on the AG appliance.
Table 3–3 Supported RDN on AG
RDN Standard Name

C Country Name
ST State or Province Name

RDN Standard Name

L Locality Name
O Organization Name
OU Organizational Unit Name
CN Common Name
SN Serial Number
dnQualifier DN Qualifier
Pseudonym Pseudonym
Title Title
GQ Generation Qualifier
Initials Initials
Name Name
givenName Given Name
Surname Surname
DC Domain Component
emailAddress Email Address
{OID expression} OID information, for example: 1.2.3.4
An example is shown in Figure 3–19.
Figure 3–19 SSL Client Authentication
In this situation, the AG appliance will authenticate the client certificate by using the trusted root
certificate. Then the configured subject filter rule will be used to permit (if matching the filter rule)
or deny the client’s access to the SSL virtual host. For this example, all client certificates with the
“C” entry “US”, the “O” entry “Array”, the “OU” entry “QA”, and the “emailAddress” entry
“admin@arraynetworks.com” will pass the subject filter. Otherwise, the client will not pass the
authentication.
Two kinds of client authentication modes are supported: mandatory and non-mandatory. Client
authentication mode defaults to mandatory. In non-mandatory client authentication mode, when
the server sends a certificate request to the client, if the client has no matched certificate or cancels
the authentication, the server will permit the client to access limited network resources instead of
dropping the SSL connection.
 Step 9 Configure Certification Revocation List
AG supports the Certification Revocation List (CRL) functionality. You can configure the AG
appliance to fetch the CRL file periodically from a CRL distribution point by using HTTP, FTP or
LDAP.

For our example, let’s consider a case when you have put your CRL file (Array.crl) on an HTTP
Web server (www.crldp.com) and you want to fetch it every one minute.
Select Site Configuration > SSL/DTLS Certificates > SSL Settings > Client Authentication
under the virtual site scope, and click the Add action link in the Certification Revocation List
area, as shown in Figure 3–20.
Figure 3–20 Certification Revocation List
In the Add Certification Revocation List window, you can specify a certification revocation item,
Figure 3–21 Add Certification Revocation List
This will cause the AG appliance to fetch the CRL file at the regular interval of one minute from
the “www.crldp.com” site by utilizing HTTP.
You can also specify an FTP URL to download the CRL file, and the CRL URL should be
“ftp://ftp.crldp.com/Array.crl”. Or you may also specify an LDAP URL to download the CRL file,
and the CRL URL should be “ldap://ldap.crldp.com/cn=array,dc=arraynetworks,dc=com”.
When using FTP and HTTP server, you must specify the file to be downloaded. For LDAP server,
you can just specify the directory of CRL files, AG will download all the CRL files in the
directory.
 Step 10 Configure Cipher Suites for the Virtual Site
The cipher suite settings allow you to define ciphers for the virtual site. The following lists the
cipher suites allowed for a virtual site:
 128-bit RC4 with MD5
 128-bit RC4 with SHA

 112-bit Triple-DES with SHA
 128-bit AES with SHA
 256-bit AES with SHA
 56-bit DES with SHA*
 40-bit RC4 with MD5*
 40-bit DES with SHA*
 AES128-SHA256
 AES256-SHA256
To enable multiple ciphers for a single virtual site, you will need to specify the priority for each
cipher, as shown in Figure 3–22.
Figure 3–22 Set Priority of Cipher Suites

Chapter 4 AAA (Authentication, Authorization, Accounting)
Chapter 4 AAA (Authentication, Authorization,

Accounting)
4.1 Introduction
AAA is a series of combined features and operations providing Authentication, Authorization and
Accounting for all connections and transactions carried out across the network. It refers to a
security architecture, which enables control which users are allowed access to which services, and
how much of the resources they have used. This empowers the administrators to tightly control
user access to content, grant users with specific authorities to internal resources and realize the
charging for services.
4.1.1 Authentication
“Authentication” is the first process in the AAA feature. In this process, the authentication server
will check the identifier and corresponding credential. Valid credential will grant successful login,
which is the prerequisite to user authorization for proper internal resources.
Figure 4–1 Authentication Workflow
The preceding figure shows the workflow of authentication:
1. The user arrives at the Web portal of the virtual site where credential input is required.
2. The authentication server(s) checks the credentials entered by the user.
3. If the credentials are correct, AG displays the successful login page for the user.
4. If the credentials are incorrect, AG prompts the user to enter the credential again.
4.1.2 Authorization
Authorization determines whether a particular entity is authorized to access an application or
service. Authorization will be determined based on a range of restrictions, for example the group
restrictions, time-of-day restrictions, or physical location restrictions, or combined restrictions.
4.1.3 Accounting
Accounting refers to the tracking of network resource consumption by users for the purpose of
capacity and trend analysis, cost allocation, and billing.

4.2 AAA in AG
Figure 4–2 How AAA Works
The preceding figure shows how AAA works:
1. A user enters credentials on the portal login page of the virtual site.
2. AAA server(s) checks the credentials entered by the user.
3. AG will get the success or failure of authentication, authorization and accounting from the
AAA server(s).
4. Upon successful login, the user is redirected to a portal welcome page where internal
resources authorized for the user will be displayed for the user.
Note: The “server” does not necessarily mean external servers, but any entity used to
authenticate or authorize the users, including AG's local database (LocalDB) and Client
Certificate server.
When a virtual portal is created, AAA is enabled by default. The administrator has the option of
disabling AAA on a per-virtual-site basis.
4.2.1 AAA Server

AG uses one of several available AAA servers to “authenticate” the identity of end users. A
“server” is any entity that can be used to authenticate or authorize (or both authenticate and
authorize) users through AAA.
AG supports the following types of AAA servers:
 LocalDB
 Lightweight Directory Access Protocol (LDAP)
 Remote Authentication Dial In User Service (RADIUS)
 Client Certificate

 SECUREMATRIX (SMX)
 Short Message Service (SMS)
4.2.1.1 LocalDB
Administrators can record all users, passwords and groups into local database on AG. Users will
input their names and passwords as the credential to log into the virtual site.
The LocalDB of an AG appliance can accommodate up to 500,000 user accounts and 50,000
groups. The LocalDB of a particular virtual site shares the storage with the LocalDB of other
virtual sites on the same AG appliance. One virtual site can only have one LocalDB server with
the same name as the virtual site name. The following are some assumptions of LocalDB:
 User/Group name should be unique within a virtual site.
 Each user or group can be a member of zero or multiple groups.
 Password quality check can be enabled in LocalDB.
4.2.1.1.1 Configuration Example
Before enabled LocalDB as the AAA server for the virtual site, the administrator needs to add
local accounts and local groups in the LocalDB.
 Add Local Accounts
Under the virtual site scope, select Local Database > Local Accounts > Local Accounts, click
the Add action link in the Local Accounts List area, as shown in Figure 4–3.
Figure 4–3 Local Accounts List
In the Add Local Account area, specify the parameters User Name, Password and Confirm
Password, optionally select other check boxes and specify other parameters, and click the Save
action link, as shown in the Figure 4–4.

Figure 4–4 Add a Local Account
 Add Local Groups
Under the virtual site scope, select Local Database > Local Groups> Local Groups, click the
Add action link in the Local Groups area, as shown in Figure 4–5.
Figure 4–5 Local Groups
In the Add Local Account area, specify the Group Name parameter and select the check boxes
before the local accounts to be added to the local group and click the Save action link, as shown in
the Figure 4–6.

Figure 4–6 Add a Local Group
 Enable the LocalDB server
Under the virtual site scope, select Site Configuration > AAA > Server > LocalDB, select the
Enable LocalDB Server and Username Case Insensitive During LocalDB Authentication
check boxes and specify the parameter Default Group Name in the LocalDB Server
Configuration area, and click the Apply Changes button on the upper right corner to save this
configuration, as shown in Figure 4–7.
Figure 4–7 Enable the LocalDB Server
Note: If the Default Group Name parameter is specified, its value will be used as the
group name when LocalDB fails to obtain the group names for users.
4.2.1.2 LDAP (including AD)
AG supports authentication and authorization with LDAP. All LDAP servers of LDAP protocol
v3 are supported by the AAA module, such as OpenLDAP and Active Directory (AD).
Up to three LDAP servers can be set for a virtual site. For redundancy purposes, each server can
have three hosts. If multiple LDAP servers are utilized, the hosts’ Round Robin (rr) load balancing
can be implemented to further improve performance.
LDAP servers can be configured to be accessed for both authentication and authorization using the
SSL/TLS protocol per host.
4.2.1.2.1 Group Mapping
Group mapping is another way to control user and group access to internal resources. This feature
enables AG to retrieve group information from external LDAP/RADIUS servers and map that

group information to local AG groups. Users in the external group will be authorized as in the
mapped local group.
For each virtual site, the administrator may optionally configure a local default group. In the event
that the group mapping between the external authentication server and AG is incomplete (for
example, there are external group names not mapped to any LocalDB groups), AG will map these
external groups to the local default group. If no local default group has been configured, login may
be rejected for these unmapped external groups.
4.2.1.2.2 LDAP Password Change
The LDAP Password Change function allows LDAP users to change their password through the
virtual portal and displays password expiry warning messages to friendly notify LDAP users that
their passwords are going to expire.
This function allows the virtual portal either to always display the “LDAP password change” links
on the welcome page or to display the “LDAP password change” links on the portal page only
when password expiry warning messages are started to show up. By clicking an “LDAP password
change” link, the user can change the password on the specified LDAP server in the displayed
password change page. If the LDAP password has expired, the user will be redirected to the
password change page in the LDAP authentication process.
Note:
 In a multi-factor authentication scenario, a maximum of three “change password”

links including “LDAP password change” links can be displayed on the welcome
page.
 When the user’s password has expired on more than one AAA server, the user is
allowed to change the expired password on only one AAA server at a time. After the
user changes the expired password, the virtual site will skip the authentication from
other AAA servers and let the user log into the virtual site successfully. When
logging into the virtual site next time, the user is allowed to change the expired
password on another AAA sever.
This function will also display a password expiry warning message on the welcome page to notify
the LDAP user of the password’s remaining valid time. This password expiry warning mechanism
can help LDAP users to change their passwords timely to avoid login failures, which improves
user experience.
Before using the LDAP Password Change function, please make sure that:
 On related LDAP servers, lifetime of LDAP passwords has been configured.
 For the OpenLDAP server, the external default policy has been configured.
 For the Windows AD server, its system time must be the same as the system time of the AG
appliance.
 On the AG appliance, the related Windows AD servers have been configured to use port 636
and to be accessed using the TLS protocol.

4.2.1.2.3 LDAP Browser
The LDAP Browser function is provided to enable administrators to easily search and add
usernames and groups to user role conditions from an LDAP host.
In addition, this function supports LDAP auto-search and email notification, which enables
auto-search of usernames and groups at a specific frequency and notifies the administrators of the
search result (users and groups) changes via emails.
To achieve LDAP auto-search and email notification, the administrators needs to define an LDAP
auto-search profile, in which the LDAP host settings, search attribute, search filter, and search
frequency, email addresses to notify and the email subject can be configured.
After the LDAP auto-search profile is enabled, the system will carry out a search on the specified
LDAP host at the specified hour per day, per week, or per month. If the search results change
since last search, the administrators will be notified of the search result changes via emails.
Besides, the administrator can also manually execute the profile to carry out a search immediately.
LDAP auto-search and email notification also provides a shortcut to role qualification, which
allows the administrators to easily add the usernames or groups in the search results to role
conditions.
 Add an LDAP Server
Under the virtual site scope, select Site Configuration > AAA > Server > LDAP, specify the
Server Name and Description parameters and click the Add button in the Server List area, as
shown in Figure 4–8.
Figure 4–8 Add an LDAP Server
In the Server List area, double-click the server entry to add more advanced configuration for the
LDAP server.
In the LDAP Server Configuration area of the displayed window, click the Add LDAP Server
action link to add a host for the LDAP server, as shown in Figure 4–9.

Figure 4–9 LDAP Server Configuration
In the Add LDAP Server area, specify the parameters Server IP, Server Port, User Name, User
Password, Base, Timeout and Redundancy Order, select the Use TLS check box if required,
and click the Save action link, as shown in Figure 4–10.
Figure 4–10 Add an LDAP Server Host
Repeat the preceding configuration to add at most three hosts for the LDAP server.
In the Advanced LDAP Server Configuration area, specify the parameters Server Filter,
Group Attribute, Default Group and Authenticate with Bind, specify other parameters if
required, and click the Apply Changes button on the upper right corner to save the configurations

Figure 4–11 Advanced LDAP Server Configuration
 Configure Group Mapping
Under the virtual site scope, select Site Configuration > AAA > Group Mapping, specify the
External Group and Internal Group parameters and click the Add button in the Group List
area, as shown in Figure 4–12.
Figure 4–12 Add an Group Mapping Entry
 Configure LDAP Password Change
 Configure password expiry warning
In the Advanced LDAP Server Configuration window, specify the parameters Password
Expire Warning and Password Policy DN (only for the OpenLDAP server) and click the Apply
Changes button, as shown in Figure 4–13.

Figure 4–13 Configure Password Expiry Warning
 Enable LDAP Password Change on the Web portal
Under the virtual site scope, in the Basic Settings area of Site Configuration > Portal > General
Settings > Common Settings, select the Enable LDAP Password Change check box, and select
the only when expire warning check box as required, as shown in Figure 4–14.
Figure 4–14 Enable LDAP Password Change
 Configure LDAP Browser
LDAP Browser allows the administrator to add usernames or groups as role condition from the
LDAP server

 Add usernames from an existing LDAP Host
Under the virtual site scope, select Role > Role Settings > Role Qualifications, and click the
Add button, as shown in Figure 5–5.
In the Add Role Qualification configuration window, select the pre-defined Role Name from the
drop-down list, enter the name of Qualification, Description (optional). Then, specify the
condition Type as User Name, and the Add from LDAP button will appear to the right of the
Content text box.
Figure 4–15 Add Condition of Username
After clicking the Add from LDAP button, the Add Users from LDAP configuration window
will appear. Select the Add From an Existing LDAP Host radio button, and the LDAP hosts
available will be displayed.

Figure 4–16 Select an Existing LDAP Host
Select the LDAP host from the Host table, specify the Attribute as Username and Search Filter
text boxes (the Search Filter content needs to follow the LDAP search rules), and click the
Search button.
After clicking the Search button, the Search Results will be returned, as shown in Figure 4–17.
Figure 4–17 Search Results
Note: By default, only 1000 results of LDAP records can be returned.
Select the record(s) in the search results, and click the OK button on the top-right corner to add
the username(s). At most 10 items can be selected at one time.
 Add usernames from a new LDAP host
To add usernames from a new LDAP host, select the Add From a New LDAP Host radio button
in the Add Users from LDAP configuration window, specify the Host IP, Port, Username,
Password, Base, Timeout, Attribute as Username and Search Filter, and click the Search
button. The search results will be displayed in the table below.

Figure 4–18 Add Usernames from a New LDAP Host
Select the record(s) in the search results, and click the OK button on the top-right corner. At most
ten items can be selected at one time.
 Add groups from an LDAP host
drop-down list, enter the name of Qualification, Description (optional). Then, specify the
condition Type as Group Name, and the Add from LDAP button will appear to the right of the
Content text box.
The only difference between adding groups and adding usernames is that the Attribute as
Groupname is retrieved from LDAP Attribute Group in the Advanced LDAP Server
Configuration, as shown in Figure 4–11.
 Configure an LDAP Auto-search Profile
Under the virtual site scope, select Site Configuration > AAA > Server > LDAP, and click the
Add Profile action link in the Auto Search & Email Notifications area, as shown in Figure
4–19.
Figure 4–19 Add an LDAP Auto-search Profile
In the Add Search Profile configuration window, select the Enable Search & Notify check box,
specify the parameters Profile Name, Search From, Server Name, Host, Search Attribute,
Search Filter, Search At, Email, and Subject, and then click the Save action link, as shown in
Figure 4–20.

Figure 4–20 Add an LDAP Auto-search Profile for an Existing LDAP Host
To associate the LDAP auto-search profile to a new LDAP host, you also need to specify the
parameters Host IP, Port, Username, Password, Base, and Use TLS, as show in Figure 4–21.
Figure 4–21 Add LDAP Auto-search Profile for a New LDAP Host
To view the latest search result of the specified profile, click the Latest Search Result cell of the
profile entry in the Auto Search & Email Notifications table, as show in Figure 4–22. In the
Search Result and Detected Changes window, the latest search results and detected changes will
be displayed, as shown in Figure 4–23.

Figure 4–22 Viewing Latest Search Result
Figure 4–23 Search Result and Detected Changes
Note: If the search result is different from the last search result, the Latest Search Result
cell will be highlighted in a different color, as shown in Figure 4–22. After viewing the
changes, you can click the I got it button to acknowledge the changes, as shown in Figure
4–23.
To add a username or group to a specified role qualification, click the Expand action link in the
Shortcut to Role Qualification area, and specify parameters Role Name, Qualification Source,
Qualification, Description, Condition Type, Condition Action, and Condition Content, and
click the Add button, as shown in Figure 4–24.

Figure 4–24 Shortcut to Role Qualification
4.2.1.3 RADIUS
AG supports authentication and authorization with RADIUS.
Up to three RADIUS servers can be set for a virtual site. For redundancy purposes, each server
can have three hosts. If multiple RADIUS servers are utilized, the hosts’ Round Robin (rr) load
balancing can implemented to further improve performance.
RADIUS requests are non-blocking. Timeouts will be scheduled for all RADIUS requests.
 Add a RADIUS Server
Under the virtual site scope, select Site Configuration > AAA > Server > RADIUS, specify the
Server Name and Description parameters and click the Add button in the Server List area, as
Figure 4–25 Add a RADIUS Server
In the Server List area, double-click the server entry to add more advanced configuration for the
RADIUS server. In the RADIUS Server Configuration area of the displayed window, click the
Add LDAP Server action link to add a host for the RADIUS server, as shown in Figure 4–26.

Figure 4–26 RADIUS Server Configuration
In the Add RADIUS Server area, specify the parameters Server IP, Server Port, Secret
Password, Timeout, Redundancy Order, Retries and Accounting Port, and click the Save
action link, as shown in Figure 4–27.
Figure 4–27 Add a RADIUS Server Host
Repeat the preceding configuration to add at most three hosts for the RADIUS server.
In the Advanced RADIUS Server Configuration area, specify the parameters RADIUS NASIP,
RADIUS Attribute Group, RADIUS Attribute Default Group, RADIUS Attribute ClientIP
and RADIUS Attribute ClientIP Mask, and click the Apply Changes button on the upper right
corner to save the configurations as shown in Figure 4–28.

Figure 4–28 Advanced RADIUS Server Configuration
4.2.1.4 Client Certificate
AG has the capability to verify whether the certificate is signed by a trusted Certificate Authority
(CA). With this capability, AG supports three types of client certificate authentication:
 “Anonymous”: The “Anonymous” type only needs the client certificate for user
authentication.
 “NoChallenge”: The “NoChallenge” type needs the client certificate and account existence
on the authentication server.
 “Challenge”: The “Challenge” type needs the client certificate and a password for user
authentication.
For the “Anonymous” type, the administrator does not need to use another additional
authentication server, and the certificate validation will be performed by the SSL module to check
if the provided certificate is singed by a trusted CA certificate. For the “NoChallenge” or
“Challenge” type, the administrator must configure either a LocalDB or an LDAP server as the
authentication server for authenticating client certificates.
If SSL Certificate Authentication is enabled (by checking the Enable Client Authentication
check box in the path Site Configuration > SSL/DTLS Certificates > SSL Settings > Client
Authentication under the virtual site scope), the message box for choosing the client certificate
will be prompted before the portal login page is display when the user accesses the virtual site.
Otherwise, the message box for choosing the client certificate will be prompted when the AAA
method using client certificate authentication is selected.
For the client certificate authorization, the administrator needs to use LocalDB, LDAP or External
Group as the authorization server against which the certificate will be authorized. “External
Group” authorization differentiates users based on the specific field(s) of the users’ certificates
(for example, users with the same field(s) value will be regarded as the same group and granted
with the same permission).

The general workflow of certificate authentication/authorization looks like this:
1. SSL verifies the client certificate against trusted CAs.
2. SSL extracts the appropriate fields from the certificate.
3. SSL passes the field values to the AAA server.
4. AAA performs the authentication using the LDAP server or LocalDB.
5. AAA performs the authorization using the LDAP server, LocalDB, or External Group.
Under the virtual site scope, select Site Configuration > AAA > Server > Client Certificates,
click the Add Certificate Server button in the Certificate Server Configuration area, as shown
in Figure 4–29.
Figure 4–29 Certificate Server Configuration
In the Add Certificate Server area, specify the Server Name and Display Name parameters,
select the Authenticate and Authorize check boxes according to actual requirements, specify
necessary parameters if predefined AAA servers are selected for client certificate authentication or
authorization, as shown in Figure 4–30.

Figure 4–30 Add a Certificate Server
4.2.1.5 SMX
SECUREMATRIX (SMX) is a highly secure and tokenless authentication method, which

combines patterns and images to form a one-time password. Whenever authentication is requested,
the SMX server randomly generates a unique matrix and sends it to the user terminal. The matrix
table changes for each login but the pattern does not. The users only need to enter the numbers
within their chosen superimposed pattern in a sequence that the users have also chosen and
registered in advance.
Note: The authentication method of SECUREMATRIX® is a patent possessed by the

Japanese company CSE Secure Systems, Inc.
AG supports only authentication with SMX.
Up to three SMX servers can be set for a virtual site. For redundancy purposes, each server can
have at most two hosts: one primary host and one secondary host. The primary host is mandatory
and the secondary host is optional. The secondary host is used only when the user fails the
authentication performed by the primary host or when the primary host is unavailable.
To make an SMX host work for authentication, you must import the certificate file of the SMX
host into AG. You can import the certificate file into AG in any of the following ways via AG
WebUI:

 From the SMX host itself: You need to specify the credential for logging into the SMX host.
 From the local host: You need to specify the path of the certificate file on the local host.
 From a remote host: You need to specify the credential for logging to the remote host and the
path of the certificate file on the remote host.
Note:
 The certificate file is one .zip file, which contains the private key, cert file and CA
file.
 You can only import the certificate file into AG from a remote host via CLI.
 When the session reuse feature is enabled, SMX authentication cannot be used.
Under the virtual site scope, select Site Configuration > AAA > Server > SMX, specify the
parameters Server Name and Description in the Server List area and click the Add button to add
the SMX server, as shown in Figure 4–31.
Figure 4–31 Add an SMX Server
Double-click this server entry in the Server List area. In the Advanced SMX Server
Configuration area of the displayed window, add the primary and secondary host for the SMX
server, as shown in Figure 4–32.

Figure 4–32 Advanced SMX Server Configuration
Note: To make an SMX host work for authentication, you must import the certificate file
of the SMX host into AG.
4.2.1.6 SMS
When a two-step authentication process is required, AG allows the administrator to use the
preceding normal authentications as the first part of the authentication and to use Short Message
Service (SMS) authentication as the second part of the authentication process. After users have
successfully passed normal authentications, they will be switched to the SMS authentication page
if SMS authentication is used. AG will automatically send users’ mobile phones SMS messages
that contain verification codes through an SMS server. If users enter the correct verification codes,
they successfully pass the two-step authentication process.
Users have three chances to enter the verification codes. If users enter verification codes for three
times, they will be switched to the user login page. Verification codes sent by AG will expire in a
specified period. Users can click the Resend button on the SMS authentication page to resend
verification codes to their mobile phones for at most three times.
Mobile phone numbers of users can be obtained from:
 LocalDB
 LDAP server
 RADIUS server
 Certificate server
To obtain mobile phone numbers of user from a certificate server, the administrator can further
configure AG to obtain mobile phone numbers from certificates, LocalDB, or associated LDAP
server.
Under the virtual site scope, select Site Configuration > AAA > Server > SMS, specify the
parameters Server Name and Description in the Server List area and click the Add button to add
the SMS server, as shown in Figure 4–33.

Figure 4–33 Add an SMS Server
Double-click this server entry in the Server List area. In the Advanced SMS Server
Configuration area of the displayed window, specify the basic parameters of the SMS server, and
specify advanced parameters of the SMS server as required, as shown in Figure 4–34.
Figure 4–34 Advanced SMS Server Configuration
4.2.1.7 Hardware ID
Hardware ID is the hardware character string that can uniquely identifies the client used to access
the virtual site. The hardware ID value can be either auto collected by the component of ActiveX
or Java applet in the login process, or registered by administrators manually with the dedicated
Hardware ID Generator tool.
Hardware ID Authorization is used to approve or deny users’ access to the virtual site with the
specified client based on the hardware ID value of the client. To make Hardware ID Authorization
take effect for a LocalDB group, administrator must enable Hardware ID Authorization both
globally and for the LocalDB group. By default, Hardware ID Authorization is disabled both
globally and per LocalDB group.
When Hardware ID Authorization is enabled for a LocalDB group, the Auto Collect option is
enabled so that hardware ID values of clients used by users belonging to this group will be auto
collected. The clients can be used to access the virtual site only when they are approved. When the
user passes the authentication and authorization, authorization requests will be sent to the
administrators for approval and the status of the client is “Pending”. When the Aggregation option

is enabled for the group, administrators can configure the Hardware ID rule to authorize the users
of this group to use this client to access the virtual site. When the Aggregation option is disabled
for the group, administrators can configure the Hardware ID rule to authorize only a specified user
in the group to use this client to access the virtual site. The collected hardware ID values can
match the Hardware ID rules in three modes:
 “mac_any”: A Hardware ID rule will be matched when any client’s MAC address hits a
MAC address in the rule.
 “mac_all”: A Hardware ID rule will be matched when all the client’s MAC addresses hit the
MAC addresses in the rule and the number of the client’s MAC addresses is equal to that of
the MAC addresses in the rule.
 “machineid”: A Hardware ID rule will be matched when the client’s MachineID hits the
MachineID in the rule. MachineID is a combination of MAC, CPU ID and OS ID of the
client.
To reduce the workload of administrators, Hardware ID Authorization supports the Auto Approve
option for the LocalDB group, which enables the virtual site to set the status of the client used by
users in the group to “Approve” automatically.
What’s more, administrators can set the limits of clients that a LocalDB user or group can use.
Hardware ID Authorization can also be integrated with LocalDB and other several third-party
authorization servers (such as LDAP and RADIUS). Please note that the external groups need to
be mapped to LocalDB groups for this function.
 Configure Hardware ID Authorization
Under the virtual site scope, select Local Database > Login Authorization > Hardware ID >
General Settings, as shown in Figure 4–35.
In the General Settings area, specify the parameters Enable AAA Hardware ID, Initiation
mode for Hardware ID authorization, Automatically choose available initiation mode,
Notification Email Address and Hardware ID Limit (Per User) as required.
In the Hardware ID Authorization (Group Settings) area, select the Enable check box of one
group entry, then specify the parameters ID Type, Auto Collect, Auto Approve, Aggregation
and Hardware ID Limit as required.

Figure 4–35 Hardware ID Authorization
 Download the Hardware ID Generator Tool
Click one of the Download Now action links in the Hardware ID Generator Tool area to
download the Hardware ID Generator tool for PCs running a specified OS, as shown in Figure
4–35.
 Configure Hardware ID Rules
Under the virtual site scope, select Local Database > Login Authorization > Hardware ID >
Authorization Requests, select the Add action link to add an authorization request, as shown in
Figure 4–36.

Figure 4–36 Authorization Requests
In the Add Authorization Policy configuration window, specify the parameters Hardware ID,
Category, User/Group Name, Status and Host Name, as shown in Figure 4–37.
Figure 4–37 Add an Authorization Request
Specify the Category and Status dropdown lists and the Search Keyword parameter to filter the
Hardware ID authorization requests, as shown in Figure 4–38.
Figure 4–38 Hardware ID Authorization Request List
Select a specific request entry, then select the Approve or deny action link to update the request
status, as shown in Figure 4–39.
Figure 4–39 Update the Request Status
4.2.2 AAA Method

AAA method specifies the AAA server(s) used for authentication and the AAA server
authorization. For example, the administrator can define the AAA method that uses an LDAP
server for authentication and uses LocalDB for authorization.

4.2.2.1 Multi-factor Authentication
To enforce stricter security checks on users and ensure a higher level of security for the virtual site,
AG allows the administrator to configure multiple authentication servers for a single AAA method
to support multi-factor authentication (mutual username and multiple passwords). The user can
successfully logs into the virtual site only after passing authentication from all authentication
servers.
A maximum of three authentication servers are allowed for one AAA method. These three
authentication servers can be of the same type or different types.
Figure 4–40 Multi-Factor Authentication
The preceding figure shows the workflow of multi-factor authentication (two authentication
servers):
1. The user arrives at the Web portal of the virtual site where credential input is required.
2. The authentication server 1 checks the entered user credential for this server.
3. If the credentials are rejected by server 1, login fails.
4. If the credentials are accepted by server 1, the authentication server 2 checks the entered user
credential for this server (for example, the authentication server with the next highest
priority).
5. If the credentials are incorrect, AG prompts the user to enter the credential again.
6. If the credentials are correct, AG displays the successful login page for the user.
Note: For multi-factor authentication, the first set of user credential will be used for the
SSO function.
4.2.2.2 Authorization
During the authorization process, AG will obtain authorization data from the authorization server,
such as group information, external Access Control Lists (ACLs), external subnet/Netpool.

These authorization data will be further used for resource assignment and access control. For more
information, please refer to section 5.1 Role and 5.2 ACL.
4.2.2.3 Configuration Example
Under the virtual site scope, select Site Configuration > AAA > Method, and click the Add
Method button in the Method area, as shown in Figure 4–41.
Figure 4–41 Method
In the Add Method Configuration area, specify the Method Name and Method Description
parameters, select specific AAA server(s) for authentication and a specific AAA server for
authorization, and click the Save action link, as shown in Figure 4–42.
Figure 4–42 Add a AAA Method
Note: When authorization of a AAA method is set as “NONE”, the user group
information will not be retrieved by AG. In this case, the user role with condition of
“Group Name” type and ACLs configured for the group will not be matched to the user
who logs into the virtual site using this AAA method.
4.2.3 AAA Method Rank

If the customers have several AAA servers and user credentials are stored on these AAA servers
in a distributed manner. AG allows the administrator to define several AAA methods for a virtual
site so that the users can select the AAA method before they log into the virtual site.

However, sometimes the administrator does not want the users to know what authentication
methods are used by the virtual site, or the users do not care about which AAA method that the
virtual site adopts for authentication. AG uses the Rank function to can arrange these AAA
methods together and hides the choosing AAA method option. After the users enter their
credentials, AG will try to perform AAA with the arranged methods from the highest priority the
lowest priority. Once the credential is verified using one AAA method, the AAA methods with
lower priorities will be omitted and the user passes AAA checking.
Rank supports defining the priorities for a maximum of four AAA methods. The following figures
show the login pages when Rank is disabled and enabled.
Figure 4–43 Rank Disabled
Figure 4–44 Rank Enabled
Note:
 AAA methods, servers and rank settings are configured on a per-virtual-site basis.
All the “AAA” related commands should be executed in the scope of the targeted
virtual site. Therefore, administrators need to switch to the virtual site by using the
command “switch <virtual_site>” in advance.
 If the AAA feature is disabled for a given virtual portal, all users may access that
portal without going through a login page. Instead, users are immediately redirected
to the portal home page as a “guest” user. Their authorized ACLs will be determined
by the username “guest” and their assigned roles (based on username “guest”, client

IP address or access time).
Under the virtual site scope, select Site Configuration > AAA > Rank, select the Rank Enable
check box, and specify parameters Rank 1 to Rank 4, and click the Apply Changes button to
save the configurations, as shown in Figure 4–45.
Figure 4–45 Enable Rank
4.2.4 Accounting
The Accounting service is only supported on RADIUS servers. With RADIUS Accounting
services, AG will log all START and STOP records for each session. The START record is sent
once the user has been authenticated. The STOP record is sent when the user’s session is
terminated. Sessions can be terminated due to user logout, timeout (lifetime or session) or
explicitly terminated by administrators by using the session kill feature.
Note: RADIUS accounting only tracks the START and STOP records, while the logging
feature of AG records other activities of the session. If the RADIUS server does not
respond to the “start” request, the authentication will fail.
Under the virtual site scope, select Site Configuration > AAA > Accounting, select the Enable
RADIUS Accounting and Allow Access If Accounting Fails check boxes, specify the RADIUS
Server Name parameter in the RADIUS Accounting Settings area, and click the Apply Changes

Figure 4–46 Configure RADIUS Accounting
4.3 Configuration Example

The following table describes a typical AAA deployment example.
Table 4–1 Typical AAA Deployment Example
Rank Method Authentication Server Authorization Server
1 method1 LDAP+LocalDB LDAP
2 method2 RADIUS+LocalDB RADIUS
3 method3 LocalDB LocalDB
The following configuration examples are all based in this AAA deployment example.
4.3.1 Enable AAA

Make sure that the AAA feature is enabled. If the AAA feature is disabled, perform the following
step to enable it:
Under the virtual site scope, select Site Configuration > AAA > General, and check the Enable
AAA check box, as shown in Figure 4–47.
Figure 4–47 Enable AAA
4.3.2 Configure AAA Servers

Add local accounts and groups and enable the LocalDB server according to section 4.2.1.1.1
Configuration Example.
Add the LDAP server named “ldap1” according to section 4.2.1.2.4 Configuration Example.
Add the RADIUS server named “radius1” according to section 4.2.1.3.1 Configuration Example.

4.3.3 Configure AAA Methods

Add three AAA methods named “method1”, “method2” and “method3” respectively according to
section 4.2.2.3 Configuration Example, as shown in the following figures.
Figure 4–48 Add method1

4.3.4 Configure AAA Method Rank

Configure the Rank settings for three AAA methods according to section 4.2.3.1 Configuration
Example, as shown in Figure 4–51.
Figure 4–51 Configure Rank

Chapter 5 User Policy
5.1 Role
AG user roles are used to authorize authenticated users with resources based on specific
qualifications, such as login time, username, group name, source IP address and selected AAA
method, thus achieving accurate, fine-grained and flexible resource assignment.
Before accessing any resources provided by the virtual site, the user must obtain at least one role.
Otherwise, AG will log out the user from the virtual site and request the user to log into the virtual
site again. When obtains one or more role, the user will be authorized with the resources that are
assigned to the roles. AG supports displaying the links to the authorized resources (usually Web
and File Share resources) on the Web portal after the user successfully logs into the virtual site.
5.1.1 Role, Qualification and Condition

Users can obtain a role only when meeting a specific qualification that further contains one or
more conditions. AG allows the administrator to define multiple qualifications for a role and
multiple conditions for a qualification. Users can meet a role condition only when meeting all
conditions under a qualification and obtain the role when meeting any one of the role
qualifications.
The conditions under a qualification describe the following user characteristics:
 Login Year
 Login Month
 Login Day
 Login Time
 Login Date
 Login Week
 Username
 Group Name
 Source IP
 AAA Method

Figure 5–1 Role, Qualification and Condition
The above figure shows the overall process of the user role qualification when authorizing a large
quantity of login users. There are two qualifications, and each contains one condition:
 Qualification 1 condition: User group is “engineer”;
 Qualification 2 condition: The source network is “10.10.30.0/24”.
According to the preceding figure, the following results will occur:
 Users from the “Engineer Group” match the Qualification 1 condition “group = engineer”,
and therefore obtain the role “Engineer”.
 Users on the network “10.10.30.0/24” match the Qualification 2 condition “network =

10.10.30.0/24” and therefore obtain the role “Sales”.
 Users match neither the Qualification 1 condition nor the Qualification 2 condition cannot
obtain any role and therefore cannot access any resources via AG.
Note:
 The administrator can define multiple conditions in one qualification. The

relationship among these conditions is “AND”. The administrator can bind multiple
qualifications to one role. The relationship among these qualifications is “OR”.
 Administrators can define a catch-all qualification without any conditions. Roles
defined with this type of qualification will be assigned to any authenticated user.
5.1.2 Role Resources

The following types of resources can be assigned to a role:

 WRM
 QuickLink
 Netpool
 VPN resource group
 Common Internet File System (CIFS)
To assign resources to a role, the administrator needs to associate the resources with the role.
WRM and QuickLink role resources are all Web role resources. When the user obtains a role with
Web role resources, the links to these Web resources will be displayed on the Web portal. When
clicking this link, the user will be directed to the Web page of this Web resource.
Note: For details about QuickLink and WRM, please refer to the section 6.1 Web Access.
A Netpool role resource associates a role with a VPN Netpool that contains the configuration used
for VPN network access, such as IP range.
A VPN resource group associates a role with a VPN resource group that contains application-type
and network-type VPN resource items.
On when the user are authorized with both the Netpool role resource and VPN resource group, a
button for connecting to VPN will be displayed on the Web portal. When the user clicks the button,
the VPN tunnel will be established between the user client and the AG. Data transmitted between
the client and destinations indicated by the VPN resource group is encrypted by the VPN tunnel.
Note: For more details about Netpool and VPN resource group, please refer to section 6.2
Network Access and Array Client.
A CIFS resource associates a role with a folder shared by a backend host that running the CIFS
protocol. When clicking on this link, the user with this role can view all the files in the shared
folder. The permissions of this role on the shared folder depend on the permissions on the shared
folder set on the backend host.
Note: For details about CIFS, please refer to section 6.3 File Share.
The system provides an “auto-generation of ACL permit configurations” option for the WRM,
QuickLink, and CIFS role resources. If this option is enabled when a WRM, QuickLink, and CIFS
role resource is added, the system will automatically generate an ACL resource, add the ACL
resource to an auto-generated resource group, and generate an ACL permit rule with the priority
200. The auto-generated resource group is named “auto_web_resgroup_for_<role_name>” for the
WRM or QuickLink role resource, and “auto_fileshare_resgroup_for_<role_name>” for the CIFS

role resource. The auto-generated ACL permit configurations cannot be deleted manually. Instead,
they can only be deleted automatically when the specified role resource is deleted.
The following figure shows the process of the role resource.

Figure 5–2 Role Resource
5.1.3 Working Process of User Role
Figure 5–3 User Role Working Process
The preceding figure shows the working process of the user role function:
1. The end user logs into the Web portal of the virtual site;

2. The username and password are sent to the AAA server for authentication. If authentication
fails, the end user will be asked to log in again. If authentication succeeds, the AG appliance
will proceed to assign a role to the authenticated user.
3. There are several roles pre-defined by administrators on the AG appliance, and each role is
defined with several qualifications.
4. To be assigned a role, the user’s information needs to match at least one of the qualifications
defined for the role. If the user’s information does not match any qualification, the user will
see the login error prompt message and be redirected back to the login page.
5. Once being assigned with the role(s), the user is authorized with resources assigned to the
role(s). In this example, the role is associated with two Web resources: Resource Link A and
Resource Link B.
6. The AG appliance will further use ACLs matching the user to filter the authorized resources.
According to the configured ACL rules, Resource Link A will be allowed while Resource
Link B will be denied. Therefore, only Resource Link A is authorized to the user.
7. At last, Resource Link A will be displayed on the Web portal for the end user to access.
5.1.4.1 Role Settings
 Add a Role
Under the virtual site scope, select User Policies > Role > Role, enter the Role Name and
Description (optional), and click the Add a Role button, as shown in Figure 5–4.
Figure 5–4 Add a Role
 Add a Role Qualification
Under the virtual site scope, select User Policies > Role > Role Qualifications, and click the Add

Figure 5–5 Role Qualification List
drop-down list, enter the name of Qualification, and Description (optional) and specify the
condition settings in the Type, and Action drop-down lists and the Content text box, as shown in
Figure 5–6.
Figure 5–6 Add a Role Qualification
For example, the role condition for login during work time can be defined as shown in Figure 5–7.

Figure 5–7 Condition-Login Time
After clicking the Add button, the role condition will be added, as shown in Figure 5–8.
Figure 5–8 Added Condition-Login Time
After defining all parameters in the Add Role Qualification area, please click the Save button on
the upper right corner to save the configuration.
5.1.4.2 Role Resources
 Add a QuickLink Type of Role Resource

Under the virtual site scope, select User Policies > Role > Role Resource > Web, click the Add
action link in the QuickLink Resources area to assign a QuickLink resource to a defined role, as
Figure 5–9 Add the Web Resource
In the Add QuickLink Resource configuration window, select a defined role from the Role
Name drop-down list, select a previously defined QuickLink policy from the Resource ID
drop-down list, specified the parameters Display Name, Path and Position as needed, select the
Enable Auto Generate ACL Permit Configurations and Enable Frontend SSO check boxes if
required, and click the Save action link to assign the QuickLink resource to the role, as shown in
Figure 5–10.
Figure 5–10 Add the QuickLink Resource
 Add a WRM Type of Role Resource
action link in the WRM Resources area to assign a WRM resource to a defined role, as shown in
Figure 5–9.

In the Add WRM Resource configuration window, select a defined role from the Role Name
drop-down list, specify the parameters URL, Display Name and Position, select the Enable Auto
Generate ACL Permit Configurations, Direct link and Enable Frontend SSO check boxes as
required, and click the Save action link to assign the WRM resource to the role, as shown in
Figure 5–11.
Figure 5–11 Add the WRM Resource
 Add VPN Role Resource
Please select User Policies > Role > Role Resource >VPN under the virtual site scope and click
the Add button in the Netpool Resources area to assign a Netpool to a defined role, as shown in
Figure 5–12.
Figure 5–12 Add the VPN Resource
In the Add Netpool Resource configuration window, select the role name and Netpool name from
the Role Name and Netpool Name drop-down lists, and click the Save button to assign the
Netpool to the role, as shown in Figure 5–13.

Figure 5–13 Add the Netpool Resource
For the functioning of the VPN resource, a VPN resource group also needs to be assigned to the
role. Select User Policies > Role > Role Resource > VPN under the virtual site scope and click
the Add button in the VPN-Resource-Group Resources area to assign a VPN resource group to
the role, as shown in Figure 5–12.
In the Add VPN-Resource-Group Resource configuration window, select the role name and
group name from the Role Name and Group Name drop-down lists, and click the Save button to
assign the VPN resource group to the role, as shown in Figure 5–14.
Figure 5–14 Add the VPN-Resource-Group Resource
 Add a CIFS Type of Role Resource
Please select User Policies > Role > Role Resource > CIFS under the virtual site scope and click
the Add button in the CIFS Resources area to assign a CIFS resource to a defined role, as shown
in Figure 5–15.
Figure 5–15 Add the CIFS Resource
In the Add CIFS Resource configuration window, select a role name from the Role Name
drop-down list and specify the parameters URL, Display Name and Position, select the Enable
Auto Generate ACL Permit Configurations check box and click the Save button to assign the
CIFS resource to the role, as shown in Figure 5–16.

Figure 5–16 Assign the CIFS Resource
5.2 ACL
5.2.1 ACL
Access control list specifies which users, groups or role are granted to access to specific resources.
These ACL rules are applied to a user as the user accesses contents through the virtual site. ACLs
support permission control on three types of resources: Web application (HTTP/HTTPS), Network
(IP/TCP/UDP/ICMP), and File Share (CIFS). For more information about these resources, refer to
Chapter 6 Access Method.
ACLs can be configured for users, user roles, or user groups. When accessing a virtual site, the
user will get the combination of all the ACLs configured for the user, roles that are assigned to the
user, and the groups to which the user belongs. All the ACLs for the user will be stored in the user
session according to descending order of the priority.
ACLs are associated with a session upon successful authentication and cannot be updated or
changed during the session lifetime. Therefore, if the administrator changes any ACL for a user
currently logged in (an active session), the changes will not be applied to that user until the user
logs out of the current session and logs back to start a new session.
If the user’s session matches no ACL that is associated with the specified virtual site, the user will
be allowed to have unrestricted access to all Web, File Share and VPN resources through the
virtual site. If the user’s session matches one or more ACLs that is associated with the specified
virtual site and applies to some or all resources of the same type (Web, File Share, or VPN), the
AG appliance will deny the user’s access to resources of the same type that are not specifically
permitted by the ACLs.
5.2.2 ACL Resources

The administrator can define three types of ACL resources: Web resources, network resources,
and file share resources.
 A Web resource is a Layer 7 resource such as “http://*.domain.com/public/*” or

“https://www.domain.com:443/*”.

 A network resource is a Layer 3 or 4 resource such as “udp://10.1.1.1:25”,

“tcp://10.1.1.0/24:25, 1080, 2200” or “10.10.1.1/24”.
 A file share resource is a CIFS (DFS) resource such as “\\10.3.0.255\test” and

“\\Intranet\Employees\*”.
A resource group is an object that can contain one or more resources of the same type. An ACL
rule has the ability to permit or deny a role, user or group from accessing specific resource group.
Note: You are advised not to configure more than 1000 ACL resources of the file share
type. When a user matches 1000 or more ACL resources of the file share type, the user
may not be able to access any permitted file share resource.
Figure 5–17 ACL Rule
5.2.3 External ACL

AG supports external ACLs stored on the LDAP or RADIUS server. External ACLs are used to
check whether the user can access the requested resources in precedence to ACLs configured on
the AG appliance. The AG appliance will use configured ACLs only when the user’s session
matches no external ACL.
Two types of external ACLs are supported.
The first type of external ACL applies to Web and File Share traffic and its format is as follows:
<priority> <scheme>:<host><path> [AND <virtual_site_id>] {PERMIT|DENY}
The following table describes the meaning of every field.

Field Meaning
This field specifies the priority to the ACL. The lower the value, the
higher the ACL priority. The ACL with highest priority determines
priority
whether to permit or deny a request when the request matches
multiple ACLs.
This field can only be “http” or “file”.
 “http” indicates that this ACL applies to Web requests
scheme (including HTTP and HTTPS).
 “file” indicates that this ACL applies to the File Share requests
(CIFS).
This field specifies the IP address or name of the backend Web or
host CIFS server. The wildcard “*” is supported in the front of the host
name, to match one or more characters.
This field specifies the requested web path or file share path on the
backend Web or CIFS server. The path must consist of at least one
path
forward slash (/) character. If the requested path begins with the
“path” field of an ACL, the requested path matches the ACL.
This field specifies the name of the virtual site with which this ACL
virtual_site_id is associated. “ALL” indicates that this ACL is associated with all
virtual sites.
This field permits or denies the Web or CIFS requests to the
PERMIT|DENY
backend Web and CIFS server.
The second type of external ACL applies to VPN traffic and its format is as follows:
<priority> ip <protocol>:<host_ip>[/<netmask>][:port] [AND <virtual_site_id>]

{PERMIT|DENY}
The following table describes the meaning of every field.
Field Meaning
This field specifies the priority to the ACL. The lower the value, the
higher the ACL priority. The ACL with highest priority determines
priority
whether to permit or deny a request when the request matches
multiple ACLs.
ip “ip” is the fixed value for this field.
This field can only be:
 “tcp”: indicates that this ACL applies to TCP VPN traffic.
 “udp”: indicates that this ACL applies to UDP VPN traffic.
protocol
 “icmp”: indicates that this ACL applies to ICMP VPN traffic.
 “*”: indicates that this ACL applies to all VPN traffic including
TCP, UDP, ICMP, and other IP-based traffic.
This field specifies the IP address of the host or network to which
host_ip
the ACL applies. It can only be an IPv4 address.
This field specifies the netmask of the host or network to which this
netmask
ACL applies. It can be a dotted IP address or an integer. If it is an

Field Meaning
integer, its value should range from 0 to 32. If it is not specified,
“255.255.255.255” will be used.
This field specifies the port number to which this ACL applies. Its
port value can be a single port or a port range, such as 60-70. If it is not
specified, this ACL will apply to all ports.
This field specifies the name of the virtual site with which this ACL
virtual_site_id is associated. “ALL” indicates that this ACL is associated with all
virtual sites.
PERMIT|DENY This field permits or denies the VPN packets to the host or network.
5.2.4 Dynamic ACL

The Dynamic ACL function allows the AG appliance to accept the dynamic ACLs generated by
the clients. When receiving the request for a virtual site, the AG appliance first uses external
ACLs for matching. If the request matches no external ACL, the AG appliance then uses the
configured ACL rules for matching. If the request matches no configured ACL rule, the AG
appliance finally uses dynamic ACLs for matching.
The matched dynamic ACLs will be effective during the session lifetime. When the user logs out
the virtual site, the session’s dynamic ACLs will be cleared.
By default, this function is disabled, indicating that the AG appliance will not match the request
with dynamic ACLs.
5.2.5.1 Configure ACL Rules
 Add an ACL Rule for the Role
Under the virtual site scope, select User Policies > ACLs > Basic ACL > ACL Rules, click the
Add action link in the ACL Rules area to add an ACL rule, as shown in Figure 5–18.

Figure 5–18 ACL Rules for the Role
In the Add ACL Rule area of the displayed window, select the Role Name radio button behind
ACL Target, select the desired role from the Role Name drop-down list, specify the Action as
permit or deny, and specify the Priority parameter. To define a new resource group, specify the
parameters Resource Group, Description, Resource Type and Resource List, and click the
Save action link, as shown in Figure 5–19.

Figure 5–19 Add an ACL Rule for the Role
 Add an ACL Rule for the User
Figure 5–20 ACL Rules for the User
In the Add ACL Rule area of the displayed window, select the User Name radio button behind
ACL Target, specify the User Name parameter, specify the Action as permit or deny, and
specify the Priority parameter. To define a new resource group, specify the parameters Resource
Group, Description, Resource Type and Resource List, and click the Save action link, as shown
in Figure 5–21.

Figure 5–21 Add an ACL Rule for the User
 Add an ACL Rule for the Group
Figure 5–22 ACL Rules for the Group
In the Add ACL Rule area of the displayed window, select the Group Name radio button behind
ACL Target, specify the Group Name parameter, specify the Action as permit or deny, and
specify the Priority parameter. To define a new resource group, specify the parameters Resource
Group, Description, Resource Type and Resource List, and click the Save action link, as shown
in Figure 5–23.

Figure 5–23 Add an ACL Rule for the Group
5.2.5.2 Enable Dynamic ACL
Under the virtual site scope, select User Policies > ACLs > Advanced ACL > Dynamic ACL,
select the Enable Dynamic ACL check box in the General Settings area, then click the Apply
Changes button, as shown in Figure 5–24.
Figure 5–24 Enable Dynamic ACL
5.3 User Session Management

Session Management is a way for AG to control the usage of the device. The session between the
client and the AG records several important user information such as username, role name, the
type of the session, L3 required IP or connection parameters, etc.
AG allows the administrator to monitor, terminate, reuse and limit user sessions.

5.3.1 Session Statistics

Through session management, the active sessions can be listed in the order by which they have
been created. And, the administrator can run the “show session active” and “show session policy”
commands to see the following session statistics:
Table 5–1 Session Statistics
Statistics Information Description

User name The username of this session.
Session ID The session ID. If session reuse is turned on, some statistic records
may have the same session ID.
Session Age The remaining time of the session since the session was created.
Last active time The remaining time of the session since the user’s last operating
time.
The status of the session:
 Authenticated means the user has already been
authenticated.
 Challenge means the user is being authenticated through the
RADIUS server.
 Change password means the user is authenticated through
Authentication status
the LocalDB, and is changing his password.
 SMS means the user is being authenticated through the SMS
server.
 SMX means the user is being authenticated through the SMX

server.
Role name The role which the authenticated user is assigned with.
The ACL group information, like the ACL action, the ACL
ACL group info
priority, the ACL group type.
5.3.2 Session Timeout

The administrator can manage the expiration of authenticated and unauthenticated sessions
separately.
For authenticated sessions, the administrator can configure them to expire in two ways:
 Idle expiration: makes the session expire when the session remains idle for the permitted time
(configured by using the command “session timeout idle”).
 Lifetime expiration: makes the session expire when the session has lived for the permitted
time (configured by using the command “session timeout lifetime”).
For unauthenticated sessions, the administrator can configure them to expire in the lifetime
expiration way. The expiration time is configured by using the command “session timeout
unauth”.

Note:
 If the administrator sets both types of expiration time at the same time, the
authenticated session will be terminated based on whichever expiration times out
first.
 Unauthenticated sessions here include challenge and change-password sessions.
The administrator can also manually close a session by using the command “session kill”.
5.3.3 Session Timeout Warning

The administrator can enable the Session Timeout Warning function for the virtual site so that
users will be warned prior to idle session timeout or lifetime session timeout. When this function
is enabled, the administrator can set the amount of time that users will be warned prior to session
idle timeout and session lifetime timeout by using the command “session timeout warning
threshold”.
 Idle timeout warning: When being warned of the session idle timeout, the user is provided
with option to reset the session idle timeout timer.
 Lifetime timeout warning: When being warned of the session lifetime timeout, the user is
provided with the option to extend the session lifetime. The amount of time by which the user
can extend the session lifetime manually each time can be configured using the command
“session timeout warning extension_lifetime”.
5.3.4 Session Reuse

There are two parameters to control how sessions are managed: AAA on/off and session reuse
on/off.
When the AAA feature is turned on, the session reuse feature can be used.
When the session reuse feature is enabled for a virtual site, all the users going to that virtual site
via the same username will share the same session. If one of these users closes the session, all the
other users should log in again to continue their connections. And this function works per virtual
site.
When the session reuse feature is disabled, multiple users from different clients will have their
own sessions.
When the AAA feature is turned off, system will generate “guest” session for every end user that
tries to access the virtual portal of AG. Under this condition, the session reuse feature must be
turned off.
Note: The session reuse feature can only be set under the global level.

5.3.5 Session Limit

AG limits the total number of sessions allowed via the session license. Administrators can
distribute the number of licensed sessions among groups or virtual sites.
Session License is used to limit the total number of the sessions. If the number of the sessions has
reached the limitation defined in the session license, new users cannot create new sessions. When
the AAA feature is on, the max session number will be controlled by “licensed session number”.
When the AAA feature is off, system will generate “guest” session for every end user that tries to
access the virtual portal of AG and the max “guest” session number will be controlled by
“licensed session number”.
The Pre-Paid Flex Licensing allows temporary session usage to exceed the base license
allotment of user sessions. The Flex License is comprised of “Credits”. A “Credit” is made up of
the maximum number of sessions per day (24 hour period) on the pre-paid flex license and the
number of days (individual 24 hour periods). Whenever the Flex License feature is enabled,
anytime that the base license session limit is reached, a “Credit” will be initiated when the first
session request (above the base limit) is authenticated allowing additional sessions for 24 hours
(up to the maximum as set by the purchased license). For example, the AG can be licensed for 2
users and also have the ability to automatically enable the flex license to swell to 27 users on
demand (2 standard users and 25 on-demand flex users). Please contact Array sales representative
to order Flex Licenses or additional permanent licenses.
Session Limit Group allows the administrator to create a group object with a set session limit.
One or more virtual sites may be added to this group. These virtual sites share the session limit as
a group. So, if the total combined number of the sessions for all the virtual sites reaches the group
session limit, new users cannot create new session on any of the virtual sites.
Session Limits maintains a per-virtual site counter of the number of active sessions. If a user tries
to log in and the number of active, non-expired sessions is less than the allowed limit for the
virtual site, a new session will be created and the session counter for the virtual site will be
increased. Anonymous sessions will not be counted.
Session Limit User allows the administrator to limit the number of concurrent sessions allowed
per user. If the number of sessions reaches the user session limit, the user cannot create new
sessions any more.

This section will illustrate how to configure session security settings and manage active sessions
in the system.
 Configure Session Security Settings
Under the virtual site scope, select Site Configuration > Security Settings > Sessions, and then
specify the parameters Session Limit per User, Idle Session Timeout, Maximum Session
Lifetime and Unauthenticated Session Lifetime in the Basic Session Settings area. Select the

Enable Session Timeout Warning check box and specify the parameters Warning Threshold
for Session Idle Timeout, Warning Threshold for Session Lifetime Timeout and Session
Lifetime Extension Each Time in the Session Timeout Warning Settings area if required.
Select the Pass Session Cookie to Origin Server and Expire Session Cookie check boxes in the
Session Settings area if required and click the Apply Changes button, as shown in Figure 5–25.
Figure 5–25 Configure Session Security Settings
 Manage Active Sessions
For active sessions, you can check the status of the sessions or terminate specified sessions via
Admin Tools > Session Management > Active Session under the virtual site scope, as shown in
Figure 5–26. You can also search the session information based on specified username.
Figure 5–26 Active Session Management
Please select Admin Tools > Session Management > Session Policy to check more detailed
information of the sessions, as shown in Figure 5–27.
Figure 5–27 Active Session Information
To view sessions matching external ACLs, in the Session with External ACL area of Admin
Tools > Session Management > Session with External ACL, optionally specify parameters
Session Type, Session User Name, Start of Display Range and Display Amount, and click the
Search button, as shown in Figure 5–28.

Figure 5–28 Session with External ACL

Chapter 6 Access Method

AG supports three kinds of access methods: Web Access, Network Access, and File Access. Web
Access applies to Web applications browsing HTTP/HTTPS resources, while Network Access
applies to all IP applications. Web Access does not require any client software or browser plug-in
components, while for Network Access, the initial deployment requires the installation of client
software (Array Client). Two launching methods are supported for Network Access: Web Launch
and Standalone Launch. API (Application Programming Interface) is provided for calling the
Array Client. File Access applies to sharing files on backend servers of the Intranet. Remote users
can access the shared files by using AG-compatible browsers without installing any client
software or browser plug-in components.
6.1 Web Access

Web applications are applications that provide clientless and seamless user experiences in
browsing the Web contents. AG provides users with two different ways to access internal
resources typically hidden from the outside network. The first way, called QuickLink, uses a
unique hostname or a unique port to represent the backend web server with a one-to-one mapping
between internal resources and public resources. The second way, called Web Resource Mapping
(WRM), provides an algorithm to automatically rewrite the URL of the internal resource.
The Custom Rewrite feature provides flexible configurations for non-standard Web programming,
application security flaws, new technology and other reasons.
The URL Policy provides the administrator with the options to define which resources need to be
accessed through AG, which resources should not be accessed through AG and which resources
can be accessed without authentication.
Some clients have the need to hide their internal network architecture for safety reasons. AG
provides users with the function to mask the internal URL with the URL Masking sub feature of
the WRM method.

Figure 6–1 Web Application
The above figure illustrated how Web Application works:
1. Remote user logs in the virtual site portal page.
2. User’s request for internal resources will go through AG to the targeted backend server.
3. Internal users accessing the internal resources will not need to go through AG.
6.1.1 QuickLink
QuickLink is a clientless access method that provides AG users with instant access to Web content
originating from the internal network (often from servers that are not exposed to the external
network). Rather than doing full content parsing and rewriting, QuickLink uses a unique hostname
or a unique port to represent the backend Web server. This way parsing and rewriting are greatly
simplified and streamlined. When backend Web contents pass through AG, only absolute paths
with hostnames are rewritten to the configured unique hostname or port. This feature is a pure
Web-based SSL VPN solution requiring no plug-in and no client, making QuickLink platform and
browser neutral.
The features of the two QuickLink modes are:
 hostname: In this mode, the internal resources are mapped to a hostname.
 port: In this mode, the internal resources are mapped to a port of the virtual site.

Figure 6–2 QuickLink Deployment
For the hostname mode, in order to access a website hosted on Server 1, users will point their
browsers to http://server1.company.com. In this scenario, Server 1 is not directly accessible from
the Internet since it does not have a public IP address (this is often done for security reasons). The
QuickLink technology allows administrators to add a link to Server 1 on the vpn.company.com
portal page (or any other subsequent pages). When the user clicks that link, the request is sent to
the AG appliance and then forwarded to www.server1.com.
Some Web application may have binary objects embedded (for example, Java Applets, Flash or
ActiveX). If the binary has hard coded URLs such as “/dir/file.html”, QuickLink can support it.
However, hard coded absolute URLs such as http://webmail1.company.com/dir/file.html are not
supported by QuickLink.
Note: It is expected that QuickLink might not be able to handle certain cases due to
non-standard Web programming or new technologies; therefore it is recommended that
customers test their applications with QuickLink before deploying them.
Each published internal Web server or resource needs its own unique hostname or port. When
using the hostname mode, administrators need to make sure that the hostname can be resolved to
the AG’s virtual site IP address. It is recommended that administrators deploy a domain wildcard
certificate (or add the alternative names to the virtual site certificate) to avoid certificate alerts.
When using the port mode, the used ports must be permitted on the firewalls.
QuickLink supports the following features:
 ACL
 SSO (Single Sign-On)
 Client Certificates Authentication
 Certificate Forwarding
 Custom Rewrite
 Book Marking
 Portal Theme Configuration
 SharePoint
 OWA

Note:
 Limitations of the two modes are:
– For the hostname mode, administrators need to add DNS entries, for the
published hostname must be a recognized hostname;
– For the port mode, administrators need to open port on firewalls;
 Please do not add QuickLink resources in different modes in a virtual site, that is, all
the QuickLink resources in a virtual site can only be either in hostname mode or in
port mode.
 In some rare cases, a URL within a Webpage or the Location header (for redirection)
may include the port value even if it is the default port, (i.e.
http://host.company.com:80/page.html). In this situation, an alias rule will be needed
if http://host.company.com is configured for QuickLink access.
 Same hostnames with different ports are treated as two different Web servers. Two
separate QuickLink access links are needed to support them. For example:
http://host.company.com and http://host.company.com:8080.
 In QuickLink hostname mode, the QuickLink URL must have the same sub-domain
as the current QuickLink page.
 For the browser Internet Explorer, if the current page is the sub-domain of the virtual
site, then only the adjacent lower level sub-domain of the current page can be the
QuickLink URL on the current page.
 If multiple IP addresses are configured for one virtual site, for QuickLink hostname
mode please make sure the hostname can be redirected to the correct IP address via
DNS server.
 Port-mode QuickLink cannot work normally with the ISA server configured as the
outside proxy server on the end user’s browser, because ISA server does not support
non-standard SSL port (other than port 443).
OWA is a common deployment scenario of QuickLink. The configuration tips are as follows:
 The “rewritexml” option in the “portal quicklink rule” command is required for OWA
2003.
 Besides the “rewritexml” option, the “http cookie expire passthrough” and “urlproperty
mask wrm” commands need to be executed for the functioning of OWA 2010.
 Port-mode QuickLink does not support changing the language of OWA 2010. This is due to
the limitation with OWA 2010 that the port information is not passed while changing the
language setting. Language change of OWA 2010 works fine with the hostname-mode
QuickLink.

6.1.2 WRM (Web Resource Mapping)

Web Resource Mapping (WRM) is another clientless access method that allows AG users
instantly access to Web contents originating from the internal network (often from servers that are
not exposed to the external network).
Figure 6–3 WRM Deployment
Consider the deployment scenario discussed in the previous section for QuickLink. To access the
Web Mail, users will point their browsers to http://webmail1.company.com. The webmail1 server
is only directly accessible to users who are within the company’s network. The webmail1 server is
not accessible from the Internet. The WRM technology allows administrators to add a link to
webmail1 on the portal page that will be presented to users when accessing the virtual portal
vpn.company.com (or any other subsequent pages). The link http://webmail1.company.com will
be automatically rewritten (by the AG) to
https://vpn.company.com/prx/000/http/webmail1.company.com. The new link points back to AG
and therefore Internet user’s requests will be sent to AG and then forwarded to the actual
webmail1 server.
Since WRM is clientless, there are no platform restrictions or requirements. It is easy to setup and
requires no administrator privileges. With this technology, links embedded within the
HTML/JavaScript content are rewritten so that the client side HTTP requests are sent to the virtual
portal instead of to internal servers directly. In essence, this allows administrators to hide the
internal network architecture by only exposing one domain and IP address to the public Internet.
Web Resource Mapping does not rewrite embedded URLs within PDF or Microsoft Office files
(including Word, Excel, PowerPoint, etc.). Therefore it is recommended that relative URLs be
used within these types of documents whenever possible.
WRM transforms internal URLs into external URLs using the following format:
https://<virtual_portal>/prx/000/<scheme>/<internal_URL>
 <virtual_portal> is the FQDN of the virtual portal;
 <scheme> is “http” or “https”;

 <internal_URL> is the original URL (host and path).
For example, “http://server.company.com/” will be translated into

“https://sp.company.com/prx/000/http/server.company.com/”.
When the end user clicks on the translated link, the request will be sent to AG to be checked
against existing ACL or other access rules before forwarding the request to the internal network
location.
Web Resource Mapping will rewrite the following items:
 HTTP Responses
 HTML – All tags with attributes containing URLs
 JavaScript
 Cascading Style Sheets (CSS)
 HTTP Cookies
Web applications that use embedded Java applets, Flash or ActiveX elements must be routed
through port 433 for HTTPS and port 80 for HTTP schemes since they are not really using HTTP
to communicate with backend servers.
Note: It is expected that WRM might not be able to handle certain cases due to
non-standard Web programming, new technologies and other circumstances. Therefore, it
is recommended that customers test their applications with WRM before deploying them.
Web contents not supported by WRM include :
 Pre-compiled code in HTML
 UTR-16 encoding
 Absolute URLs in XML files
 Non-ASCII characters in JavaScript
 Unpaired comments in JavaScript code
 JavaScript files larger than 500KB are not recommended
 Absolute URLs in client-side VBScript.
 ActiveX that makes network calls (socket)
 Flash object files with URLs or TCP network calls defined in them
 VBScript with absolute URLs
 URL Masking

The URL masking feature is for concealing the internal architecture from the clients for safety
considerations. With URL masking, the URL will be rewritten with a pre-set algorithm to hide the
protocol, file name and file type after standard rewriting of URLs by WRM.
The function to rewrite relative URLs must be enabled in order to enable URL masking.
For example, the URL “http://www.sina.com.cn” will be masked as

“https://virtualsite_domain_name/prx/00/54xr/3TAk11slMsAnwnr_/
6.1.3 Custom Rewrite

AG supports the Custom Rewrite feature which provides a way to work around WRM issues
caused by non-standard Web content (for example, non-standard Web programming, new
technology, etc.). There are two methods of custom rewrite: pre-rewrite and post-rewrite.
Pre-rewrite rewrites the Web contents before standard rewrite, while post-rewrite means rewrite of
the Web contents after standard rewrite. In both cases, standard rewrite means formal rewrite
operation of the Web contents.
The common deployment scenario is in the case of rewrite errors. In this way, the administrator
can configure a pre/post customizable CLI to manually rewrite the faulty Webpage.
6.1.4 URL Policy

By default the Web application will rewrite all the URLs embedded on a given page, even if the
URL points to a location that is “public” and requires no special security considerations. For
example, a company portal page may include a link to the company’s public Website (for example
www.arraynetworks.com). There is no reason for remote users to access www.arraynetworks.com
through the AG appliance. Using URL policies, it is possible to instruct the AG appliance to
redirect users so that they directly access the URL www.arraynetworks.com without going
through the AG appliance.
AG offers three types of URL policies:
 Internal—The URL should be accessed through the Web application.
 External—If a URL is classified as external according to the URL Policies, AG will redirect
the end users browser to the publicly available Web content without proxying the request to a
backend server. The URL should not be accessed through Web Application.
 Public—The URL is accessed via Web application but does not require authentication.
Public URL policies should be used with care, for the obvious reason that they provide
unrestricted access to internal content. The common use for public URL policies is to provide
public access to content embedded in custom login pages, logout pages, and error pages.
URL policies should be assigned with priorities. The priority should be an integer ranging from 0
to 65535. This value specifies when this policy will be applied to a request relative to the other
configured policies. For instance, if a policy has, priority 0, it will be applied to a requested URL
before a policy with priority 1. If a URL matches more than one policy, the matching policy with

the highest precedence (i.e. lowest priority number) will be used to determine whether the
requested is internal, external, or public.
For the administrator cannot define all possible URLs, the setting of default URL policy is
necessary. If the default policy is “external”, then all Web content is assumed to be external,
unless it matches a configured internal policy. If the default policy is "internal", then all Web
content is assumed to be internal unless it matches a configured external policy. By default, the
default URL policy is internal.
Note: it is not possible to make the default policy “public”, options only including
“internal” and “external”.
6.1.5.1 Basic Settings
AG provides some basic setting options to customize Web Access. Select Access Methods > Web
Access > Basic Settings under the virtual site scope, where you can set the Web Access to open
Web links in new windows, show the URL bar on the portal homepage, display the navigation tool
and allow the browser bookmarking, as shown in Figure 6–4.
Figure 6–4 Web Access Basic Settings
6.1.5.2 QuickLink
 Configure a Hostname-Mode QuickLink Policy for a Virtual Site
To configure a QuickLink policy, please first select Virtual Sites > Virtual Sites >QuickLink
under the global scope, then click the Add action link, as shown in Figure 6–5.

Figure 6–5 Add a QuickLink Policy Under the Global Scope
In the Add Link configuration window, specify the parameters Resource ID, Mode and Host
Name, select a virtual site from the Virtual Site drop-down list and click the Save action link, as
Figure 6–6 Configure the QuickLink Policy
You can also define port-mode QuickLink rules by selecting the Port radio button and specifying
the relative information.
 Configure a Hostname-Mode QuickLink Policy under the Virtual Site Scope
 Add a QuickLink Resource
Select Access Methods > Web Access >QuickLink under the virtual site scope, and click the
Add action link to configure a hostname-mode QuickLink resource, as shown in Figure 6–7.
Figure 6–7 Add a QuickLink Policy for the Virtual Site Scope
In the Add QuickLink Resource configuration window, select the Resource ID (configured
under the global scope in the Add Link configuration window after selecting Virtual sites>
Virtual Sites > QuickLink) from the drop-down list and enter the URL of the resource, as shown
in Figure 6–8.

Optionally, the QuickLink resource can by assigned to a pre-defined role in this Add QuickLink
Resource configuration window. In the Quicklink Resources table, select a defined role from the
Role Name drop-down list, specify the parameters Display Name, Path and Position as needed,
select the Enable Auto Generate ACL Permit Configurations and Enable Frontend SSO
check boxes as required, and click the Add button to assign the QuickLink resource to the role.
Figure 6–8 Add the QuickLink Resource
Please note that if the URL of the QuickLink resource has a scheme of “https”, the Server
Certificate Verification needs to be disabled by selecting System Configuration > Advanced
Networking > SSL > SSL Global Settings under the global scope,clear the Enable Server
Certificate Verification check box, and click the Apply Changes button, as shown in Figure 6–9.
Figure 6–9 SSL Global Settings
In this window, you can also make more QuickLink configurations by selecting the Do not
rewrite web content, Rewrite external links, Rewrite XML, Block cookies from backend
server and Header forwarding check boxes as required in the QuickLink Options (Optional)
area.
 Add an Alias Link

Note: By defining an alias for a QuickLink rule, administrators can specify additional
URLs that should be mapped to the same resource identified by the Resource ID
parameter.
Click the Add action link in the Alias Links area to add an alias link, as shown in Figure 6–10.
Figure 6–10 Alias Links
In the Add Alias Links configuration window, select Resource ID from the Resource ID
drop-down list, enter the URL for the alias in the text box, and click the Save action link, as
Figure 6–11 Add Alias Links
6.1.5.3 Web Resource Mapping
Under the virtual site scope, select Access Methods > Web Access > Web Resource Mapping >
Rewrite Parameter, specify the Parameter Matching Method parameter in the Rewrite Match
Parameter area and click the Add Rule action link in the Rewrite Parameter Rules area to add
a rule, as shown in Figure 6–12.
Figure 6–12 Web Resource Mapping
In the Add Rule area, specify the parameters Rule ID, Parameter Name, Type, Separator and
Index, and then click the Save action link to save the rule, as shown in Figure 6–13.

Figure 6–13 Add a Rewrite Parameter Rule
Under the Advanced Settings sub-tab, select the check boxes Disable WRM, Rewrite Relative
URLs, Mask Internal URLs and Mask Filename in the Rewrite Settings area if required, as
Figure 6–14 Advanced Settings
6.1.5.4 Server Access
6.1.5.4.1 HTTP Setting Options
For user Web experience customization, Array AG provides multiple HTTP setting options,
including: Insert X-CLIENT-CERT header (to enable the function of inserting a header field or
cookie containing the client certificate into every request sent to the backend server if the client
certificate is given), Insert X-SSO-USER header (to enable the function of inserting an
“X-SSO-USER” HTTP header to set the username into every request to the backend server),
Redirect HTTP requests to HTTPS, Redirection URL for HTTP requests without valid
session cookies, Prevent browsers from storing responses, Enable propagation of the expire
clause in HTTP set-cookie headers (to enable transferring of the expiration clause in HTTP
set-cookie headers to the users), Enable HTTP X-Forwarded-For header insertion (to enable
“X-Forwarded-For” header insertion into every request that it sends to the backend servers, in
which the “X-Forwarded-For” header contains the IP address of the client who originated the
request. You can customize the values of the parameters Client certificate header name, Client
certificate insert mode, and Client certificate insert type. You can customize the
“X-Forwarded-For” header name if necessary.), and Method (the X-Forwarded-For header
insertion mode, either Header, URL, Cookie or All).
To configure the HTTP setting options, please select Access Methods > Web Access >Server
Access under the virtual site scope, and you can see the HTTP setting options in the General
Settings area, as shown in Figure 6–15.

Figure 6–15 HTTP Setting Options
6.1.5.4.2 Proxy Settings
You can configure proxy server between the AG appliance and the backend server by selecting
Access Methods > Web Access > Server Access > Proxy Settings under the virtual site scope.
You can configure three kinds of proxy servers: HTTP Proxy Server, HTTPS Proxy Server and
Automated Proxy Server, as shown in Figure 6–16.
Figure 6–16 Proxy Settings
6.1.5.5 URL Policy
You can assign URL policy with priority for URLs by selecting Access Methods > Web Access >
URL Policies under the virtual site scope and clicking the Add URL Policy button in the URL
Policies area, as shown in Figure 6–17.

Figure 6–17 URL Policies
In the Add URL Policy configuration window, specify the Type of the URL policy, the Priority
and the Keyword, and then click the Save button to save the URL policy, as shown in Figure
6–18.
Figure 6–18 Add a URL Policy
After defining the URL policy, it will be shown in the URL Policies sort-ready table.
For those URLs not assigned with URL policy, they will follow the default URL policy, which
can be specified in the Default URL Policy area, as shown in Figure 6–17.
6.1.5.6 Custom Rewrite
By default, the Custom Rewrite feature is enabled. You can disable the feature by unchecking the
Enable Custom Rewrite check box, as shown in Figure 6–19.
Figure 6–19 Custom Rewrite
To add custom rewrite rules, please first select Access Methods > Web Access > Custom
Rewrite under the virtual site scope and click the Add button, as shown in Figure 6–19.
In the Add Custom Rewrite Rule configuration window, you can specify the Rule ID, Rewrite
Position, URL, Regular Expression Script, Flag and click the Save button to add the custom
rewrite rule, as shown in Figure 6–20.

Figure 6–20 Add the Custom Rewrite Rule
6.1.5.7 URL Property
To add URL property, please first select Access Methods > Web Access > URL Property under
the virtual site scope and click the Add URL Property button, as shown in Figure 6–21.
Figure 6–21 URL Property
In the Add URL Property configuration window, you can specify the Mask Type, URL, and
click the Save button to add the URL property, as shown in Figure 6–22.
Figure 6–22 Add the URL Property
Note: For the Mask Type radio button, “rewrite” means to mask URL rewriting, i.e. the
URL will not be rewritten; “acceptencoding” means to mask the Accept Encoding header,
i.e. to disable the insertion of the Accept Encoding header on a per-URL basis.

6.2 Network Access and Array Client
6.2.1 Overview
Network Access is the client end application that needs to be installed for VPN (Virtual Private
Network) access. Its client end module is called Array Client. Network Access is the universal
solution for both network and application access. It is designed to maximize security for the
company’s network and application servers.
Array Client module can be installed on all mainstream desktop operating system. It provides two
launching methods: Web Launch and Standalone Launch. Web Launch supports most types of
mainstream browsers. The advantage of Web Launch is ease of installation with minimal user
intervention. The advantage of Standalone Launch is the capability to store configurations,
convenient for the end users.
Array Client supports three kinds of running mode: Network, Application and both. Network
mode covers network-level access to the internal resources and supports all TCP/IP protocols, and
two-way access. Application mode covers resources defined by executable programs.
6.2.2 Web Launch and Standalone Launch

There are two ways of using Network Access: one is through Web Launch, and the other is
through Standalone Launch. The Web Launch method also requires installation of a module, but
the installation virtually transparent through the browser. Thus the user experience is very smooth.
The Standalone Launch requires manual installation of the client end module. The Standalone
Launch supports the storing of the user configurations, more suitable for users who frequently
access the internal resources through Network Access.
Note: When client authentication is required, for the Web Launch, the administrator must
install root CA and intermediate CA certificates to the browser; for the Standalone
Launch, the administrator needs to import both root CA and intermediate CA certificates
to the AG appliance as the root CA certificates for the virtual site.
6.2.2.1 Web Launch
Web Launch provides a seamless user experience without the need to install any client-end
software. AG provides customers with Browser/Server network and application access.
Installation of the VPN Client-Side browser component is a one-time process unless it is explicitly
uninstalled by the remote user. By default, AG will attempt to install an ActiveX object. If
ActiveX support is disabled (or otherwise not supported) on the client browser, AG will attempt to
install a Java applet instead.
Once activated, the Array Client client-side component (ActiveX or Java applet) automatically
downloads and installs additional services and drivers as needed. The exact files downloaded and

installed are dependent on the type and version of the client’s operating system. When a newer
version of Array Client is detected by the client’s browser, the browser will proceed to update the
component automatically (unless the user has uninstalled it explicitly).
To install the client-side component on a remote machine, the remote user is required to have
“Administrator” privileges. Once the VPN client is installed, no further “Administrator” privileges
are required. For users to take advantage of the Java applet, the remote machines must be JVM
enabled/compatible.
6.2.2.2 Standalone Launch
AG provides both Client/Server and Browser/Server applications. The Standalone Launch can be
downloaded and installed for accessing the internal resources, network or applications without
requiring a browser.
The Standalone Launch provides users with the ease of one-button startup and the flexibility of
configuration storage (username and password, etc.).
The AG administrator can download the Standalone software from the WebUI under the Access
Methods > VPN path of the particular virtual site.
Note: Firewall software installed on the client's terminal may prevent the port of Array
Client Installer. Therefore before installing Array Client, please temporarily close the
firewall software first.
6.2.3 Network Mode and TCP Application Mode
6.2.3.1 Network Mode
VPNs are widely used to allow mobile users, telecommuters, offsite partners and customers to
securely access applications hosted on an internal network. Fundamentally, the VPN is a private
network that uses the Internet to connect remote sites or users together. The Array network-access
VPN provides users with network-level access equivalent to traditional IPSEC-based VPNs, while
greatly simplifying installation and support.
When the network-access VPN feature is enabled, a VPN client-side component (either ActiveX
or Java Applet) is automatically installed on the client-side machine through the Web browser
when the user initiates the SSL VPN connection through the virtual portal. AG assigns the remote
user an IP address based on the internal network. Specified resources on the inside network will
now be accessible via this assigned internal IP address.

Figure 6–23 Network Mode of Array Client
All tunneled data is protected by SSL encryption. Since all IP traffic to the network is tunneled, all
IP-based applications work transparently, including those using dynamic port TCP and UDP
protocols, NetBIOS, or ICMP. If the user’s login session is terminated for any reason, the user’s
VPN tunnel is immediately terminated too.
6.2.3.1.1 Netpool
 Assigning IP Address
When a remote user establishes a VPN tunnel, the user is assigned with an internal IP address. The
assigned IP address is persistent for the duration of the user’s login session. AG supports both
dynamic and static IP address assignment. The administrator may associate each user group
(defined either on LocalDB or on an external AAA server) with a network pool, or “Netpool”. A
“Netpool” defines a set of network connectivity parameters including one or more IP address
ranges. Alternatively, fixed IP addresses can be assigned to individual users who have LocalDB
accounts or have fixed IP in the RADIUS responses. To avoid IP conflicts, the administrator
should ensure that any IP addresses assigned by AG are not assigned to any other host for the
internal network.
If AG has a physical interface on the network containing the IP address to be assigned, the IP
address will be configured on that interface. A client that is assigned an IP address on a physical
AG interface will be able to send IP broadcast traffic to the internal network connected to the
interface.
Figure 6–24 Netpool of Physical IP Addresses
Regarding the above figure:

 The inside interface of AG will be assigned with an internal IP address so that the user will
be treated like an internal user. The assigned IP address can be either a fixed IP address for
individual users who have LocalDB accounts or a selected IP address from the previously
defined Netpool.
 For the above example, the internal IP range is defined with a 24 bit Subnet Mask (i.e., the
internal IP range is 192.168.1.1-192.168.1.255). The assigned address (192.168.1.1) is an
accepted internal IP address.
 The Netpool IP range can be 192.168.1.10-192.168.1.50 (a subset of the internal IP range).
If the assigned IP address is located on a virtual subnet, the client assigned with a virtual IP
address in the Netpool will be routed to the backend server. A client that is assigned an IP address
on a virtual subnet will not be able to send IP broadcast traffic to the internal network. However,
one VPN client can broadcast to all other VPN clients on the same virtual subnet.
Figure 6–25 Netpool of Virtual Subnet
Regarding the above figure:
 The client will be assigned with an IP address of the Netpool. In this case, it will be a part of
a virtual subnet. For example, if the virtual subnet is 10.10.1.1-10.10.1.100 then the assigned
IP may be 10.10.1.1.
 The assigned IP needs to be routed to the internal IP address through the gateway of the
internal AG interface (i.e., 192.168.1.1).
IP Ranges and Network Zones
The administrator may specify one or more contiguous IP address ranges from which internal IP
addresses may be assigned to Netpools. If split tunneling is needed, the administrator must define
one or more internal IP subnets (or network zones) to which VPN users will have access.
It is the administrator’s responsibility to ensure that all configured network zones are routable
from all IP ranges configured for the Netpool. When setting up VPN for Network mode,
administrators should not use the reserved IP addresses 1.1.1.1 and 2.2.2.2.
IP ranges must not overlap with other configured IP ranges for any Netpool, or with static IP
addresses assigned to individual users in LocalDB, LDAP or RADIUS servers. RADIUS has
standard attributes to store a client IP and netmask for use in VPN devices. The standard attributes

for these are the Framed-IP-Address (attribute 8) and Framed-IP-Netmask (attribute 9). If IP
addresses or Netmasks are present, the first one is used, while the rest are discarded.
Administrators may also configure AG for DHCP (Dynamic Host Configuration Protocol). This
will allow network clients to get IP addresses from a configured DHCP server. AG can accept up
to three DHCP servers. As a DHCP client, the AG appliance will send the DHCP request to the
first server first. If there is no response, the AG appliance will retry two additional times every 4
seconds before moving on to the next DHCP server. Administrators can optionally configure the
lease time, client subnet and whether to use the client MAC address as the unique client ID in the
DHCP requests. If the lease time is configured, AG will request to lease a client IP address for that
lease time. However, it is up to the DHCP server to determine the lease time. The IP address will
automatically be renewed if the VPN tunnel is still active before the lease time expires. If the
client subnet is configured, AG will request an IP address belonging to that subnet from the DHCP
server. However, it is up to the DHCP server to determine what IP address to be assigned to the
client. Administrators can also configure the AG appliance to use the client PC’s MAC address as
the unique client ID or use the auto-generated unique client ID to request the IP address from the
DHCP server.
 Speed Tunnel
The Speed Tunnel function provides high-speed UDP tunneling for applications that require
real-time transmission. The speed tunnel is best suited for applications that can tolerate packet
losses and out-of-order receptions such as VoIP. The administrator can configure a default
dispatch rule for VPN data to go through TCP or speed tunnels, for example, making all VPN data
go through speed tunnels.
Speed Tunnel is encrypted with the Datagram Transport Layer Security (DTLS) protocol, which
provides communications privacy for datagrams and prevents eavesdropping, tampering, or
message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and
provides equivalent security guarantees.
Note: Please note that only Windows clients support Speed Tunnel for now. Clients
running on other platforms will still establish TCP tunnels only to virtual sites even with
Speed Tunnel enabled.
 DNS
After the VPN is connected, when end users access resources represented by hostnames, the Array
Client can use the following two types of DNS servers:
 Virtual DNS server: indicates the DNS server assigned to the Array Client by the virtual site.
The administrator can configure the DNS server for the virtual site and use this DNS server
as the virtual DNS server. Alternatively, the administrator can configure the global DNS
server and use the global DNS server as the virtual DNS server. For details of the global DNS
server or the DNS server configured for the virtual site, please refer to section 2.4 DNS
Configuration on AG.

 Local DNS server: indicates the local DNS server configured on the machine where the
Array Client is installed.
Normal DNS resolution
After the VPN is connected, the normal DNS resolution process performed by the Array Client is
as follows:
1. The Array Client will first try to perform DNS resolution using the virtual DNS server.
2. If the response from the virtual DNS server times out, the Array Client will then try to
perform DNS resolution using the local DNS server.
The administrator can set the timeout value for the virtual or local DNS servers according to the
network environment. For 3G/WIFI network that has a very large round-trip time (RTT), the
administrator should increase the DNS timeout value. Besides, end users can set the timeout value
on the Array Client by themselves.
DNS Filter
AG provides DNS filter rules for the administrator to customize the DNS resolution process for
end users assigned with the specified Netpool. When the VPN is connected, the DNS filter rules
will be assigned to end users together with the Netpool. When end users access resources
represented by hostnames, the Array Client performs DNS resolution according to the DNS filter
rules.
AG supports two types of DNS filter rules:
 Virtual DNS filter rule: With the virtual DNS filter rule configured, when the hostname to be
resolved matches this DNS filter rule, the Array Client will use only the virtual DNS server
to perform the DNS resolution. When not match, the Array Client will perform the normal
DNS resolution process (flag=0) or use only the local DNS server (flag=1) to perform the
DNS resolution according to the setting of the virtual DNS filter rule. For details of the “flag”
parameter, please refer to the ArrayOS AG CLI Handbook.
 Local DNS filter rule: With the local DNS filter rule configured, when the hostname to be
resolved matches this DNS filter rule, the Array Client will use only the local DNS server to
perform the DNS resolution. When not match, the Array Client will perform the normal DNS
resolution process (flag=0) or use only the virtual DNS server (flag=1) to perform the DNS
resolution according to the setting of the local DNS filter rule.
If no virtual or local DNS filter rule is configured, the Array Client will perform the normal DNS
resolution process.
If both the virtual and local DNS filter rules are configured:
 If the hostname matches one virtual DNS filter rule, the virtual DNS filter rule will take
effect.
 If the hostname does not match any virtual DNS filter rule but match one local DNS filter
rule, the local DNS filter rule will take effect.

 If the hostname does not match any virtual or local DNS filter rule but one virtual DNS filter
rule with flag=1 exists, this virtual DNS filter rule will take effect.
 If the hostname does not match any virtual or local DNS filter rule, no virtual DNS filter rule
with flag=1 exists, but one local DNS filter rule with flag=1 exists, this local DNS filter rule
will take effect.
 If the hostname does not match any virtual or local DNS filter rule and no virtual or local
DNS filter rule with flag=1 exists, the Array Client will perform the normal DNS resolution
process.
 Routing
The administrator can use this function to direct the VPN tunneled traffic of the specified Netpool.
After receiving a packet, AG will direct it in the following mechanism:
 If only the route gateway is configured for the Netpool using the “vpn netpool route
gateway <netpool> <gateway> [unit_name]” command, the received packet will always be
sent to this route gateway.
 If both the default route (configured using the “vpn netpool route default <netpool>”
command) and the route gateway (configured using the “vpn netpool route gateway
<netpool> <gateway > [unit_name]” command) are configured for the Netpool, when
receiving a packet, AG will first check whether the destination IP included in the packet
matches any existing route in the global routing table. If yes, the received packet will be sent
to the gateway specified by the matched route. Otherwise, the received packet will be sent to
the route gateway by default.
 If neither the route gateway nor the default route is configured for the Netpool, the received
packet will be sent based on the global routing table.
 Windows Administrator Account
Windows users can install the Array Client only with administrator privileges. The administrator
can configure Windows administrator accounts for the specified Netpool. Once the Netpool is
authorized to Windows users without administrator privileges, they can use the privileges of the
Windows administrator accounts to install the Array Client.
 Proxy
Due to access limitation, the proxy mechanism needs to be applied, either on the client end or on
the server end. Two types of proxies are supported by the AG appliance: inside proxy and outside
proxy. The inside proxy is configured by the administrator and supports only network VPN and
full tunneling mode. The outside proxy is configured by the client (typically in the browser). The
AG will provide safe communication with the client despite the existence of the outside proxy (i.e.,
SSL VPN connection will be established between the client and the outside proxy, and between
the outside proxy and the AG appliance). The following figure shows the layout and
communication of the inside proxy and the outside proxy.

Figure 6–26 Inside and Outside Proxy
Note: When an inside proxy is in use, the AG appliance does not resolve the DNS names
of backend servers. This affects the operation of the configured ACLs. If a given ACL
matches the IP address of a backend server but not the host name, the AG appliance will
not enforce the ACL if a backend server is accessed via its host name.
6.2.3.2 TCP Application Mode
This access method features a local proxy that intercepts the VPN connections initiated from the
application, tunnels the data (over a secure SSL connection) and then proxies the data to the
intended backend resource.
Figure 6–27 Proxy Mechanism of Array Client
The above figure illustrates the proxy mechanism of the Array Client:
1. The connection requests are intercepted by the local proxy.
2. The local proxy sends information to AG over a secured tunnel.
3. AG opens connections to the backend server and transfers data.
This feature supports most fixed-port TCP applications, including common mail applications such
as Microsoft Exchange and Lotus Notes. Once this feature is configured, users may securely
access applications from most Windows and recent Macintosh clients running a current Web
browser (IE or Firefox) with Java support. All application data is securely transferred between the
client and the AG appliance over SSL, and only data from clients authenticated on the AG
appliance are accepted.
The Array Client listens for TCP traffic from applications running on the client machine, encrypts
the packets, and forwards them to the AG over SSL connections. The AG then decrypts the
packets and forwards them to the appropriate backend servers.

All data transferred between the client machine and the AG is sent over SSL connections using
strong encryption. And all access to the application servers is controlled and restricted by AG via
user authentication/authorization policies and ACL rules.
6.2.3.2.1 Security
The TCP application access methods offer several security advantages in the area of network
exposure. When using the Local Proxy concept the connection between the user’s PC and the
network is done on the TCP level, so the user is not assigned with an IP address on the internal
network. As a result, the network is less exposed to whatever traffic originating from the user’s PC
(such as Trojans). Conceptually the TCP applications approach is more locked down as the
administrator has to explicitly define each server (and port range) and/or application and/or
subnet.
6.2.3.2.2 Netpool
In order to use Array Client in the TCP Application mode, Netpools also need to be configured,
while IP range does not have to be specified for Application mode.
6.2.4 VPN Resource

A Netpool needs to be assigned with VPN resources in order to function properly. For Network
mode, the VPN resource assigns resources in some IP ranges or network zones. For Application
mode, the VPN resource assigns resources of particular applications, defined by IP addresses and
ports/paths.
6.2.4.1 Tunneling Modes
For each Netpool, the administrator may select either split tunneling or full tunneling for the
remote clients/users. In split tunneling, only traffic to certain destinations will be encrypted and
sent over the SSL VPN tunnel to the AG appliance and from there to the secured internal network.
All other traffic will continue to be routed normally, and the client will continue to have access to
local network resources or networks (as long as their IP addresses do not conflict with any
configured zones). In the event that the internal name servers (added by AG to the client) are
unavailable or do not respond to a request from the client for any reason, the name servers on the
client-side will be used. However, if the name servers added by AG send a negative response to a
query from the client application, the client application will not try the name servers previously
configured. The following illustration shows the Windows’ default behavior.

Figure 6–28 Split Tunneling
About the above figure:
 For Split Tunneling, only traffic bound for the internal network (for example, IP range of
192.168.1.0/24 in the figure above) will go through the AG appliance.
 Other traffic bound for IP addresses other than the intranet will not go through the AG
appliance.
If full tunneling is configured, all traffic (regardless of destination) will be tunneled. Selecting full
tunnel mode means that even traffic that is not destined to resources on the secured internal
network will pass through it; and if the corporate network policies do not permit access to certain
destinations users will not be able to access them. Please note that with full tunneling the user will
not have access to the local network. In full-tunneling mode, only name servers added by the AG
will be queried. When the client disconnects from the VPN, the original DNS/WINS settings on
the client machine will be restored.
Figure 6–29 Full Tunneling
For the above figure:
 All traffic will be sent through the AG appliance over the SSL VPN tunnel.
 Requests for the internal resources will be sent to the intranet.
 Requests for the Internet resources will be sent to the correspondent Internet server.

Note:
 To establish a full tunnel VPN, you can configure the VPN resource group as
“0.0.0.0/0.0.0.0:0-65535” so that all the traffic will go through the VPN tunnel.
 To establish a split tunnel VPN, you can configure the VPN resource group as
“10.10.10.0/255.255.255.0:0-65535” so that only the packets in this IP range
(between 10.10.10.0 and 10.10.10.255) will go through the VPN tunnel.
6.2.5 Mobile VPN

To supply secure VPN support for smart phones and tablet devices, AG provides the Mobile VPN
feature supporting secured L2TP VPN with IPSec protection. The Mobile VPN feature utilizes the
existing L2TP/IPSec client of iOS/Android to avoid installation of a special client. For the iOS
platform, the Mobile VPN feature also supports loading VPN configurations by installing the
Array mobile VPN client.
The functions provided by Mobile VPN include:
 Hardware acceleration
 IPSec virtual site with IPv6 address
 NAT traversal that supports three modes (off/on-demand/force)
 Provide necessary logs and status information
 Global-scope IPSec configurations
 IKE phase1 and phase2 configured separately
 Dedicated AAA method or shared AAA method with SSL VPN
 Netpool configurations and user role assignment
 ACL
 Mobile VPN session management
 VPN configuration profile for iOS clients to automatically load Mobile VPN configurations
 Supported mobile platforms: iOS 5.0 or higher, Android 2.0 or higher
Note:
 The Mobile VPN feature can share some of the Netpool configurations with the SSL
VPN feature such as IP ranges and DHCP servers.
 If the server certificate, root CA or intermediate CA is imported or updated, please

make sure to activate it by executing the “ipsec certificate activate server”, “ipsec
certificate activate rootca” or “ipsec certificate activate interca” command.
Alternatively, you can execute the “ipsec start” command which activates all the

certificates. Otherwise, the IPSec VPN will fail to work.
6.2.6.1 SSL VPN Configuration Example
 Enable VPN
Under the virtual site scope, select Access Methods > VPN > SSL VPN. In the General Settings
area, select the Enable VPN check box to enable SSL VPN, select the Enable L3VPN Client
Traffic Isolation and Enable L4VPN Backend Connection Keepalive check boxes, specify the
parameters Speed Tunnel Port and Speed Tunnel Dispatch Rule, and click the Apply Changes
Figure 6–30 Enable VPN
 Add a Netpool
Under the virtual site scope, select Access Methods > VPN > Common Settings > Netpools,
click the Add action link in the Netpools table, as shown in Figure 6–31.

Figure 6–31 Netpools
In the Add Netpool configuration window, specify the Netpool Name parameter and configure
other parameters as required, as shown in Figure 6–32.
Figure 6–32 Add a Netpool
After clicking the Save button, the defined Netpool will be displayed in the Netpools sort-ready
table, as shown in Figure 6–33.
Figure 6–33 Netpools Configured
Double click the defined Netpool to make more configurations on the Netpool. Under the Basic >
IP Address tab, specify the parameters First IP Address, Last IP Address, and HA Unit Name,
and click the Add button to save the settings, as shown in Figure 6–34.

Figure 6–34 Set the Dynamic IP Address Range
In the IP Addresses Via DHCP area, specify the DHCP Server IP Address parameter and click
the Add button to add a DHCP server for the Netpool. Specify the parameters Desired Lease
Time and Request IP From Subnet, and select the Use Client MAC as Client ID check box as
required, as shown in Figure 6–35.
Figure 6–35 Set IP Addresses via DHCP
In addition, the administrator can add the following configurations to the Netpool if required.
Click the Launch Commands tab to configure the options related to the launch of the Array
Client, as show in the Figure 6–36.

Figure 6–36 Launch Commands
Select Advanced > General to configure general advanced options for the Netpool, such as
keep-alive interval, routing gateway, NAT, client subnet, IPSec over SSL and Array Client
options for Windows, as shown in Figure 6–37.

Figure 6–37 General Advanced Options
Select Advanced > Windows Administrator to configure Windows administrator accounts for
the Netpool, as show in Figure 6–38.
Figure 6–38 Windows Administrator Accounts
Select Advanced > Inside Proxy to configure manual-type or script-type inside proxy for the
Netpool, as show in Figure 6–39.
Figure 6–39 Inside Proxy
Click the DNS tab to configure DNS records and DNS timeout for the Netpool, as shown in
Figure 6–40.
Figure 6–40 DNS
 Add a VPN Resource Group
Under the virtual site scope, select Access Methods > VPN > Common Settings > VPN
Resource, click the Add action link in the VPN Resource Group List table, as shown in Figure
6–41.

Figure 6–41 Add a VPN Resource Group
In the Add VPN Resource Group configuration window, specify the Group Name parameter, as
In the Application-type VPN Resource Item table, specify the parameters Application Name,
File Name and MD5 Hash Value and click the Add button to add a resource item, as shown in
Figure 6–42.
Figure 6–42 Add an Application-type VPN Resource Item
In the Network-type VPN Resource Item area, specify the parameters Network Resource and
Type and click the Add button to add a resource item, as shown in Figure 6–43.

Figure 6–43 Add a Network-type VPN Resource Item
In the Application-type VPN Resource Excluded Item and Network-type VPN Resource
Excluded Item areas, add excluded application-type and network-type items to the VPN resource
group in the same way as adding application-type VPN resource and network-type VPN resource
items, as shown in Figure 6–44.
Figure 6–44 Add Excluded Application-type and Network-type Items
 Assign a Netpool to a Role

To assign a VPN Netpool to a role, select Role > Role Resource > Role Resource > VPN under
the virtual site scope, and click the Add button in the Netpool Resources table, as shown in
Figure 6–45. For details, refer to section 5.1.2 Role Resources.
Figure 6–45 Assign the Netpool and VPN Resource Group to a role
 Assign a VPN Resource Group to a Role
To assign a VPN resource group to a role, select Role > Role Resource > Role Resource > VPN
under the virtual site scope, and click the Add button in the VPN-Resource-Group Resources
table, as shown in Figure 6–45. For details, refer to section 5.1.2 Role Resources.
Note: Users can use the SSL VPN feature only when they are authorized with valid VPN
resources including the Netpool and VPN resource groups.
 Network Access via Web Launch
After completing the VPN and role configurations, authorized users can launch VPN and access
VPN resources via the Web browser. Once successfully logged into the virtual site, users can click
the Connect button in the VPN Network area in the welcome page to establish the VPN tunnel,
as shown in Figure 6–46. When the VPN tunnel is established, the icon of a red “A” will appear in
the status bar of the window.

Figure 6–46 Web Launch Network Access
 Network Access via Standalone VPN Client
Users can launch VPN via the Standalone Array Clients obtained from their administrator. The
administrator can download the Standalone Array Clients for different operating systems from the
VPN Software Downloads area after selecting Access Methods > VPN > SSL VPN under the
virtual site scope as shown in Figure 6–30 and deliver them to users.
 Customizable options of Array VPN Client
AG provides several customizable options for Web Launch Array Client. The customizable
options are available in Virtual Sites > Custom Management > Client Custom under the global
scope, as shown in Figure 6–47.

Figure 6–47 Client Custom
Note: Please note that the Client Custom function only works for Web-launched Array
Client, not Standalone Array Client.
6.2.6.2 Mobile VPN Configuration Example
6.2.6.2.1 Global IPSec Configuration
 Add an IPSec Service
The administrator can add two types of IPSec service:
 “transport”: indicates that an L2TP over IPSec tunnel will be established between the mobile
client and AG.
 “tunnel”: indicates that an IPSec tunnel will be established between the mobile client and AG.
This type of tunnel is only used by MotionPro virtual sites.
Under the global scope, select Virtual Sites > Virtual Sites > IPSec, select Site Name, IP
Address and Mode from the drop-down lists in the IPSec Service List table, and click the Add a
Service button to add an IPSec service for the virtual site, as shown in Figure 6–48.
Figure 6–48 IPSec Service
 Set IPSec Global Parameters
Under the global scope, select System Configuration > Advanced Networking > IPSec, specify
the NAT-T Keep Alive (seconds) parameter and select the Enable IPSec Acceleration check
box in the General Settings area, specify the Expiration Time (seconds) parameter in both IKE
Phase1 and IKE Phase2 areas and click the Apply Changes button, as shown in Figure 6–49.

Figure 6–49 IPSec Global Settings
6.2.6.2.2 Mobile VPN and Virtual Site IPSec Configuration
 Set AAA Method for Mobile VPN Clients
Under the virtual site scope, select Site Configuration > AAA > Method, select a method from
the AAA Method for Mobile VPN Clients drop-down list box, and click the Apply Changes
Figure 6–50 Set AAA Method for Mobile VPN Clients
Note:
 When AAA Rank is disabled, the AAA Method for Mobile VPN Clients parameter
needs to be specified for the Mobile VPN feature to work; when AAA Rank is
enabled, the ranked AAA methods will be tested one by one, ignoring this AAA
Method for Mobile VPN Clients configuration.
 The AAA method with multi-step authentication may cause the mobile VPN clients
to fail authentication.
 Configure IPSec Service
 Transport Mode IPSec Service

Under the virtual site scope, select Access Methods > VPN > Mobile VPN > General, specify
the Pre-shared Key parameter and click the Add action link in the IKE Phase1 area, as shown in
Figure 6–51.
Figure 6–51 Transport Mode IPSec Service General Settings
In the Add Phase1 Proposal area, specify the parameters Proposal ID, Encryption, Hash and
DH Group, and click the Save action link, as shown in Figure 6–52.

Figure 6–52 Add an IKE Phase1 Proposal
Next, specify the parameters PFS Group, Encryption and Authentication in the IKE Phase2
area and the parameters Profile Name and NAT-T (NAT traversal) in the General Settings area,
select the Enable Mobile VPN check box and click the Apply Changes button as shown in
Figure 6–51.
Under the virtual site scope, select Access Methods > VPN > Mobile VPN > Tunnel, specify the
Device Authentication Method parameter in the General Settings area, as shown in Figure
6–53.
Figure 6–53 Transport Mode IPSec Service Tunnel Settings
 Tunnel Mode IPSec Service
Under the virtual site scope, select Access Methods > VPN > Mobile VPN > General, click the
Add action link in the IKE Phase1 area, as shown in Figure 6–54.

Figure 6–54 Tunnel Mode IPSec Service General Settings
In the Add Phase1 Proposal area, specify the parameters Proposal ID, Encryption, Hash and
DH Group, and click the Save action link, as shown in Figure 6–55.

Figure 6–55 Add an IKE Phase1 Proposal
Next, specify the parameters PFS Group, Encryption and Authentication in the IKE Phase2
area, the parameters Activate Trusted Root CA Certificate, Activate Intermediate CA
Certificate and Activate Certificate in the Certificate area and the parameters Profile Name and
NAT-T (NAT traversal) in the General Settings area, select the Enable Mobile VPN check box
and click the Apply Changes button as shown in Figure 6–54.
Under the virtual site scope, select Access Methods > VPN > Mobile VPN > Tunnel, specify the
parameters Device Authentication Method and Tunnel Lifetime(seconds) in the General
Settings area, specify the Domain Name parameter and click the Add button in the Split DNS
area to add a split DNS domain name, as shown in Figure 6–56.
Figure 6–56 Tunnel Mode IPSec Service Tunnel Settings
Click the Add action link in the VOD area, then specify the parameters Domain Name and Mode
in the Add VOD Configuration configuration window, as shown in Figure 6–57.

Figure 6–57 Add a VOD Domain
6.3 File Share
6.3.1 Overview
The file share function provides shared remote access to files on backend Windows-based
Common Internet File System (CIFS) file servers of the Intranet. This function allows users to
browse, download, upload, rename, move, and delete files and to create, rename, move, and delete
folders on CIFS file servers from any client on the Internet using an AG-compatible browser. The
permissions assigned to users are actually determined by the permissions set on files on the CIFS
file serves.
To provide shared access to files on CIFS servers, the administrator needs to define the folder
containing shared files as a CIFS role resource first. Multiple CIFS resources can be bound to the
same role and a CIFS resource can be bound to multiple roles. When a remote user successfully
logs in to the virtual site, only the CIFS resources for the authorized roles are displayed. Only
when an ACL rule has been configured to deny a role’s access to a CIFS resource, the CIFS
resource will not be displayed for this role. Otherwise, the CIFS resource will be displayed for the
role by default.
After successfully logging into the virtual site with CIFS resources, the user can access the
resources by clicking the CIFS resource links displayed on the Welcome page. However, if the
CIFS server requires authentication and the virtual site login credential cannot be used to log into
the CIFS server, the user will have to enter a valid CIFS server credential on the prompted
Authentication Required page, as shown in Figure 6–58.

Figure 6–58 Authentication Required by the CIFS Server
Note:
 The maximum size of the file that can be uploaded to the CIFS server is 500 MB.
 The maximum size of the file that can be downloaded from the CIFS server is 1 GB.

 Add CIFS Role Resource
Please add CIFS resources and assign them to a role according to the configuration example of
“Add a CIFS Type of Role Resource” in section 5.1.4 Configuration Example.
 (Optional) Add ACL Rule for CIFS Role Resource
Please add ACL rules for the CIFS role resources according to the configuration example of
“ACLs” in section 5.2.5 Configuration Example.
 Enable CIFS
Under the virtual site scope, select Access Methods > File Access > Basic Settings, select the
Enable CIFS check box, and click the Apply Changes button in the upper-right corner of the

Figure 6–59 Enable CIFS

Chapter 7 Web Portal
7.1 Default Portal

The virtual portal of a virtual site is a URL where remote users go to gain access to all the
resources they require for their day to day business. Before a user is granted portal access, the AG
checks the user’s credentials (for example, username and password) to enforce authentication.
Then, based on the user’s assigned privileges/roles, the AG authorizes the user access to specific
files, applications and other subnet destinations. As such, all resource access is carefully and
thoroughly controlled and audited by the AG. The appearance of the Web portal can also be
customized by the administrator.
7.1.1 Understanding the Virtual Portal

The virtual portal provides a single interface for remote users to access internal network content.
Each virtual portal is associated with a fully qualified domain name (FQDN) and can listen on
multiple IP addresses or ports (defaults to 443). In essence, the AG allows administrators to hide
the internal network architecture by exposing multiple domains and IP addresses to the public
Internet. This approach also allows for effective controlling and recording of users activity as they
navigate the portal(s). Virtual portals are designed to be independently configured such that each
has its own custom interface (login, welcome and navigational pages), SSL settings, AAA
configuration, access methods and more.
The unique ability to configure multiple user roles provides greater flexibility in exposing
different sets of internal resources to different types of users. For example, a company might have
one role for employees to access Websites, files and legacy application resources, and another role
for partners to access selected Web resources only.

Figure 7–1 Virtual Portal
7.1.2 Defining the Virtual Portal Appearance

The look-n-feel of each virtual portal may be configured to match a company’s existing branding
scheme. With a unified look-n-feel, the virtual portals will be immediately recognizable by
customer’s end users for a perfectly seamless integration.
Note: To make sure that the login page, challenge password page, SMS page, or other
portal page shown to the user before login can be accessed before successful login, all
contents on these pages should be set as public resource using the “urlpolicy public”
command.
7.1.2.1 Default Portal
On the AG appliance, the default portal theme is applicable to the exclusive and alias virtual sites.
The default portal theme defines the overall appearance of the following portal pages:
 The page for auto-launching Application Manager/L3VPN
 The RADIUS challenge response page
 The page for choosing an alias virtual site (only applicable to the shared virtual site)
 The login page
 The logout page
 The page for changing a user’s LocalDB password
 The page for changing a user’s LDAP password
 The SMS authentication page
 The SMX authentication page
 The folders that contain several different error pages
 The welcome page
7.1.2.2 Basic Virtual Portal Setting
The AG allows administrators to configure the following portal page settings:
Page format Defines what format that the virtual site’s portal page will be displayed in
(for example, HTML or XML).
Language Defines in what language a given portal page will appear. The AG supports
English, Simplified Chinese, Traditional Chinese and Japanese (the default
is English). Also, the AG allows administrators to set a language override
for specific content (such as an active hyperlink) in case its language needs

to be different from the rest of the portal page.

Error page Defines the external error pages to show when specific errors occur.
Note: The administrator can also define error pages via the portal theme function (this
topic will be covered later in this chapter). However, the error page setting here has higher
priority than those defined via the portal theme feature.
7.2 Portal Custom

The administrator may also change the style or look of the portal theme pages by using the “Portal
Custom” feature. With this feature, the administrator can easily define the following single pages
as desired:
 Welcome page
 Login page
 Log out page
 Change password page
 Change password OK page
Note: The portal custom setting has higher priority than the default portal theme. If the
administrator has configured the portal custom settings, the above five pages will first
follow the portal custom settings while the other pages will follow the settings in the
default portal theme.
7.3 Portal Theme

The Custom Portal Theme feature allows the administrator to customize the appearance of all the
portal pages shown to the end user (for example, the login page, logout page, password change
page, RADIUS challenge page, etc.). With the portal theme function, the administrator can:
 Easily import the already published pages into AG and utilize them on the portal as needed.
 Import the pre-defined portal pages into AG, without spending much time on the design
work.
Before importing the portal theme into the AG appliance, the administrator should have the portal
theme pre-defined. There are two kinds of portal themes supported by the AG appliance:
The published portal theme is to import some necessary pages from a completed Web site. So if
the administrator wants to import the portal theme via the URL link, the related Web site should
be created first.
The portal theme packet is to compress portal pages into a ZIP packet, and import the ZIP
package (up to 10M) into the AG appliance. If the administrator chooses this kind of portal theme,
the related pages should be designed and compressed first.

After the portal theme ZIP packet is imported, the administrator is allowed to edit the source codes
of the imported portal page files online.
Figure 7–2 Two Ways to Import Portal Theme
To create a custom portal theme ZIP package, all the customized portal pages should be stored in
the following folders respectively:
Table 7–1 Folders in the Portal Theme ZIP Packet
Folder Name Contents

autolaunch The page for auto-launching Application Manager/L3VPN
challenge The RADIUS challenge response page
The page for choosing an alias virtual site (only applicable to shared
choose_site
virtual site, and the shared virtual site only has this page)
login The login page
logout The logout page
passchange The page for changing a user’s LocalDB password
ldappasschange The page for changing a user’s LDAP password
sms The SMS authentication page
smx The SMX authentication page
static This folder is for public pictures and CSS files
theme_error The folders that contain several different error pages
welcome The welcome portal page
In addition, the folder “theme_error” further contains the following sub-folders:
Table 7–2 Sub-folders in the “theme_error” Folder

passwordchangefail The page displayed when the user failed to change password
newpasscheckfail The page displayed when the user set an invalid new password
dns The page displayed when the domain name service resolution failed


revdns The page displayed when the reverse domain name service resolution
failed
https The page displayed if the HTTPS server is not configured
cookies The page displayed when the browser does not support cookies
sessionexpired The page displayed for that the login session has expired
request The page displayed when the generic request error occurred
access The page displayed when the access is denied
genlogin The page displayed when the generic login error occurred
failedlogin The page displayed when the login attempt failed
internal The page displayed when the generic internal error occurred
badacls The page displayed when the account has invalid ACLs
Note: The portal custom settings have a higher priority than the portal theme settings.
And, the portal theme settings have a higher priority than the default portal theme settings.
So, for example, if both portal custom and portal theme define a given portal page, the
portal page will obey the portal custom settings.
There are several JavaScript files included in each portal theme package. These JavaScript files
contain objects and variables that the administrator may use to further customize the portal pages.
The following tables show more information about each of these JavaScript files:
Table 7–3 Portal Theme JavaScript Files
File name: an_login.js
This file is used to define the information displayed on the login page.
Variable Meaning
_AN_str_title_login The title of login page.
_AN_str_help The string for help. For example, if user chooses English as the portal
language, the value will be “Help”.
_AN_str_username Label for username field.
_AN_str_password Label for password field.
_AN_str_login Label for the login button.
_AN_str_errormsg_login Error message when login failed.
Enable auto complete when entering text in a text box (TRUE or
_AN_autocomplete
FALSE).
_AN_aaa_rank_on Enable AAA rank (TRUE or FALSE).
The default authentication method index, starting with 0. This
_AN_aaa_defmethod_idx determines the default selected authentication method on the login
portal page when a user lands on this page for the first time.
_AN_str_aaa_nomethod The string indicating that no AAA method has been configured.
The structure of AAA method.
_AN_aaa_method Parameter Meaning
name The method name, which will be passed to the

Variable Meaning
backend server.
method_disp The display name for the method.
auth_server The name of the authentication server.
authtype The authenticate type:
LocalDB/LDAP/RADIUS/CERT
server_disp The authentication server name being displayed.
authaction The authentication action type. (cert anonymous, cert
challenge, etc.)
multiauth Enable or disable multi-factor authentication.
multistep How many steps are needed except for the basic
authentication step.
multisteps The structure of multiple authentication steps.
File name: an_welcome.js
This file contains objects used to define resources that can be assigned to users, such as Web links,
File Share links, VPN resources and DesktopDirect resources.
Variable Meaning
Portal links that is shown on the welcome page.
Only links that permitted by ACL rules will be
displayed. The members are “href”, “description”
_AN_weblinks_list and “type”.
 href: URL of the link
 description: Descriptive label for the link
 type: portal_link
Title of the area displaying portal links, for
_AN_str_weblinks
example, Web Links.
Whether the SSL VPN is enabled.
_AN_enable_vpn  0: Disabled
 1: Enabled
Whether the Mobile VPN is enabled.
_AN_enable_l2tp  0: Disabled
 1: Enabled
Title of the area displaying the SSL or Mobile
_AN_str_networkresource
VPN.
Label of the button for starting SSL or Mobile
_AN_str_startvpn
VPN.
Whether the initiation mode of Array Client is set
to ActiveX.
_AN_activex_client
 0: No
 1: Yes
Whether the initiation mode of Array Client is set
_AN_java_client
to Java.

Variable Meaning
 0: No
 1: Yes
Whether auto-switch of initiation mode of Array
Client is enabled.
_AN_autoswitch
 0: Disabled
 1: Enabled
Whether VPN auto-launch is enabled.
_AN_autolaunch_enable  0: Disabled
 1: Enabled
Prompt message for installing the ActiveX
_AN_str_failmsg_vpn
components for IE 8.
Prompt message for installing the ActiveX
_AN_str_failmsg_vpn_IE9
components for IE 9 and IE 10.
_AN_str_portallanguage Language the portal uses.
Error message displayed when the user’s OS and
_AN_str_localcheck_errmsg
browser does not support the VPN.
Error message displayed when Java Virtual
_AN_str_fail_needJVM
Machine is not installed or is disabled.
Error message displayed for Java component
_AN_str_fail_insJAVA
installation failure.
Error message displayed when the user uses non-IE
_AN_str_fail_enActiveX browser but the VPN initiation mode is ActiveX
and auto-switch of initiation mode is disabled.
Error message displayed for Java component
_AN_str_fail_initJAVA
initiation failure.
Error message displayed when the client OS is the
_AN_str_fail_Win98me
unsupported Windows 98 or Windows Me.
Whether File Share is enabled.
_AN_enable_fileshare  true: enabled
 false: disabled
CIFS links that are shown on the welcome page.
Only links that permitted by ACL rules will be
displayed. Only links that permitted by ACL rules
will be displayed. The members are “href”,
_AN_filelinks_list
“description” and “type”.
 href: URL of the link
 description: Descriptive label for the link
 type: cifs_link
Title of the area displaying the CIFS links, for
_AN_str_filelinks
example, Files.
Whether integration of DesktopDirect resources
_AN_show_desktop with the portal is enabled.
 true: Enabled

Variable Meaning
 false: Disabled
Whether DesktopDirect resources are displayed
DesktopDirect resources.
_AN_desktop_newwindow  true: Displayed in a new window by clicking
the hyperlink on the welcome page.
 false: Embedded in the welcome page.
Whether the DesktopDirect initiation mode is
“java”:
 true: “java” that the DesktopDirect client is set
_AN_desktop_java_client
up with Java components
 false: “activex” that the DesktopDirect client
is set up with ActiveX components.
Whether auto-switch of DesktopDirect initiation
mode is enabled.
_AN_desktop_autoswitch
 0: Disabled
 1: Enabled
Label of the area displaying DesktopDirect
_AN_str_dd resources when they are embedded with the
welcome page.
Label of the hyperlink by clicking which
_AN_str_my_desktop DesktopDirect resource will be displayed in a new
window.
Whether to show or hide he navigational bar on the
page. With the bar, users can input a URL and then
_AN_neednavbar navigate it.
 true: Show the navigational bar.
 false: Hide the navigational bar.
Whether the logout link is displayed.
_AN_needlogoutlink  true: Displayed
 false: Not displayed
_AN_user Username.
_AN_str_logout String displayed for the Logout link.
_AN_str_help String displayed for the Help link.
_AN_str_pagetitle Title displayed in the welcome page.
_AN_str_msg_welcome Message used to welcome the user.
_AN_str_title_welcome Tab title of the welcome page.
_AN_str_browse Title of the area providing URL searching.
_AN_str_go Label of the button for searching the entered URL.
Whether changing the user password is allowed for
the first AAA server. When allowed, the change
_AN_enable_changepass1 password link will be displayed on the welcome
page.
 true: Allowed

Variable Meaning
 false: Not allowed
Label of the change password link for the first
_AN_str_changepass1
AAA server
URL of the change password page for the first
_AN_changepassurl1
AAA server
String that is displayed on the welcome page when
the first AAA server is an LDAP server and the
_AN_str_msg_ldap_pwd_expiring_title1
LDAP password is going to expire. For example, it
can be “Your password will expire in”.
_AN_str_msg_ldap_pwd_expiring_day1 String of “day”
_AN_str_msg_ldap_pwd_expiring_hour1 String of “hour”
_AN_str_msg_ldap_pwd_expiring_minute1 String of “minute”
_AN_str_msg_ldap_pwd_expiring_second1 String of “second”
the second AAA server. When allowed, the change
password link will be displayed on the welcome
_AN_enable_changepass2
page.
 true: Allowed
Label of the change password link for the second
_AN_str_changepass2
AAA server
URL of the change password page for the second
_AN_changepassurl2
AAA server
the second AAA server is an LDAP server and the
the third AAA server. When allowed, the change
password link will be displayed on the welcome
_AN_enable_changepass3
page.
 true: Allowed
Label of the change password link for the third
_AN_str_changepass3
AAA server
URL of the change password page for the third
_AN_changepassurl3
AAA server
the first AAA server is an LDAP server and the

Variable Meaning
Whether the option to extend the session lifetime is
enabled.
_AN_enable_sess_mng
 true: Enabled
 false: Disabled
File name: an_dd.js
This file is used to define the DesktopDirect information integrated with the virtual portal.
Variable Meaning
_AN_str_second The unit in seconds.
_AN_str_initializing Message displayed after the user passed the authentication.
Message indicating the resources assigned to the user are retrieving,
_AN_str_retrieving
which is displayed after the configuration file has been retrieved.
_AN_str_downloading Message indicating client components are being downloaded.
_AN_str_unknown_state Unknown state of the desktop.
_AN_str_power_up Message indicating that the desktop is powered up.
_AN_str_connecting Message indicating that the desktop is being connected.
_AN_str_connected Message indicating that the desktop has been connected.
_AN_str_disconnecting Message indicating that the desktop is being disconnected.
Message indicating that the ART server is verifying the availability
_AN_str_verify_desktop
of the desktop.
_AN_str_power_up_fail Error message indicating the desktop fails to be powered up.
_AN_str_session_expire Error message indicating the session has expired due to inactivity.
Message prompting the user that their sessions will be terminated in
_AN_str_due
certain period of time due to inactivity.
_AN_str_sess_expire Error message indicating the session has expired.
Message prompting the user that their sessions will be terminated in
_AN_str_terminate
certain period of time.
Message prompting the user to save their work before session
_AN_str_save_work
termination.
Message providing the measures to avoid session termination due to
_AN_str_avoid
inactivity.
_AN_str_unkown_error Unknown error.
_AN_str_case1~25 Error messages displayed in various cases.
_AN_str_turn_off Message to indicate the desktop is power off.
_AN_str_turn_on Message to confirm whether to power on the desktop.
_AN_str_connection_type Label for setting the network type.

Variable Meaning
_AN_str_slow_dialup Slow Dialup.
_AN_str_fast_dialup Fast Dialup.
_AN_str_broadband Broadband.
_AN_str_custom Custom.
_AN_str_disable_option Label of the check box group.
_AN_str_bitmap Label of the Bitmap check box.
_AN_str_wallpaper Label of the Wallpaper check box.
_AN_str_full_window Label of the Full Window check box.
_AN_str_menu_animation Label of the Menu check box.
_AN_str_themes Label of the Themes check box.
_AN_str_screen_size Label for setting screen size.
_AN_str_full_screen Full screen.
_AN_str_width Width of the screen.
_AN_str_height Height of the screen.
_AN_str_color_depth Label for setting color depth.
_AN_str_default Default color depth.
_AN_str_256_color 256 color depth.
_AN_str_high_color High color (16 bits) depth.
_AN_str_true_color True color (32) depth.
_AN_str_32bit_color Highest quality(32 bits).
_AN_str_sound Label of the drop-down list box for sound setting.
_AN_str_play_sound_1 Option 1 in the drop-down list box: Play Sounds on This Computer.
_AN_str_play_sound_2 Option 2 in the drop-down list box: Play Sounds on The Server.
_AN_str_play_sound_3 Option 3 in the drop-down list box: Do Not Play Any Sounds.
Label for the Connect to Console check box. When selected, the user
_AN_str_connect_console is allowed to create connection to the console session of a Windows
2008 Terminal Server.
_AN_str_redirection Option for the resource redirection function.
_AN_str_drives Label for the drivers check box.
_AN_str_printers Label for the printers check box.
_AN_str_clipboard Label for the clipboard check box.
_AN_str_ports Label for the serial ports check box.
_AN_str_smart_cards Label for the smart cards check box.
_AN_str_install Message indicating client components are being installed.
_AN_str_take_a_while Message displayed when the user needs to wait for a while.
_AN_str_retrieve_config Message indicating the configuration file is being retrieved.
File name: an_ldappasschange.js
This file is used to define the information displayed on the page for changing user’s LDAP
password.

Variable Meaning
Label of the change password button and the tab title of the
_AN_str_button_passchange
change password page
_AN_str_title_passchange Title of the change password page
_AN_str_help Label of the help link
_AN_str_errmsg_passchange
_AN_str_info_passchange String giving tips on changing password
_AN_str_newpass Label of the new password text box
_AN_str_confirm Label of the confirm password text box
_AN_str_cancel Label of the cancel button
_AN_str_error_pass Error message indicating that the new password is not accepted
because the length is longer than 32 characters.
File name: an_logout.js
This file is used to define the information displayed on the logout page.
Variable Meaning
_AN_str_title_logout The title of the logout page.
_AN_str_title_cache_cle The title of the logout page for cache clean.
an
_AN_str_bye The string indicating goodbye message.
_AN_str_info The information shown to indicate that the user has logged out.
_AN_str_hint The information shown to indicate what the user should do.
_AN_str-close The string prompting users to close the window.
File name: an_vpn.js
This file is used to define the information displayed on the VPN connection page.
Variable Meaning
_AN_str_title_starting The title of the page.
_AN_str_notsupport The information shown to users when the browser does not support
VPN.
_AN_str_startvpn The string indicating VPN is starting.
_AN_str_info_vpn The VPN information shown on the page.
_AN_str_info_vpn2 The VPN information shown on the page.
_AN_str_info_wait The waiting information shown on the page.
_AN_str_failmsg_vpn The fail information shown on the page.
_AN_redirecturl Which URL should be redirected to after VPN is launched
successfully.
_AN_activex_client Enable IE users to start ActiveX control.
_AN_java_client Whether Java Applet should be used.
_AN_vsite_name Virtual site name.
_AN_vsite_port Virtual site port.

Variable Meaning
_AN_sessionid The session ID of the user logged in.
_AN_username The name of the user logged in.
File name: an_chal.js
This file is used to define the information displayed on the RADIUS challenge page.
Variable Meaning
_AN_str_title_challenge Title of the challenge page.
_AN_str_signin Label for the login button.
_AN_str_cancel Label for the cancel button.
_AN_str_password Label for the password field.
_AN_str_info_chal The information on the challenge page.
_AN_str_errmsg_char The error message on the challenge page.
File name: an_sms.js
This file is used to define the information displayed on the SMS authentication page.
Variable Meaning
_AN_str_title_otp Title of the SMS authentication page.
_AN_str_otp_result Result of verification code checking or resending.
_AN_str_otp_message Message displayed on the SMS authentication page.
_AN_str_resend Label for the resend button.
_AN_str_submit Label for the submit button.
_AN_str_vcode Name of the text box for inputting the verification code.
_AN_str_otp_resend Whether the user can resend the verification code.
File name: an_smx.js
This file is used to define the information displayed on the SMX authentication page.
Variable Meaning
_AN_str_title Title of the SMX authentication page.
_AN_str_username Label for the username field.
_AN_str_password Label for the password field.
_AN_str_currentpass Label for the current password field.
_AN_str_newpass Label for the new password field.
_AN_str_confirm Label for the confirm password field.
_AN_str_submit Label for the submit button.
_AN_error_msg The error message returned by the SMX server.
_AN_LoginID The ID used to log into the virtual site or to change password.
_AN_matrixResource Generate the Matrix table
_AN_boxCount The type of the Matrix table, with three or four columns
_AN_charcheck Case sensitivity of password

Variable Meaning
_AN_smxRecpNo Transaction number
_AN_posPassword Pattern and sequence of new password
The action to be performed, including:
 CONFIRM_PASSWORD: verify password in normal
authentication.
 GET_MATRIX_RESOURCE_C: verify old password in
_AN_action
password change
 COMMIT_PASSWORD: enter new password in password
change
 DECIDE_PASSWORD: confirm the password change
7.4 Special Type of Portal Links

A special type of portal links can be added on the portal pages of Portal Custom and Portal Theme.
After the end user clicks on this portal link, the VPN tunnel will be automatically launched.
The URL of this type of Web links is formatted as:
https://www.hostname.com/prx/000/http/localhost/autolaunch.html?url=http://192.168.1.1/vedio/0
01.html
The first part “www.hostname.com” stands for the hostname of the virtual site; the second part
“/prx/000/http/localhost/autolaunch.html?url=” is fixed; the third part
“http://192.168.1.1/video/001.html” is an example for the internal URL that will be accessed
through the VPN tunnel.
7.5 User Resource

The user resource function allows the site administrator to publish user resources to all end users,
such as installation packages of the Standalone Array Client and user manuals, on the virtual
portal. After logging in to the virtual portal, end users can download the desired user resources via
the displayed link.
Note:
 The maximum size of a single user resource file allowed to be uploaded is 100 MB
and the maximum size of user resource files allowed to be uploaded to all virtual
sites is 1 GB.
 Because end users can download the published user resource without login if already
knowing the URL address of the resource, it is recommended that the site
administrator should publish public resources only.

7.6 DesktopDirect Integration

The DesktopDirect Integration function allows the virtual portal to integrate DesktopDirect
resources assigned to the user. AG provides two integration modes:
 Embed: DesktopDirect resources are displayed on the welcome page just like Web resources
and other resources.
 Hyperlink: A hyperlink to DesktopDirect resources is displayed on the welcome page.

DesktopDirect resources will be displayed in a new window after you click the hyperlink.
AG supports setting up and initializing the DesktopDirect client with Java or ActiveX components.
Also, AG supports auto-switch of the DesktopDirect initiation mode from “activex” to “java”
when the DesktopDirect client cannot be set up with ActiveX components in the user’s PC
environment.
Either on the welcome page or in the new window, the user can click any desktop or application
icon to access the desktop or application.

7.7 Bookmark
The bookmark function allows the end user to add bookmarks for resources on the virtual portal.
AG now supports adding bookmarks for three types of resources: Web, File Share and Desktops.
With this function, end users can add the frequently accessed Web sites, remote servers and
desktops on the virtual portal as bookmark links and access these resources conveniently by
clicking these bookmark links in future.
Note:
 This function does not work in the HA environment.
 The “portal desktop embed” command must be configured to display the bookmark
option for desktops.
 For an end user that supports multiple AAA methods, the user has the same
bookmark list when logging into the portal using different AAA methods.
 This function does not work when a AAA method not validating usernames, such as
anonymous certificate authentication, is used.
7.8.1 Default Portal Theme

By default, the portal page appearance is provided by AG, as shown in Figure 7–3.

Figure 7–3 Default Portal Theme
Administrators can customize the default portal theme via WebUI. Under the virtual site scope,
select Site Configuration > Portal > General Settings > Common Settings, where
administrators can change the portal language, enable LocalDB users changing password on the
portal, import logos using local file or URL, set character set and define type of encoding
conversion (HTML to binary), as shown in Figure 7–4.
Figure 7–4 Common Settings of Default Portal Theme
Note: Before going to the next tab, please remember to click Apply Changes to make
your configurations take effect.
The login page and welcome page can also be customized. Under the virtual site scope, select Site
Configuration > Portal > General Settings > Portal Pages, where administrators can define the
login message, enable the portal page to remember the username and define welcome page title
and message, and define the OTP page title and message, as shown in Figure 7–5.

Figure 7–5 Customize Portal Pages of Default Portal Theme
Note: When Language is set to a non-UTF-8 format language under the Common
Settings sub-tab, such as “chinese-Big5”, or “chinese-GB2312”, the administrator needs
to convert the characters into the Unicode format before configuring portal pages. While
Language is set to a UTF-8 format language, such as “english”, “japanese”, “chinese”, or
“chinese-traditional”, the administrator can enter the characters directly when configuring
portal pages.
7.8.2 Virtual Portal Custom

Administrators can customize Login page, Welcome page, Change password page, Change
password OK page and Logout page via Site Configuration > Portal > External Pages > Portal
Pages under the virtual site scope, as shown in Figure 7–6.
Figure 7–6 Customize Portal Pages
In Figure 7–6, the parameters User Name and Password, Token and Password define the fields
to be passed to the backend server. For the Change password page, different methods require
different Web pages. For example, a method with LDAP server as the authentication server
requires the HTTP POST to be sent to the LDAP server, and a method with RADIUS server as the
authentication server will require that the HTTP POST to be sent to the RADIUS server
Besides the above-mentioned portal pages, error pages can also be easily customized. Under the
virtual site scope, select Site Configuration > Portal > External Pages >Error Pages, as shown
in Figure 7–7.

Figure 7–7 Customize Error Pages
Click the Add button on the upper right corner, select the error type and specify the URL in the
Figure 7–8 Add an Error Page
7.8.3 Custom Portal Theme

Under the virtual site scope, select Site Configuration > Portal > Themes, and click the
Download Template button on the upper side of the page to download the portal theme template,
Figure 7–9 Portal Theme Import
After customizing the downloaded portal theme template, click the Import Theme button on the
upper side of the page to add a portal theme, as shown in Figure 7–9.

In the Import Theme configuration window, select a local file or a remote file by URL, define a
theme name, and then click the Import button to import the theme, as shown in Figure 7–10.
Figure 7–10 Import the Portal Theme
The imported local file must be a ZIP file. For the directory in the file, please refer to Table 7–1
and Table 7–2.
 Edit Source Code of Imported Portal Page File
In the Themes table, double-click the imported portal theme packet, as shown in Figure 7–11.
Figure 7–11 Imported Portal Theme Packet
In the Theme Objects table, double click the object entry that you want to modify, as shown in
Figure 7–12.
Figure 7–12 Theme Objects
In the Object Resources table, click the Edit action link, as shown in Figure 7–13.

Figure 7–13 Edit Source Code of Object Resource
In the Edit Object Resources area, modify the source codes as you want and click the Save
action link to save the modified object resource, as shown in Figure 7–14.
Figure 7–14 Save Modified Object Resource
7.8.4 User Resource

Under the virtual site scope, select Site Configuration > Portal >User Resources, and click the
Import User Resource action link to add a user resource, as shown in Figure 7–15.
Figure 7–15 User Resource Import
In the Import User Resource configuration window, select a local file, specify the Description,
and then click the Import button to import the user resource, as shown in Figure 7–16.

Figure 7–16 Import the User Resource
7.8.5 DesktopDirect Integration

Under the virtual site scope, select Site Configuration > Portal > DesktopDirect, select the
Enable DesktopDirect Integration and Enable Initiation Mode Autoswitch check boxes,
specify the parameters Integration Mode and Initiation Mode, and click the Apply Changes
Figure 7–17 Configure DesktopDirect Integration
7.8.6 Bookmark
Before using the bookmark function, please login into the virtual site first.
 Add a bookmark
To add a bookmark link for a resource, please click the Add Bookmark link on the Welcome page,
Figure 7–18 Bookmark
Specify the parameters URL and Description, as shown in Figure 7–19.

Figure 7–19 Add a Bookmark Link
 Edit a bookmark
To edit an existing bookmark link, click the button at the right of the bookmark link to be
edited, as shown in Figure 7–20.
Figure 7–20 Edit a Bookmark Link
 Delete a bookmark
To delete an existing bookmark link, click the button on the right of the bookmark link to be
deleted, as shown in Figure 7–21.

Figure 7–21 Delete a Bookmark Link
7.9 Single Sign-On (SSO)

The Single Sign-On (SSO) function allows users to access backend applications without entering
login credentials after portal login. AG now can support SSO in two different scenarios:
 Scenario 1: Portal login credential = Application login credential
Figure 7–22 SSO Scenario 1
In this scenario, the virtual portal and backend application server share the same AAA server, and
the portal and application login credentials are the same. When the user accesses the backend
application after portal login, the login credential will be passed to the application server for
authentication.
 Scenario 2: Portal login credential ≠ Application login credential
Figure 7–23 SSO Scenario 2
In this scenario, the virtual portal and the backend application server use different AAA servers,
and the portal and application login credentials are different (even the usernames can be different).
When the user accesses the backend application after portal login, the user is required entering the
application login credential. The Application SSO function allows the application login credential
to be passed to the backend application server on behalf of the user.
Note: The portal login credential refers to the first login credential if multiple-factor
authentication is used in any SSO scenario.

7.9.1 Single Sign-On (SSO)

With the SSO function, the portal credential will be passed to the backend application server for
authentication when the portal and application login credentials are the same. This function works
for Web, File Share and DesktopDirect applications. SSO is always enabled for File Share
applications, and can be enabled for both Web and DesktopDirect applications by the
administrator.
7.9.1.1 SSO for Web
For Web applications, the SSO function supports the NT LAN Manager (NTLM) authentication,
HTTP Basic authentication and Post authentication methods.
 NTLM authentication
NTLM employs a challenge-response mechanism for authentication. AG sends the challenge

message to the backend Web server on behalf of users so that the users can prove their identities
without sending a password to the backend Web server.
 HTTP Basic authentication
AG used the cached portal login credential and forwards the HTTP requests with the header
containing the token Basic and base64-encoded credential.
 SSO Post
When the requested URL matched the SSO post rule, AG uses the cached credential to construct
and send the HTTP form-based post request to the backend Web server on behalf of the user.
 Frontend SSO Post
When the requested URL matched the SSO post rule, AG returns the HTTP response containing
HTTP forms and AG-generated Javascript codes to the client that executes the Javascript codes to
automatically construct and send the HTTP form-based post request.
Only Frontend SSO Post can work along with the Session Reuse feature. What’s more, Front SSO
Post can stay effective as long as the session is alive, while the other three methods mentioned
above can only work once in a session life.
Note:
 If the requested Web URL is a direct link, the client will send the post request
directly to the backend server.
 If the requested Web URL is not a direct link, the client will send the post request to
AG first and AG forwards the request to the backend Web server.

7.9.1.2 SSO for DesktopDirect
For detailed introduction to and configuration example of SSO for DesktopDirect, please refer to
the DesktopDirect Administration Guide.
7.9.2 Application SSO

The Application SSO function enables application login credentials to be passed to the backend
application servers for the login users when the portal and application credentials are different.
This function works for Web, Fileshare and DesktopDirect applications. By default, this function
is disabled for Web, Fileshare and DesktopDirect applications.
To use this function, you also need to configure application login credentials for login users in the
LocalDB server even if the LocalDB server is not used for authentication. The portal login
username must be the same as the LocalDB account username associated with the application
login credential.
Note: If the Application SSO function is enabled for DesktopDirect applications, the
administrator needs to associate the DesktopDirect resources with the application login
usernames used for Application SSO instead of the binding LocalDB accounts.
7.9.3 Configuration Examples
7.9.3.1 SSO for Web
To enable the Single Sign-On function, select Access Methods > Web Access >Server Access >
General Settings under the virtual site scope, select the Enable Single Sign-On check box in the
SSO Settings area, and click the Apply Changes button, as shown in Figure 7–24.

Figure 7–24 Enable SSO
7.9.3.1.1 SSO Post
To add an SSO post rule, click the Add action link in the SSO Post area, as shown in Figure 7–24.
In the Add SSO Post configuration window, specify the parameters as needed, and click the Save
action link to save the configuration, as shown in Figure 7–25.
Figure 7–25 Add SSO Post
7.9.3.1.2 Frontend SSO Post
 Enable Frontend SSO Post for a WRM Resource
action link in the WRM Resources area, select the Enable Frontend SSO check box in the Add
WRM Resource configuration window, as shown in Figure 7–26.
Figure 7–26 Enable Frontend SSO Post for a WRM Resource
 Enable Frontend SSO Post for a DirectLink Resource

action link in the WRM Resources area, select the Direct link and Enable Frontend SSO check
boxes in the Add WRM Resource configuration window, as shown in Figure 7–27.
Figure 7–27 Enable Frontend SSO Post for a DirectLink Resource
 Enable Frontend SSO for a QuickLink Resource
action link in the QuickLink Resources area, select the Enable Frontend SSO check box in the
Add QuickLink Resource configuration window, as shown in Figure 7–28.
Figure 7–28 Enable Frontend SSO for a QuickLink Resource
7.9.3.2 Application SSO
7.9.3.2.1 Application SSO for Web
Under the virtual site scope, select Site Configuration > Security Settings > Application SSO,
select the Enable Application SSO for Web check box in the General Settings area and click
the Apply Changes button, as shown in Figure 7–29.

Figure 7–29 Enable Application SSO for Web
7.9.3.2.2 Application SSO for File Share
select the Enable Application SSO for Fileshare check box in the General Settings area and
click the Apply Changes button, as shown in Figure 7–30.
Figure 7–30 Enable Application SSO for File Share
7.9.3.2.3 Application SSO for DesktopDirect
select the Enable Application SSO for DesktopDirect check box in the General Settings area
and click the Apply Changes button, as shown in Figure 7–31.
Figure 7–31 Enable Application SSO for DesktopDirect
7.9.3.2.4 Add the Application Login Credential to the LocalDB Account
 Add the Application Login Credential to an Existing LocalDB Account
1. Under the virtual site scope, select Local Database > Local Accounts > Local Accounts,
click a LocalDB account entry in the Local Accounts List table, as shown in Figure 7–32.

Figure 7–32 Edit an Existing LocalDB Account
2. In the Application SSO area of the displayed window, specify the parameters User Name,
Password, Confirm Password and Application Domain, and click the Save action link, as

Figure 7–33 Add the Application Login Credential to an Existing LocalDB Account
 Add a New LocalDB Account with the Application Login Credential
1. Click the Add action link in the Local Accounts List table, as shown in Figure 7–32.
2. In the Add Local Account area, specify the local account parameters as required and specify
the parameters User Name, Password, Confirm Password and Application Domain in the
Application SSO area, and click the Save action link, as shown in Figure 7–34.

Figure 7–34 Add a New LocalDB Account with the Application Login Credential

Chapter 8 High Availability
8.1 Clustering
8.1.1 Overview
The Array Clustering function allows you to maintain high availability within a local site. With
other options you can also distribute load across multiple boxes within a cluster.
8.1.2 Understanding Clustering

The Clustering function allows two or more AG appliances to be grouped together to form a
logical device, which provides scalability and high availability within a local site. Please refer to
the following figure.
Figure 8–1 AG Clustering
Clustering can be configured in Active-Standby (A/S) or Active-Active (A/A) mode:
 Active-Standby mode – In Active-Standby mode, all VIPs on one AG appliance in the

cluster will be the master, and all VIPs on the other AG appliances in the cluster are standby.
In this mode, clustering supports fast failover.
 Active-Active mode – In Active-Active mode, each AG appliance in the cluster has a

different master VIP or cluster ID.
Note: In Array clustering technology, please make sure all the appliances in a cluster
domain have the same features licensed, the same device module and software version
installed.

8.1.3 Configuration Synchronizing

In order to ease the administrative tasks related to AG appliance configuration, administrators can
use the synchronizing technology to push configuration from one AG appliance to one or more
other AG appliances on the same network using a single command.
Both bootup configuration synchronization and runtime configuration synchronization are

supported by HA.
Array synchronizing technology requires that all appliances in the same cluster domain have the
same licensed features. Also, each appliance on the network must first be configured with its basic
unique parameters (for example, unique IP address, hostname, etc.) and then be configured with a
list of all its peers. Furthermore, the virtual portals that are clustered together should have the
same configuration across all appliances.
Once all appliances are ready, the administrator can initiate the synchronization process from any
appliance in the cluster (for example, mostly likely the appliance with a “master” configuration).
After the configuration synchronization is complete, the new configuration is automatically saved
to the hard drive of each target appliance so that the appliance will remember the latest
configuration even after a reboot.
Please note that the following configurations will not be synchronized:
 Bond configurations
 Host name
 Interface IP address
 Interface name
 IP route
 Virtual cluster priority configurations
 VLAN configurations
 WebUI IP address
8.1.4 Failover
Array Clustering technology allows two or more AG appliances to be clustered together to form a
logical appliance working as a single unit.
Administrators can assign a priority (from 1 to 255) to each AG appliance in the cluster. The
higher the number, the higher the priority of the appliance is compared to its peers. The appliance
with the highest priority becomes the master (active unit) of a cluster domain.
AG appliances in the cluster group use VRRP protocol to exchange the information between
Active and Standby appliances. The Array cluster VIP uses the MAC address of the Active
appliance to process traffic from any clients on the networks. Failover occurs when the standby

appliance does not receive the VRRP messages sent out by the Active appliance within the given
time threshold. During a failover, the Standby appliance will immediately announce ownership of
the serving IP address and send free ARP to update the ARP table of the switch or other devices
In addition, administrators can enable the preemption mode for an appliance of the cluster. If the
preemption mode has been enabled on the initial Active appliance, it will reassume mastership as
soon as it returns to normal working state. Otherwise, the new Active unit will continue serving
traffic until the unit fails.
8.1.5 Advanced Configuration

To achieve higher appliance utilization, administrators can configure multiple cluster pairs to pass
traffic through all appliances at the same time. The figure below shows how the cluster pairs work.
Figure 8–2 How the Cluster Pairs Work
In this case, administrators can create at least two virtual sites on an AG appliance. One virtual
site state is active and the other one is standby. On another AG appliance, the same virtual sites
are created but with opposite states. As shown in the above figure, virtual site 1 is the master of
VIP1 and processes the traffic from clients while virtual site 2 is standby on AG1. By contrast,
virtual site 2 is the master of VIP2 and processes the traffic from clients while virtual site 1 is
standby on AG2. If virtual site 1 on AG1 becomes down, virtual site 1 on AG2 will be the master
of VIP1 and take over the traffic processing. The same is the case with virtual site 2 on AG2.
8.2 High Availability (HA)
8.2.1 Overview
HA (High Availability) function, which can accommodate up to 32 AG appliances (hereinafter
referred to as “unit”), provides more comprehensive and reliable support for high availability

based on the five major features including Multiple Communication Links, Floating IP Group,
Failover Decision Rule, Configuration Synchronization and Session Stateful Failover.
These five features are interrelated and can cooperate to meet the need of high availability for
varied applications. Multiple communication links are used to check the status of the peer unit via
heartbeat packets and perform configuration synchronization between the two units. As such,
when certain failover conditions occur, the predefined failover decision rules will be enforced, and
the floating IP group, connections or sessions will be switched to the active unit.
In the remainder of this chapter, the working mechanism and functionalities of the five features
will be introduced in details.
8.2.2 Multiple Communication Links

Multiple communication links are used to connect two units in one HA domain to ensure that the
two units can exchange status information and configurations in real time. At the same time, each
link can be a backup of one another to send heartbeat packets between the two units. This is the
fundamental for the HA function to work properly.
The primary and secondary links can connect the two units via network cables, either by direct
connection or through a switched network. The primary link is mandatory and only one primary
link is supported. The secondary link is optional and a maximum of 31 secondary links are
supported. Both types of links can connect the two units via network cables, either by direct
connection or through a switched network.
Table 8–1 shows the differences and similarities between the two types of HA communication
links.
Table 8–1 Difference and Similarity among HA Links
HA Link Difference Similarity

1. Synchronize all HA-related configurations 1. Both types of links can
(functioning the same as the command be used to transmit HA
“synconfig from”) at the bootup time of HA, heartbeat packets. The
including configurations about HA groups, HA heartbeat information
secondary links, health check conditions, includes group status and
decision rules, and so on. all decision conditions (both
(HA link configurations will not be default and user defined
Primary link synchronized here.) conditions, which can be
2. Synchronize HA, and Netpool related seen by the command
configurations during the runtime of HA, “show ha condition”).
including all CLI configurations starting with: 2. When both types of links
[no|clear] ha ... become down, the peer unit
[no|clear] virtual site ... will be considered as down.
write …
3. Synchronize SSF sessions.
Secondary link The secondary link is used only for exchanging

HA Link Difference Similarity

HA heartbeat packets between the two units.
8.2.3 Floating IP Group

Floating IP addresses indicate the IP addresses that can float back and forth between units, such as
the IP addresses (VIP) of a virtual site, IP addresses in a Netpool, etc. The floating IP addresses
can be either IPv4 or IPv6 addresses. A floating IP range contains at most 256 floating IP
addresses. The floating IP addresses and ranges can be added to a pre-defined floating IP group.
The total number of floating IP addresses and floating IP ranges configured for a floating IP group
cannot exceed 16.
Note:
 The floating IP addresses or floating IP ranges must be bound with the system
interface.
 The IP addresses configured by the command “ip address” cannot be configured as

floating IP addresses.
8.2.3.1 Group Status
The status of all floating IP addresses in the same floating IP group is the same. The status is also
called the status of the floating IP group.
The status of a floating IP group is determined by the group priority, failover mode, and results of
the health checks related to the group. After the floating IP group is configured correctly, the HA
module will the check the running environment of the group based on the configured health check
conditions. Based on the health check results, the group status can be one of the following two
types:
 Active/Standby: The results of all health checks related to the group are “Up”, indicating the
group is ready to provide services. In this case, the group status is “Active” or “Standby”. If
the group status is “Active”, this unit will obtain all the floating IP addresses of the group and
provide services. If the group status is “Standby”, this unit will provide backup for services
and take over services in case of service failover.
 Init: Initial group status. If the result of any health checks related to the group is “Down”, the
group status is “Init”, which indicates that this unit is not qualified for providing services of
the group. Even if service failover occurs on the group, this unit cannot take over services.
Note: When the group status is “Init”, check the group configurations or the health check
results to make the group status change to “Active” or “Standby” so that the unit will
provide services or backup for services.

On one unit, multiple floating IP groups can be configured. The status of every group is
independent from each other. If all groups on a unit need to be switched over together, the
“Unit_Failover” mode (see the section 8.2.4 Failover Rule for details) is required.
8.2.3.2 Group Failover Mode
The HA function supports two group failover modes: non-preempt and preempt modes.
When a floating IP group is enabled on multiple units:
 In the non-preempt mode, the group status on the local unit will not change until a failover
occurs.
 In the preempt mode, if the group’s priority on the local unit is higher than those on other all
peer units, the group’s status on the local unit will be forcibly switched to “Active”. If the
group’s status on a peer unit was “Active” before this, it will be forcibly switched to
“Standby”.
8.2.3.3 Group Management
Each floating IP group can be enabled or disabled independently. The status of the group will
become “Init” when it is disabled. Once it is enabled, its status will become “Standby” or “Active”
depending on the previously defined failover mode. If it was configured with the preempt mode, it
would switch to “Active” and could start to process the traffic; if configured with the non-preempt
mode, it would switch to “Standby”.
8.2.4 Failover Rule

The HA function is capable of performing health checks on the system status and network
conditions in an HA domain. Once any failure is detected by health check and it matches one of
the pre-configured failover conditions, the corresponding failover action will be taken. Usually,
the system will select another unit which is with the highest priority among the available units and
change the status of the floating IP group enabled on that unit to be “Active” forcibly. To achieve
this, HA provides failover rules to control the switchover of group status.
Failover rules are defined by associating failover conditions with failover actions. Failover
conditions indicate the monitoring status on system hardware or software, such as network
interface status, and CPU utilization. Failover actions are the operations to be performed by the
system when the associated failover conditions occur. HA provides three failover actions:
 Group_Failover: Switch over the status of the floating IP group. For this action, the system
will select a new unit based on the health condition and group priority, and change the status
of the floating IP group enabled on that unit to be “Active” to take over the services.
 Unit_Failover: Switch over the status of all the floating IP groups enabled on a unit.
 Reboot: Switch over the status of all the floating IP groups enabled on a unit, and then restart
the unit.

8.2.4.1 Build-in Failover Rules
To facilitate use of administrators, HA also provides built-in network connectivity check to detect
network exceptions, such as network interface failure and network interruption among units. Once
any of these exceptions occurs, the system will perform failover actions automatically.
Note: Only when the network connections of all interfaces in a bond interface become
down, will the “Group_Failover” action be taken for the floating IP group to which the IP
addresses of the bond interface belong.
The administrator can execute the command “show ha decision” to view the build-in failover
rules.
AN(config)#show ha decision
ID Condition_Name Action_Name Group_ID
0 PORT_1 Group_Failover -

If an interface is detected down, group failover will be performed on the floating IP groups bound
to this interface.
8.2.4.2 Customized Failover Rules
Besides providing built-in failover rules, the HA function also allows administrators to manually
configure multiple failover rules. To do this, the following software or hardware health check
conditions can be configured as failover conditions:
 Hardware:
– CPU overheat health check condition
– SSL card health check condition
– Port health check condition (built-in health check conditions)
 Software:
– CPU utilization health check condition
– ATCP zone memory utilization health check condition
– System memory health check condition
– Network packet memory health check condition
– Process health check condition
 Network condition:
– Gateway health check condition
Apart from the preceding health check conditions, a health check condition group (virtual
condition) can also be configured as failover conditions. The sub-condition can be a real health
check condition or another virtual condition, which further comprises sub-conditions. The logical
relationship among multiple sub-conditions can be either “AND” or “OR”.
The administrator can choose Group_Failover, Unit_Failover, or Reboot as the failover action for
the configured failover conditions.
8.2.5 Configuration Synchronization

The HA function provides configuration synchronization to simplify configurations on units and
ensure the consistency of configurations among all units in an HA domain. HA supports two kinds
of configuration synchronization: Bootup Synconfig and Runtime Synconfig. The two
configuration synchronization functions can be both enabled.

Note: To use Bootup Synconfig or Runtime Synconfig, the administrator must make sure
that on each HA unit:
 All HA units have been configured as the synchronization peers.
 The same synchronization challenge code has been configured.
8.2.5.1 Bootup Synconfig
Bootup Synconfig is to synchronize the configurations of the peer unit to the local unit after the
local unit logs into the HA domain. After the local unit logs into the HA domain, it starts to
synchronize HA-related configurations from a peer unit (usually the unit first joining the HA
domain) through the primary link between them.
Before using Bootup Synconfig, the administrator needs to configure local and peer units to log
into the HA domain.
Note:
 In Bootup Synconfig, only the configurations saved by executing the command

“write memory” can be synchronized. Therefore, please execute the command
“write memory all” on the peer unit before Bootup Synconfig; otherwise the
configuration may be inconsistent between HA units.
 The interface name on different units in an HA domain should be the same;

otherwise, configurations might be lost after the “synconfig to/from” operations.
8.2.5.2 Runtime Synconfig
Runtime Synconfig is to synchronize the add/deletion/change of configurations on the local unit to

other units in the same HA domain automatically while the HA is running. This ensures that the
configurations on all units in one HA domain are always the same.
The administrator can view the blacklist and whitelist of Runtime Synconfig by executing the
command “show ha status”.
Note: To synchronize the configuration changes from the local unit to the peer units,
please make sure that Runtime Synconfig is enabled on both the local unit and the peer
units.
The following table displays what configurations Bootup Synconfig and Runtime Synconfig can
synchronize.

Table 8–2 Configurations Supported by Bootup Synconfig and Runtime Synconfig
Bootup Runtime
Item
Synconfig Synconfig
General Settings Y1 Y1
Basic Networking N2 N2
System Advanced Networking Y3 Y3

Configuration Clustering Y4 Y4
High Availability Y5 Y5
Global
WebWall N N
Configuration
Global Admin Y Y
Site Admin Y Y
Administrators Admin Roles Y Y
Site Access Y Y
Admin AAA Y Y
SSL/DTLS Certificates Y Y
Security Settings (Client

Y Y
Security/Application SSO)
Site Configuration
AAA Y Y
Portal Y Y
Networking Y Y
LocalDB General Settings Y Y

Site
Configuration Local Accounts Y Y
Local Database
Local Groups Y Y
Login Authorization Y Y
Web Access Y Y
Access Methods File Access Y Y
VPN Y Y6
Role Y Y
User Policies
ACLs Y Y
Replication N N
Client Package N N
DesktopDirect7 General
Published Applications Y Y
External Providers Y Y

Bootup Runtime
Item
Synconfig Synconfig
Data Protection Policies Y Y
Client Settings Y Y
Client Verification Y Y
Instance General Settings Y Y
Users and Groups Y Y
Power Management Y Y
Device Based
Instances Y Y
Identification
Host SSO Y Y
Registration Policies Y Y
VMView Credentials Y Y
Authentication Y8 Y8
Authorization Y Y
AAA
Auditing Y9 Y9
DeviceID Information Y Y
Authorized Web Resources Y Y

Resources Native Applications Y Y
MotionPro
VPN on Demand VPN on Demand Y Y
Enterprise Enterprise Application

Y Y
Application Store Store
Security Policies Y Y
Enterprise
Application Remote Device
Y Y10
Security Management
Note:
1. Host name, date and time cannot be synchronized.
2. Exception: Bootup Synconfig can synchronize the speed and MTU of the interface,
name resolution host and DNS. Runtime Synconfig can synchronize the interface
port name and the configurations which Bootup Synconfig can synchronize.
3. NAT configurations cannot be synchronized.
4. Virtual cluster priority configuration cannot be synchronized.
5. “ha on|off”, “ha synconfig runtime on|off”, “ha group enable|disable”, and “clear

ha all” cannot be synchronized.
6. For the same virtual site, Netpool’s dynamic IP ranges for HA units must be
different, and the “unit name” parameter of the “vpn netpool iprange dynamic”
command must be specified so that Runtime Synconfig can synchronize this
command.
For example, the following two commands can be successfully synchronized:
vs(config)$vpn netpool iprange dynamic “netpool1” 192.168.0.101 192.168.0.110 “unit1”
vs(config)$vpn netpool iprange dynamic “netpool1” 192.168.0.111 192.168.0.120 “unit2”
However, the command below without a “unit name” cannot be synchronized:
vs(config)$vpn netpool iprange dynamic “netpool1” 192.168.0.101 192.168.0.120
7. For ART database configuration, please execute “write memory all” before Bootup
Synconfig.
8. SMX server configurations cannot be synchronized.
9. The device auditing information on AGs is logs that can be backed up to the log
server. However, the device auditing information cannot be synchronized.
10. Although the device authentication information collected when users log in can be
synchronized, the device information collected after MDM is enabled cannot be
synchronized.
8.2.6 Session Stateful Failover (SSF)

The Stateful Session Failover (SSF) function is used by HA to synchronize session information
between units.
The session information processed by each floating IP groups will be synchronized in real time
from a unit on which the group status is “Active” to the other units on which the group status is
“Standby”. In this way, when group failover occurs, one of the “Standby” units can take over
existing sessions processed by this group. However, the clients need to reestablish connections to
this group on the new unit. The new unit will reuse the session information and therefore clients
do not need to go through the login, authentication, authorization, and other processes again.
The session information synchronized by SSF includes:
 Username
 Virtual site name
 Role name
 AAA method name
 Client Security settings

8.2.7 HA Deployment Scenarios

The HA function can be deployed flexibly. Besides the Active/Active and Active/Standby
deployment scenarios between two appliances, the HA function can be deployed among multiple
appliances to achieve mutual-backup.
 Active/Standby: The HA domain comprises two units; the status of all floating IP groups are
“Active” on one unit and “Standby” on the other unit.
 Active/Active: The HA domain comprises two units; on each unit, there are “Active” floating
IP groups and “Standby” floating IP groups, the status of which are “Active” on the peer unit.
The HA domain comprises two units.
 When the HA function is deployed among multiple appliances to achieve mutual-backup, the
HA domain comprises multiple units to provide services or backup for services. Among these
scenarios, the “N+1” deployment scenario is the commonest one. In this scenario, the HA
domain contains N+1 units. On N units, the status of the floating IP groups are all “Active”,
while on the remaining one unit, the status of the floating IP groups are all “Standby”.
8.2.8 Configuration Examples

The HA configuration may vary with the three deployment scenarios. The following sections will
describe the details.
Section 8.2.8.4 covers the detailed steps commonly used in HA configuration.
Sections 8.2.8.1 to 8.2.8.3 introduce detailed configuration steps of each scenario respectively.
8.2.8.1 Configurations for the Active/Standby Deployment
Scenario
8.2.8.1.1 Configuration Objectives
 The HA domain contains two HA units, each of which is enabled with the same floating IP
group.
 The group status is “Active” on unit 1 and “Standby” on unit 2.
8.2.8.1.2 Configuration Guidelines
 Configurations on Unit 1
 Add two HA units (1 and 2) according to section 8.2.8.4.1 Add HA Units.
 Configure the synconfig challenge code and synconfig peers according to section 12.4.5
Configuration Synchronization.
 Configure the floating IP group 1 and make the group priority on unit 1 higher than on unit 2
according to section 8.2.8.4.2 Configure HA Groups.

 Add health check conditions and failover rules according to sections 8.2.8.4.3 Add Health
Check Conditions and 8.2.8.4.4 Add Failover Rules.
 Enable the SSF, Bootup Synconfig, Runtime Synconfig, and the HA function according to
section 8.2.8.4.5 Enable SSF, Configuration Synchronization and HA.
Bootup Synconfig allows a new AG appliance to synchronize HA-related configurations from an

existing HA units after it joins the HA domain. This highly simplifies the HA configurations. By
using Bootup Synconfig, the administrator only needs to perform the following steps:
 Enable the Bootup Synconfig and HA functions according to sections 8.2.8.4.3 Add Health
After the HA function is enabled on unit 2, unit 2 starts to synchronize HA-related configurations
from unit 1 through the primary link between them.
8.2.8.2 Configurations for the Active/Active Deployment
Scenario
 The HA domain contains two HA units and provides two floating IP groups.
 The status of group 1 is “Active” on unit 1 and “Standby” on unit 2, while the status of group
2 is “Active” on unit 2 and “Standby” on unit 1.
 Configure two floating IP groups (1 and 2) according to section 8.2.8.4.2 Configure HA

Groups. Make sure that the priority of group 1 is higher on unit 1 than on unit 2 and that the
priority of group 2 is higher on unit 2 than on unit 1.


existing HA units after it joins the HA domain. This highly simplifies the HA configurations. By
using Bootup Synconfig, the administrator only needs to perform the following steps:
 Enable the Bootup Synconfig and HA functions according to section 8.2.8.4.5 Enable SSF,
Configuration Synchronization and HA.
After the HA function is enabled on unit 2, unit 2 starts to synchronize HA-related configurations
from unit 1 through the primary link between them.
8.2.8.3 Configurations for the N+1 Deployment Scenario
In the N+1 deployment scenario, the HA domain contains N+1 units. On N units, the status of all
the floating IP groups are “Active”, while on the remaining one unit, the status of all the floating
IP groups are “Standby”. This section will introduce the configuration objectives and guidelines
by taking the “3+1” deployment scenario as an example.
 The HA domain contains four HA units (1 to 4) and provides three floating IP groups (1 to
3).
 The status of three groups are “Active” on unit 1~3, respectively, and are all “standby” on
unit 4.
 Add four HA units (1 to 4) according to section 8.2.8.4.1 Add HA Units.
 Configure three floating IP groups (1 to 3) according to section 8.2.8.4.2 Configure HA

Groups. Make sure the group configurations meet all the following conditions at the same
time:
– Group 1 is enabled on both unit 1 and unit 4 and the group priority is higher on unit 1
than on unit 4.
than on unit 4.

than on unit 4.
 Configurations on Units 2~4

existing HA units after it joins the HA domain. The administrator can use Bootup Synconfig to
simplify the HA configurations on units 2~4 as follows:
 Add four HA units (1 to 4) according to section 8.2.8.4.1 Add HA Units.
 Enable the Bootup Synconfig and HA functions according to section 8.2.8.4.5 Enable SSF,
Configuration Synchronization and HA.
8.2.8.4 HA Common Configuration Steps
8.2.8.4.1 Add HA Units
Under the global scope, select System Configuration > High Availability > General, and click
the Add button in the Unit area, as shown in Figure 8–3.

Figure 8–3 General Settings of HA
In the Add HA Unit configuration window, specify the parameters Unit ID, HA Unit Name,
Description, IP Address and Port, and click the Save button to save the configuration, as shown
in Figure 8–4
Figure 8–4 Add the HA Unit
Please note that for the functioning of the HA feature, at least two HA units are needed in an
domain, and at most 32 HA units are supported. After the local unit and a peer unit have been
configured, the primary link will be established automatically between them by using the units’ IP
addresses.
8.2.8.4.2 Configure HA Groups
 Add HA Groups

Under the global scope, select System Configuration > High Availability > Group, enter the
group ID in the Group ID text box and click the Add button in the Add Group area. The newly
added group will be displayed in the Group List table, as shown in Figure 8–5.
Figure 8–5 Add the HA Group
 Edit HA Groups
Double-click the group item in the Group List table to edit the HA group, and a new
configuration window will be displayed for more configurations on the HA group, as shown in
Figure 8–6.

Figure 8–6 Advanced Group Configuration
 Add Group Float IP Addresses
Click the Add button in the Float IP Address area, as shown in Figure 8–6.
In the Add Group Float IP configuration window, specify the Float IP Address and Interface,
and click the Save button to save the configuration, as shown in Figure 8–7.
Figure 8–7 Add the Group Float IP
 Add Group Float IP Ranges
Click the Add button in the Float IP Range area, as shown in Figure 8–6.
In the Add Group Float IP Range configuration window, specify the parameters Begin, End,
and Interface, and click the Save button to save the configuration, as shown in Figure 8–8.
Figure 8–8 Add the Group Float IP Range
 Add HA Group Priorities
Click the Add button in the Priority area, as shown in Figure 8–6.
In the Add Group Priority configuration window, specify the parameter s Unit ID and Priority,
and click the Save button to save the configuration, as shown in Figure 8–9 and Figure 8–10.
Figure 8–9 Add the Group Priority for Unit 1

Figure 8–10 Add the Group Priority for Unit 2
 Enable the Preempt Mode and the HA Group
In the Advanced Group Configuration window, select the Enable Group and Enable Preempt
check boxes, and click the Apply Changes button, as shown in Figure 8–11.
Figure 8–11 Enable the Preempt Mode and the HA Group
Please note that after enabling the preempt mode, the HA unit with higher priority will always
take the active mode if it is healthy.
8.2.8.4.3 Add Health Check Conditions
Health check conditions are used as the failover conditions of failover rules. HA supports various
types of health check conditions. This section use configurations of the gateway health check
conditions, CPU health check conditions, and virtual condition as an example.
 Add CPU Health Check Conditions
Under the global scope, select System Configuration > High Availability > Health Check >
CPU. Select the Enable check box and specify the Overheat Temperature parameter in the
CPU Overheat area, select the Enable check box and specify the Fatal Percent parameter in the
CPU Utilization area, and then click the Apply Changes button, as shown in Figure 8–12.
Figure 8–12 Add the CPU Health Check Condition
 Add Gateway Health Check Conditions
Click the Add button in the Gateway area under the Gateway sub-tab, as shown in Figure 8–13.

Figure 8–13 Gateway Health Check Conditions
In the Add Gateway Health Check configuration window, select a unit ID from Unit ID
drop-down list, specify the IP Address and Condition Name parameters, and then click the Save
Figure 8–14 Add the Gateway Health Check Condition
 Add HA Virtual Conditions
Under the global scope, select System Configuration > High Availability > Health Check >
Virtual Condition, click the Add button in the Virtual Condition area, as shown in Figure 8–15.
Figure 8–15 HA Virtual Condition
In the Add Virtual Condition configuration window, specify the virtual condition name in the
Name text box, specifies the Condition Name and Member Logic parameters, select the
Member Conditions check boxes and click the Save button, as shown in Figure 8–16.

Figure 8–16 Add the Virtual Condition and Member Condition
8.2.8.4.4 Add Failover Rules
Under the global scope, select System Configuration > High Availability > Decision, click the
Add button in the Rule area, as shown in Figure 8–17.
Figure 8–17 HA Failover Rule
In the Add Rule configuration window, specify the Condition Name and Action Name
parameters, and click the Save button to save the configuration, as shown in Figure 8–18.

Figure 8–18 Add the HA Failover Rule
8.2.8.4.5 Enable SSF, Configuration Synchronization and HA
Under the global scope, select System Configuration > High Availability > General, select the
Enable HA check box in the General Settings area, select the Enable SSF check box in the
Session Synchronization area, select the Enable Bootup Configuration Sync and Enable
Runtime Configuration Sync check boxes in the Configuration Synchronization area, and then
click the Apply Changes button, as shown in Figure 8–19.
Figure 8–19 Enable SSF, Configuration Synchronization and HA
Please note that the HA log function will be automatically enabled once the HA feature is enabled.

Chapter 9 WebWall
Chapter 9 WebWall
The WebWall functionality of the AG appliance allows you to create permit/deny rules to filter
packets passing through your network infrastructure. The WebWall supports the filtering of TCP,
UDP and ICMP packets that are using the IPv4 or IPv6 address. To use access lists you will define
these “permit” and “deny” rules and apply them to access groups. Once the access lists are
configured, you may apply or bind the group to an interface within the network.
The steps for basic WebWall configurations are explained in this section, along with some
advanced features and general knowledge of how WebWall works. For AG, the WebWall feature
can independently control each interface, which can be system interface, bond interface or VLAN
interface.
WebWall permits TCP and UDP health check traffic, but cannot permit ICMP health check traffic
automatically.
9.1 Understanding WebWall

WebWall is a full-fledged stateful firewall. It bridges the gap between speed and security.
Figure 9–1 WebWall
WebWall contains several security mechanisms to protect backend servers from attack, including:
 Access List filtering
 Protection against Syn-Flood, Fragmentation and DoS (Denial Of Service) attacks
 Stateful packet inspection
 Single packet attack prevention
Access List Filtering provides tight control over who may and may not enter the network by
utilizing AG’s ultra-fast rules engine. WebWall access list filtering mechanism ensures virtually

Chapter 9 WebWall
no performance loss with up to 1,000 Access List rules, while never consuming more than one
percent of the AG appliance capability.
In addition to Access List filtering, the WebWall provides stateful packet inspection and protects
against Syn-Flood, fragmentation, DoS and single packet attacks.
The WebWall is a default-deny firewall. Default-Deny refers to the notion that if you do not have
any permit rules in your access control lists, no packets will be allowed to pass through the
appliance. During the initial installation of the box it might be helpful to leave the WebWall in the
off or disengaged state until your total configuration is complete.
Note:
By default, the WebWall is turned off. The WebWall function will remain disabled until it
is activated via the “webwall on” command.
For the Configuration Synchronization feature to work, you need to define access list rules
to permit traffic to come in through port 65519 from the synconfig peers.
9.2 WebWall Configuration
9.2.1 Configuration Guidelines

Let’s start with the basic step for configuring the WebWall. To better assist you with configuration
strategies that maximize the power of the AG appliance, please take a moment to familiarize
yourself with basic network architecture.

Chapter 9 WebWall
Figure 9–2 WebWall Configuration
Then we must define what we want to deny and permit. Since “example.com” is a relatively small
site, let’s begin with the following:
 Permit port 80 to our VIP (10.10.0.10).
 Permit port 22 to the Management IP of the AG appliance for SSH access.
 Permit port 8888 to the Management IP of the AG appliance for WebUI access.
 Deny network 10.10.20.0/255.255.255.0, since that network has been abusing its privileges.
 Allow all inside hosts to ping the IP address of the interface “port2” (inside interface).
Initially we will define our access groups as follows:
 50 miscellaneous rules
 100 Management IP related rules
 150 VIP (Virtual IP) related rules

 Step 1 Configure Access lists
To add an access list, select System Configuration > Webwall >Webwall under the global scope,
and click the Add button in the Access List Configuration area.
Figure 9–3 Access List Configuration
In the Add Access List Entry configuration window, specify the necessary parameters, and click
the Save button to add access list entry.

Chapter 9 WebWall
Figure 9–4 Add the Access List Entry
 Step 2 Configure Access Group
After adding the access list, you can bind the access list to an interface by configuring an access
group.
To add an access group, select System Configuration > Webwall >Webwall under the global
scope. In the Access Group Configuration area, select an interface from the Interface
drop-down list, specify the access list ID in the Access List ID text box, and click the Add button.
Figure 9–5 Access Group Configuration
 Step 3 Configure WebWall
After configuring access list and binding the access list to an interface, you can enable WebWall
for this interface.
To do this, select System Configuration > Webwall >Webwall under the global scope, and
select the check box for the specific port in the Webwall Status area.

Chapter 9 WebWall
Figure 9–6 Enabling Webwall
Note:
 Please exercise WebWall configurations with caution. It is possible to deny yourself

from accessing the appliance if you are logged in remotely through SSH or the
WebUI. In this situation, your session will be interrupted directly before
configuration is completed.
 If you configure the DNS servers and have WebWall turned on for the destination
interface through which the DNS requests/responses go, you need to add the
corresponding access list rules to allow that traffic.
9.2.3 Verification and Troubleshooting of the WebWall

After adding all the rules, it is helpful to display the current lists and groups. To do this, employ
the following commands.
AN(config)#show accesslist
accesslist deny tcp 10.10.10.33 255.255.255.255 0 10.10.10.10 255.255.255.255 0 50
accesslist permit tcp 10.10.10.30 255.255.255.255 0 10.10.10.10 255.255.255.255 22 100
accesslist permit tcp 10.10.10.0 255.255.255.0 10.10.10.10 255.255.255.255 8888 100
accesslist permit tcp 0.0.0.0 0.0.0.0 0 10.10.10.20 255.255.255.255 80 150
accesslist permit icmp echorequest 10.10.10.0 255.255.255.0 10.10.10.10 255.255.255.255 50
accesslist permit icmp echoreply 0.0.0.0 0.0.0.0 10.10.10.10 255.255.255.255 50
AN(config)#show accessgroup
accessgroup 50 port1

Chapter 9 WebWall
If you run into problems with access lists, keep your configurations simple. With multiple access
groups, you can apply them once at a time and see which access list is causing problems. Of
course you can turn the WebWall completely off to determine if the WebWall itself is indeed
causing the problem.
To check the status of the firewall, use the “show interface” command:
AN(config)#show interface
port1(port1): flags=8843<UP,BROADCAST,RUNNING,SIMPLEX> mtu 1500
inet 10.3.20.100 netmask 0xffff0000 broadcast 10.3.255.255
inet 10.3.20.56 netmask 0xffffffff broadcast 10.3.20.56
ether 00:30:48:82:81:7a
media: autoselect (100baseTX <full-duplex>)
status: active
webwall status: OFF
Hardware is i82547gi
Input queue: 435/512 (size/max)
total: 19376 packets, good: 19376 packets, 2053879 bytes
broadcasts: 19130, multicasts: 2
11317 64 bytes, 4282 65-127 bytes,3242 128-255 bytes
522 255-511 bytes,13 512-1023 bytes,0 1024-1522 bytes
0 input errors
0 runts, 0 giants, 0 Jabbers, 0 CRCs
0 Flow Control, 0 Fragments, 0 Receive errors
0 Driver dropped, 0 Frame, 0 Lengths, 0 No Buffers
0 overruns, Carrier extension errors: 0
Output queue: 0/512 (size/max)
0 output errors
0 Collsions, 0 Late collisions, 0 Deferred
0 Single Collisions, 0 Multiple Collisions, 0 Excessive collsions
0 lost carrier, 0 WDT reset
packet drop (not permit): 0
tcp 0 udp 0 icmp 0 ah 0 esp 0
packet drop (deny): 0
5 minute input rate 2160 bits/sec, 2 packets/sec
5 minute output rate 80 bits/sec, 0 packets/sec
port2(port2): flags=8843<UP,BROADCAST,RUNNING,SIMPLEX> mtu 1500
inet 10.4.20.100 netmask 0xffff0000 broadcast 10.4.255.255
ether 00:30:48:82:81:7b
media: autoselect (100baseTX <full-duplex>)

Chapter 9 WebWall
status: active
webwall status: OFF
Hardware is i82541gi
Input queue: 71/512 (size/max)
0 input errors
0 runts, 0 giants, 0 Jabbers, 0 CRCs
0 Flow Control, 0 Fragments, 0 Receive errors
0 Driver dropped, 0 Frame, 0 Lengths, 0 No Buffers
0 overruns, Carrier extension errors: 0
Output queue: 0/512 (size/max)
0 output errors
0 Collsions, 0 Late collisions, 0 Deferred
0 Single Collisions, 0 Multiple Collisions, 0 Excessive collsions
0 lost carrier, 0 WDT reset
packet drop (not permit): 0
packet drop (deny): 0
5 minute input rate 2336 bits/sec, 3 packets/sec
5 minute output rate 224 bits/sec, 0 packets/sec
This command will also show if the interface is up and running, as well as those IP addresses
assigned to it. More detailed network information is also included, such as input queue and output
queue information.
The following explains the terms and phrases used in the output:
 Input queue size: the current occupied input.
 Input queue max: the maximum items of input.
 The numbers of different sizes: the counts of the packages of each size.
 Runt: the number of received frames that have passed address filtering that are less than the
minimum size (64 bytes from <Destination Address> through <CRC>, inclusively), and have
a valid CRC.
 Giant: the number of received frames with valid CRC field that have passed address filtering
and are larger than the maximum size.

Chapter 9 WebWall
 Jabber: the number of received frames that have passed address filtering that are greater than
the maximum size and have a bad CRC. It may be the result of a bad NIC or electronic
interfering.
 CRC: the number of received packets with alignment errors.
 Flow Control: the number of the received, unsupported flow control frames.
 Fragments: the number of received frames that have passed address filtering, are less than
the minimum size and have a bad CRC.
 Frame: the number of received packets with alignment errors (the packet is not an integer
number of bytes in length).
 Lengths: the number of received length error events.
 No Buffers: the number of times that frames are received when there are no available buffers
in host memory to store those frames.
 Overruns: the number of missed packets. Packets are missed when the received FIFO has
insufficient space to store the incoming packets. This can be caused by too few allocated
buffers, or insufficient bandwidth on the PCI bus.
 Carrier extension errors: the number of received packets where the carrier extension error
is signaled across the internal PHY interface.
 Collisions: the total number of collisions that are not late collisions as seen by the
transmitter.
 Late collisions: late collisions are collisions that occur after 64-byte time into the
transmission of the packet while working in 10-100 Mb/s data rate, and after 512-byte time
into the transmission of the packet while working in the 1000 Mb/s data rate.
 Deferred: a deferred event occurs when the transmitter cannot immediately send a packet
because the medium is busy or another device is transmitting.
 Single Collisions: the number of times that a successfully transmitted packet has encountered
only one collision.
 Multiple Collisions: the number of times that a successfully transmitted packet has
encountered more than one collision but less than 16.
 Excessive collisions: the number of times that 16 or more collisions have occurred on a
packet.

Chapter 10 Client Security

Client security makes it possible for the AG to scan the remote client that is being used to access a
virtual portal before authenticating the client. During the scan, the AG determines whether the
client is allowed to ultimately connect to the virtual portal as well as what type of access methods
are available after the client is authenticated.
The client security function is launched from and runs on the client computer before the client logs
into the AG appliance. It has three modules: device class, host integrity and cache cleaner. The
device class module is used to classify and identify authorized client computers based on a
uniquely defined set of device attributes. Multiple device classes can be defined for each virtual
portal. After the device class recognition process is finished, the host integrity module is used to
check the security level of the client computer based on highly customizable rule sets. If the client
computer passes the host integrity check, the user will be presented with the virtual portal login
page. If the client computer fails to pass the host integrity check, the user will be denied of access
to the virtual portal. The cache cleaner module is used to remove confidential information from
the client computer’s cache after the user leaves the virtual portal and closes the browser. The
figure below shows the work flow of client security on the AG appliance.
Figure 10–1 Work Flow of Client Security
The following sections will introduce details about device class, host integrity, cache cleaner and
secure virtual desktop.
10.1 Device Class

The client computer must first be classified into a device class before the AG launches host
integrity check and/or cache cleaner on it. Administrators can configure multiple device classes,
each of which has its own unique settings. The order by which the device classes are defined will
determine their priorities. A client computer can only belong to one device class.
The administrator can use one or more of the device attributes listed below to define a single
device class. If more than one device attribute is used, the administrator must select the logical

relationship (“AND” or “OR”) between the attributes. A client computer’s profile must match a
device class in order for the AG to classify the system. The supported device attributes include:
 IP Address
 DNS
 IP Range
 Domain Name
 Host Name
 Registry
 Gateway
 Operating System
Every virtual portal is preconfigured with a default client security device class with no matching
rules. If a client computer fails to match the rules of any defined device class, it will be classified
with the default device class. The default device class does not have recognition settings and
cannot be deleted.
10.2 Host Integrity

Host integrity is designed to check whether the client computer environment is up to date with the
required security policies. To ensure the host integrity, the following five aspects will be inspected
on the host:
 Anti-Virus – Check whether a specific anti-virus software (multiple anti-virus products may
be specified) is installed and whether its virus definition database is up to date.
 Personal Firewall – Check whether a specific personal firewall software (multiple products
may be specified) is installed.
 Service Pack – Check what service pack is installed on the client computer.
 Anti-Spy – Check whether a specific anti-spy software (multiple anti-spy products may be
specified) is installed.
 Custom – Allow the administrator to check a Registry value, the existence/attribute of a file,
the existence of an application (and whether it is running), the OS version of the client and
whether the user is an administrator on the client. Multiple conditions can be specified to
create complex custom rules.
With host integrity check, administrators can get a preliminary security assurance of the client
computer environment.

10.3 Cache Cleaner

The cache cleaner removes any temporary data generated by the browser during the client’s
session. Any credentials, autocomplete, cookies, history or cached pages left behind are cleaned
out as soon as the browser is closed by the user.
With the cache cleaner, the client can monitor and detect the Web pages opened by the Web
browser. When a browser is closed, the cache cleaner will attempt to clean the relevant Web tracks.
Although some objects cannot be cleaned while another browser is running, the cache cleaner will
perform the cleaning again once all the browsers are closed. As such, the cache cleaner creates a
secure Web browsing environment.
Note: To ensure that the cache cleaner functions well, please make sure JRE version is 1.6
or above.
10.4 Two-stage Security

The Two-stage Security feature is designed to allow the AG appliance to handle requests from a
broader range of client devices with varying levels of security.
By default, the Two-stage Security feature is disabled for a virtual portal. With this configuration,
the AG will immediately deny portal access if the client computer matches a defined device class
but fails to pass the host integrity check.
With the Two-stage Security feature enabled, instead of immediately denying portal access, the
AG will perform a second host integrity check based on the default device class. If the client
device passes the second host integrity check, the user will be granted access to some low-level
resources on the virtual portal.
10.5.1 General Settings

 Import Settings
The administrator can import existing Client Security configuration file into the AG appliance.
Under the virtual site scope, select Site Configuration > Security Settings > Client Security >
General Settings and click the Import Settings button, as shown in Figure 10–2.

Figure 10–2 General Settings of Client Security
In the Import Client Security Setup File configuration page, you can import the configuration
file via local file or URL, as shown in Figure 10–3.
Figure 10–3 Import the Client Security Setup File
 Export Settings
Once configured the Client Security function, you can export your current Client Security
configurations via SCP or TFTP. Under the virtual site scope, select Site Configuration >
Security Settings > Client Security > General Settings and click the Export Settings button, as
1. Export via SCP
To export the Client Security configurations via SCP, enter the Server Name, User Name,
Password and Path, as shown in Figure 10–4. Then click the Export button to export the
configuration file.
Figure 10–4 Export the Client Security Setup File via SCP
2. Export via TFTP
To export the Client Security configurations via TFTP, enter the Server IP and File Name, as
shown in Figure 10–5. Then click the Export button to export the configuration file.
Figure 10–5 Export the Client Security Setup File via TFTP
 Enable Client Security

General Settings, check the Enable Client Security check box and save the configuration by
clicking the Apply Changes button, as shown in Figure 10–6.
Figure 10–6 Enable Client Security
 Enable Two-stage Security
Under the virtual site scope, select Site Configuration > Security Settings >Client Security >
General Settings, check the Enable Two-stage Security check box and save the configuration by
clicking the Apply Changes button, as shown in Figure 10–7.
Figure 10–7 Enable Two-stage Security
10.5.2 Basic Device Class Configuration

 Add an Access Level
Device Classes, and click the Manage Access Levels button, as shown in Figure 10–8.
Figure 10–8 Device Classes
In the Access Levels configuration window, click the Add button to add an access level, as shown
in Figure 10–9.

Note: The Default Access Level is the access level assumed by users with no device class.
It is recommended to assign lowest access privileges to this access level.
Figure 10–9 Access Levels
In the Add Custom Access Level configuration window, enter the Access Level Name and
specify the Access Privileges, as shown in Figure 10–10.
Figure 10–10 Add the Custom Access Level
 Add a Device Class
Device Classes, and click the Add button, as shown in Figure 10–8.
In the Add Device Class configuration window, enter the Device Class Name and specify the
access level from the Access Level drop-down list. You can either select a previously defined
access level or Create New Access Level, as shown in Figure 10–11.

Figure 10–11 Add the Device Class
If Create New Access Level is selected, more configurations are required to add a device class
with a new access level, as shown in Figure 10–12.
Figure 10–12 Add the Device Class with New Access Level
 Operations on a Device Class
1. Set Access Level
For multiple devices (corporate or home PCs, employee laptops, etc.), administrators can set the
device class’ access level to determine the order by which the devices will be checked. Devices
are checked in the order they appear within the Device Classes sort-ready table. The order can be
changed by using the UP and DOWN arrows, as shown in Figure 10–13.
Figure 10–13 Set the Access Level of a Device Class
2. Delete Access Level Setting
Device Classes, and click the icon, as shown in Figure 10–13.
Note: The access level of the “Default” device class is defined by the system and cannot
be deleted.
3. Duplicate Device Class

To set multiple devices with the same configuration parameters, after the first device is setup,
click the icon of the existing device. In the Duplicate Device Class configuration window,
enter the Device Class Name and choose the Access Level from the drop-down list, as shown in
Figure 10–14. A device class with the same configurations of the existing device class is then set
up.
Figure 10–14 Duplicate the Device Class
10.5.3 Advanced Device Class Configuration

Device Classes, and double-click a device class to perform more configurations.
10.5.3.1 General Settings
 General Settings
In the General Settings area under the General Settings tab, you can change the Device Class
Name and specify the Success URL and Failure URL, as shown in Figure 10–15. The Success
URL and Failure URL are the pages to be shown after successful and failed matching with the
Host Integrity rules.
Figure 10–15 General Settings of Device Class
 Device Attributes
In the Device Attributes area, Logical Condition of “AND” and “OR” can be defined for
multiple device attributes. Click the Add button to add a device attribute, as shown in Figure
10–16.

Figure 10–16 Device Attributes
Note: The Device Attributes do not apply to the Default device class. Thus devices not
matching with the device attributes of any device class will assume the Default device
class.
In the Add Device Attribute configuration window, as shown in Add the Device Attribute, first
specify the type of the device attribute. The following device attribute types are supported:
 IP Address
 IP Range
 Registry
 Operating System
 DNS Server IP
 Domain Name
 Host Name
 Gateway
Figure 10–17 Add the Device Attribute
For different device attribute types, the required configurations are different. Please refer to the
following examples:

Figure 10–18 Device Attribute-IP Address
Figure 10–19 Device Attribute-IP Range
Figure 10–20 Device Attribute-Registry
Figure 10–21 Device Attribute-OS
Figure 10–22 Device Attribute-DNS Server IP
Figure 10–23 Device Attribute-Domain Name

Figure 10–24 Device Attribute-Host Name
Figure 10–25 Device Attribute-Gateway
10.5.3.2 Host Integrity
1. Enable Host Integrity
Under the Host Integrity > General sub-tab, check the Enable Host Integrity check box to
enable this feature, as shown in Figure 10–26.
Figure 10–26 Enable Host Integrity
2. Enable Host Integrity Rules
Different combinations of Host Integrity rules can be enabled, by checking the correspondent
check boxes, as shown in Figure 10–26.
 Set Antivirus Rules
1. Set Logical Condition
Under the Host Integrity > Antivirus sub-tab, Logical Condition of “AND” and “OR” can be
defined for multiple antivirus rules, as shown in Figure 10–27.
2. Add an Antivirus Rule
Click the Add button to add an antivirus rule, as shown in Figure 10–27.

Figure 10–27 Antivirus Rules of Host Integrity
In the Add Antivirus Rule configuration window, enter the Rule Name, specify the Default
Maximum Age (of the antivirus software, in days), select desired antivirus software via the check
boxes in the Rule Definition table, and click the Save button to save your configurations, as
Figure 10–28 Add the Antivirus Rule
Note: After choosing the specific antivirus software, it will be moved to the top of the
Rule Definition table.
 Set Firewall Rules
Under the Host Integrity > Firewall sub-tab, Logical Condition of “AND” and “OR” can be
defined for multiple firewall rules, as shown in Figure 10–29.
2. Add a Firewall Rule
Click the Add button to add a firewall rule, as shown in Figure 10–29.

Figure 10–29 Firewall Rules of Host Integrity
In the Add Firewall Rule configuration window, enter the Rule Name, select desired firewall
software via the check boxes in the Rule Definition table, and click the Save button to save your
configurations, as shown in Figure 10–30.
Figure 10–30 Add the Firewall Rule
 Set Service Pack Rules
Under the Host Integrity > Service Pack sub-tab, click the Add button to add a service pack rule,
Figure 10–31 Service Pack Rules of Host Integrity
In the Add Service Pack Rule configuration window, enter the Rule Name, select desired service
pack via the check boxes in the Rule Definition table, and click the Save button to save your

Figure 10–32 Add the Service Pack Rule
 Set Antispyware Rules
Under the Host Integrity > Antispyware sub-tab, Logical Condition of “AND” and “OR” can
be defined for multiple antispyware rules, as shown in Figure 10–33.
2. Add an Antispyware Rule
Click the Add button to add an antispyware rule, as shown in Figure 10–33
Figure 10–33 Antispyware Rules of Host Integrity
In the Add Antispyware Rule configuration window, enter the Rule Name, select desired
antispyware via the check boxes in the Rule Definition table, and click the Save button to save
your configurations, as shown in Figure 10–34.

Figure 10–34 Add the Antispyware Rule
 Set Custom Rules
Besides the above mentioned rules, the administrators can also add custom Host Integrity rules to
enforce customized host check.
Under the Host Integrity > Custom sub-tab, Logical Condition of “AND” and “OR” can be first
defined for multiple custom rules, as shown in Figure 10–35.
2. Add a Custom Rule
Click the Add button to add a custom rule, as shown in Figure 10–35.
Figure 10–35 Custom Rules of Host Integrity
In the Add Custom Rule configuration window, enter the Rule Name, specify the Sub-Rule
Type (Registry, OS, File or Application) and click the Add button to add a sub-rule of the
particular type, as shown in Figure 10–36.

Figure 10–36 Add the Custom Sub-rule of Different Types
For different sub-rule types, the required configurations are different. Please refer to the following
examples:
Figure 10–37 Configure Registry Sub-rule
Figure 10–38 Configure OS Sub-rule
Figure 10–39 Configure File Sub- rule
Figure 10–40 Configure Application Sub- rule
3. Enable/disable a Custom Rule
After defining a custom rule, it will be displayed in the Rules table, where the custom rules can be
enabled or disabled via check boxes, as shown in Figure 10–41. By default, a custom rule is
enabled.

Figure 10–41 Enable/Disable Custom Rules
10.5.3.3 Cache Cleaner
 Enable Cache Cleaner
Under the Cache Cleaner tab, select the Enable Cache Cleaner check box to enable this feature,
Figure 10–42 Cache Cleaner Settings
 Cache Type
The type of the cache contents to be cleaned can be specified in the Cache Type drop-down list,
The supported cache types include:
 History
 Web Address
 Cached Password
 Cache
 Cookie
 All of the above
To clear all the cache contents of one specific type, select the Clear All Cache of the Specified
Type check box after the Cache Type drop-down list is specified, as shown in Figure 10–43

Figure 10–43 Clear All Cache of the Specified Type

Chapter 11 System Monitoring
11.1 Logging
The logging mechanism used by the AG appliance is Syslog compliant. Syslog is a protocol that is
used to receive and store log messages from local or remote hosts. The AG’s Syslog logging has
eight log levels including emerg, alert, crit, error, warning, notice, info and debug. And, it
supports facilities from LOCAL0 to LOCAL7. The system error information and Web access
information during proxy application are both logged by the AG.
11.1.1 Logging Type

The Array AG appliance supports several logging types for different contents. The log entries of
these logging types conform to the WebTrends Extended Log Format (WELF), which includes
some log fields as shown in the table below.
Table 11–1 Log Fields
Field Name Description

N/A The log level associated with the message.
N/A The log time of the message in the format of “MM DD hh:mm:ss”.
id The ID of Array AG appliance. The default value is “Array OS”.
time The log time in the format of “YY-MM-DD hh:mm:ss”.
time_zone The time zone configured on the appliance.
vpn The ID of the virtual site which is generating the message.
user The username of the user associated with the message.
proto The protocol (http, https, tcp, file) associated with the message.
src The IP address of the end user associated with the message.
sport The port of the end user associated with the message.
dst The IP address of the backend server associated with the message.
dport The port of the backend server associated with the message.
dstname The host name of the backend server associated with the message.
arg The URL associated with the message.
op The HTTP method (GET, POST, etc.) associated with the message.
result The HTTP status code associated with the message.
The number of bytes of all the data that the client receives from the
revd
server on this (tcp, udp, icmp) connection.
The number of bytes of all the data that the client sends to the server on
sent
this (tcp, udp, icmp) connection.
rule The ID of the ACL rule associated with the message.
type The type of the message. It is either access log or management log.
msg The description of the event.
The following logging types are supported by the AG appliance:

 Access logging - Logging the information about authentication and session, Web access,
TCP applications, portal login and logout, HTTP request and response. A single log entry is
generated for each attempted access to the internal network resources.
For example:
INFO Aug 04 11:16:58 id=ArrayOS time=“2011-8-4 11:16:58” timezone=CST(+0800) fw=AN

pri=6 vpn=vs user=t1 src=10.4.102.4 sport=44047 dport=80 dstname=localhost
arg=/prx/000/http/localhost/login rcvd=600 type=vpn msg=“Authentication successful, group info
(), login method (ldb)”
 Management logging - Logging the information about configuration operations on the AG

appliance via CLI or WebUI.
For example:
INFO Aug 04 11:17:35 id=ArrayOS time=“2011-8-4 11:17:35” timezone=CST(+0800) fw=AN

pri=6 user= type=mgmt msg=“CLI cmd “show cluster virtual status” success code 0”
 VPN traffic logging – Logging the information about VPN connections.
For example:
INFO Aug 04 10:05:20 id=ArrayOS time=“2011-8-4 10:05:20 timezone=CST(+0800) fw=AN

pri=6 vpn=testHS user=a proto=ICMP src=10.3.124.210 dst=10.3.0.55 dport=2 type=vpn
msg=ICMP session start
11.1.2 Log Host & Log Filtering

The system only stores a maximum of 1000 latest syslog messages due to the memory space
consideration. To enable the administrator to store all history syslogs for future system
troubleshooting, the Logging function allows the syslog messages of the specified log level(s) to
be sent to and stored on remote log hosts. What’s more, log filters can be configured for the
remote log host so that only logs matching the filter strings will be sent to the specific remote log
host for storing. For example, the administrator of “www.site1.com” may want to collect only the
HTTP access logs for “www.site1.com”. In this case, the administrator can create a log filter to
instruct the system to send only logs matching the keyword “site1.com” to the specified remote
log host. The administrator then can have the log file which contains the desired logs only.
When defining a remote log host, the administrator needs to specify a host ID for it.
 If the host ID is set to the default value 0, all logs of the specified level(s) will be sent to the
remote log host without any other filtering.
 If the host ID is set to a value larger than 0, logs of the specified level(s) will be sent to the
remote log host after being filtered by the “log filter” configurations for this remote log host.
The host ID of multiple remote log hosts can be set to 0 simultaneously while the host ID larger
than 0 must be unique among all remote log hosts.

Note:
 A maximum of 6 remote log hosts can be configured.
 A maximum of 64 log filters can be configured for one remote log host. If multiple
log filters are configured for a remote log host, the logs matching any one of the filter
strings will be sent to the remote log host. If no log filter is configured, no log will be
sent to the remote log host.
11.1.3 Disabling the System Log

The administrator can disable system logs by log ID so that the system will not generate such
system logs any more. The disabled system log will be added to the disabled system log list. By
default, the disabled system log list is empty, that is to say, all system logs are enabled. At most
128 system logs can be disabled.
11.1.4 Email Alert

Administrators may configure the AG to send email alerts whenever a given string appears in a
log message. The alert messages will be sent to the predefined emails address.
11.1.5.1 General Settings
 Enable the Logging Function
Under the global scope, select Admin Tools > Monitoring > Logging > General, and select the
Enable Logging check box, as shown in Figure 11–1.

Figure 11–1 General Settings of Logging
The Logging function is disabled by default.
 Enable the Timestamp Feature
Under the global scope, select Admin Tools > Monitoring > Logging > General, and check the
Enable Timestamp check box, as shown in Figure 11–1.
 Specify the Syslog Facility
Under the global scope, select Admin Tools > Monitoring > Logging > General, and specify
Facility from the drop-down list, as shown in Figure 11–1.
The default facility setting is “LOCAL0”.
 Specify the Minimum Log Level
Once the minimum log level is set, the messages below the configured level will be ignored.
Under the global scope, select Admin Tools > Monitoring > Logging > General, select Level
from the drop-down list, as shown in Figure 11–1.
The default level is “1:INFO”.
After finishing the above configurations, remember to click the Apply Changes button to save the
configurations.
11.1.5.2 Syslog Server
Please follow the steps to add a syslog server:
 Add a Syslog Server
Under the global scope, select Admin Tools > Monitoring > Logging > Syslog Servers, and
click the Add Server Entry action link in the Remote Syslog Server Configuration area, as
Figure 11–2 Syslog Servers
In the Add Server Entry area, specify the parameters Host IP, Protocol, Host Port and Host ID,
select the Log Level Options check boxes if required, and click the Save action link to save the

Figure 11–3 Add the Syslog Server
 Configure Log Filter for the Syslog Server
Under the global scope, select Admin Tools > Monitoring > Logging > Syslog Servers, select
one specific server entry and then click the Log Filters for Selected Server action link in the
Remote Syslog Server Configuration area to go to the Log Filter Configuration window, as
Figure 11–4 Log Filter Configuration
Click the Add action link in the Log Filter Configuration area. In the Add Log Filter Entry
area, specify the parameters Filter ID and Filter String, and click the Save action link to save the

Figure 11–5 Add the Log Filter Entry
11.1.5.3 HTTP Logging
HTTP access information can be logged in one of the standard formats Squid, WELF, Common
and Combined, or it can be logged in a format customized by the administrator.
To enable the HTTP Logging function, select Admin Tools > Monitoring > Logging > HTTP
Logging under the global scope, choose the desired log format to enable via the radio buttons in
the HTTP Logging Configuration area, and click the Apply action link to make the
configuration take effect, as shown in Figure 11–6.
Figure 11–6 HTTP Logging Configuration
11.1.5.4 Disabling the System Log
Under the global scope, select Admin Tools > Monitoring > Logging > Disabled Log, enter the
ID of the system log to be disabled in the Log ID text box in the Disabled Log area, and click the
Add action link, as shown in Figure 11–7.
Figure 11–7 Disable the System Log
To view the ID of all system logs, click the Log ID list link behind the Log ID text box.
11.2 SNMP
Simple Network Management Protocol (SNMP) is mostly used in network management systems
to monitor network-attached devices. The administrator monitors the status of the AG appliance
via the information collected by SNMP.
The AG appliance supports SNMP version v1, v2 and v3.
SNMP provides two methods to monitor the status of the AG appliance:
 Collecting information from SNMP OIDs

 Collecting information from SNMP Trap messages
 SNMP OIDs
To use this method, first install the SNMP client software onto the administrator’s client. SNMP
itself does not define what information a client should offer. Rather, SNMP uses an extensible
design, where the available information is defined by management information bases (MIBs).
MIBs describe the structure of the management data of a device subsystem; they use a hierarchical
namespace containing object identifiers (OID). Each OID identifies a variable that can be read or
set via SNMP. The administrator will get the SNMP OIDs via the SNMP client.
The following figure shows the process of getting SNMP OIDs.
Figure 11–8 Get the SNMP OID
The SNMP client keeps an SNMP OID list. When needed, it will send a “Get-Request” message
to the AG appliance which contains the OID object. Upon receiving the request, the AG appliance
will send back a “Get-Response” message to the client with the information for that particular
OID object. This gathering of information will help the administrator to monitor the status of the
AG appliance.
For more information of the SNMP OIDs, please refer to Appendix III SNMP OID List.
 SNMP Trap
Figure 11–9 SNMP Trap
The above figure shows the process of SNMP Traps. Once the AG appliance encounters any
problem, like SNMP termination, the AG appliance will send out a trap message to the SNMP
client without waiting for a “Get-Request”. Each trap message contains an OID that exactly
describes what event occurred on the AG appliance. The administrator may use this information to
help troubleshoot the system. In order to take advantage of this feature, the administrator must
define where the trap messages will be sent by running the “snmp host” command.

1. Enable the SNMP Feature
Under the global scope, select Admin Tools > Monitoring > SNMP > General, and select on v3
from the Enable SNMP drop-down list, as shown in Figure 11–10.

Figure 11–10 General Settings of SNMP
2. Enable AG to Send Generic and Enterprise Traps
Under the global scope, select Admin Tools > Monitoring > SNMP > General, and check the
Enable Trap check box, as shown in Figure 11–10.
3. Enable Access Control based on the Source IP of a SNMP Client
Under the global scope, select Admin Tools > Monitoring > SNMP > General, and check the
Enable IP check box, as shown in Figure 11–10.
4. Define a Community String as Password to Control Access from the NMS to the Agent.
Under the global scope, select Admin Tools > Monitoring > SNMP > General, and enter the
Community String in the text box, as shown in Figure 11–10.
 SNMP Servers
Under the global scope, select Admin Tools > Monitoring > SNMP > SNMP Servers, and click
the Add Server Entry button, as shown in Figure 11–11.
Figure 11–11 SNMP Servers
In the Add Server Entry configuration window, enter the IP Address, select the Version ID and
specify the Community String, as shown in Figure 11–12.

Figure 11–12 Add the Server Entry
If the Version ID is set to 3, then some other fields also need to be defined, as shown in Figure
11–13.
Figure 11–13 Add theServer Entry with Version ID Set to 3
 SNMP V3 User
Under the global scope, select Admin Tools > Monitoring > SNMP > User, and click the Add
User button, as shown in Figure 11–14.
Figure 11–14 SNMP V3 User Setting
In the SNMP V3 User Setting configuration window, enter the User Name, specify the Security
Level and set the Authentication Password, as shown in Figure 11–15.

Figure 11–15 Add the SNMP V3 User
Note: The SNMP feature needs to be temporarily disabled before adding an SNMP user,
because the SNMP security parameters can be changed only when the SNMP agent is off.
 Permitted IP
Under the global scope, select Admin Tools > Monitoring > SNMP > Permitted IP, and click
the Add Permitted IP button, as shown in Figure 11–16.
Figure 11–16 Permitted IP
In the Add Permitted IP configuration window, enter the IP Address and Netmask, as shown in
Figure 11–17.
Figure 11–17 Add the Permitted IP
 MIB File
Under the global scope, select Admin Tools > Monitoring > SNMP > MIB File, and the user’s
MIB file will be displayed if applicable.
11.3 Troubleshooting
For troubleshooting, the AG provides basic commands to ping (generate an echo request), perform
packet traces or perform NS (name server) verification. The AG also provides a set of debug
commands to help administrators collect debugging data.
For more details, please refer to the section about Troubleshooting commands in the AG CLI
Handbook.

 Tools

Under the global scope, please select Admin Tools > Troubleshooting > Tools to use the
troubleshooting tools.
1. Ping
Enter the IP or Host Name and click the Ping button, and the Ping Result will be displayed, as
Figure 11–18 Ping
2. Traceroute
Enter the IP or Host Name and the timeout value, and click the Traceroute button. The
Traceroute Result will be displayed, as shown in Figure 11–19.
Figure 11–19 Traceroute
3. Name Server Lookup
Enter the IP or Host Name and click the Lookup button, and the Name Server Lookup Result
will be displayed, as shown in Figure 11–20.
Figure 11–20 Name Server Lookup
4. Build Debug Files
Under the global scope, please select Admin Tools > Troubleshooting, and click the Build
button in the Build Debug Files area.
Via this operation, the system will generate four kinds of system debug files which respectively
record the system activities information by categories:
 sys_snap.tar.gz.gpg

 sys_log.tar.gz.gpg
 sys_core.tar.gz.gpg
 app_core.tar.gz.gpg
You can manually generate and obtain these files.
In the Build Debug Files area, enter the Number of System Core Files Included in the text box
and click the Build button, as shown in Figure 11–21.
Figure 11–21 Build Debug Files
After a while, the system debug files obtained successfully will be displayed in the sort ready
table.
 Debug Monitor
Please select Admin Tools > Troubleshooting > Debug Monitor under the global scope to make
Debug Monitor configurations.
1. Enable Debug Monitor
Click the Enable Debug Monitor check box, and click the Set action link to make the
configuration take effect, as shown in Figure 11–22.
Figure 11–22 Enable Debug Monitor
2. Import Debug Monitor CLI Configuration
Select the import method as FTP or SCP, enter the User Name, Password, IP address of the FTP
or SCP server, File Name in the text boxes, and click the Import action link, as shown in Figure
11–23.

Figure 11–23 Import Debug Monitor CLI Configuration
Note: The Debug Monitor page display error may occur if files larger than 1 MB are
imported. To solve this problem, the administrator needs to reimport a file smaller than 1
MB via CLI.
After the import is successful, the imported CLI configuration will be displayed in the Imported
Debug Monitor CLI area, as shown in Figure 11–24.
Figure 11–24 Imported Debug Monitor CLI
3. Export Debug Monitor Data
Select the export method as FTP or SCP, enter the User Name, Password, IP address of the FTP
or SCP server, and click the Export action link, as shown in Figure 11–25.
Figure 11–25 Export Debug Monitor Data
Note: The Debug Monitor function needs to be disabled before importing debug monitor
CLI configurations and exporting debug monitor data.
 Supported Access
Under the global scope, select Admin Tools > Troubleshooting > Supported Access and click
the Add Supported Entry button, as shown in Figure 11–26.

Figure 11–26 Supported Access Configuration
In the Add Support Entry configuration window, enter the IP Address and Netmask in the text
boxes. For example, to allow access from all IP addresses, the support entry can be configured as
Figure 11–27 Add the Support Entry

Chapter 12 Admin Tools

This chapter focuses on the administrative tools of AG appliance, including admin role setting,
admin AAA, source IP login authorization, and XML-RPC.
12.1 Administrators
12.1.1 Admin User

The admin user functionality enables management of administrator accounts for system
administration. An administrator user needs to be specified with access level and access privilege.
Please note that there must be at least one global administrator with Config access level. The
following figure gives an example of specifying scope and access level for a particular
administrator.
Figure 12–1 Admin User
For each admin user, the AG provides the following options for management control:
 Configuration scope: Define which configuration scope to allow administrators to perform

settings and configurations in, the global scope or a specific virtual site scope.
 Access level: Define which access level to allow administrators to access, the Enable level,
the Config level or the access level defined by an admin role.
– The Enable privilege allows the administrators to only have the “read” access right to all
features.
– The Config privilege allows the administrators to have the “read and write” access right
to all features.
The assigned user role will further define the “read” access, “read and write” access or no access
right to certain features.
12.1.2 Admin Role

The admin role functionality enables the AG appliance to precisely delegate and control
administrator access privileges to specific management functionalities (or AG features). These AG

features can be delegated to one or more admin roles. Similarly, each admin role can be assigned
with one or more AG features.
Note: The “admin user” configuration is the precondition to make “admin role” effective.
An administrator who is assigned with any admin role(s) will be allowed to access the features
delegated to the role(s) only.
Figure 12–2 Admin Role
For each admin role, the AG also provides the following options for even more flexible
management control:
 Configuration scope: Define which configuration scope to allow administrators to perform

settings and configurations in, the global scope or the virtual site scope.
 Privilege level: Define which privilege level to allow administrators to access, the Enable
level or the Config level.
– The Enable privilege allows the administrators to only have the “read” access right to
the related features.
– The Config privilege allows the administrators to have the “read and write” access right
to the related features.
To use the admin role, please note the following information:
 If no feature is assigned to a role, the administrator can only access some very basic
commands and non-critical functions such as ping and traceroute.
 Global scope admin roles cannot be delegated to virtual site scope administrator accounts.

 The virtual site scope features can be assigned to global scope admin roles, and administrator
accounts with global scope roles can access virtual site scope as long as specific features are
added.
 Virtual site scope admin roles cannot access the global scope features.
 Cannot delegate a “config” mode feature to an admin role if this admin role has already been
delegated with any “enable” mode administrator account.
 Cannot delegate an admin role with any “config” mode feature to a “enable” mode
administrator account.
If an administrator account does not match any admin role:
 The administrator account will be granted with the access rights to both the Enable and
Config privileges of the global and virtual site scopes.
 The administrator account will be granted with the access rights to all existing virtual sites.
The following table displays the available features on the AG appliance based on the configuration
scope.
Table 12–1 AG Features
Scope Feature
aaa
admin
art
cluster
ha
http
ipsec
localdb
log
network
Global
quicklink
saa
session
snmp
ssl
system
vpn
vsite
webui
xmlrpc
aaa
Virtual site admin
art

Scope Feature
clientsecurity
fileshare
http
ipsec
localdb
motionpro
network
policy
portal
quicklink
rewrite
session
ssl
system
vpn
vsite
12.1.3 WebUI Admin Role

AG provides the WebUI admin role function to control the site administrator’s WebUI access
privileges. The WebUI admin role function provides a fine-grained access control method to
control the site administrator’s access to every WebUI menu. One WebUI admin role can be
associated with multiple site administrators and one site can have multiple WebUI admin roles.
Each WebUI admin role controls the following privileges for WebUI menus:
 Read access privilege: indicates that the site administrators have only the “read” access
privilege to the related WebUI menus.
 Read and write access privilege: indicates that the administrators will have the “read and
write” access privilege to the related WebUI menus.
 Visible tabs: indicates that the tabs of certain WebUI menus will be displayed.
The following table displays the available WebUI menus for which the access privilege can be
controlled.
Table 12–2 WebUI Menus
Site Functions Sub Functions

SSL/DTLS Certificates
Security Settings
Site Configuration AAA
Access Direct
Portal
Networking
Local Database General Settings

Site Functions Sub Functions

Local Accounts
Local Groups
Login Authorization
Web Access
Access Methods File Access
VPN
Role
User Policies
ACLs
Session Management
View
Configuration Backup
Admin Tools Management Load
Clear
Monitoring
Troubleshooting
Base System
DD Pilot Virtual Portal
Art Server
System Monitor
MotionPro Pilot
Site Settings
To use the WebUI admin role, please note the following information:
 If no access privilege is configured for any WebUI menu in a WebUI admin role, the
administrator associated with only this WebUI admin role can only view the virtual site home
page.
 A WebUI admin role with any WebUI menu configured with certain access privilege cannot
be associated with a “enable” mode administrator account.
 The site administrator associated with any WebUI admin role can access and manage the AG
appliance only through WebUI.
Note:
 For site administrators, admin roles and WebUI admin roles are mutually exclusive.
 If no admin role or WebUI role is associated with a site administrator, the

administrator will have full access privileges specified by its “Enable” or “Config”
access level.
12.1.4 Admin AAA

The Admin AAA function enables the system to authenticate and authorize administrators using
external AAA servers. By default, this function is disabled.

This function supports only two AAA methods: LDAP and RADIUS and applies AAA Ranking to
both methods. At least one AAA method must be configured. For each AAA method, at most
three external AAA servers can be configured.
Administrators will be authorized with “enable” or “config” access level on the global scope or a
specified virtual site scope based on the external admin groups retrieved from the external AAA
server.
In addition, this function provides an option “Enable Admin Local Auth First”. By default, this
option is enabled.
 When this option is enabled, the administrators will use the local database to authenticate the
administrators first. The system will use external AAA servers to authenticate administrators
only when the administrators fail the local authentication.
 When this option is disabled, the system will use external AAA servers to authenticate the
administrators first. If the external AAA servers return the “Accept” or “Deny” response, the
system will not use the local database to authenticate the administrators later. However, if the
system does not receive any response from the AAA servers, the system will then use the
local database to authenticate the administrators.
Note: This function works only for administrators who log into the appliance through SSH
or WebUI connections.
12.1.5 Source IP Login Authorization

The Source IP Login Authorization function ensures that administrators can access the system
only from authorized source IP addresses, thus enhancing the system security. Both WebUI access
and SSH access to the system are controlled by this function.
If no authorized source IP or subnet is configured, administrators can access the system via
WebUI or SSH from any source IP.
Note: After authorized source IP addresses or subnets are added or deleted, you need to
restart the WebUI for the configuration changes to take effect for all WebUI sessions.
12.1.6.1 Admin User and Admin Role
This section provides an example for configuring an administrator account “aaa_account” that can
perform LocalDB and AAA configurations in the “demo_portal” virtual site.
Under the global scope, select Administrators > Admin Roles > Admin Roles, and click the
Add Role button, as shown in Figure 12–3.

Figure 12–3 Admin Roles
In the Add Administrator Role configuration window, specify the parameters Role Name and
Scope, select the Global/Site Features as needed and click the Save action link to save the
administrator role, as shown in Figure 12–4.
Figure 12–4 Add the Admin Role
Under the global scope, select Administrators > Site Admin > Site Admin, and click the Add
Admin button, as shown in Figure 12–5.
Figure 12–5 Site Administrators
In the Add Site Admin Account configuration window, enter the User Name, Password,
Confirm Password, select the Virtual Site, specify the Access Level as Config, specify the
Access Privilege as Role Based, select the previously defined admin role in the Assigned Roles
table and click the Save button to save the site administrator account, as shown in Figure 12–6.

Figure 12–6 Add the Site Admin Account
12.1.6.2 Admin User and WebUI Admin Role
This section provides an example for configuring an administrator account “a” that are granted
with the “read and write” access privilege to the Site Configuration and Local DatabaseWebUI
menus of the “vs” virtual site.
Under the global scope, select Administrators > Admin Roles > WebUI Admin Roles, and click
the Add WebUI Admin Role button, as shown in Figure 12–7.
Figure 12–7 WebUI Admin Roles
In the Add WebUI Administrator Role configuration window, specify the parameters Role
Name, select the Write Access check boxes of the Site Configuration and Local Database
WebUI menus and click the Save action link to save the admin, as shown in Figure 12–8.

Figure 12–8 Add the WebUI Admin Role
Under the global scope, select Administrators > Site Admin > Site Admin, and click the Add
Admin button, as shown in Figure 12–9.
Figure 12–9 Site Administrators
In the Add Site Admin Account configuration window, specify the parameters User Name,
Password, Confirm Password, set the Virtual Site parameter to “vs”, set the Access Level
parameter to “Config”, select the WebUI Admin Role radio button and select the previously
added WebUI admin role in the Assigned Roles table, and click the Save button to save the site
administrator account, as shown in Figure 12–10.
Figure 12–10 Add the Site Admin Account
12.1.6.3 Admin AAA
 Add AAA Methods
Under the global scope, select Administrators > Admin AAA > Method, and select the Rank
Enable check box, and specify Rank 1 and Rank 2 AAA methods, as shown in Figure 12–11.
Figure 12–11 Add AAA Methods and Enable Rank
 Add AAA Servers
Click the LDAP tab and specify the parameters Search Filter, Group Attribute, Get External
Group Name from DN Suffix, Default Group, Idletime, and Authenticate with Bind in the
Advanced LDAP Server Configuration area, as shown in Figure 12–12.

Figure 12–12 Advanced LDAP Server Configuration
Click the Add LDAP Server action link in the LDAP Server Configuration area, specify the
parameters Server IP, Server Port, User Name, User Password, Base, Timeout, Redundancy
Order, and Use TLS in the displayed Add LDAP Server configuration window, and click the
Save action link, as shown in Figure 12–13.
Figure 12–13 Add the LDAP Server
Click the RADIUS tab and specify the parameters RADIUS NASIP, Group Attribute, and
Default Group in the Advanced RADIUS Server Configuration window, as shown in Figure
12–14.

Figure 12–14 Advanced RADIUS Server Configuration
Click the Add RADIUS Server action link in the RADIUS Server Configuration area, specify
parameters Server IP, Server Port, Secret Password, Timeout, Redundancy Order, and
Retries in the displayed Add RADIUS Server configuration window, and click the Save action
link, as shown in Figure 12–15.
Figure 12–15 Add the RADIUS Server
 Add Admin Groups
Click the Admin Group tab and click the Add Group action link in the Group List area, as
Figure 12–16 Add the Admin Group
In the displayed Add Administrator Group configuration window, specify the parameters
Group Name, Access Level, and Scope, and click the Save action link, as shown in Figure
12–17.
Figure 12–17 Admin Group Configuration
 Enable Admin AAA
Click the General Settings tab, select the Enable Administrator AAA check box in the General
Settings area, and click the Apply Changes button on the upper-right corner, as shown in Figure
12–18.

Figure 12–18 Enable Admin AAA
12.1.6.4 Source IP Login Authorization
Under the global scope, select Administrators > Admin AAA > General Settings, click the Add
action link in the Source IP Login Authorization area, as shown in Figure 12–19.
Figure 12–19 Source IP Login Authorization
In the Add Source IP area, specify the parameters IP and Netmask, and click the Save action
link to add a source IP address or subnet, as shown in Figure 12–20.
Figure 12–20 Add a Source IP Address or Subnet
The newly added source IP address or subnet will be displayed in the Source IP Login
Authorization table.
Click the Restart WebUI action link to restart the WebUI for the configuration changes to take
effect for the WebUI sessions, as shown in Figure 12–21.

Figure 12–21 Restart WebUI
12.2 System Access Control
12.2.1 WebUI Access

WebUI Access functionality allows the administrator to connect to the AG appliance via WebUI.
A valid WebUI IP address and port number can be assigned to allow administrators to access AG
WebUI only via the specified IP address and port. If the WebUI IP and port are not specified,
administrators can use any interface or virtual site IP address and the default port 8888 to access
AG WebUI.
Idle timeout is supported for WebUI Access. When the WebUI connection is idle for the specified
time, the AG appliance will timeout the WebUI connection.
Under the global scope, select Admin Tools > System Management > Access Control, select the
Enable WebUI check box in the WebUI Settings area, and specify the parameters IP(v4), IP(v6),
Port, Language and Idle Timeout as needed, as shown in Figure 12–22.

Figure 12–22 WebUI Access Settings
12.2.2 SSH Access

SSH Access functionality allows the administrator to connect to the AG appliance via SSH. A
valid SSH IP address can be set so that the AG appliance will only accept SSH connections to this
specified IP address. If the SSH IP address is not specified, administrators can access the AG
appliance via SSH at any available IP address (including virtual site IP addresses) on the AG
appliance.
Idle timeout is supported for SSH Access. When the SSH connection is idle for the specified time,
the AG appliance will timeout the SSH connection. SSH Access supports two idle timeout modes:
 Input only: The SSH session will be considered as not idle only when there is user input.
 Input and output: The SSH session will be considered as not idle when there is user input or
TTY output.
Enable SSH Access check box in the SSH Settings area, and specify the parameters IP(v4),
IP(v6), Idle Timeout and Idle Timeout Mode as needed, as shown in Figure 12–23.

Figure 12–23 SSH Access Settings
12.2.3 XML-RPC Access

XML-RPC functionality works by sending an HTTP-based request or file to the AG. This method
allows multiple input parameters to be passed to the remote AG (only one return value is
returned/expected). This greatly simplifies the configuration process because large and complex
configuration files can be transported using this single operation. A valid XML-RPC IP address
can be set so that the AG appliance will only accept XML-RPC requests to this specified IP
address. If the XML-RPC IP address is not specified, administrators can access the AG appliance
via XML-RPC at any available IPv4 address (including virtual site IP addresses) on the AG
appliance.
As shown in the figure below, the client sends an HTTP POST Request to Array AG. The
XML-RPC message is the body of the HTTP Request, in which the commands to run and the
commands’ parameters are specified. Then, Array AG decodes the XML-RPC message and
executes the called commands. At last it returns the results formatted in XML to the client.
Figure 12–24 XML-RPC Working Mechanism
 XML File
To take advantage of the AG XML-RPC support, administrators will have to use a very specific
XML file to upload the necessary files into the AG itself.
<?xml version="1.0" ?>

<methodCall>
<methodName>arrayos_cli_config</methodName>
<params>
<param>
<value>
<struct>
<member>
<name>enable_passwd</name>
<value>
<string>PASSWD</string>
</value>
</member>
<member>
<name>username</name>
<value>
<string>USERNAME</string>
</value>
</member>
<member>
<name>password</name>
<value>
<string>PASSWORD</string>
</value>
</member>
<member>
<name>num</name>
<value>
<int>2</int>
</value>
</member>
<member>
<name>cli_string0</name>
<value>
<string>switch vsite_test config</string>
</value>
</member>
<member>
<name>cli_string1</name>
<value>
<string>sso off</string>
</value>
</member>
</struct>
</value>

</param>
</params>
</methodCall>
Here are the key restrictions and requirements for this file:
“arrayos_cli_config”, “enable_passwd”, “username”, “password”, “num” and both “cli_string” are

fixed and CANNOT be changed.
Any parameters in RED are changeable and it should be replaced according to the requirements of
the administrator. Any text in red is for example purposes only.
 arrayos_cli_config: indicates the XML file is being used for delivering the configuration to
the AG or other ArrayOS powered appliance.
 enable_passwd: “<string>PASSWD</string>” contains the enable password of the AG

(PASSWD should be replaced by the real enable password of the AG; if admin did not
configure the enable password via CLI “enable password”, please use “<string />” instead of
“<string>PASSWD</string>”).
 username: “<string>USERNAME</string>” specifies the username for XML-RPC

Authentication (USERNAME should be replaced by the real username set by the admin. Its
value should be a string of 1 to 8 characters).
 password: “<string>PASSWORD</string>” specifies the password for XML-RPC

Authentication (PASSWORD should be replaced by the real password set by the admin. Its
value should be a string of 1 to 13 characters).
 num: refers to the number of CLI commands that admin would like the AG to execute.
Supply the value <int>X</int>.
 cli_string0: indicates the CLI command whose index is 0.
 cli_stringX: indicates the CLI command whose index is X.
(If the num is 4, the postfix of cli_string should be 0, 1, 2, 3: cli_string0 cli_string1

cli_string2 cli_string3.)
 switch vsite_test config and sso off: the real CLI commands. They can be changed to any
CLI commands which AG’s XML RPC supports.
 XML-RPC Authentication
After the XML file is uploaded, the XML-RPC Authentication function allows the system to
authenticate the XML file by the username and password before executing CLI commands
contained in this XML file. If the username and password contained in the XML file does not
match the XML-RPC Authentication username and password configured on AG, the system will
deny the XML file. This function enhances security for the system when the XML-RPC function
is used.
The XML-RPC Authentication function can be configured only via CLI.

For example:
AN(config)#xmlrpc authentication on
AN(config)#xmlrpc authentication user username password
Enable XMLRPC check box in the XMLRPC Settings area, and specify the parameters IP(v4)
and Port as needed, as shown in Figure 12–25.
Figure 12–25 XML-RPC Access Settings
Note: The XML-RPC function is enabled by default and the default port for XML-RPC
communication is port 9999.
12.3 System Management
12.3.1 System Reboot and Shutdown

 System Reboot
To reboot the system (ArrayOS), select Admin Tools > System Management >
Shutdown/Reboot, click the Reboot Now button in the System Control area, as shown in Figure
12–26.

Figure 12–26 System Reboot/Shutdown
The administrator can select the Fallback to previous Version on Next Reboot check box if
wanting to fall back the system to the previous version at the next reboot.
 System Shutdown
The AG appliance provides two options for system shutdown:
 poweroff (default value): The system is stopped and the power is turned off.
 halt: The system is stopped but the power is not turned off.
To perform system shutdown, select Admin Tools > System Management > Shutdown/Reboot,
select the poweroff or halt option, and click the Shut down Now in the System Control area, as
12.3.2 System Update

The AG appliance provides administrators with two options for updating the system: system
update using a local host file and system update using a URL.
 System Update Using a Local Host File
Before performing system update using a local host file, the administrator must store the new
system version package locally.
To perform system update using a local host file, select Admin Tools > System Management >
Update, select the Local Host File radio button in the System Update area, click the Browse…
button to specify the local host file, and click the Apply Update action link, as shown inFigure
12–27.
Figure 12–27 System Update Using a Local Host File
 System Update Using a URL

To perform system update using a URL, select Admin Tools > System Management > Update,
select the URL radio button in the System Update area, click the Browse… button to specify the
URL of the new system version package, and click the Apply Update action link, as shown in
Figure 12–28.
Figure 12–28 System Update Using a URL
For any of the two options, a message box will be prompted to ask the administrator to confirm
the system update operation. The administrator can click the Ok button to continue the system
update operation or click the Cancel button to cancel the system update operation.
Note:
 Before performing system update, please make sure that you have saved all
configurations including global and virtual site configurations. Otherwise, running
configurations that have not been written into memory will be lost.
 The system update operation will take a few minutes and the AG appliance will stop
providing services. It is recommended to perform system update when the network
traffic is low.
12.3.3 Component Update

The AG appliance allows the administrator to update components of the system without updating
the entire system or even forcing the AG appliance to reboot.
The operations of component update are similar to those of system update. You can use the system
update operations for reference.
12.3.4 System License

The system must run with a valid software license. After the software license expires or becomes
invalid, you need to purchase a new valid license and import it to the system.
To import a valid license to the system, select Admin Tools > System Management > License,
paste the license key into the License Code text box in the License Import area, and click the
Import With Validation or Import Without Validation action link, as shown in Figure 12–29.

Figure 12–29 Import a License to the System
12.4 Configuration Management
12.4.1 Startup Configuration and Running Configuration

Startup Configuration refers to the configurations that the system will load from the memory at the
system startup. Running Configuration refers to the configurations that the system is currently
running. At the system startup, Startup Configuration equals to Running Configuration. After
adding, deleting and modifying configurations, administrators need to write all the running
configurations into memory. Otherwise, unsaved running configurations will be missing at next
system startup.
To save running configurations into memory, click the Save Configuration action link in the
upper-right corner of the Top Bar, as shown in Figure 12–30.
Figure 12–30 Save Configurations
In the displayed dialog box, select desired save configuration option and click the OK button, as
Figure 12–31 Save Configuration Options
To view the current running configurations or startup configurations, select Admin Tools >
Config Management > View, and select the corresponding sub-tab, as shown in Figure 12–32.

Figure 12–32 View Configurations
12.4.2 Configuration Backup

The AG appliance supports four methods to backup the current running configuration.
 Backup Using Startup Configuration
To save the current running configurations into the startup configuration file, select Admin
Tools > Config Management > Backup, select the Startup Config radio button, and click the
Backup action link in the upper-right corner of the Running Configuration Backup area, as
Figure 12–33 Backup Using Startup Configuration
 Backup Using SCP
To save the current running configurations onto the remote SCP server, select Admin Tools >
Config Management > Backup, select the SCP radio button, select the Save all configuration
check box and specify the parameters Server Name, User Name, Password and Path, click the
Backup action link in the upper-right corner of the Running Configuration Backup area, as

Figure 12–34 Backup Using SCP
 Backup Using TFTP
To save the current running configurations onto the remote TFTP server, select Admin Tools >
Config Management > Backup, select the TFTP radio button, select the Save all configuration
check box and specify the parameters Server IP and File Name, click the Backup action link in
the upper-right corner of the Running Configuration Backup area, as shown in Figure 12–35.
Figure 12–35 Backup Using TFTP
 Backup Using Saved File
To save the current running configurations into a backup file on the AG appliance, select Admin
Tools > Config Management > Backup, select the Saved File radio button, select the Save all
configuration check box and specify the parameter File Name, click the Backup action link in
the upper-right corner of the Running Configuration Backup area, as shown in Figure 12–36.

Figure 12–36 Backup Using Saved File
12.4.3 Configuration Import

To load an existing configuration, select Admin Tools > Config Management > Load, specify
the Load Using and related parameters as needed, then click the Load action link in the
upper-right corner of the Load Running Configuration area, as shown in Figure 12–37.
Figure 12–37 Import Configurations
12.4.4 Configuration Clearance

The AG appliance provides four options for configuration clearance:
 Primary: restore the basic network settings to their default values (including settings about
IP address, cluster, access list, group, WebUI, “Enable” level password, “array” user
password…etc). Also, all administrator accounts except “array” will be deleted. If there are
other configurations depending on these basic network settings, please first delete the related
configurations, and then choose this option again.

 Secondary: restore all the secondary AG settings such as NAT, FWD, SNMP, log, domain
server and proxy server.
 Entire: clear all settings on the AG appliance.
 Factory Default: reset the AG appliance to the factory default settings. The difference with
the “Entire” option is that this option will also clear imported SSL key files.
To clear the configuration on the AG appliance, select Admin Tools > Config Management >
Clear, click the button as needed in the Clear Configuration area, as shown in Figure 12–38.
Figure 12–38 Clear Configurations
12.4.5 Configuration Synchronization

The Configuration Synchronization (synconfig) feature of the AG appliance allows administrators
to transfer configuration information among AG appliances within the same network.
To use the synconfig feature, you need to configure all the synchronization peers on each
synchronization node. In addition, you need to configure the same synchronization challenge code
on each synchronization unit. If the synchronization units have different synchronization challenge
codes, configuration synchronization operations will be rejected.
Note: For the Configuration Synchronization feature to work, you need to define access
list rules to permit traffic to come in through port 65519 from the synconfig peers.
To set the synchronization challenge code, select Admin Tools > Config Management >
Synchronization > Nodes/Peers, set the Challenge Code text box in the Sync Challenge
Configuration area, and click the Apply Changes button, as shown in Figure 12–39.

Figure 12–39 Set the Synchronization Challenge Code
To add a synchronization peer, select Admin Tools > Config Management > Synchronization >
Nodes/Peers, click the Add Node/Peer Entry action link in the Synch Node/Peer Configuration
area, then specify the parameters Node/Peer Name and Node/Peer IP in the Add Node/Peer
Entry area, as shown in Figure 12–40.
Figure 12–40 Add a Node or Peer
To execute synchronization related tasks, select Admin Tools > Config Management >
Synchronization > Tasks, specify the Synchronization Direction parameter in the
Configuration Synchronization area, then click the Synchronize action link, as shown in Figure
12–41.
 To: retrieve configurations from the AG appliance and synchronize it with the specified peer.
 From: retrieve configurations from the specified peer and synchronize it with the AG
appliance.

Figure 12–41 Synchronization Configurations
To restore the configurations of the AG appliance back to what it was, specify the Rollback
Location parameter in the Synchronization Rollback area, then click the Rollback action link,
To view the synchronization results, select Admin Tools > Config Management >
Synchronization > Results, as shown in Figure 12–42.
Figure 12–42 View Synchronization Results
To view the configuration differences between the AG appliance and the specified peer, select
Admin Tools > Config Management > Synchronization > Differences, as shown in Figure
12–43.

Figure 12–43 View Synchronization Differences
To view the history of synchronization events initiated on the AG appliance, select Admin
Tools > Config Management > Synchronization > History, as shown in Figure 12–44.
Figure 12–44 View Synchronization History

Chapter 13 12BAdvanced System Operations
Chapter 13 Advanced System Operations

Array AG appliance allows you to configure advanced operation options such as RTS (Return to
Sender), Bond and NAT (Network Address Translation).
13.1 RTS
The RTS (Return to Sender) feature helps to ensure that each response packet or the response
packet of which the request packet is routed from configured gateways will be directed to the link
from which its corresponding request packet is sent.
The RTS feature eliminates unnecessary network traffic when the shortest route does not go
through the default gateway, or when no static route is defined for the IP address of the client or
server. The following figure shows an example of an RTS deployment.
Figure 13–1 RTS Deployment
In this example, the default gateway is configured on the inside interface. Client A sends a packet
through the AG’s outside interface. If RTS is disabled, the AG will send the return packet through
the inside interface based on the routing table preventing the return packet from reaching Client A.
If RTS is enabled, the return packet will not be routed through the default gateway (inside
interface). Instead, the return packet will go back along the same path that originated the request,
thus insuring a successful transaction. Administrators can configure this feature by using the
command “ip rts on”.
Note: Due to system limitation, please configure the default gateway for RTS to work
properly.
13.2 Bond
Bond interface is usually used for link aggregation and redundancy purposes. Link Aggregation
(or trunking) is a method of combining physical network links into a single logical link to increase
bandwidth. With link aggregation, two or more Gigabit Ethernet connections are combined in
order to increase the bandwidth capacity and create resilient and redundant links between devices.

Outbound traffic interface is selected using the following parameters:
 For TCP and UDP traffic, destination port is used.
 For other IP protocols such as ICMP, destination IP is used.
Bond interface can support multiple primary/backup interfaces for redundancy purposes. If all the
primary interfaces in the bond fail, the backup interfaces will immediately take the place of the
primary interfaces.
The AG appliance supports up to 3 bond interfaces. The bond will check the status of the system
interfaces. If a system interface becomes down, the traffic processed by this interface will be
directed to other working system interfaces in the bond.
Note: To bind a system interface with a bond interface, the system interface should be
configured with no IP address information. If there is IP configuration on the system
interface, the administrator needs to remove the IP configuration first. Otherwise, the
system will refuse to add the system interface into the bond.
In addition, the AG appliance also supports configuring VLAN on a bond interface. The bond
interface must be configured before adding the VLAN support.
13.3 NAT
NAT (Network Address Translation) translates an IP address within an inside network to a
different IP address within an outside network, and vice versa. NAT is used in such cases where
computers on the inside network need to access the outside network. Using NAT, all packets will
appear as though they come from the AG appliance.
When the packets pass through the NAT gateway like AG appliance, they will be modified so that
they appear to be coming from the NAT gateway itself. The NAT gateway will record the changes
in its state table so that it can reverse the changes on returned packets and ensure that the returned
packets are passed through the firewall without being blocked.
AG appliance can support two types of NAT: static NAT and port-level NAT.
Static NAT: Mapping an IP address on a one-to-one basis. By configuring static NAT, the AG
appliance maps an inside real IP address to an outside VIP address. For inbound traffic directed
from the outside VIP, the traffic will be forwarded to a corresponding inside real IP without any
change in the port number or protocol value. Thus, hosts on the inside network will be directly
accessible via the VIP on the outside interface. The outbound traffic coming from an inside host
will use the corresponding outside VIP as the source IP for the outgoing traffic. The port number
and protocol remain unchanged. TCP, UDP and ICMP are supported for static NAT.
In the static NAT diagram below, the computer with the IP address (10.3.0.88) will be always
translated into 227.70.201.18.

Figure 13–2 Static NAT
Port-level NAT: Mapping multiple inside real IP addresses to a single VIP address by assigning
different port numbers. By configuring port-level NAT, the group of hosts on the inside network
will be directly accessible via the VIP on the outside interface.
In the port-level NAT diagram below, the computers with the IP address in the range from
10.3.0.88 to 10.3.0.89 will each be translated into 227.201.70.18 with a unique port number on the
outside network.

Figure 13–3 Port-level NAT
If a port-level NAT is configured for an inside real IP address, static NAT should take precedence
over the regular NAT policy. VIPs used by static NAT should not be used by regular NAT. Also,
one static NAT VIP should not map to multiple real IP addresses.
13.4 HTTP Compression

HTTP Compression, otherwise known as content encoding, is a publicly defined way to compress
textual contents transferred from Web servers to browsers. HTTP Compression uses public
domain compression algorithms to compress XHTML, JavaScript, Cascade Style Sheets (CSS),
and other text files at the server.
By default, the following Multipurpose Internet Mail Extensions (MIME) types can be
compressed by the AG appliance for all the browsers:
 .txt (text/plain)
 .html (text/HTML)
 .xml (text/XML)
The following MIME types can be compressed by the AG appliance for certain browsers by
configuring advanced HTTP compression policies:
 .js (text/javascript)
 .css (text/css)
 .pdf (application/pdf)
 .ppt (application/mspowerpoint)
 .xls documents (application/msexcel)
 .doc (application/msword)
In addition, the URL-excluded compression policies can be configured under the virtual site scope
so that URLs matching the configured “keyword” regular expression will not be compressed.
13.5 NDP
NDP (Neighbor Discovery Protocol), a key protocol of the IPv6 stack, can be used for obtaining
the link address information of other neighbor nodes connected with the local nodes.
Similar to the ARP (Address Resolution Protocol) of the IPv4 stack, NDP can perform address
transformation between the network layer and the link layer. The difference is that NDP uses
ICMPv6 (Internet Control Message Protocol version 6) and multicast to manage the information
exchanged among the neighboring nodes (within the same link), and keeps the address mapping
between the network layer and the link layer in the same subnet.

13.6.1 RTS
 Enable RTS
Under the global scope, select System Configuration > Basic Networking > Routing > RTS and
check the Enable RTS check box, as shown in Figure 13–4.
Figure 13–4 RTS Settings
 Set RTS Expiration Time
Under the global scope, select System Configuration > Basic Networking > Routing > RTS and
enter the RTS expiration time in the text box, as shown in Figure 13–4.
 Check RTS Statistics
Its statistics can be checked in the RTS Statistics area, as shown in Figure 13–4.
13.6.2 Bond
Under the global scope, select System Configuration > Basic Networking > Interface > Link
Aggregation and select Bond ID from the drop-down list, as shown in Figure 13–5.

Figure 13–5 Link Aggregation
 Interface Settings
For this particular Bond, enter a custom Name, the Static IP Address and Static Netmask, as
Figure 13–6 Interface Settings
After clicking the Apply Changes button, you will be presented with more configurations in the
Add Bond configuration window. Select the Interface Name from the drop-down list and the
Interface Type as Primary or Backup, and then click the Save & Add Another button to add
another port to the Bond, as shown in Figure 13–7.
Figure 13–7 Add the Bond
Note:
 The IP address of the port to be added in the Bond cannot be configured. Otherwise
you need to remove the IP address of the port first before adding it to the Bond.
 The internet traffic will first go through the Primary interfaces, and go through the
Backup interface only when the Primary interfaces go wrong.
 Add VLAN
Under the global scope, select System Configuration > Basic Networking > Interface > Port,
click the Add VLAN button in the VLAN Configurations area, as shown in Figure 13–8.

Figure 13–8 VLAN Configurations
In the Add VLAN configuration window, specify the VLAN Name, Network IP, Netmask and
Tag Number, as shown in Figure 13–9.
Figure 13–9 Add the VLAN
13.6.3 NAT
Please select System Configuration > Advanced Networking > NAT under the global scope to
set NAT configurations, as shown in Figure 13–10.
Figure 13–10 NAT
 Add NAT Port
Click the Add NAT Port button in the NAT Port Configuration area, as shown in Figure 13–10.
In the Add NAT Port configuration window, enter the Virtual IP, Network IP, Netmask,
Timeout value and Gateway IP in the text boxes, as shown in Figure 13–11.

Figure 13–11 Add NAT Port
 Add NAT Static
Click the Add NAT Static button in the NAT Static Configuration area, as shown in Figure
13–10.
In the Add NAT Static configuration window, enter the Virtual IP, Network IP, Timeout value
and Gateway IP in the text boxes, as shown in Figure 13–12.
Figure 13–12 Add NAT Static
13.6.4 HTTP Compression

 Enable HTTP Compression
Under the global scope, select System Configuration > Advanced Networking > HTTP >
HTTP Compression, and select the Enable HTTP Compression check box in the General
HTTP Compression Setting area, as shown in Figure 13–13.

Figure 13–13 Enable HTTP Compression
 Add Recommended Policies
In the Advanced HTTP Compression Policies table in Figure 13–13, click the Add
Recommended Policies action link, as shown in Figure 13–14. That is, the AG appliance
compresses JavaScript and CSS-type data for the following four types of explorers (user agents):
IE 6, IE 7, IE 8 and Mozilla 5.0.
Apply Changes

Figure 13–14 Add Recommended Policies
 Add Advanced HTTP Compression Policy
In the Advanced HTTP Compression Policies table in Figure 13–13, click the Add action link.
In the displayed Add Advanced HTTP Compression Policy area, specify the parameters User
Agent and MIME Type(s), and click the Save action link, as shown in Figure 13–15.
Figure 13–15 Add Advanced HTTP Compression Policy
 Add URL-excluded Compression Policy under the Virtual Site Scope
Under the virtual site scope, in the URL-excluded Compression Policies area of Access
Methods > Web Access > Server Access > Compression Policies, click the Add action link, as
Figure 13–16 URL-excluded Compression Policies
In the Add URL-excluded Compression Policy area, enter a regular expression in the URL
Keyword text box and click the Save action link, as shown in Figure 13–17.

Figure 13–17 Add URL-excluded Compression Policy
13.6.5 NDP
 Configure NDP Entry
Under the global scope, select System Configuration > Basic Networking > ARP. Click the
Add action link in the NDP Configuration area, specify parameters in the Add NDP area and
click the Save action link, as shown in Figure 13–18.
Figure 13–18 Add an NDP Entry

Chapter 14 13BIPv6 Support
Chapter 14 IPv6 Support

As the IPv4 addresses exhaust, how to transit from the IPv4 network to the IPv6 network becomes
a challenge for many Internet service providers.
The AG appliance provides IPv6 support to help enterprises and organizations with the
IPv4-to-IPv6 transition. With the IPv4/IPv6 dual stack support on AG, the IPv4 resources can be
delivered to the IPv6 users.
This chapter will introduce IPv6 functions and configurations concerning NDP, AG management,
portal access, QuickLink, Array Client, Speed Tunnel and HA.
14.1 AG Management via IPv6

The IP addresses of the AG interfaces can now be configured as IPv6 addresses. The following are
also supported:
 IPv6 route configuration
 IPv6 bond interface
 WebUI access via IPv6
 SSH access via IPv6
 IPv6 portal access
14.2 IPv6 Access Method

QuickLink (including hostname mode and port mode) and Array Client (including Speed Tunnel)
both support IPv4 over IPv6 now. IPv4 over IPv6 here means that the clients and the AG
appliance use IPv6 addresses for network connection, while the backend server uses IPv4 address.
14.3 HA Support for IPv6

The HA feature supports IPv6 now, that is, IPv6 addresses can be configured for the HA units.
Please note that the HA units in one HA domain must be all IPv4 address, or all IPv6 address, but
not be a mixture of the two.
For the configuration of the above-mentioned features, please go to the specific sections.

Appendix I Array Networks Product Registration

Array Networks invites you to register your product and to activate your warranty. Activation is
simple; and by doing so you will be able to receive such benefits as:
 Access to the Array Networks Customer Support Portal
 Notifications of important Array product and software updates
 Reminders regarding support license expirations and extensions
 Personalized and expedient technical support responses
Registration
Note: You must have basic network connectivity in order to finish the registration,
because the questionnaire for registration is online.
The first time you log onto the Array product you will be prompted to register, as shown in the
following figure. By clicking on the “Register Now” button you will be presented with a short
questionnaire. Please take a moment to supply this important information. Once you’ve filled out
the form, simply click the “Signup” button. That’s it! Your Array product is registered.
Figure I-1 Registration
Should you wish to register later, simply click on the “Register Later” button and you will
continue the login process arriving to the configuration management homepage. Each time you
login, you will be asked if you would like to register.
If you wish never to register, simply click on the “Never Register” button and you will be
directed to the configuration management homepage. However, should you choose at a later time
to register your Array product, you will be able to do so from the configuration home page by
clicking on the “Register Now” link located next to the model number, as shown in the following
figure.

Figure I-2 Register Now Link

Appendix II Abbreviations and Acronyms

Abbreviation/Acronym Full Spelling
AAA Authentication, Authorization & Accounting
ACL Access Control List
AD Active Directory
ADC Application Delivery Controller
API Application Programming Interface
ARP Address Resolution Protocol
ASCII American Standard Code for Information Interchange
CA Certificate Authority
CLI Command Line Interface
CPU Central Processing Unit
CSS Cascading Style Sheets
DHCP Dynamic Host Configuration Protocol
DMZ DeMilitarized Zone
DNS Domain Name Service
DoS Denial Of Service
FFO Fast Failover
FQDN Fully Qualified Domain Name
GMT Greenwich Mean Time
HA High Availability
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol over Secure Socket Layer
ICMP Internet Control Message Protocol
IE Internet Explorer
IP Internet Protocol
IPSEC Internet Protocol Security
JRE Java Runtime Environment
LDAP Lightweight Directory Access Protocol
LED Light Emitting Diode
Local DNS Local Domain Name Service
LocalDB Local Database
MAC Media Access Control
MIB Management Information Base
NAT Network Address Translation
NDS Novell Directory Services
NetBIOS Network Basic Input/Output System
NIC Network Interface Card
NS Name Server
NTP Network Time Protocol

Abbreviation/Acronym Full Spelling

OID Object Identifier
OWA Outlook Web Access
PDF Portable Document Format
PST Pacific Standard Time
RADIUS Remote Authentication Dial In User Service
RTS Return to Sender
SNMP Simple Network Management Protocol
SSH Secure Shell Protocol
SSL Secure Sockets Layer
SSO Single Sign On
TACACS Terminal Access Controller Access Control System
TCP Transmission Control Protocol
TTL Time to Live
UDP User Datagram Protocol
URL Uniform Resource Locator
Vbscript Visual Basic Script
VIP Virtual IP
VLAN Virtual Local Area Network
VRRP Virtual Router Redundancy Protocol
VPN Virtual Private Network
WebUI Web User Interface
WRM Web Resource Mapping
WELF WebTrends Enhanced Log Format
WINS Windows Internet Name Service
XML Extensible Markup Language
XML RPC XML-based Remote Procedure Call

Appendix III SNMP OID List

SNMP OID List
.1.3.6.1.4.1.7564 This file defines the private CA SNMP MIB extensions.
.1.3.6.1.4.1.7564.4.1 Current total available memory in the system.
Current maximum possible number of entries in the vrrpTable,
.1.3.6.1.4.1.7564.18.1.1 which is 255 * (number of interfaces for which a cluster is
defined). 255 is the max number of VIPs in a cluster.
.1.3.6.1.4.1.7564.18.1.2 Current number of entries in the vrrpTable.
.1.3.6.1.4.1.7564.18.1.3 A table containing cluster configurations.
An entry in the vrrpTable. Each entry represents a cluster VIP,
not the cluster itself. If a cluster has n VIPs, then there will be n
entries for the cluster in the vrrpTable (0 <= n <= 255). All the
.1.3.6.1.4.1.7564.18.1.3.1
entries in the vrrpTable belonging to a single cluster will have
the same values for all the fields except clusterVirIndex and
clusterVirAddr.
.1.3.6.1.4.1.7564.18.1.3.1.1 The cluster virtual table index.
.1.3.6.1.4.1.7564.18.1.3.1.2 The cluster identifier.
.1.3.6.1.4.1.7564.18.1.3.1.3 The current state of the cluster.
.1.3.6.1.4.1.7564.18.1.3.1.4 The interface name on which the cluster is defined.
.1.3.6.1.4.1.7564.18.1.3.1.5 A virtual IP address (VIP) in the cluster.
Type of authentication being used. none(0) - no authentication;
.1.3.6.1.4.1.7564.18.1.3.1.6 simple-text-password(1) - use password specified in cluster
virtual for authentication.
.1.3.6.1.4.1.7564.18.1.3.1.7 The password for authentication.
This is for controlling whether a higher priority Backup VRRP
.1.3.6.1.4.1.7564.18.1.3.1.8
virtual preempts a low priority Master.
.1.3.6.1.4.1.7564.18.1.3.1.9 VRRP advertisement interval.
.1.3.6.1.4.1.7564.18.1.3.1.10 Priority of the local node in the cluster.
.1.3.6.1.4.1.7564.20.1.2 Number of vhosts currently configured.
.1.3.6.1.4.1.7564.20.2.1 Total number of open SSL connections (all vhosts).
.1.3.6.1.4.1.7564.20.2.2 Total number of accepted SSL connections (all vhosts).
.1.3.6.1.4.1.7564.20.2.3 Total number of requested SSL connections (all vhosts).
.1.3.6.1.4.1.7564.20.2.4 SSL vhost statistics table.
.1.3.6.1.4.1.7564.20.2.4.1 SSL table entry for one vhost.
.1.3.6.1.4.1.7564.20.2.4.1.1 The SSL table index.
.1.3.6.1.4.1.7564.20.2.4.1.2 Name of the SSL vhost.
.1.3.6.1.4.1.7564.20.2.4.1.3 Open SSL connections for vhostName.
.1.3.6.1.4.1.7564.20.2.4.1.4 Number of accepted SSL connections for vhostName.
.1.3.6.1.4.1.7564.20.2.4.1.5 Number of requested SSL connections for vhostName.
.1.3.6.1.4.1.7564.20.2.4.1.6 Number of resumed SSL sessions for vhostName.
.1.3.6.1.4.1.7564.20.2.4.1.7 Number of resumable SSL sessions for vhostName.
.1.3.6.1.4.1.7564.20.2.4.1.8 Number of session misses for vhostName.

SNMP OID List

1.3.6.1.4.1.7564.21.1 Number of sessions by the security proxy.
1.3.6.1.4.1.7564.21.2 Number of successful login by the security proxy.
1.3.6.1.4.1.7564.21.3 Number of successful logout by the security proxy.
1.3.6.1.4.1.7564.21.4 Number of failed login by the security proxy.
1.3.6.1.4.1.7564.21.5 Number of total bytes in.
1.3.6.1.4.1.7564.21.6 Number of total bytes out.
1.3.6.1.4.1.7564.21.7 Maximum number of active sessions by the security proxy.
1.3.6.1.4.1.7564.21.8 Number of login errors by the security proxy.
Number of login failures due to the user lockout login by the
1.3.6.1.4.1.7564.21.9
security proxy.
1.3.6.1.4.1.7564.21.10 Number of total backend server bytes in.
1.3.6.1.4.1.7564.21.11 Number of total backend server bytes out.
.1.3.6.1.4.1.7564.22.1 Status of VIP statistics gathering - on or off.
The hostname that the VIP is representing (hostname of the
.1.3.6.1.4.1.7564.22.2
appliance).
.1.3.6.1.4.1.7564.22.3 The current time in the format of MM/DD/YY HH:MM.
.1.3.6.1.4.1.7564.22.4 Total number of IP packets received on all VIPs.
.1.3.6.1.4.1.7564.22.5 Total number of IP packets sent out on all VIPs.
.1.3.6.1.4.1.7564.22.6 Total number of IP bytes received on all VIPs.
.1.3.6.1.4.1.7564.22.7 Total number of IP bytes sent out on all VIPs.
.1.3.6.1.4.1.7564.22.8 A table of VIP statistics.
.1.3.6.1.4.1.7564.22.8.1 An entry in the ipStatsTable which is created for each VIP.
.1.3.6.1.4.1.7564.22.8.1.1 The VIP statistics table index.
.1.3.6.1.4.1.7564.22.8.1.2 The VIP address.
.1.3.6.1.4.1.7564.22.8.1.3 Total number of IP packets received on the VIP.
.1.3.6.1.4.1.7564.22.8.1.4 Total number of IP bytes received on the VIP.
.1.3.6.1.4.1.7564.22.8.1.5 Total number of IP packets sent out on the VIP.
.1.3.6.1.4.1.7564.22.8.1.6 Total number of IP bytes sent out on the VIP.
.1.3.6.1.4.1.7564.22.8.1.7 The time statistics gathering was enabled for the VIP.
.1.3.6.1.4.1.7564.23.1 The number of network interfaces presented on this system.
The total accumulated number of octets received on all the
.1.3.6.1.4.1.7564.23.2
active interfaces (loopback is not included).
The total accumulated number of octets transmitted out on all
.1.3.6.1.4.1.7564.23.3
the active interfaces (loopback is not included).
A table of interface statistics. The number of entries is given by
.1.3.6.1.4.1.7564.23.4
the value of infNumber.
.1.3.6.1.4.1.7564.23.4.1 An infTable entry for one interface.
A unique value for each interface. Its value ranges between 1
and the value of infNumber. The value for each interface must
.1.3.6.1.4.1.7564.23.4.1.1
remain constant at least from one re-initialization of the entities
network management system to the next re- initialization.
.1.3.6.1.4.1.7564.23.4.1.2 Name of the interface.

SNMP OID List

.1.3.6.1.4.1.7564.23.4.1.3 The current operational state of the interface (up or down).
.1.3.6.1.4.1.7564.23.4.1.4 The interface's IP address.
The total number of octets received on the interface, including
.1.3.6.1.4.1.7564.23.4.1.5
framing characters.
The number of packets, delivered by this sub-layer to a higher
.1.3.6.1.4.1.7564.23.4.1.6 (sub-) layer, which were not addressed to a multicast or
broadcast address at this sub-layer.
The number of packets, delivered by this sub-layer to a higher
(sub-) layer, which were addressed to a multicast or broadcast
address at this sub-layer.
Discontinuities in the value of this counter can occur at
.1.3.6.1.4.1.7564.23.4.1.7
re-initialization of the management system, and at other times as
indicated by the value of ifCounterDiscontinuityTime.
This object is deprecated in favor of ifInMulticastPkts and
ifInBroadcastPkts.
The number of inbound packets which were chosen to be
discarded even though no errors had been detected to prevent
them from being deliverable to a higher-layer protocol. One
possible reason for discarding such a packet could be to free up
.1.3.6.1.4.1.7564.23.4.1.8
buffer space.
indicated by the value of ifCounterDiscontinuityTime
For packet-oriented interfaces, the number of inbound packets
that contain errors preventing them from being deliverable to a
higher-layer protocol. For character- oriented or fixed-length
interfaces, the number of inbound transmission units that
.1.3.6.1.4.1.7564.23.4.1.9 contain errors preventing them from being deliverable to a
higher-layer protocol.
For packet-oriented interfaces, the number of packets received
via the interface which were discarded because of an unknown
or unsupported protocol. For character-oriented or fixed-length
interfaces that support protocol multiplexing the number of
transmission units received via the interface which were
.1.3.6.1.4.1.7564.23.4.1.10 discarded because of an unknown or unsupported protocol. For
any interface that does not support protocol multiplexing, this
counter will always be 0.

SNMP OID List

The total number of octets transmitted out of the interface,
including framing characters.
.1.3.6.1.4.1.7564.23.4.1.11 Discontinuities in the value of this counter can occur at
The total number of packets that higher-level protocols request
to be transmitted, and which were not addressed to a multicast
or broadcast address at this sub-layer, including those that were
.1.3.6.1.4.1.7564.23.4.1.12 discarded or not sent.
The total number of packets that higher-level protocols request
to be transmitted, and which were addressed to a multicast or
broadcast address at this sub-layer, including those that were
discarded or not sent.
.1.3.6.1.4.1.7564.23.4.1.13 Discontinuities in the value of this counter can occur at
This object is deprecated in favor of ifOutMulticastPkts and
ifOutBroadcastPkts.
For packet-oriented interfaces, the number of outbound packets
that could not be transmitted because of errors. For
character-oriented or fixed-length interfaces, the number of
outbound transmission units that could not be transmitted
.1.3.6.1.4.1.7564.23.4.1.14
because of errors.
The number of Syslog notifications that have been sent. This
number can include notifications that were prevented from being
transmitted due to reasons such as resource limitations and/or
.1.3.6.1.4.1.7564.24.1.1 non-connectivity. If one is receiving notifications, one can
periodically poll this object to determine if any notifications
were missed. If so, a poll of the logHistoryTable might be
appropriate.
Indicates whether logMessageGenerated notifications will or
will not be sent when a Syslog message is generated by the
.1.3.6.1.4.1.7564.24.1.2
device. Disabling notifications does not prevent Syslog
messages from being added to the logHistoryTable.
Indicates which Syslog severity levels will be processed. Any
.1.3.6.1.4.1.7564.24.1.3 Syslog message with a severity value greater than this value will
be ignored by the agent. Note: the severity numeric values

SNMP OID List

increase as their severity decreases, e.g. error(4) is more severe
than debug(8).
The upper limit on the number of entries that the
logHistoryTable can contain. A value of 0 will prevent any
.1.3.6.1.4.1.7564.24.2.1
history from being retained. When this table is full, the oldest
entry will be deleted and a new one will be created.
A table of Syslog messages generated by this device. All
.1.3.6.1.4.1.7564.24.2.2 'interesting' Syslog messages (i.e. severity <= logMaxSeverity)
are entered into this table.
A Syslog message that was previously generated by this device.
.1.3.6.1.4.1.7564.24.2.2.1
Each entry is indexed by a message index.
A monotonically increasing integer for the sole purpose of
.1.3.6.1.4.1.7564.24.2.2.1.1 indexing messages. When it reaches the maximum value the
agent flushes the table and wraps the value back to 1.
.1.3.6.1.4.1.7564.24.2.2.1.2 The severity of the message.
The text of the message. If the text of the message exceeds 255
bytes, the message will be truncated to 254 bytes and a '*'
.1.3.6.1.4.1.7564.24.2.2.1.3
character will be appended, indicating that the message has been
truncated.
When a syslogTrap message is generated by the device a
syslogTrap notification is sent. The sending of these
.1.3.6.1.4.1.7564.24.3.1
notifications can be enabled/disabled via the
logNotificationsEnabled object.
The number of times ClickTCP connections have made a direct
.1.3.6.1.4.1.7564.25.1
transition to the SYN-SENT state from the CLOSED state.
.1.3.6.1.4.1.7564.25.2
transition to the SYN-RCVD state from the LISTEN state.
transition to the CLOSED state from either the SYN-SENT state
.1.3.6.1.4.1.7564.25.3 or the SYN-RCVD state, plus the number of times TCP
connections have made a direct transition to the LISTEN state
from the SYN-RCVD state.
.1.3.6.1.4.1.7564.25.4 transition to the CLOSED state from either the ESTABLISHED
state or the CLOSE-WAIT state.
The number of ClickTCP connections for which the current
.1.3.6.1.4.1.7564.25.5
state is either ESTABLISHED or CLOSE-WAIT.
The total number of ClickTCP segments received, including
.1.3.6.1.4.1.7564.25.6 those received in error. This count includes segments received
on currently established connections.
The total number of ClickTCP segments sent, including those on
.1.3.6.1.4.1.7564.25.7 current connections but excluding those containing only
retransmitted octets.

SNMP OID List

The total number of segments retransmitted - that is, the number
.1.3.6.1.4.1.7564.25.8 of ClickTCP segments transmitted containing one or more
previously transmitted octets.
The total number of segments received in error (for example,
.1.3.6.1.4.1.7564.25.9
bad ClickTCP checksums).
The number of ClickTCP segments sent containing the RST
.1.3.6.1.4.1.7564.25.10
flag.
.1.3.6.1.4.1.7564.25.11 A table containing ClickTCP connection-specific information.
A conceptual row of the ctcpConnTable containing information
about a particular current TCP connection. Each row of this
.1.3.6.1.4.1.7564.25.11.1
table is transient, in that it ceases to exist when (or soon after)
the connection makes the transition to the CLOSED state.
.1.3.6.1.4.1.7564.25.11.1.1 A unique value for each ClickTCP connection.
The state of this TCP connection.
The only value which can be set by a management station is
deleteTCB(12). Accordingly, it is appropriate for an agent to
return a 'badValue' response if a management station attempts to
set this object to any other value.
If a management station sets this object to the value
.1.3.6.1.4.1.7564.25.11.1.2 deleteTCB(12), then this has the effect of deleting the TCB (as
defined in RFC 793) of the corresponding connection on the
managed node, resulting in immediate termination of the
connection.
As an implementation-specific option, an RST segment can be
sent from the managed node to the other TCP endpoint (note
however that RST segments are not sent reliably).
The local IP address for this TCP connection. In the case of a
connection in the listen state which is willing to accept
.1.3.6.1.4.1.7564.25.11.1.3
connections for any IP interface associated with the node, the
value 0.0.0.0 is used.
.1.3.6.1.4.1.7564.25.11.1.4 The local port number for this TCP connection.
.1.3.6.1.4.1.7564.25.11.1.5 The remote IP address for this TCP connection.
.1.3.6.1.4.1.7564.25.11.1.6 The remote port number for this TCP connection.
.1.3.6.1.4.1.7564.28.1 Total number of bytes received.
.1.3.6.1.4.1.7564.28.2 Total number of bytes sent.
.1.3.6.1.4.1.7564.28.3 Number of bytes received per second.
.1.3.6.1.4.1.7564.28.4 Number of bytes sent per second.
.1.3.6.1.4.1.7564.28.5 Peak received bytes per second.
.1.3.6.1.4.1.7564.28.6 Peak sent bytes per second.
.1.3.6.1.4.1.7564.28.7 Number of currently active transaction.
.1.3.6.1.4.1.7564.30.1 Current percentage of CPU utilization.
.1.3.6.1.4.1.7564.30.2 Number of connections per second.

SNMP OID List

.1.3.6.1.4.1.7564.30.3 Number of requests per second.
The number of <Virtual Site ID, login, logout> combo pairs that
.1.3.6.1.4.1.7564.31.1.1
is involved in the virtual site.
1.3.6.1.4.1.7564.31.1.2 A table containing virtual site statistics.
1.3.6.1.4.1.7564.31.1.2.1 The entry in virtualSiteStatsTable.
Reference index for virtual site (Virtual Site ID, login, logout)
1.3.6.1.4.1.7564.31.1.2.1.1
combo.
1.3.6.1.4.1.7564.31.1.2.1.2 Virtual site name ID.
1.3.6.1.4.1.7564.31.1.2.1.3 Virtual site active sessions.
1.3.6.1.4.1.7564.31.1.2.1.4 Virtual site successful login.
1.3.6.1.4.1.7564.31.1.2.1.5 Virtual site failed login.
1.3.6.1.4.1.7564.31.1.2.1.6 Virtual site error login.
1.3.6.1.4.1.7564.31.1.2.1.7 Virtual site success logout.
1.3.6.1.4.1.7564.31.1.2.1.8 Number of bytes in per virtual site.
1.3.6.1.4.1.7564.31.1.2.1.9 Number of bytes out per virtual site.
1.3.6.1.4.1.7564.31.1.2.1.10 Virtual site maximum active sessions.
1.3.6.1.4.1.7564.31.1.2.1.15 Virtual site user locked out upon login.
1.3.6.1.4.1.7564.31.1.2.1.16 Virtual site user rejected upon login.
1.3.6.1.4.1.7564.31.1.2.1.17 Virtual site IP list.
1.3.6.1.4.1.7564.31.1.2.1.18 Virtual site domain list.
1.3.6.1.4.1.7564.31.1.2.1.19 Number of backend server bytes in per virtual site.
1.3.6.1.4.1.7564.31.1.2.1.20 Number of backend server bytes out per virtual site.
The number of <Virtual Site ID, login, logout> combo pairs that
1.3.6.1.4.1.7564.32.1.1
is involved in the virtual site.
1.3.6.1.4.1.7564.32.1.2.1 The entry in vpnStatsTable.
1.3.6.1.4.1.7564.32.1.2.1.1 Reference index for VPN (Virtual Site ID, login, logout) combo.
1.3.6.1.4.1.7564.32.1.2.1.2 Virtual site ID.
1.3.6.1.4.1.7564.32.1.2.1.3 VPN tunnels open.
1.3.6.1.4.1.7564.32.1.2.1.4 VPN tunnels established.
1.3.6.1.4.1.7564.32.1.2.1.5 VPN tunnels rejected.
1.3.6.1.4.1.7564.32.1.2.1.6 VPN tunnels terminated.
1.3.6.1.4.1.7564.32.1.2.1.7 Number of bytes coming in.
1.3.6.1.4.1.7564.32.1.2.1.8 Number of bytes going out.
1.3.6.1.4.1.7564.32.1.2.1.9 Number of unauthorized packets in.
1.3.6.1.4.1.7564.32.1.2.1.10 Number of bytes of application inbound traffic.
1.3.6.1.4.1.7564.32.1.2.1.11 Number of bytes of application outbound traffic.
The number of <Virtual Site ID, AuthorizedReq,
1.3.6.1.4.1.7564.33.1.1 webUnauthorizedReq> combo pairs that is involved in the
virtual site.
1.3.6.1.4.1.7564.33.1.2.1 The entry in webStatsTable.

SNMP OID List

Reference index for Web (Virtual Site ID, AuthorizedReq,
1.3.6.1.4.1.7564.33.1.2.1.1
webUnauthorizedReq) combo.
1.3.6.1.4.1.7564.33.1.2.1.2 Virtual site name ID.
1.3.6.1.4.1.7564.33.1.2.1.3 Web authorized requests.
1.3.6.1.4.1.7564.33.1.2.1.4 Web unauthorized requests.
1.3.6.1.4.1.7564.33.1.2.1.5 Number of bytes in by web.
1.3.6.1.4.1.7564.33.1.2.1.6 Number of bytes out by web.
1.3.6.1.4.1.7564.33.1.2.1.7 Number of backend server bytes in by web.
1.3.6.1.4.1.7564.33.1.2.1.8 Number of backend server bytes out by web.
The number of <Group ID, session count, max session count>
1.3.6.1.4.1.7564.36.1.1
combo pairs that is involved in the virtualSiteGroup.
1.3.6.1.4.1.7564.36.1.2 A table containing virtual site group statistics.
1.3.6.1.4.1.7564.36.1.2.1 The entry in virtualSiteStatsTable.
Reference index for virtual site group (Group ID, session count,
1.3.6.1.4.1.7564.36.1.2.1.1
max session count) combo.
1.3.6.1.4.1.7564.36.1.2.1.2 Virtual site group ID.
virtual Site Group Active
Virtual site group active sessions.
Sessions
1.3.6.1.4.1.7564.36.1.2.1.4 Virtual site group maximum active sessions.
.1.3.6.1.4.1.7564.251.1 This trap is sent when the agent starts.
.1.3.6.1.4.1.7564.251.2 This trap is sent when the agent terminates.
This trap is automatically sent to remind you of the license
.1.3.6.1.4.1.7564.251.3
remaining days.
A single precision floating-point number. The semantics and
encoding are identical for type 'single' defined in IEEE Standard
for Binary Floating-Point, ANSI/IEEE Std 754-1985. The value
is restricted to the BER serialization of the following ASN.1
type: FLOATTYPE ::= [120] IMPLICIT FloatType (note: the
value 120 is the sum of '30'h and '48'h) The BER serialization of
Float the length for values of this type must use the definite length,
short encoding form. For example, the BER serialization of
value 123 of type FLOATTYPE is '9f780442f60000'h. (The tag
is '9f78'h; the length is '04'h; and the value is '42f60000'h.) The
BER serialization of value '9f780442f60000'h of data type
Opaque is '44079f780442f60000'h. (The tag is '44'h; the length
is '07'h; and the value is '9f780442f60000'h.
The severity of a Syslog message. The enumeration values are
Synlogseverity equal to the values that Syslog uses + 1. For example, with
Syslog, emergency=0.


Array User Guide PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Array User Guide PDF

Hochgeladen von

Copyright:

Verfügbare Formate

ArrayOS AG 9.

2015 Array Networks, Inc. I

About Array Networks

Contacting Array Networks

Toll Free: 1-866-692-7729 (1-866-MY-ARRAY)

Support: 1-877-992-7729 (1-877-99-ARRAY)

1371 McCarthy Boulevard

Milpitas, California 95035, USA

2015 Array Networks, Inc. II

2015 Array Networks, Inc. III

Declaration of Conformity ................................................................................................................ I

About Array Networks ..................................................................................................................... II

Contacting Array Networks ............................................................................................................. II

Revision History ............................................................................................................................. III

Table of Contents ............................................................................................................................IV

Chapter 1 Array AG Functionality Overview ................................................................................... 1

1.1 Introduction to the Array AG .............................................................................................. 1

1.2 Quick Start for Array AG.................................................................................................... 3

Chapter 2 Initial System Setup & Configuration .............................................................................. 6

2.1 Connecting to AG ............................................................................................................... 6

2.1.1 Console Connection ................................................................................................. 6

2.1.2 SSH Connection ....................................................................................................... 6

2.1.3 WebUI Connection................................................................................................... 7

2.1.4 Reading the LED ...................................................................................................... 8

2.2 AG Command Line Interface Structure .............................................................................. 9

2.2.1 Command Usage Breakdown ................................................................................... 9

2.2.2 Levels of Global Access Control ........................................................................... 10

2.2.3 Levels of Virtual Site Access Control .................................................................... 11

2.2.4 Switching between Global and Virtual Site ........................................................... 12

2.3 Initial Network Setup ........................................................................................................ 13

2.3.1 Basic Network Topology ....................................................................................... 13

2.3.2 Initial Setup Guidelines .......................................................................................... 15

2.3.3 Configuration Example for Initial Setup ................................................................ 15

2.4 DNS Configuration on AG................................................................................................ 20

2.4.1 Introduction to DNS ............................................................................................... 20

2.4.2 Understanding AG DNS ........................................................................................ 21

2.4.3 Configuration Example for DNS............................................................................ 22

2015 Array Networks, Inc. IV

Chapter 3 Virtual Site ..................................................................................................................... 29

3.1 Virtual Site ........................................................................................................................ 29

3.1.1 Introduction ............................................................................................................ 29

3.1.2 Different Virtual Site Types ................................................................................... 29

3.1.3 Configuration Example .......................................................................................... 30

3.2.1 Cryptography ......................................................................................................... 34

3.2.2 Digital Signature .................................................................................................... 35

3.2.3 Certificate ............................................................................................................... 35

3.2.4 SSL Certificates and Authentication ...................................................................... 36

3.2.5 Configuration Example .......................................................................................... 39

Chapter 4 AAA (Authentication, Authorization, Accounting) ....................................................... 47

4.1 Introduction ....................................................................................................................... 47

4.1.1 Authentication ........................................................................................................ 47

4.1.2 Authorization ......................................................................................................... 47

4.1.3 Accounting ............................................................................................................. 47

4.2 AAA in AG ....................................................................................................................... 48

4.2.1 AAA Server............................................................................................................ 48

4.2.2 AAA Method.......................................................................................................... 72

4.2.3 AAA Method Rank ................................................................................................ 74

4.2.4 Accounting ............................................................................................................. 76

4.3 Configuration Example ..................................................................................................... 77

4.3.1 Enable AAA ........................................................................................................... 77

4.3.2 Configure AAA Servers ......................................................................................... 77

4.3.3 Configure AAA Methods ....................................................................................... 78

4.3.4 Configure AAA Method Rank ............................................................................... 79