Version 8.2.1
Copyright © 2004 - 2008 AppGate Network Security AB
AppGate and MindTerm are trademarks of AppGate Network Security AB. Other brands and product names may be trademarks of their respective companies or organizations.
The contents of this document are subject to revision and can be changed without notice. AppGate Network Security AB shall have no liability for any error or damage resulting from the usage of this document.
Table of Contents
- 1. About this guide
- 2. Functional Overview
- 3. Clients
- 3.1. Client Overview
- 3.1.1. AppGate Client
- 3.1.2. AppGate Connect and Applet
- 3.1.3. AppGate Mobile client
- 3.1.4. Clients for Citrix and Terminal Servers
- 3.1.5. Operating System support of AppGate clients
- 3.1.6. AppGate IP Tunneling Driver
- 3.1.7. AppGate Hosts File Writer
- 3.1.8. AppGate Device Firewall
- 3.1.9. Deployment of AppGate clients
- 3.2. Client Installation
- 3.2.1. Installation on Windows
- 3.2.2. Installation on Mac OS X
- 3.2.3. Installation on Solaris
- 3.2.4. Installation on Linux
- 3.2.5. Installation From the Web Server
- 3.2.6. AppGate IP Tunneling Driver Installation
- 3.2.7. AppGate Hosts File Writer Installation
- 3.2.8. Repackaging the AppGate clients
- 3.2.9. Over the air provisioning of mobile clients
- 3.3. Client Usage
- 3.3.1. Launching clients
- 3.3.2. Open connection dialog
- 3.3.3. First time connection
- 3.3.4. The connection process
- 3.3.5. Roaming (Suspend/Resume)
- 3.3.6. Selecting a role
- 3.3.7. Starting services
- 3.3.8. Disconnecting
- 3.3.9. Advanced features
- 3.3.10. Local print
- 3.3.11. TCP forwarding proxy
- 3.3.12. Host certificate considerations
- 3.3.13. Entrust considerations
- 3.3.14. Using certificate authentication
- 3.3.15. Share access considerations
- 3.4. Client configuration
- 3.5. Using other clients
- 3.6. AppGate USB client
- 4. Administration
- 5. Customization
- 6. Traffic Capture
- 7. AppGate Logging
- 7.1. Background
- 7.2. Graphical interface to logs
- 7.2.1. Logs information panel
- 7.2.2. Log panels
- 7.2.3. Live panel
- 7.2.4. Events selection panel
- 7.2.5. Event list panel
- 7.2.6. Sessions selection panel
- 7.2.7. Session list panel
- 7.2.8. User selection panel
- 7.2.9. User report panel
- 7.2.10. Roles/services report selection panel
- 7.2.11. Roles/services list panel
- 7.2.12. Role and service report panel
- 7.2.13. Graph selection panel
- 7.2.14. Graphs panel
- 7.3. Exporting logs and reports as CSV-files
- 7.4. Command line tools
- 7.5. Automatic actions and remote logs
- 8. AppGate Licensing
- 9. Single Sign On features
- 10. Local Print
- 11. Reference
- 11.1. Programs and daemons
- 11.2. The Database
- 11.3. Attributes
- 11.4. IP Filter
- 11.5. SNMP Traps
- 11.6. IP filter reference
- 11.7. Logcat reference
- 11.8. Loggen reference
- 11.9. ag_cfggetset reference
- 11.10. Ag_dbadmin reference
- 11.11. Regular Expressions Reference
- 11.12. Device Firewall rule syntax
- 11.13. IP Tunneling - Additional configuration
- 11.14. Hardware Platforms
- 11.14.1. AppGate A1 and A2 - The Sun V100 based servers.
- 11.14.2. AppGate A4 - The Sun V210 based servers.
- 11.14.3. Connecting to the Serial Console on the A1,A2 & A4
- 11.14.4. AppGate Ax1 and Ax2 on Sun x2100 based servers.
- 11.14.5. AppGate Ax1 and Ax2 on Sun x2100m2 based servers.
- 11.14.6. AppGate Ax4 on Sun X4100 and x4100m2 based servers.
- 12. Copyright Notices
- 12.1. CrystalSVG icons from KDE
- 12.2. curl
- 12.3. GLIB
- 12.4. ipfilter
- 12.5. javahelp
- 12.6. jgraph
- 12.7. Java 2 SE Runtime Environment
- 12.8. Java Service Wrapper
- 12.9. libident
- 12.10. OpenLDAP
- 12.11. OpenSSH
- 12.12. OpenSSL
- 12.13. pidentd
- 12.14. prngd
- 12.15. Swing
- 12.16. tun
- 12.17. UCD-SNMP
- 12.18. zlib
- 12.19. ProperJavaRDP
- 12.20. Log4j
- 12.21. GNU Getopt for Java
- 12.22. GNU Lesser General Public License
- 12.23. GNU General Public License
- 12.24. Apache License, Version 2.0
- Index
List of Figures
- 2.1. An AppGate session
- 4.1. Tree structure in database
- 4.2. Network diagram for the Secure Mobile Office solution
- 4.3. Firewall example network
- 6.1. TCP connections involved in a Port forward
- 6.2. TCP connections involved in a web access
- 6.3. Proxy ARP example
- 6.4. Routed example
- 10.1. Local print data flow
- 11.1. The Back Panel of the V100
- 11.2. The Back Panel of the V210
- 11.3. The Back Panel of the x2100
- 11.4. The Back Panel of the x2100m2
- 11.5. The Back Panel of the x4100 and x4100m2
List of Tables
- 3.1. Feature support matrix
- 3.2. Authentication methods supported on each operating system
- 3.3. Client features vs deployment method
- 3.4. Rules for merging configuration options of an AppGate client
- 3.5. Client configuration options
- 3.6. Included applications
- 4.1. Predefined attributes
- 4.2. RDP Client Selection
- 4.3. Mobile client provisioning parameters
- 6.1. Hostname resolution with port forwarding
- 6.2. Hostname resolution with IP Tunneling
- 7.1. Log event CSV definition
- 7.2. Sessions list CSV definition
- 7.3. Roles/Services report CSV definition
- 7.4. Role/Service report CSV definition
- 11.1. The correct values for all settings in this window are as shown below.
This guide describes how an AppGate system works and how to configure and administer it.
This manual has been written for administrators of the AppGate system with basic knowledge of network security and TCP/IP networking.
Some concepts also requires basic knowledge of Microsoft Windows system administration while other advanced concepts may require basic knowledge of Unix system administration.
This is an overview of the functions of the AppGate Security Server. The intent of this overview is to outline the technical concept. After reading it, you should be acquainted with:
How an AppGate session works.
What major features are available and what they can be used for.
How an AppGate system interacts with the rest of the network infrastructure.
At the center of an AppGate system is the AppGate security server. The AppGate security server acts as an access control gateway in the middle of a network. The users connect thorough different means, are authenticated and allowed access according to the AppGate configuration. The AppGate Security Server acts as an end-point for the encrypted tunnels from the client and as an access control filter which controls what resources each user may access under what circumstances.
The users experience of the Appgate system normally begins with one of the AppGate clients.
The AppGate clients
There are a couple of variants of the AppGate client. They share 90% of the code and can perform almost the same tasks. The reason they differ is that they are tuned for different scenarios.
AppGate Client - A full GUI, installed.
AppGate Connect - A minimal GUI, installed. The need for this special client has more or less disappeared since the regular client can be configured to also present a minimal GUI. The connect client is therefore deprecated and will disappear in the future.
AppGate Java Web Start clients - Java Web Start versions of the above AppGate clients. These clients are initially started from the browser and will be cached on the local system so they do not need to be downloaded each time. They can be available as icons on the desktop. Java Web Start clients have the advantage that they will automatically be updated from the AppGate Security Server when the server is upgraded.
AppGate Applet - An Applet variant of AppGate Connect. It requires very little from the host system but as a consequence it also has a very limited graphical user interface. This client will also be replaced by an applet version of the regular client in the future.
Clients for mobile devices - can be installed on most popular mobile phones. The clients can be downloaded and installed manually from the AppGate server or over the air provisioning can be used by the AppGate administrator to initiate the installation via SMS.
In addition, normal web browsers and their built-in SSL support can be used to access web based services from end systems without having to download or install any software on the client at all. This enables true client less access although the user is limited to web based applications offered by the system owner.
The AppGate Administration Console is actually also an AppGate client, but with a very specific GUI and a special purpose.
The main tasks of the AppGate clients are:
Handle the user interaction dialogs for connection, authentication, application usage and final disconnection.
Set up and handle the encrypted tunnel to the AppGate Security Server.
Handle traffic and interact with the client computer to make it possible for the applications to reach the application servers.
This section will present the different steps involved in an AppGate session. It will briefly go through many aspects of how the system works.
Before a session can be initiated, the user must first launch an AppGate client. The user may then be presented with a connection dialog and asked to give the name of the AppGate Security Server he/she wishes to connect to. For the Java Web start version of the client all the configuration data is filled in automatically.
It is also possible to connect to the AppGate server using a standard SSH2 client, but the functionality available will be limited to port forwards and server commands.
The AppGate client establishes an encrypted communication channel to the AppGate server. All traffic between the client and the AppGate server is sent through this encrypted channel. The traffic may also be compressed if desired. This channel consists of a single TCP connection which normally runs on port 22 (SSH), other ports can also be used if needed.
The session establishment is done using the standard SSH2 protocol. It involves a Diffie-Hellman key exchange to negotiate session encryption keys. If the client has previously connected to the server or if it has been pre-configured with its public SSH keys it will verify that the keys match to protect against man-in-the-middle attacks. If the keys are not known to the client then the user will have to confirm that it is the first connection to the server.
The AppGate Security Sever consults its user account sources to find out whether the user has an account. The two most common account databases are LDAP (Active Directory) and the local AppGate server database. It is possible to use multiple account sources.
If an account is found, the system will proceed to authentication. As part of the connection dialog, the user chooses authentication method. The AppGate server checks with the account information whether that authentication method is available.
Several methods may be available at the same time for the same user. The user may already have given the credentials or will now be prompted to do so. The AppGate Security Server will use the credentials and consult the appropriate subsystem to authenticate the user.
When logging on, the AppGate client sets a number of attributes, for instance the IP address of the client, and which AppGate client is used. These attributes can later be used in access rules or client commands. See Section 11.3, “Attributes” for details.
If the user is authenticated, the AppGate server will now instruct the AppGate client to perform all defined Client Checks and ask whether an AppGate Device Firewall is available.
The results of all Client Checks and DFW presence checks are fed back to the AppGate server. Client Check result strings are set as attribute values. Access rules can later on use those attribute values to control which services the user should have access to during this session.
The AppGate server will now perform the authorization decision. Authorization is done by evaluating all applicable Access rules which are defined for the user.
All Access rules will evaluate to either true or false. Access rules can be attached to Roles and to references to Services and will govern whether those Roles and Services shall be allowed for this session.
If the user has access to only one role or if all the roles are combinable then, by default, the role selection will happen automatically without user intervention.
If not all of the roles the user has access to are combinable or if combinable merging has been turned off then the user must manually select which role/roles the session should use. The role selection can not be changed during a session. If no roles are available, for example due to access rule restrictions, then the session is terminated.
Along with the Role there may be an AppGate Device Firewall rule set defined. If so, that rule set is transferred to the client and activated.
As soon as the roles have been selected, the AppGate server will inform the AppGate client of all the Services which are part of the roles.
The different Services are presented to the user. Depending on which AppGate client the user is running and how it is configured, the Services will be presented in different ways. Perhaps the most common, and very user friendly, is the portal-like icon view of the AppGate Client.
When using a web browser for client-less access using SSL, web services will be immediately available and the discussion below will not be applicable.
In the icon view, the user can start a Service by double-clicking on its icon.
When a Service is started, all its Components are activated. The most common Component type is the IP access rule. An IP access rule enables access to the specified IP addresses / host names and port numbers.
When the client activates an IP access rule, it asks the AppGate server to prepare to handle traffic. The client will also make the necessary preparation on the client computer to make sure that the relevant application protocols and data traffic will flow through the AppGate system - this is called traffic capture.
There are two methods that can be used for traffic capture: Port Forward and IP tunneling.
Port Forward utilizes TCP sockets on the client computer. The AppGate client opens listening sockets on the loop-back interface and forwards all connections through the encrypted tunnel. This method is very portable and non-intrusive to the operating system.
IP tunneling routes IP packets through an encrypted tunnel with a Virtual Network adapter on the client computer. IP tunneling requires that the AppGate IP tunneling driver is installed on the client computer. IP tunneling is very versatile and handles TCP, UDP and ICMP in both directions, to whole networks, ranges of hosts and ports.
There are a number of other components that all can be combined into a Service, Client commands, Server commands, proxies etc.
When the user closes the connection to the AppGate server the session is terminated, all traffic flows are stopped and the user is logged out.
If the Roaming feature is used, the session may be temporarily Suspended but still active. Later on it may be Resumed. This is very useful for mobile applications. See Section 3.3.5, “Roaming (Suspend/Resume)” for details.
The previous section presented the fundamental technology and outlined the operation by going through the steps in a normal user session.
This section will simply present the major features to give a more complete picture of what an AppGate system can do.
- Roaming
The client can temporarily suspend the communication with the server. This is useful for unreliable connections like GPRS or if the client computer changes IP address (e.g. a laptop moving to another location).
- Compression
To reduce the amount of traffic sent or received, data compression may be enabled in the client. On very slow connections this may also improve the response times.
- Proxy traversal
The client can be configured to use a local proxy to reach out from a local network and onward to an AppGate server.
- SSH host keys based X509 certificates
If SSH hosts keys are not known beforehand, a scheme with X509 certificates can be used.
- Encryption methods
AES128, AES256, Blowfish, 3DES and RC4.
- X11 forwarding
A client computer running an X Window server can display remote X applications via the encrypted tunnel.
- Keepalives
The client can send keep-alive packets to maintain a connection through proxies.
- User databases
The AppGate system differentiates between user account establishment and user authentication. As an example, a user account may be found to exist if an appropriate LDAP record is found; this user may then be authenticated toward a SecurID server or with a certificate.
User accounts may be searched for in a number of sources:
The AppGate internal user database.
From any LDAP-compatible directory such as Active Directory. Multiple LDAP sources may be used, and attributes in the user record may specify AppGate roles and allowed authentication methods.
Radius, SecurID and Certificate. These are primitive and somewhat limited sources for account establishment, but can be useful in some cases.
- Authentication Methods
The AppGate system supports a wide range of authentication methods:
Password: Plain passwords are used for authentication. Passwords are stored and managed in the AppGate user database.
LDAP: The AppGate system can use a connection to an LDAP based directory as a password type of authentication.
Radius: The common client-server security protocol best known for providing remote authentication and access.
RSA SecurID: Short-time passwords generated by a small hand-held token. The AppGate system talks to an RSA Ace server using the RSA native protocols.
Certificate: Uses any X.509 certificate, including certificates issued by Verisign and SmartTrust, for authentication. On the client side, the user certificates can be retrieved from MS-CAPI, PKCS#11, MS Explorer Certificate Store, Mozilla/Firefox Certificate Store or directly from files in PEM, DER or PKCS#12 encoded formats. One can upload CA certificates to the AppGate as well as configure revocation policies.
A large number of popular smart cards, USB based and other certificate sources can be used via MS-CAPI or PKCS#11.
Kerberos: a non-interactive method where the client uses a Kerberos ticket to authenticate to the AppGate server. The client obtains the ticket from the local Key Distribution Center which is a Kerberos server. Microsoft Active Directory also works as a Kerberos server and can be used for AppGate authentication.
Note that the client must be able to talk to, and be authenticated by, the KDC before it can be authenticated by the AppGate server. This means that the KDC must be reachable without going through the AppGate server.
Entrust: Uses the Entrust Technologies PKI environment. Entrust certificates are used only for authentication.
Public key: Authentication through asymmetric key cryptography using DSA or RSA keys. This is useful for automated SSH connections.
CryptoCard: A token based challenge/response system that the AppGate system supports natively. The AppGate server communicates with the CryptoCard server via the Radius protocol.
The Entrust, LDAP, Radius, Kerberos, CryptoCard and SecurID methods all require third party products in addition to the AppGate system.
- Client Check
When an AppGate client connects to an AppGate Security Server, a Client Check may be performed. The Client Check can check for any type of state at the client side. E.g. check for a certain anti virus software, a certain hardware configuration, check that a specific process is running, a file exists or just about anything else.
The result of a Client Check is fed back to the AppGate Security Server and can be used as a factor in any Access rule.
- Device Firewall integration
An AppGate client can be instructed by the AppGate Security Server to activate a rule set in the AppGate Device Firewall. This rule set will last for the whole session. An Access rule can be used to verify that such a rule set is actually effective.
- Cluster
Two or more AppGate servers can be configured into a cluster. The main purpose of a cluster is to increase performance. A cluster may also reduce the risk that hardware failures causes the system to become unavailable.
- IP tunneling
Gives true IP connectivity from the client to the application server. It is able to give full network access and is able to handle protocols which are difficult or impossible using the Port Forward method.
- Write to hosts file
The client can write entries to the hosts file in order to map host names to the special 127.0.0.x IP addresses that the Port Forward mechanism relies on.
This feature may also be used for IP tunneling if no internal DNS servers are available for the client.
- 127.0.0.x
The client can use multiple local IP addresses like 127.0.0.2 and 127.0.0.3 in order to handle Port Forwards for the same port number going to multiple servers.
- Localization
The client GUI can be Localized for other languages.
- VT100 Terminal emulator
The client contains a complete VT100 terminal emulator which can be used to connect to servers.
- Detailed view of IP access components for the user.
The technically oriented users can have a detailed view of IP addresses and port numbers to actually see what traffic is allowed.
- Local Print
Can pick up print jobs from the inside and print on locally attached printers.
- SSO features
The server can attach an HTTP header to HTTP traffic. The header will contain the authenticated user name.
The server can also route the HTTP traffic through a special "Web agent". The Web agent is a customized script located on the AppGate server which knows how to login a user to other web applications.
An AppGate server also answers questions for the standardized "ident" protocol.
- NTP
The AppGate server can synchronize its time from an NTP server.
- External syslog
The AppGate log can be sent to an external syslog server.
- Dual partitions
The AppGate Appliance has two partitions, which can contain complete and different AppGate versions and operating systems. This is useful when upgrading and as a backup.
- Backup and restore
The AppGate console can be used to make a configuration backup of the server.
- SNMP
The AppGate server can send SNMP traps when certain criteria are met.
- User session monitoring
Using the console, it is possible to monitor each user session. It is also possible to terminate a specific user session.
- Open file formats
The configuration files on the AppGate are stored in a plain-text format, which is open and documented - this makes it possible for customers to develop scripts and do other customizations. It is also possible to transfer files to and from the server using the AppGate console.
Other features of the AppGate system include: Idle timeout, Extensive password policies, Message Of The Day, Built-in web server for client deployment, and FTP, HTTP, telnet and NetBIOS proxies.
The AppGate server uses OpenSSH to encrypt network traffic and OpenSSH in turn uses the OpenSSL libraries for most of its cryptographic operations. It is possible to configure OpenSSH to use OpenSSL in FIPS mode. This means that all code in OpenSSH which is used to encrypt network traffic on the AppGate server will use an embedded FIPS 140-2 level 1 validated cryptographic module (OpenSSL 1.1.2, Certificate #918) running on the AppGate server per FIPS 140-2 Implementation Guidance section G.5 Guidelines.
The AppGate SSL module is currently not able to run in FIPS mode so enabling FIPS mode will disable the SSL mode. The kerberos module is also not FIPS-enabled and will be disabled when FIPS mode is enabled.
FIPS mode can be enabled from the AppGate console. See Section 4.9.3, “Connection Settings” for details.
When setting up an AppGate system, the most common problem is to get any surrounding firewalls to allow the necessary traffic.
All application traffic from the client to the AppGate server will go through the SSH tunnel. On the AppGate server it will be decrypted and travel onwards as clear text.
Allow traffic to the AppGate server
The AppGate Security Server is by default using port 22 for incoming connections for SSH2. This port number can be changed and other ports can be added using the AppGate Console.
The AppGate Security Server also acts as a web server to allow for downloading of the various clients, the AppGate Applet and the Java Web Start files. The web server listens on port 80 by default. This can be changed from the configuration files. The web server can also be configured for HTTPS/SSL and will then normally listen on port 443.
If the AppGate server is connected on a DMZ, the firewall rules must allow for the clients to reach the SSH port (22) and for the web server port 80 and/or port 443 (SSL).
Allow traffic from the AppGate server
From the AppGate server to the application servers the traffic will be using the normal application port numbers and protocols. Therefore, any firewall in between must allow for the application data to flow accordingly.
When the Port Forward method is used, the source IP address of the traffic to the application server will be the IP address of the AppGate server.
If IP tunneling is used, the source IP address of traffic going to the application servers will be an address from the configured IP tunneling address pool.
The AppGate Security Server can use one or more Ethernet interfaces. The AppGate server can have one or more IP addresses on each interface. It will normally not forward traffic between interfaces. In terms of routing, the following should be considered.
Default route
If one of the interfaces is connected to the Internet, or possibly any large routed internal network with many IP networks, it is probably a good idea to use the default route for that interface. It is only possible to define one default route for the whole AppGate server.
Additional routes may be added as static routes for any interface.
It is possible to use the AppGate server as a simple firewall and let it forward normal non-encrypted traffic between interfaces. This can be useful to allow for traffic from a protected application server to reach the outside. In this case, static routing entries are probably needed on the application server and on the hosts it is communicating with. Those static routes should point to the AppGate server as the gateway.
IP tunneling address pool
There are two approaches when defining an IP tunneling address pool.
Use a new IP subnet that is not part of any of the other connected IP networks.
This will require routers in the network to know about this new subnet and route traffic for it to the AppGate server.
Use a part of an IP subnet that is directly connected to one of the interfaces.
The AppGate server will issue Proxy ARP packets on this interface for all the IP addresses defined in the IP tunneling address pool.
- 3.1.1. AppGate Client
- 3.1.2. AppGate Connect and Applet
- 3.1.3. AppGate Mobile client
- 3.1.4. Clients for Citrix and Terminal Servers
- 3.1.5. Operating System support of AppGate clients
- 3.1.6. AppGate IP Tunneling Driver
- 3.1.7. AppGate Hosts File Writer
- 3.1.8. AppGate Device Firewall
- 3.1.9. Deployment of AppGate clients
The AppGate system includes a number of different client modules. When deploying an AppGate system, one of the decisions which must be made is which modules to use and how to deploy them. There are mainly three aspects to consider:
Type of user interface. What type of user interface is desired? There are three AppGate clients available: "AppGate Client", "AppGate Connect" and "AppGate Mobile Client". The main difference between the first two clients is the graphical user interface. AppGate Client has a fuller interface where the user may browse the services easily, while AppGate Connect is more geared towards the simple case where all needed services are auto-started. The mobile client is for mobile units like smartphones and PDAs.
Types of applications to use. What type of functionality, in terms of applications and protocols, should be available to the users? This determines if any additional modules, like IP tunneling and Device Firewall, needs to be installed.
How to deploy the clients. There are different ways to deploy the clients. They can be installed locally, be managed with Java Web Start or run as an applet (AppGate Connect only). Note that the IP tunneling (IPTD) and Device Firewall modules only support direct installation on the user's machine.
Table 3.1. Feature support matrix
| Client | Client + IPTD | Connect (applet) | Connect (applet) + IPTD | Mobile | Console | |
|---|---|---|---|---|---|---|
| Admin access | n/a | n/a | n/a | n/a | n/a | Yes |
| Client command | Yes | Yes | Yes | Yes | Yes[4] | No |
| FTP proxy | Yes[1] | Yes[2] | Yes[1] | Yes[2] | No | No |
| ICMP access | No | Yes | No | Yes | No | No |
| IP access | Yes[1] | Yes | Yes[1] | Yes | Yes | No |
| Log access | n/a | n/a | n/a | n/a | n/a | Yes |
| Message component | Yes | Yes | Yes | Yes | No | No |
| Reverse IP access | No | Yes | No | Yes | No | No |
| Server command | Yes | Yes | Yes | Yes | No | Yes |
| Share access | Yes[3] | Yes[2,3] | Yes[3] | Yes[2,3] | No | No |
| Web access | Yes[1] | Yes[2] | Yes[1] | Yes[2] | Yes | No |
[1] To be able to use host names, the client must be able to write to the hosts file.
[2] Does not use IP tunneling.
[3] Requires that the client can update lmhosts.
[4] A limited subset of built in client commands
AppGate Client is the name of the most complete and most widely used of the different clients. AppGate Client is written mostly in Java, with some native code components. These native code components handle interfacing with the local operating system, PKI authentication, fast encryption and compression. AppGate Client is the standard and recommended client.
- User interface
Full graphical user interface. Icon-based portal style view of the available services, as well as a more technical view of ports, IP-numbers and such. It has many user-configurable options.
- Functionality
It can be used to connect to multiple AppGate servers simultaneously.
- Deployment
It can be deployed as an installed client or using Java Web Start. As an installed client it is possible to repackage it with different default configurations, host keys etc. The Java Web Start version will automatically download all needed settings from the AppGate server.
Note that the AppGate Connect client and applet are deprecated and will dissappear in a future version of AppGate. There will be a new applet based on the full AppGate client.
AppGate Connect is the name of the simpler client. It is, just like AppGate Client, written mostly in Java and with some native code components. These native code components handle interfacing with the local operating system, PKI authentication, fast encryption and compression.
The main differences between AppGate Client and AppGate Connect is the GUI and the fact that AppGate Connect is also available as a java applet. The AppGate Applet client is just AppGate Connect started as an applet.
- User interface
AppGate Connect is a simpler and more compact version of AppGate Client. It is best suited for users who need only run one or two applications, normally auto-started. AppGate Connect does not provide an interface for the user to modify the local IP access port numbers. Once Connect has established a connection to the AppGate server, it automatically shrinks itself to a smaller window, thus becoming less apparent to the user.
- Functionality
AppGate Connect Is capable of almost all functionality, except of simultaneous connections to more than one AppGate Server.
- Deployment
It is possible to run the Connect client as an applet; install it or deploy it using Java Web Start. As an applet or Java Web Start client it requires no installation on the user's system. The applet is cached locally on the client machine and is automatically updated when the applet program on the server is updated.
The AppGate Mobile Client is a client specifically geared towards mobile devices. Currently it supports Windows Mobile, Sony Ericsson UIQ3 based phones and Nokia S60 3rd edition devices.
The Citrix and Terminal server clients are special versions of AppGate Client and AppGate Connect. These are meant to be used when the user's computer is a Citrix or Terminal Server client. That is; the user runs the AppGate client on a Citrix or Terminal server system to access a remote AppGate server. These clients have nothing to do with accessing Citrix or terminal servers behind an AppGate server.
These clients use a special program, called
agmud, to handle IP access components. This
program runs as administrator and is able to
differentiate between users, so that each user utilizes the
right AppGate connection. That is; this program manages the
separation between the users on the Citrix or Terminal server. For
instance, say that users A and B, running on the same Citrix or
Terminal server, have both launched AppGate clients. The agmud
program makes sure that only user A may access the services
provided by user A's AppGate client, that is; user B or C may not
access the opened ports. agmud will also manage port conflicts so
that both A and B can start the same IP access but the traffic
from user A ends up in the tunnel opened by A and vice
versa.
These clients must be installed by an administrator on the Citrix or Terminal server. To the users the clients will look and behave like the ordinary AppGate clients.
Note that IP tunneling and Device Firewall integration is not available on Citrix and Terminal server.
The AppGate clients (Client and Connect) have been tested on Windows 2000/XP/2003/Vista, Linux, Mac OS X and Solaris. The clients should work on any OS which has a proper Java implementation. The mobile client should work on any Windows Mobile device as well as Nokia S60 3rd edition and Sony Ericsson UIQ3 devices.
The AppGate IP Tunneling Driver (IPTD) is complementary software and will work with both Client and Connect, regardless of how they are deployed. When any of the AppGate clients starts, it will detect whether the IP Tunneling Driver is installed, and use it.
The AppGate IP Tunneling Driver consists of a service and a virtual network adapter which will tunnel IP traffic to and from the AppGate server over the SSH connection. The AppGate IP Tunneling Driver is optional, but must be installed if any of the following functionality is needed:
UDP traffic
Applications where clients needs to connect directly to each other.
Applications that use dynamic port assignment such as DCOM RPCs (E.g Outlook to Exchange communication).
Applications where servers behind the AppGate server need to initiate connections to the client computer.
When the AppGate IP Tunneling Driver is installed, it will also handle hosts file writing and forward DNS queries to DNS servers behind the AppGate server. Installing the tunneling driver requires administrative privileges. However, when the driver is installed, any user starting an AppGate client will take advantage of the driver.
The AppGate IP Tunneling Driver is currently supported on Windows 2000, Windows XP, 32-bit Windows Vista, Mac OS X, Linux and Solaris.
The AppGate Hosts File Writer (aghostsd) is complementary software for Windows 2000, XP, Vista, Linux and Mac OS X. It works with both Client and Connect, regardless of how they are deployed. When any of the AppGate clients starts, it will detect whether the Hosts File Writer is installed, and use it.
The Java Web Start versions of the Linux and Mac OS X clients includes the hosts file writer and will ask the user for the superuser password in order to be able to install it if needed.
The hosts file writer adds and removes entries in the windows hosts file and the lmhosts file on behalf of the AppGate client. The hosts file writer runs as a windows service with administrator rights and may thus be used when it isn't possible or desirable to let ordinary users write to the hosts file or the lmhosts file.
On the Windows platform it is possible to integrate the AppGate clients with the AppGate Device Firewall (DFW). The DFW has the unique feature of a near zero user interface, which makes it ideal when rule sets are to be enforced on sensitive VPN connections.
The DFW is a separate product, but if installed, the AppGate clients will detect it and may dynamically load rules into it. The rules will be fetched from the AppGate Security Server and be in effect during an AppGate session.
The AppGate clients will report the status of the DFW back to the AppGate Security Server, so that access rules can take this into account.
There are three different ways of deploying the AppGate Java based clients. They can be deployed using Java Web Start, installed on the user's PC or launched as applets. This section explains those methods and the issues surrounding them. Deployment of mobile clients is discussed in Section 3.2.9, “Over the air provisioning of mobile clients”.
- Java Web Start
Java Web Start (JWS) is a way to deploy applications over the web. It has been included in Sun Java since version 1.3. To launch a JWS application, the user clicks on a link on a webpage. The link leads to a
.jnlp-file which defines the application. JWS will parse this file and download all needed files before launching the application. The application files are cached on the user's PC to speed up future starts. JWS may also optionally, controlled by the user, place an icon on the desktop so that the application is easy to launch in the future. The JWS system will check that the application files are up to date each time the application is started, and it will update them if new versions are available. All files downloaded through JWS are signed by AppGate Network Security AB and users may get a security question the first time the application is launched.- Installed clients
Installation packages are available for Windows, Mac OS X and Solaris. Linux clients are available as compressed tar-files. The linux files can also be used to install on other operating systems. The windows install packages includes a complete Java environment while the others assume that java is already available on the users PC. All the installation packages can be downloaded from the web server which is built into the AppGate server. The installation packages are also included on the CD distributed with the AppGate server.
- Applet
AppGate Connect is also available as an applet. An applet is a java program which is run inside the browser. The main difference between using an applet and JWS is that the applet works with older java versions and that only the AppGate Connect client is available as an applet. Also the applet is run inside the browser which means that it will be killed whenever the browser window holding it is closed or when the user goes somewhere else. The AppGate applet is divided into two parts, one loader which is downloaded each time the applet is launched and one part which is cached on the client PC.
Both Java Web Start and applet will make sure that the local client is always up to date. That is any updates done on the AppGate server are automatically downloaded. The installed client has no auto-update feature.
Both Java Web Start and the installed client are able to place an icon on the desktop automatically. The JWS client can also be started by clicking on a link on a webpage.
The clients have the ability to update the hosts file with names of servers reachable through the AppGate server. The hosts file may be updated in either of the following two ways:
If the Hosts File Writer or IP tunnel driver has been installed on the client computer, the client requests that it updates the hosts file.
The client itself writes directly to the hosts file. For this to work the client must have write permission to the hosts file. This is no problem if the user runs with administrator privileges, but often the user does not. Therefore the installation packages have the option of changing the permissions to the hosts file so that anybody may update it. This is an optional step during the installation and requires administrator privileges. The AppGate clients will check whether hosts file writing is possible when they are launched. A warning dialog will pop up if hosts file writing is disabled and the Hosts File Writer isn't running. This warning dialog has a button which lets the user fix the permissions if the user has access to the administrator password.
On Unix systems the client may not listen to ports under 1024 (unless running as root). The Mac and Linux installation packages includes a small port mover program which is installed setuid root which allows the client to listen on low ports. This port mover also handles writing to the hosts file. The Java Web Start clients also includes the port mover and will ask the user if they wish to install it if needed. The user will have to enter the superuser password in order to be able to install it.
- 3.2.1. Installation on Windows
- 3.2.2. Installation on Mac OS X
- 3.2.3. Installation on Solaris
- 3.2.4. Installation on Linux
- 3.2.5. Installation From the Web Server
- 3.2.6. AppGate IP Tunneling Driver Installation
- 3.2.7. AppGate Hosts File Writer Installation
- 3.2.8. Repackaging the AppGate clients
- 3.2.9. Over the air provisioning of mobile clients
The AppGate clients are GUI applications written mostly in Java, with some native code components which handle interfacing with the local operating system, PKI authentication, fast encryption, and compression. The AppGate Client is the most advanced and configurable client program available for use with the AppGate server. The AppGate Client has many options which are configurable by the user. AppGate Connect is a less configurable client and easier to use. The AppGate Applet can be used for system-wide client uniformity and does not require installation, which makes administration easier. This section describes the issues related to the installation of AppGate Client and AppGate Connect.
The following Windows operating systems are supported:
Windows 2000, XP, 2003 or Vista
The AppGate clients can be installed using normal user privileges (administrator rights are not necessary), except on Windows 2000 SP1 (or later) and Windows XP, where administrator privileges are required if the 'Write to hosts file' feature is needed.
To start the installation, run
agclient.exe or similar, depending on which
type of client is to be installed.
These files can be found either on the AppGate USB delivered
with your server, or on the built-in web server on the AppGate
server.
The installer uses a graphical dialog which should be familiar
to most users. If anything goes wrong during the installation, the
installation log can give useful information about the problem.
The log is viewed with the button 'Show details' during installation,
and is saved as install.log in the installation
directory.
An alternative method is to use Java Web Start. Java Web Start requires that Java version 1.3.x or higher is already installed on the client computer. In order for the 'Write to hosts file' feature to work, the user must be administrator. The AppGate Client Web Start link is found on the built-in web server.
Usually when AppGate clients are installed, a number of dialogs are presented to the user, enabling the user to choose such things as where to install the AppGate clients. To further simplify things for the end user, the installation can be run silently by adding the option /S to the installation program:
agclient.exe /S
The Windows AppGate client installation includes a complete Java Runtime Environment that is solely intended to be used with and by the AppGate clients. For this purpose, the JRE has been modified so that it does not read or modify the registry.
This modification ensures that no conflict with other versions of JRE installed on the system, past or future, will occur. Other unmodified versions of JRE can use the registry entries relevant to JRE for their own purposes without affecting the AppGate clients.
It is not recommended to use the JRE included with the AppGate client for other purposes than running the AppGate clients.
The AppGate clients for Mac OS X are distributed as disk images. To install one, open the disk image and install the meta package in the top level directory. This will install the client and the AppGate Local Forwarder. The default installation path for the client is the system-wide Applications directory, but it is possible to select another path during installation.
Administrator privileges are required to install the meta packages, since they include the AppGate Local Forwarder. If the AppGate Local Forwarder should not be installed, it is possible to install the client package from the 'packages' directory. This does not require administrator privileges, but automatic hosts file writing and forwarding of privileged ports will not be available.
AppGate Local Forwarder installs the program
/usr/local/libexec/appgatefwd ,
which runs with root privileges ("setuid root"). This is used by
the AppGate clients to forward privileged ports and update the local
hosts file. When this program is installed, any user who can log
on to the system can add entries to
/etc/hosts which redirect traffic to the
local host, and it is possible to listen to privileged TCP
ports.
Warning
Security considerations: By using these features, any user who has access to an account on the machine can, for instance, redirect all connections to a specified web server to a malicious program. The malicious program may try to convince the local user to enter his password. Depending on how the Mac OS X client is used, the administrator should decide whether AppGate Local Forwarder should be installed or not.
If AppGate Local Forwarder has been installed, its features can be disabled by executing the following command as root from a terminal window:
chmod u-s
/usr/local/libexec/appgatefwd
and it can later be enabled again with the following command:
chmod u+s
/usr/local/libexec/appgatefwd
AppGate Local Forwarder writes to the file
/etc/hosts in order to transparently
redirect connections through encrypted SSH tunnels. This file is
normally not read by the system after reboot, but the
installation of AppGate Local Forwarder modifies the lookup
order to take advantage of this file. This is achieved by
creating the file /etc/lookupd/hosts to use
the /etc/hosts file before consulting DNS and
NetInfo. If the Mac OS X client is configured not to use the
files in /etc/lookupd , this will not be
effective and the administrator must make the appropriate
modifications by hand.
NOTE: The modification of the lookup order tries to be
conservative so as not to break the existing configuration. If
the file /etc/lookupd/hosts already exists,
it will not be overwritten, and if NetInfo is used, the files in
/etc/lookupd should be ignored. Some versions
of Mac OS X do not honor this, and the existence of the
/etc/lookupd directory disables other NetInfo
lookups. This may cause systems with local modifications to
change their behavior. In this case, the administrator should
back out the changes made by the installation of AppGate Local
Forwarder.
All AppGate clients require that Java is installed on the client machine to be able to run.
The client software for the Solaris platform is found on
the USB in the AppGate/client/SunOS directory.
The directory contains several packages with manual pages and executables.
For instance, to install the AppGate Client package, run
cd /usb_mountpoint/appgate/AppGate/client/SunOS/`uname -p`
cp APPGclnt.pkg.gz /tmp
cd /tmp
gunzip APPGclnt.pkg.gz
pkgadd -d APPGclnt.pkg APPGclnt
Installing the client places the files of this package in
/opt/APPGclnt. A bin
directory and a man
directory will be created to hold the executables and the manual
pages. Start the AppGate Client by executing
/opt/APPGclnt/bin/agclient.
No further configuration of this package should be necessary.
To pre-configure a Solaris installation, create a file
named agclient.properties with the desired properties in the
/opt/APPGclnt/bin directory. See Section 3.4, “Client configuration”
for configuration options.
All AppGate clients require that Java is installed on the client machine to be able to run.
The client software for the Linux platform is found on the
USB in the AppGate/client/Linux directory. The
AppGate Client can be extracted/installed by executing the
following command:
bzip2 -cd /path_to/agclient.i386.tar.bz2 | tar xf -
A subdirectory structure called opt/APPGclnt
will then be created in the current directory. Start the AppGate Client by
executing the file opt/APPGclnt/bin/agclient
The AppGate client may be distributed to users through the AppGate web server. If this method is used, each user needs to connect to the AppGate server with a web browser. Once connected, the user will be presented with a screen similar to the following.
The user may then click on the platform they are installing on. A File Download dialog box will then appear asking whether the user would like to run agclient.exe from its current location or save the file to disk. The user must select one of the two options and click OK for the download and installation to begin.
If the user chooses to run agclient.exe from its current location, the executable will automatically self-extract the package and begin the installation. If the user saves the file to disk, he must double-click on agclient.exe after it has finished downloading in order for the extraction and installation to begin.
From that point onward, the installation will behave identically to a generic USB installation (or a distributed installation package with no pre-configuration).
The AppGate IP Tunneling Driver can only be installed on computers running Windows XP or later, Linux, Mac OS X or Solaris. Administrator privileges are required for the installation.
If the AppGate IP tunneling driver should be upgraded, the previous version has to be uninstalled first.
The AppGate Hosts File Writer can only be installed on
computers running Windows 2000, Windows XP or Windows 2003.
Administrator privileges are required for the installation. The
installation file is named aghostsd.exe.
It is possible to wrap the AppGate clients for Windows into a new installation package. This is usually done to achieve one of the following goals:
Make a single installation package containing any or all of the clients, Device Firewall and IP Tunneling Driver.
Distribute host keys to avoid the first time connection vulnerability.
Install a modified agclient.properties file along with the client.
Please refer to the AppGate Support Web for detailed instructions regarding the necessary components.
Over the air provisioning is a way to install and configure the AppGate client on a mobile phone over the air. The administrator can make the AppGate server send SMSes to the mobile phone. The first SMS contains a link to the client installation package and once installed the client will use the second SMS to configure itself. It is also possible to automatically setup email accounts on the phone.
The net effect is making it easy for the mobile phone user to get started. They just need to press Ok a couple of times and enter their password before they are set up and can read their email. The whole goal of this is to make it as easy as possible for users to get started using Appgate to access their email from a mobile phone.
The first step is that the administrator triggers provisioning for the user. This is done on the local user management screen. Once the user's mobile phone number has been entered the administrator just needs to press the provision button.
Pressing the provision button causes the AppGate server to send two SMSes to the phone. The first SMS will contain a short text and a hypertext link back to the AppGate server. Pressing the link will cause the mobile phone to download the appropriate client installation package (the server uses the web request to figure out which phone model the user has). Once downloaded the client installation will start automatically (on all platforms but SonyEricsson).
The default behavior of the Appgate server is to send the SMSes through a gateway at appgate.com. Any firewall between the AppGate server and the Internet must allow the AppGate to establish a TCP connection to port 443 on provisioning.appgate.com. This gateway will allow all customers with a valid support contract to send a certain number of SMSes per month (currently 50). Customers wishing to send more need to have a separate contract for SMS sending.
When the client starts for the first time it will look for the second SMS which contains the information needed to know where to get the actual configuration. The client will then use this information to download the actual configuration from the AppGate server. The downloaded configuration includes things like name of Appgate server, authentication method and user name. The only thing the users need to enter is their passwords or other authentication data.
Once connected the client downloads the list of services as usual. But there are a couple of new client commands which may help with the user experience in this situation. There is one which creates an ordinary email account. It is also possible to create an Exchange account on Windows Mobile phones.
There is also support for downloading the exchange client for Sony Ericsson and Nokia phones.
This section covers various actions which the AppGate administrator may have to perform to set up over the air provisioning.
The basic configuration is done in the AppGate console under "Clients/Mobile Client Configuration". Here it is possible to configure which addresses the clients should use when contacting the server, the text of the SMS and other things related to provisioning.
Life for the end user becomes really easy if the administrator sets up client commands to configure and launch the email client. This done with the following client command:
mailaccount [-domain MAILDOMAIN] [-launch]
This client command should normally be set on the
*.*.mobile platform. The -domain and
-launch sections are optional. -domain will help with the
configuration and -launch will start the email client. This
client command will check to see if the email account already
exists, if not it is created. Finally, if -launch is provided
the email client is launched.
The situation is more complex if the email server is running Exchange. Both Nokia and Sony Ericsson make Exchange clients for their phones available on their web sites. AppGate may not, for legal reasons, redistribute those clients but we can redirect users to them. The redirection can be configured in the AppGate console. The administrator may either enter the relevant URLs manually or configure the AppGate server to automatically download the URLs from appgate.com once a day.
The client command which downloads the Exchange client is:
browse http://appgate_server_addr/agmobile?asclient
But this command should only be run if the client is not already installed. Fortunately a client check can check if the client is already installed. Create the following two client checks:
| Attribute | activesync_client_installed |
| Platform | symbian.s60e3.mobile |
| Command | check.exe |
| Arguments | -application easapp.exe |
| Attribute | activesync_client_installed |
| Platform | symbian.uiq3.mobile |
| Command | check.exe |
| Arguments | -application roadsync.exe |
Once that is done the following access rule will check if the Exchange client is installed:
| Name | symbian_without_activesync |
| Expression | attribute{activesync_client_installed="no"} and attribute{platform="^symbian\.[^.]*\..*"} |
use this access rule to give access to the Exchange client download command.
To configure an Exchange account for the user use the following command on a windows mobile phone:
syncaccount [-domain MAILDOMAIN] [-launch]
Set the platform to windowsce.*.*.
Both cases above causes the email client to connect to the localhost. There must also be an IP-access component available which forwards this port to the appropriate mail server. In the exchange case local port 80 must be forwarded to port 80 on the exchange server. For IMAP/SMTP ports 25 and 443 must be forwarded to the mail server.
- 3.3.1. Launching clients
- 3.3.2. Open connection dialog
- 3.3.3. First time connection
- 3.3.4. The connection process
- 3.3.5. Roaming (Suspend/Resume)
- 3.3.6. Selecting a role
- 3.3.7. Starting services
- 3.3.8. Disconnecting
- 3.3.9. Advanced features
- 3.3.10. Local print
- 3.3.11. TCP forwarding proxy
- 3.3.12. Host certificate considerations
- 3.3.13. Entrust considerations
- 3.3.14. Using certificate authentication
- 3.3.15. Share access considerations
When AppGate Client or Connect is installed on the Windows platform, a start icon is installed in the Windows Start menu and on the desktop. To start AppGate Client, either click on the AppGate Client icon on the desktop or select Start->Programs->AppGate Client 8.2.1->AppGate Client 8.2.1 from the Windows Start menu.
There are Java Web Start versions of all AppGate clients. They work just like the installed clients, but will automatically update themselves whenever a new version is installed on the AppGate server. Java Web Start requires that the client machine has Java 1.3 or later installed.
To connect using a Java Web Start client, the user must first connect to the AppGate server with a web browser. The default web page on the AppGate server checks whether the client has Java Web Start available. If so, the top client on the first page will have a Java Web Start icon. The client is launched by clicking on this icon.
Users may get a security question; whether they wish to run content from AppGate Network Security AB.
Java Web Start may ask the user whether it should place an icon on the desktop for the program. If the user answers 'Yes', this icon can be used to launch the client.
Unix machines may have Java Web Start installed but not
correctly configured in the browser. In this case, one should
associate filenames ending with .jnlp
with the javaws command.
AppGate Applet is a Java applet version of AppGate Connect, which is designed to be loaded from a web page with a web browser which supports Java. The applet does, just like the Java Web Start version, not require the user to install anything on the computer.
Using a web browser, such as Mozilla or Microsoft Internet
Explorer, the user must connect to the AppGate server by
navigating to the server by its host name or by its IP
address. The top client on the default page is either the Java
Web Start version of AppGate Client or Applet. To start
the applet, the client should request the
/applet/applet.html page.
The user must then click on the link 'Click to Connect' in order to launch AppGate Applet. The browser may then issue a security warning to warn that it is about to run a signed applet.
Once loaded, the applet works just like AppGate Connect. In fact, it is a version of AppGate Connect.
As soon as the AppGate client is started, it looks for a configuration file, and, if one exists, reads it. The Java Web Start client will also download configuration from the server, which allows the administrator to configure the first screens as well. The client will then display the Open connection dialog.
To open a connection to an AppGate server:
Specify the name of the server to connect to. Previous servers will be listed in the drop-down list. Selecting a server from the drop-down list may fill in other fields as well.
Select which authentication method to use.
The other authentication fields depend on the selected authentication method.
It is also possible to open the Connection properties dialog by pressing the 'Properties...' button. There is normally no need to do this.
When the AppGate client connects to an AppGate server for the first time, and the installation software has not installed a server host key, a dialog box may be shown.
This box asks the user to acknowledge that he is connecting to a new server. Pressing the details button will show the key fingerprint for the server. The key fingerprint will be the same for any user who connects to the same server. Therefore, the user may check the fingerprint against another installation to verify its validity before accepting it. This provides additional protection against man-in-the-middle attacks. The user must click OK in order to accept the host key and continue with the connection.
It is possible to view the host key for a server which the client is connected to. This is done by right-clicking on the server name and selecting 'Properties...' in the menu.
If the received server key does not match the stored key, the connection will fail. This is usually due to one of two events: the server software has been reinstalled and a new server key has been created, or someone is pretending to be the AppGate server (i.e. someone tries to act as a man in the middle that relays and controls the traffic to the server). Under both circumstances, please contact a system administrator to make sure nothing suspicious is going on! If there are absolutely no doubts that the server key has changed, the locally stored key can be deleted. The host keys can be found in the following directories:
- Windows NT 4
\WINNT\Profiles\Username\Appgate\Hostkeys- Windows 2000/XP/2003/Vista
\Documents and Settings\Username\Appgate\Hostkeys- Unix systems (including Mac OS X)
~/.appgate/hostkeys
The first step when connecting is to authenticate the server. Depending on the configuration, the client may present the server host key to the user for verification at the first connection (see Section 3.3.3, “First time connection”).
The server authentication process is followed by user authentication. Depending on the selected authentication method, additional dialog boxes asking for authentication information may be displayed.
When a user logs on to an AppGate server, the server checks the status of the account. If the user is already logged in, a message saying "You are already logged in" may be displayed (see Section 4.9.3, “Connection Settings” for details on how to enable/disable this message).
When the user has been successfully authenticated, information about accessible Roles, Services and server configuration parameters is downloaded.
Access to each service and role on the protected network is given, based on the evaluation of Access Rules. In other words, the services a user is granted access to during a specific session depends on the access rules that have been configured for each protected service/role and which of these rules are matched by the user at that time. The services/roles accessible to the user may therefore vary from session to session.
Roaming is a feature which allows clients to suspend the connection to the AppGate server and later to resume it again. The user does not need to re-authenticate when reconnecting. Indeed, the entire process can be completely automated and nearly invisible to the user. All established connections will remain alive while roaming. This feature is intended for mobile users who move around much in the network.
The user may change network location while roaming. The only requirement is that the user can reconnect to the AppGate server using the same name when resuming. For instance, a salesman may begin the day by logging on from his home network over a DSL connection. Then he suspends the connection and goes to the day's first customer, where he reconnects using a public wireless hot-spot. Later in the day, he may reconnect using a 3G card in his laptop. Another example is a user using the mobile client on his smartphone. Since coverage may be spotty, the phone loses network connectivity often, but roaming hides this from the user. In both cases, it is a great convenience for the users to not have to re-authenticate each time they want to resume the session.
Technically, roaming is accomplished by closing the TCP tunnel when the connection is suspended. When resuming, a new TCP connection is made to the server and the SSH data stream is redirected to this new connection. The user does not need to authenticate again, instead the client authenticates to the server, without user interaction, with the help of a random password which was made up when the user authenticated at the start of the session. In addition to knowing this password, the client must also know the encryption keys and encryption state to be able to reconnect. It is therefore impossible for a third party to break in and take over a suspended session.
To be able to use roaming, the user must have access to the roaming capability. That is, one service which the user has access to must include the roaming capability. It is also up to the administrator to set how long time a roaming user may be roaming.
Roaming can be more or less automatic. The exact level of automation is controlled by the client. The client will automatically enter the suspended state if the connection to the server is lost, assuming roaming is available. Also, the Windows client will do a suspend/resume cycle whenever the machines network configuration changes. The client may also be configured to automatically suspend the connection if no data has been sent for 60 seconds. Resuming can be manual or happen automatically when new data is sent by the client. Note that it is only the client which may resume a session. Automatic suspend/resume can be configured in the Connection properties dialog.
The maximum roaming time can be configured from AppGate Console, see Section 4.9.3, “Connection Settings”.