(For more resources related to this topic, see here.)
Firstly, let us address a little of the history of Citrix Systems, the purpose of CAG, and why this is used within corporates, from small companies to large enterprise networks.
Citrix has been providing levels of remote access since 1989, first with their Multi-User OS2 terminal server. Following the success of Citrix-Multi-User, they went on to develop for the Microsoft Windows operating systems and the milestones include:
1993 – WinView releases
1995 – WinFrame releases
1998 – MetaFrame releases
2008 – XenApp releases
In the early days of WinFrame and MetaFrame terminal servers, you would have to provide some third-party virtual private network (VPN) solution to be able to access these servers from the Internet. In many respects, the weakness of these early solutions is that they do not address secure remote access.
To mitigate this issue, Citrix introduced a product into the market, in 2001, called Citrix Secure Gateway (CSG). This is still available today and is bundled with XenApp 6.5. This, much in the same way as CAG, is a remote access solution that can be used to provide remote users on the Internet connectivity to your internal resources, such as your XenApp or XenDesktop servers.
Without CAG or CSG, each Citrix XenApp server and/or each XenDesktop virtual machine would require a public IP address to be accessible from the outside world. Of course, this is not practical, especially when we look at XenDesktop; do you have 300 public IP addresses available for your virtual desktops or VDI environment?
Both the CSG and CAG can act as an ICA proxy to provide connectivity to your internal Citrix servers.
ICA is the Citrix protocol for remote access. This can be listened on TCP port 1494 (for standard ICA connections) or TCP port 2598 (for session reliability). Session reliability tunnels ICA traffic through port 2598 to allow for momentary loss of connectivity, as would be experienced with mobile networks, and to allow seamless reconnection to the session.
So, if both devices can provide the ICA proxy functionality, why use CAG?
In 2005, Citrix systems acquired NetScaler, Inc. This gave them the NetScaler product range, and ultimately, Access Gateway. Quite simply, CAG is a secured system dedicated to remote access. It is supplied as either a hardware appliance or virtual appliance.
By "dedicated", it is meant that CAG has no other function, purpose, or unnecessary services. It is hardened or locked down for security at the time of production. CSG, on the other hand, is a software that installs onto a running operating system. We are, then, reliant on the OS that it is installed upon to be specifically hardened to provide the same level of security that you find out-of-the-box with CAG.
In addition to this, CAG can provide standard VPN connectivity into your private networks for remote users, not just connectivity to XenApp or XenDesktop. Choosing the appliance-based CAG includes support for additional applications and protocols. The software-based Secure Gateway is not only less secure but is also limited to supporting traffic directed to computers running XenApp or XenDesktop. Therefore, organizations that use the Secure Gateway might also have to deploy a remote access solution for other types of internal network resources, adding additional expense and management workload for already busy administrators.
CAG can handle your organization's remote access needs by securing traffic to applications hosted by Citrix XenApp and desktops hosted by Citrix XenDesktop as well as access to internal resources, such as e-mail, internal Web applications, and network file shares. In short, CAG is a secure remote access solution to provide VPN or ICA proxy access to internal resources to your mobile or remote workforce.
The following diagram illustrates that users connecting from the Internet pass through the external corporate firewall to the Access Gateway. From here, the incoming HTTPS is converted to an ICA stream targeting XenApp or XenDesktop servers. Possibly, even native protocols are converted to non-Citrix products when using a full VPN connection.
CAG, as mentioned already, can run as a virtual appliance or on physical hardware. The physical hardware device is a dedicated Citrix NetScaler appliance and comes in various shapes and sizes. The CAG firmware is installed into the NetScaler appliance, which runs an embedded Linux operating system. The same firmware that is used to run CAG on the hardware appliance can be used on the VPX edition, for example, both the VPX appliance and NetScaler 2010 model run Access Gateway 5.x firmware.
Model 2010 Appliance represents entry-level dedicated hardware and supports Access Gateway 5.0 and Access Gateway Standard Edition. In this book we will focus on Access Gateway 5.0.4. You can install Model 2010 in the DMZ or the secure network. The preconfigured IP address of the Access Gateway is 10.20.30.40. Citrix will tell you that you are able to change the IP address using a serial cable and a terminal emulation program such as Microsoft Windows Telnet Client, or you can connect Access Gateway using network cables and Access Gateway Management Console in Access Gateway 5. Usually, connecting via the network to change the IP address is the simplest method; just ensure you are plugged into a non-production environment when making the change, and then switch the appliance back into the DMZ. The following is a screenshot of NetScaler MPX 5500 Appliance model:
This model boasts multiple processors, and from that, you can gain faster throughput and more concurrent connection support. Citrix provides Access Gateway in multiple forms to suit your organizational needs. This model supports Access Gateway Enterprise Edition. The preconfigured IP address of Access Gateway is 192.168.100.1 with a 16-bit or class B subnet mask. The IP address is changed in the same way as Model 2010.
Other hardware appliances are available to support the growing amount of concurrent connections that you may require.
You can install the Access Gateway Enterprise Edition appliances in the DMZ or the secure network as with Access Gateway 5.
The main difference between the models is their hardware specifications. The higher the specification of the hardware, the more users the appliance will support, and it will be quicker in those tasks. One of the first tasks in the planning of your appliance is to answer the question "how many concurrent connections do we need to support?" or, simply "how many users will be connected to the appliance at the same time?".
If you are using VPX, the specifications can be managed by assigning fewer or less resources such a RAM and CPU to the virtual machine.
The following table conveniently lists each of the hardware appliances and their main specifications:
Appliance Specifications |
2010 |
5500 |
Processors RAM in GB Power supplies |
1 1 1 |
1 dual core 4 1 |
The very latest version of Access Gateway, as of June 2012, is Access Gateway 10, which is being introduced as a replacement for Access Gateway 9.3 Enterprise Edition.
Both the Access Gateway 9.x and 10.x models require NetScaler 5500 or higher as a hardware platform. The earlier editions of Access Gateway Version 4.x and 5.x can run on NetScaler 2010 or the virtual appliance. Many of the features are the same, but it is the enterprise class high availability of the premium models that sets them apart. Much of this high availability can be mirrored within your virtual host environment if you choose to use the VPX editions.
To gain an appreciation of where Citrix began on the Access Gateway product, we introduce to you the major milestones for the product under the ownership of Citrix Systems.
Milestones of Access Gateway include:
2005 – Citrix acquires NetScaler
2005 – Citrix Access Gateway names product of the year by SearchNetworking
2006 – Citrix Access Gateway Enterprise Edition launches
2008 – MPX or multi-processor version of the Access Gateway hardware appliances (NetScaler) launches
2009 – Citrix launches Access Gateway VPX edition, a cost-effective replacement for CSG in 2009
2012 – CAG 10 introduces in 2012
The latest and greatest offering from Citrix, Citrix NetScaler Access Gateway Version 10, offers support for:
Clientless access for a receiver on the Web:
Connect to your internal resources with a secure VPN connection with just a web browser
Multi-stream ICA that allows you to partition multiple ICA streams in the same session:
Multi-stream ICA is a quality of service (QoS) enhancement developed in XenDesktop 5.5 and XenApp 6.5. When implemented, Multi-stream ICA uses four separate TCP connections to carry the ICA traffic between the client and the server. Each of these TCP connections will be associated with a different class of service. ICA traffic has always implemented multiple internal channels. These channels represent clipboard mapping, audio, drive mappings, and so on. With Multi-stream ICA, the four TCP connections are assigned a QoS priority, and each ICA stream is defined to work with one of these TCP connections inheriting the QoS.
Very high priority (for real-time channels, such as audio)
High priority (for interactive channels, such as graphics, keyboard, and mouse)
Medium priority (for bulk virtual channels, such as drive mapping, scanners)
Low priority (for background virtual channels, such as printing)
Web socket protocol support that allows bi-directional communication between user devices and servers over HTTPS.
Organizational benefits of Access Gateway 10 include:
Secure remote access for the most demanding and complex environments that require increased scalability and performance
High availability of guaranteed access to resources and compliance with Service-level agreements (SLAs)
Highest level of integration and control of remotely delivered Citrix XenApp applications, data through SmartAccess (endpoint analysis), and published desktops with Citrix XenDesktop
Natural progression for existing XenApp customers who have used the Secure Gateway and wish to benefit from the added security and full VPN access
Enterprise-class SSL VPN features, including client-side cache cleanup, detailed auditing, and policy-based access control for web and server applications
Ability for remote users to work with files on shared network drives, access e-mail and intranet sites, and run applications as if they are working within your organization's firewall
Support for the Access Gateway universal license. These licenses enable SmartAccess and can be purchased separately but are also bundled with XenApp Premium Edition
Access Gateway 9.3 Enterprise Edition is very commonly deployed and probably represents many of the enterprise class installations of Access Gateway, more so than version 10 as that is so very new. There were no new features in version 9.3 over those included in the predecessor, Access Gateway 9.2 EE; the enhancements in 9.3 relate more to security.
Access Gateway 9.2 Enterprise Edition offers the following benefits:
Secure remote access for the most demanding and complex environments that require increased scalability and performance
High availability for guaranteed access to resources and compliance with SLAs
Highest level of integration and control of remotely delivered Citrix XenApp applications, data through SmartAccess, (endpoint analysis), and published desktops with Citrix XenDesktop
Natural progression for existing XenApp customers who have used the Secure Gateway and wish to benefit from the added security and full VPN access
Enterprise-class SSL VPN features, including client-side cache clean-up, detailed auditing, and policy-based access control for web and server applications
Ability for remote users to work with files on shared network drives, access e-mail and intranet sites, and run applications as if they are working within your organization's firewall
Support for the Access Gateway universal license; these licenses enable SmartAccess and can be purchased separately but are also bundled with XenApp Premium Edition
Access Gateway 9.2 and 9.3 do not provide support for ICA Multi-stream. ICA Multi-stream is supported in Access Gateway 10, 5.03, and 5.04.
Earlier versions of Access Gateway Enterprise Edition exist, but these versions are enough to cater for what you will encounter in the current market.
The Citrix Access Gateway can be used on NetScaler Model 2010 and the VPX Edition. The Gateway has two modes of operation, Standalone and Controller. Access Controller is an additional piece of software that is installed onto Windows Server 2008 R2 to allow access policies to be defined from within the standard XenApp Group Policies filters. The focus of this book is on Access Gateway in Standalone mode. The key features of Citrix Access Gateway are as follows:
Authentication of users against LDAP directories or RADIUS
Termination point for encrypted sessions
Authorization of users to access resources
Secure VPN through traffic relay for authorized users
Support for multiple logon points that can allow for basic or SmartAccess endpoint analysis
The purpose of this book is to specifically help you understand and deploy the VPX edition of Access Gateway. As organizations have increased their use of remote access solutions, Citrix has had to cater to that need with a diverse offering of systems. These solutions need to provide the same flexibility as the customer base is diverse. Access Gateway VPX is a virtual appliance delivering the same features and functionality as the Model 2010 physical appliance. Customers will find that Access Gateway VPX is ideal for:
Natural progression for existing XenApp customers, who have used the Secure Gateway and wish to benefit from the added security and full VPN access. Access Gateway VPX supports Citrix Receiver and XenDesktop whereas Citrix Secure Gateway does not.
Consolidation of physical resources where rack space may be limited.
Meeting the needs of green IT by reducing cooling needs and power consumption within the data center.
Minimizing downtime by utilizing the HA infrastructure that is already maintained with your virtual machine hosts, maximizing the investment that you have with Citrix XenServer or VMware.
Multi-tenant solutions with the availability of multiple logon points.
In simple terms, the virtual appliance is an easy choice for organizations that already implement a virtual machine infrastructure. The high availability that is not provided in the VPX is maintained by XenServer or VMware. Performance can be optimized by assigning more RAM or VCPUs (virtual processors) to the Access Gateway virtual machine. Citrix suggests a maximum of 500 concurrent users on each virtual appliance.
The Citrix Access Gateway VPX Express is free but is limited to just five concurrent users.
The VPX is downloaded from the Citrix website. If you do not already have a MyCitrix login, you will be required to register for an account.
Virtual machine resources required by the Access Gateway VPX are as follows:
XenServer version VMware version Memory Concurrent users VCPU Virtual NICS Disk space |
5.5 or Higher ESX/ESXi 4.0 or higher 1 to 4 GB RAM 500 1 to 4 VCPUs (2 recommended) 1 to 4 NICS 12 GB minimum |
The following screenshot shows the console screen from Citrix Access Gateway while running on XenServer:
So, now we understand a little of what the CAG models can provide for us and are clear that we can use hardware or virtual appliances. At this point, we can take the opportunity to review the security solutions provided with CAG and how to design a secure deployment.
How many users do you need to support concurrently?
Part of a secure solution will be making sure the system maintains its presence. Partly, that involves not overloading the system. CAG maintains all incoming connections and passes all VPN traffic into and out of your LAN. Each Model 2010 appliance and VPX can support 500 users, the MPX can support 5500 users, and a massive can support 5000 users. If you're using the VPX, make sure you have enough appliances deployed and load-balanced.
When connecting from the Internet, your remote users are going to connect into your server farms and request a published application from XenApp or a virtual desktop from XenDesktop. The corresponding ICA file that is returned to the client will contain the IP address of the server that will accept the connection. This is usually a private IP Address and the client will have no route to the network.
If remote users are presented with the internal address of the hosted applications or desktops, they will not be able to connect. Thus the need for ICA proxy.
From a security perspective, your network will be more secure if we can ensure that no single protocol can traverse from the external firewall of your DMS into the internal network hosting your private resources. Implementing an ICA proxy on CAG will allow users to connect via HTTPS to the gateway, and the Gateway to forward the connection into the private network using ICA.
Without the Access Gateway ICA, traffic is unchallenged in the DMZ.
In its simplest form, Access Gateway will proxy incoming requests— in this case, for ICA connections to XenApp/XenDesktop. As the client only ever connects to CAG, ICA traffic need not be allowed through the exterior firewall. Additionally, as the client never connects directly to the XenApp servers, they do not need public addresses and need only to be routable to CAG.
The following diagram shows that the client connects using HTTPS from their client to CAG within the DMZ and CAG connects using ICA to the internal resources of XenApp/XenDesktop:
CAG can additionally provide similar VPN access via SSL and to your internal resources using SmartAccess logon points. Multiple logon points can exist on single CAG to provide flexible access.
To allow for secure remote access, authentication of your users should take place within the DMZ. In this way, users are authenticated without the need to connect them to internal resources. CAG addresses these issues by authenticating any user request before they are connected. In addition, your existing directory infrastructure can be used as the authentication source. CAG can connect with Microsoft Active Directory and Novell eDirectory as well as Remote Authentication and Dial-In User Service (RADIUS) and other LDAP providers.
The communication from the client to CAG is secured with SSL. When planning for your CAG deployment, you will need to consider the provision of public-key infrastructure (PKI) certificates for the appliance. The public key from the issuing authority and the server's own key pair must be added to the device.
In this article, we have become familiar with the CAG range and considered which model we require and how many appliances we will need to support our projected concurrent user load. We should also now be able to envision how the gateway will provide remote access solutions to both ICA-based resources, such as XenApp and traditional VPN access to file shares, reducing your reliance on multiple remote access products.
Further resources on this subject: