Citrix released Citrix Receiver 4.2.x for Apple iOS devices (Iphone,Ipad) in December 2010. The big news in version 4.2.x was that it supports Webinterface, so you could make access your Citrix XenApp,XenDesktop by authenticating on the Webinterface. In earlier version 4.0.1 it didnt support Webinterface, so the only way to provide a secure two factor authentication solution with SMS PASSCODE access to your Citrix infrastructure from your Apple Iphone,Ipad device well you had to buy a Citrix Netscaler (CAGE). SMS PASSCODE supports authentication with Citrix CSG, CAG5 (Access Gateway 5), CAGE (Netscaler) with Citrix Receiver 4.2.x for Apple iOS devices.
See the belowed chart to get an overview of support
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.
- 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.
I am proud to inform you all that Citrix have released Citrix Access Gateway 5.0 VPX.
The CAG 5 VPX is a major breakthrough, thats going to change how we use Secure solutions from Citrix. The VPX means that is a virtual appliance, that you can implement on either XenServer or VmWare. You can also upgrade your existing 2010 appliance to Citrix Access Gateway 5.0. Access Controller is a new functionality that replace the old “Advanced Access Control” So all you people using Access Gateway, Secure Gateway. Jump on the wagon and virtualize your Access Gateway. For best redundancy i recommend that you look at Netscaler.
Access Gateway 5.0 includes the following new features:
- Access Gateway Management Console. The Management Console replaces the Administration Tool and Administration Portal in earlier versions of the appliance. The Management Console, a Web-based application, makes it easy to install certificates, configure access control, and monitor activity from any Flash-enabled Web browser. For more information, see Introducing the Access Gateway Management Console.
- Authentication profiles. Authentication profiles replace authentication realms. You can configure LDAP, RADIUS, and RSA profiles on the appliance. You can configure double source authentication using logon points. You can also use Active Directory authentication on Access Controller. For more information about configuring authentication on Access Gateway or Access Controller, see either Configuring Authentication and Authorization or Configuring Authentication and Authorization on Access Controller.
- Network resources. A network resources identifies those areas in the secure network that users are allowed to access. You can allow or deny access to a network resource in SmartGroups. For more information, see Network Resources Overview.
- Logon points. Each Access Gateway appliance can host multiple logon points to support different features or different user communities. You can configure Basic and SmartAccess logon points. Basic logon points allow users to connect with Citrix online plug-ins or Desktop Receiver only, providing access to published applications or desktops. Users do not need a Universal license to log on using a basic logon point. SmartAccess logon points allow users to connect with the Access Gateway Plug-in and have greater access to network resources. For more information, see Logon Points Overview.
- SmartGroups. SmartGroups in Access Gateway contain a collection of settings that group users according to their identity, location, authentication and authorization type, and the results of endpoint analysis (as defined in device profiles). First, you define the criteria users must match to become a member of a SmartGroup, and then you define the network resources, actions, and other settings for the SmartGroup. For more information, see SmartGroups Overview.
- Device profiles. You can configure endpoint analysis scans using device profiles. If you enable a device profile within a logon point, the endpoint analysis scan determines if users receive the logon page and subsequently log on. If you enable a device profile in a SmartGroup, the device profile you select determines the user access permissions for that SmartGroup. For more information, see Device Profiles Overview.
- Snapshots. You can take a snapshot of the appliance configuration at a given point of time. You can export snapshots to your computer and you can revert to an earlier snapshot. Using the Snapshots tab in the Management Console, you can upgrade to new Access Gateway software versions. For more information, see Snapshots Overview
- Appliance failover.You can configure two Access Gateway appliances for appliance failover. The appliances operate in active/passive mode, in which the primary appliance services all user connections, and the secondary appliance monitors the primary appliance and synchronizes session information. If the primary appliance fails, the secondary appliance takes over. For more information, see Deploying Additional Access Gateway Appliances for Load Balancing and Appliance Failover.
- Clustering. In Access Gateway 5.0, when multiple servers are running Access Controller, the servers are referred to as a cluster. When you have a cluster, you can share sessions across multiple Access Gateway appliances.
- Native Active Directory authentication. Access Controller supports native Active Directory with Windows authentication.
- Advanced endpoint analysis options.
- Advanced authentication options.
- Centralized control of multiple Access Gateway appliances.
- Centralized access logging.
- Delivery Services Console. The Access Controller administration tool is more closely aligned with XenApp and XenDesktop.
Platform License Required
Each appliance running Access Gateway 5.0 requires a platform license in order to function. Without the platform license installed, the gateway will not allow logins after a 48-hour grace period. Platform licenses are delivered electronically when an appliance is ordered. If you have an existing Access Gateway Model 2010 appliance covered by Warranty, you can obtain your Access Gateway Platform License using the Upgrade My Products toolbox on MyCitrix.
User Licenses Optional
The required Access Gateway platform license enables unlimited logins through Basic logon points. Each concurrent login to a SmartAccess logon point requires an Access Gateway user license. Access Gateway Standard Edition or Access Gateway Universal licenses may be used for this purpose.
Subscription Advantage Eligibility Date
To use your existing Access Gateway licenses with this version, the Subscription Advantage on those licenses must be valid on or after September 1, 2010.
Access Gateway 5.0 is supported only on the following appliance platforms:
- Access Gateway Model 2010
- Access Gateway VPX
Discontinued Features and Functionality
The following table below lists the features that are deprecated or removed in Access Gateway 5.0.
|Double-hop demilitarized zone (DMZ)
|Dynamic routing with the Routing Information Protocol (RIP)
|Windows NT LAN Manager (NTLM) as an authentication method
|Locally defined users on Access Gateway
|This feature is replaced by the Access Gateway Management Console.
|This feature is replaced by the Access Gateway Management Console.
|This feature was part of Access Gateway Advanced Edition and is removed from Access Controller.
|This feature was part of Access Gateway Advanced Edition and is removed from Access Controller.
|All licensing is handled on the appliance or by Citrix License Server. You do not have to install licenses on Access Controller.
|This feature is replaced by Outlook Web Access or Outlook Web App.
Citrix Access Gateway 5.0 Plug-in for Windows
Citrix Access Gateway Demo
How To: Overview of new EPA Client in Access Gateway 5.0
How To: Overview of Authentication Profiles in Access Gateway 5.0
1. Configure the XenApp Services site
If you do not already have a XenApp Services site created, in the XenApp console or Web Interface console (depending on the version of XenApp you have installed), create a XenApp Services site for mobile devices.
The Receiver for mobile devices uses a XenApp Services site (formally Program Neighborhood Agent site) to get information about the applications a user has rights to and presents them to the Receiver running on the device. This is similar to the way you use the Web Interface for traditional SSL-based XenApp connections for which an Access Gateway can be configured. XenAppServices sites running on the Web Interface 5. x have this configuration ability built in.
Configure the XenApp Services site for the Receiver for mobile devices to support connections from an Access Gateway connection.
- In the XenApp Services site, select Manage secure client access > Edit secure client access settings.
- Change the Access Method to Gateway Direct.
- Enter the FQDN of the Access Gateway appliance.
- Enter the Secure Ticket Authority (STA) information.
2. Configure the Access Gateway appliance
- Configure authentication policies to authenticate users connecting to the Access Gateway using the Access Gateway Plug-in. Bind each authentication policy to a virtual server.Active Directory authentication, TACACS authentication, SMS authentication (http://smspasscode.com) (iPhone only), and RSA SecurID are the three supported authentication methods for v1.x of the Receiver for mobile devices:
- If double source authentication is required (such as RSA SecurID and Active Directory), RSA SecurID authentication must be the primary authentication type. Active Directory authentication must be the secondary authentication type.
- RSA SecurID uses a RADIUS server to enable token authentication.
- Active Directory authentication can use either LDAP or RADIUS.
Note: For servers prior to Windows Server 2003, Active Directory can use Integrated Windows authentication, also known as NTLM.
Test a connection from a user device to verify that the Access Gateway is configured correctly in terms of networking and certificate allocation.
- Create a session policy on the Access Gateway to allow incoming XenApp connections from the Receiver, and specify the location of your newly created XenApp Services site.
Important: If the server certificate used on the Access Gateway is part of a certificate chain (with an intermediate certificate), make sure that the intermediate certificates are also installed correctly on the Access Gateway. For information about installing certificates, see the Access Gateway documentation.
- Create a new session policy to identify that the connection is from the Receiver for mobile devices. As you create the session policy, configure the following expression and select Match All Expressions as the operator for the expression:REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver
- In the associated profile configuration for the session policy, on the Security tab, set Default Authorization to Allow.On the Published Applications tab, if this is not a global setting (you checked the Override Global check box), ensure the ICA Proxy field is ON.In the Web Interface Address field, enter the URL including the config.xml for the XenApp Services site that the device users use, such as http://XenAppServerName/Citrix/PNAgent/config.xml or http://XenAppServerName/CustomPath/config.xml.
- Bind the session policy to a virtual server.
- Create authentication policies for RADIUS and Active Directory.
- Bind the authentication policies to the virtual server.
3. Configure the mobile device for the Receiver application
- In Account Settings, in the Address field, enter the matching FQDN of your Access Gateway server, such as FQDNofAccessGateway.
- In the Citrix Access Gateway settings, turn on Access Gateway, set the Gateway Type to Enterprise edition, and select the authentication method.