Access Gateway 5.0 Deep Dive – Failover
Access Gateway 5.0 adds appliance failover as a new feature, which allows two appliances to run as an active/passive pair. In this post we’ll look at how failover works in Access Gateway 5.0, how to set it up and what end users can expect to experience in the event of a failover.
How it works
When two appliances are joined as a failover pair, users connect to a shared virtual IP address instead of the real eth0 or eth1 IP address. You define one virtual IP address that users will connect to, and another virtual IP address which Access Gateway will use when communicating with back-end resources.
These two virtual IP addresses can use the same IP address if you like. At the outset, any traffic sent to the virtual IP address will be handled by the primary appliance. If the primary appliance fails, then the secondary appliance will send out a network broadcast (gratuitous ARP) letting the nearby routers and switches know that it is taking over for the shared IP addresses.
How does the secondary appliance know when to take over? Every second, the secondary appliance sends a health check request to the primary appliance on TCP port 694, expecting a normal response in return. If 10 of these requests in a row are unreturned, the failover event is triggered and the secondary appliance takes over.
Sessions stay in sync
During normal operation, user session information and policy configuration changes are automatically sent to the secondary appliance as changes occur. Therefore, when a failover occurs, users shouldn’t have to log on again. If they are connected to a hosted application or desktop using ICA, the Citrix Online Plug-in will leverage its Session Reliability feature to re-establish the network-layer connection with no data loss and minimal disruption to the end user. Ditto for the Access Gateway Plug-in; the end user gets silently reconnected without having to re-authenticate. While re-authentication should not be required, note that any TCP sessions that were active within a user’s VPN tunnel will have to be re-established after the connection is restored. So if the user was downloading a file when the failover event occurred, they would have to re-start the download.
How to set up failover
Start at the appliance you want to be the primary. Before you can enable failover, you need to assign an interface to the Appliance Failover adapter role. This is done on the Networking page of the appliance management console. If you’re using a Model 2010 appliance, choose eth1 for this role. If you have a virtual appliance, you can use eth1 or add a dedicated virtual interface (eth2) just for this role. After assigning the failover role to an interface, you can configure the settings on the Appliance Failover page.
On the Appliance Failover page, you’ll need to provide four pieces of information:
- Shared key – this is a common password known to both the primary and secondary appliances.
- Peer address – the IP address of the failover interface on the secondary appliance
- Internal virtual address – this is a new IP address that will be shared by both the primary and secondary appliances. The gateway will use this address when communicating with authentication servers and other internal resources.
- External virtual address – this is another shared address. End users connect to this IP, so it should be an externally routable address or the DMZ address that your external address maps to. The internal and external virtual IP addresses can be the same if you so choose.
After entering the above information, click Save and then click Start. You’ll be asked to reboot. After rebooting, users should be able to log on by pointing to the external virtual address.
Next, move to the management console on the secondary appliance. On the Appliance Failover page, change this appliance’s role to Secondary, and enter the following information:
- Shared key – type the same shared key that you defined on the primary appliance
- Peer address – enter the IP address of the primary appliance’s failover interface
Click Save and then Join Primary. After rebooting the secondary, appliance failover is now configured. On the secondary appliance, most of the configuration pages in the management console will become inaccessible since it inherits configuration settings from the primary, including host name, certificates, licensing configuration, authentication profiles, logon points, SmartGroups, secure ticket authorities & access control lists. Adapter roles, IP addresses and static routes are not shared between primary and secondary appliances.
Notes
- In earlier versions of Access Gateway Standard Edition, there was a failover feature that only worked for full VPN connections. In version 5.0, failover works across all connection types and does not require the Access Gateway plug-in.
- If you have trouble getting failover to work, use the console networking utilities to ensure that each gateway can ping the other’s failover interface IP address. When you have multiple interfaces, each interface should be on its own subnet. When the failover interfaces can’t reach one another, both appliances will think they are the primary.
- If you want to enable single sign-on to a Web Interface site, configure the Web Interface to resolve the Access Gateway FQDN to the internal virtual IP address. That way when the Web Interface server makes a call to the authentication service URL, the callback will reach whichever appliance is currently serving as primary.
- Physical and virtual appliances can be mixed within a pair. If you currently have a single Model 2010 appliance deployed, consider adding Access Gateway VPX as a failover appliance. This is a great way to get started with VPX and add redundancy to your deployment.
For more information about appliance failover in Access Gateway 5.0, refer to the Access Gateway 5.0 Documentation topic or watch this video of the failover configuration process.
