access gateway

Citrix

eDocs product documentation library

http://edocs.citrix.com

©2010, Citrix Systems, Inc. All rights reserved.

Access Gateway Advanced Concepts

Contents

1. Deploying the Access Gateway in a Double-Hop Demilitarized Zone1.1. How a Double-Hop Deployment Works1.2. Communication Flow in a Double-Hop DMZ Deployment1.2.1. Authenticating Users1.2.2. Creating a Session Ticket1.2.3. Citrix XenApp Online Plug-ins Start1.2.4. Completing the Connection1.3. Preparing for a Double-Hop DMZ Deployment1.4. Installing the Access Gateway in a Double-Hop DMZ1.4.1. Step 1: Installing an Access Gateway in the First DMZ1.4.2. Step 2: Configuring the First Access Gateway1.4.3. Step 3: Installing an Access Gateway in the Second DMZ1.4.4. Step 4: Configuring a Virtual Server on the Access Gateway Proxy1.4.5. Step 5: Configuring the Access Gateway to Communicate with the Access Gateway Proxy1.4.6. Step 6: Binding the Access Gateway in the Second DMZ Globally or to a Virtual Server1.4.7. Step 7: Configuring the Access Gateway to Handle the STA and ICA Traffic1.4.8. Step 8: Opening the Appropriate Ports on the Firewalls1.4.9. Step 9: Managing SSL Certificates in a Double-Hop DMZ Deployment2. Configuring DNS Virtual Servers3. Resolving DNS Name Servers Located in the Secure Network4. Using Operators and Operands in Policy Expressions5. Configuring Server-Initiated Connections6. Enabling Access Gateway Plug-in Logging7. Configuring FIPS 140-2 on the Model 9000 FIPS Series7.1. How FIPS 140-2 Works7.2. Configuring the Hardware Security Module7.3. Creating Private Keys for FIPS7.3.1. Exporting FIPS 140-2 Keys7.3.2. Importing FIPS 140-2 Keys7.3.3. Importing External Keys7.4. Configuring High Availability with FIPS 140-2

Access Gateway Advanced Concepts

Updated: 2010-03-02

The following topics provide information about configuring additional settings on the Access Gateway.

Deploying the Access Gateway in a Double-Hop Demilitarized Zone

Configuring DNS Virtual Servers

Using Operators and Operands in Policy Expressions

Configuring Server-Initiated Connections

Enabling Access Gateway Plug-in Logging

Configuring FIPS 140-2 on the Model 9000 FIPS Series

1. Deploying the Access Gateway in a Double-Hop Demilitarized Zone

Updated: 2010-03-03

Some organizations use three firewalls to protect their internal networks. The three firewalls divide the demilitarized zone (DMZ) into two stages to provide an extra layer of security for the internal network.

This network configuration is called a .double-hop DMZ

Access Gateway appliances deployed in a double-hop DMZ

Note: You can also have a double-hop DMZ with one appliance in the DMZ and one appliance in the secure network. For illustration purposes, this example describes a double-hop configuration using three firewalls. If you are configuring a double-hop configuration with one appliance in the DMZ and one in the secure network, you can ignore the instructions for opening ports on the third firewall.

1.1. How a Double-Hop Deployment Works

Updated: 2010-11-18

You can deploy Access Gateway appliances in a double-hop DMZ to control access to servers running Citrix XenApp, as shown in the previous figure.

In a double-hop DMZ deployment, users connect to the Access Gateway in the first DMZ with a Web browser and Citrix XenApp online plug-ins.

A user begins by connecting to the Access Gateway with a Web browser and selecting a published application from the Web Interface. After selecting a published application, XenApp online plug-ins are started programmatically on the client device. The client connects to the Access Gateway to access the published application running in the server farm in the secure network.

Note: The Access Gateway Plug-in is not supported in a double-hop DMZ deployment. Only Citrix online plug-ins are used for client connections.

The Access Gateway in the first DMZ handles client connections and performs the security functions of an SSL VPN. This Access Gateway encrypts the client connections, determines how clients are authenticated, and controls access to the servers in the internal network.

The Access Gateway in the second DMZ serves as a proxy device. This Access Gateway enables the ICA traffic to traverse the second DMZ to complete client connections to the server farm. Communications between the Access Gateway in the first DMZ and the Secure Ticket Authority (STA) in the internal network are also proxied through the Access Gateway in the second DMZ.

Note: The term refers to an Access Gateway appliance deployed in the second DMZ.Access Gateway proxy

Review the following topics about deploying the Access Gateway in a double-hop DMZ configuration:

Communication Flow in a Double-Hop DMZ Deployment. For reference purposes, this provides a summary and links to a detailed, step-by-step description of the client connection process and the interactions that occur among the various components involved in a double-hop DMZ deployment.

Preparing for a Double-Hop DMZ Deployment. This discusses the configuration issues you should be aware of before deploying Access Gateway appliances in a double-hop DMZ.

Installing the Access Gateway in a Double-Hop DMZ. This describes the procedures you must perform to deploy Access Gateway appliances in a double-hop DMZ configuration.

1.2. Communication Flow in a Double-Hop DMZ Deployment

Updated: 2010-11-18

The following is a summary of the communication flow that occurs between the various Access Gateway and XenApp components in a double-hop DMZ deployment to support a user connection. To understand the configuration issues involved in a double-hop DMZ deployment, you should have a basic understanding of how the various components in a double-hop DMZ deployment communicate.

For reference purposes, a detailed step-by-step description of the client connection process in a double-hop DMZ deployment is provided in this section. Although this process occurs in one continuous flow, it is discussed here in four stages to add clarity to the discussion. The four stages of the client connection process are:

Authenticating Users

Creating a Session Ticket

Citrix XenApp Online Plug-ins Start

Completing the Connection

This figure shows the steps that occur in the client connection process. The steps shown in the figure correspond to the steps discussed in the sections listed above. In the secure network, computers running XenApp are also running the Secure Ticket Authority, XML Service, and published applications.

Figure 1. Double-hop DMZ client connection process

1.2.1. Authenticating Users

Updated: 2010-03-03

User authentication is the first stage of the client connection process in a double-hop DMZ deployment

Figure 1. Basic communication flow for client authentication in a double-hop DMZ

During the client authentication stage, the following basic process occurs:

A user connects to the Access Gateway in the first DMZ with a Web browser. If logon page authentication is enabled on the Access Gateway, the Access Gateway authenticates the user.

1.

2.

3.

4.

5.

1.

2.

3.

4.

5.

1.

2.

The Access Gateway redirects the Web browser connection to the Web Interface.

The Web Interface communicates with the XML Service on a Citrix XenApp and receives from the XML Service a list of applications the user is authorized to access. The XML Service authenticates the user during this process.

Client authentication occurs as follows:

In a Web browser, the user types the address of the Access Gateway, such as https://www.ag.wxyco.com.

The Access Gateway in the first DMZ receives the connection request.

If authentication is enabled on the Access Gateway, the appliance sends the Access Gateway logon page to the user. The user enters authentication credentials on the logon page and the appliance authenticates the user. The Access Gateway then returns the user credentials to the Web Interface. If authentication is not enabled, the Access Gateway does not perform an authentication. The appliance connects to the Web Interface, retrieves the Web Interface logon page, and sends the Web Interface logon page to the user. The user enters authentication credentials on the Web Interface logon page and the Access Gateway passes the user credentials back to the Web Interface.

The Web Interface sends the user credentials to the Citrix XML Service running in the server farm in the internal network. The Citrix XML Service authenticates the user.

The XML Service creates a list of the published applications that the user is authorized to access and sends this list to the Web Interface.

1.2.2. Creating a Session Ticket

Updated: 2010-03-03

Creating the session ticket is the second stage of the client connection process in a double-hop DMZ deployment.

During the session ticket creation stage, the following basic process occurs:

The Web Interface communicates with both the XML Service and the STA in the internal network to produce session tickets for each of the published applications the user is authorized to access.

The session ticket contains an alias address for the computer running Citrix XenApp that hosts a published application.

The Web Interface sends a session ticket request to the STA for each of the published applications the user is authorized to access. Each session ticket request includes the IP address of the server that hosts the published application.

The STA saves the IP addresses of the servers that host the published applications. The STA then sends the requested session tickets to the Web Interface.

Each session ticket includes an alias that represents the IP address of the server that hosts the published application, but not the actual IP address.

The Web Interface generates an ICA file for each of the published applications. The ICA file contains the ticket issued by the STA. The Web Interface then creates and populates a Web page with a list of links to the published applications and sends this Web page to the client Web browser.

1.2.3. Citrix XenApp Online Plug-ins Start

Updated: 2010-03-03

Starting the client software is the third stage of the client connection process in a double-hop DMZ deployment.

The user clicks a link to a published application on the Web page provided by the Web Interface. The Web Interface sends the ICA file for that published application to the client browser.

The ICA file contains data instructing the Web browser to start XenApp online plug-ins.

The ICA file also contains the FQDN or the DNS name of the Access Gateway in the first DMZ.

The Web browser launches the client and the client connects to the Access Gateway in the first DMZ using the Access Gateway name in the ICA file. Initial SSL/TLS handshaking occurs to establish the

2.

1.

2.

3.

4.

5.

6.

7.

8.

9.

identity of the server running the Access Gateway.

1.2.4. Completing the Connection

Updated: 2010-03-03

Completing the connection is the fourth and last stage of the client connection process in a double-hop DMZ deployment.

Figure 1. Basic communication flow for the connection completion in a double-hop DMZ

During the connection completion stage, the following basic process occurs:

The user clicks a link to a published application on the Web page provided by the Web Interface.

The Web browser receives the ICA file generated by the Web Interface and launches the Citrix XenApp online plug-ins.

Note: The ICA file contains code that instructs the Web browser to launch the Citrix XenApp Plug-ins.

The online plug-ins initiates an ICA connection to the Access Gateway in the first DMZ.

The Access Gateway in the first DMZ communicates with the STA in the internal network to resolve the alias address in the session ticket to the real IP address of a computer running Citrix XenApp. This communication is proxied through the second DMZ by the Access Gateway proxy.

The Access Gateway in the first DMZ completes the ICA connection to the online plug-ins.

The online plug-ins can now communicate through both Access Gateway appliances to the computer running Citrix XenApp on the internal network.

The steps for completing the client connection process are as follows:

The client software sends the STA ticket for the published application to the Access Gateway in the first DMZ.

The Access Gateway in the first DMZ contacts the STA in the internal network for ticket validation. To contact the STA, the Access Gateway establishes a SOCKS or SOCKS with SSL connection to the Access Gateway proxy in the second DMZ.

The Access Gateway proxy in the second DMZ passes the ticket validation request to the STA in the internal network. The STA validates the ticket and maps it to the computer running Citrix XenApp that hosts the published application.

The STA sends a response to the Access Gateway proxy in the second DMZ, which is passed to the Access Gateway in the first DMZ. This response completes the ticket validation and includes the IP address of the computer that hosts the published application.

The Access Gateway in the first DMZ incorporates the address of the Citrix XenApp server into the client connection packet and sends this packet to the Access Gateway proxy in the second DMZ.

The Access Gateway proxy in the second DMZ makes a connection request to the server specified in the connection packet.

The server responds to the Access Gateway proxy in the second DMZ. The Access Gateway proxy in the second DMZ passes this response to the Access Gateway in the first DMZ to complete the connection between the server and the Access Gateway in the first DMZ.

The Access Gateway in the first DMZ completes the SSL/TLS handshake with the client by passing the final connection packet to the client. The connection from the client to the server is established.

9. ICA traffic flows between the client and the server through the Access Gateway in the first DMZ and the Access Gateway proxy in the second DMZ.

1.3. Preparing for a Double-Hop DMZ Deployment

Updated: 2010-03-03

To prepare appropriately for a double-hop DMZ deployment, you must answer the following questions before you begin the deployment. Answering these questions before you begin the deployment will help you avoid unnecessary problems when performing the deployment procedures.

Do I want to support load balancing?

What ports do I need to open on the firewalls?

How many SSL certificates will I need?

What components do I need before I begin the deployment?

The remaining topics in this section contain information to help you answer these questions appropriately for your environment.

Components Required to begin the Deployment

Before you begin a double-hop DMZ deployment, you must ensure you have the following components:

At minimum, you must have two Access Gateway appliances available (one for each DMZ).

Servers running Citrix XenApp must be installed and operational in the internal network.

The Web Interface must be installed in the second DMZ and configured to operate with the server farm in the internal network.

At minimum, you must have one SSL server certificate to install on the Access Gateway in the first DMZ. This certificate ensures that the Web browser and client connections to the Access Gateway are encrypted.

Additional certificates are needed if you want to encrypt connections occurring among the other components in a double-hop DMZ deployment.

1.4. Installing the Access Gateway in a Double-Hop DMZ

Updated: 2010-03-03

There are several steps required to deploy the Access Gateway in a double-hop DMZ. This includes installation of the appliances in both DMZs and configuring the appliances for client connections.

The tasks to deploy Access Gateway appliances in a double-hop DMZ include:

Step 1: Installing an Access Gateway in the First DMZ

Step 2: Configuring the First Access Gateway

Step 3: Installing an Access Gateway in the Second DMZ

Step 4: Configuring a Virtual Server on the Access Gateway Proxy

Step 5: Configuring the Access Gateway to Communicate with the Access Gateway Proxy

Step 6: Binding the Access Gateway in the Second DMZ Globally or to a Virtual Server

Step 7: Configuring the Access Gateway to Handle the STA and ICA Traffic

Step 8: Opening the Appropriate Ports on the Firewalls

Step 9: Managing SSL Certificates in a Double-Hop DMZ Deployment

1.4.1. Step 1: Installing an Access Gateway in the First DMZ

Updated: 2010-11-16

To install the Access Gateway in the first DMZ, follow the instructions in .Access Gateway Appliances

1.

2.

3.

1.

2.

3.

4.

5.

If you are installing multiple Access Gateway appliances in the first DMZ, you can deploy the appliances behind a load balancer.

1.4.2. Step 2: Configuring the First Access Gateway

Updated: 2010-03-03

In a double-hop DMZ deployment, it is mandatory that you configure each Access Gateway in the first DMZ to redirect connections to the Web Interface in the second DMZ.

Redirection to the Web Interface is performed at the Access Gateway Global or virtual server level. To connect to the Web Interface through the Access Gateway, a user must be associated with an Access Gateway user group for which redirection to the Web Interface is enabled.

1.4.3. Step 3: Installing an Access Gateway in the Second DMZ

Updated: 2010-11-16

The Access Gateway appliance in the second DMZ is called the because it proxies ICA Access Gateway proxyand STA traffic across the second DMZ.

Follow the instructions in to install each Access Gateway appliance in the second DMZ.Access Gateway Appliances

You can use this same installation procedure to install additional appliances in the second DMZ.

1.4.4. Step 4: Configuring a Virtual Server on the Access Gateway Proxy

Updated: 2010-03-03

Create a virtual server on the Access Gateway proxy. On the Access Gateway in the first DMZ, configure it to communicate with the Access Gateway in the second DMZ. You do not need to configure authentication or policies on the Access Gateway proxy. Citrix recommends disabling authentication on the virtual server.

To disable authentication on the virtual server

In the configuration utility, in the navigation pane, click . > Access Gateway Virtual Servers

In the details pane, click a virtual server and click .Open

On the tab, under , clear and click .Authentication User Authentication Enable Authentication OK

1.4.5. Step 5: Configuring the Access Gateway to Communicate with the Access Gateway Proxy

Updated: 2010-03-03

When you deploy the Access Gateway in a double-hop DMZ, you must configure the Access Gateway appliance in the first DMZ to communicate with the Access Gateway proxy appliance in the second DMZ.

If you deployed multiple appliances in the second DMZ, you must configure each Access Gateway in the first DMZ to communicate with every Access Gateway appliance in the second DMZ.

You can use this procedure to enable an Access Gateway in the first DMZ to communicate with one or more Access Gateway appliances in the second DMZ.

In the Access Gateway Policy Manager, under / , click .Available Policies Resources Next Hop Servers

Under , click .Related Tasks Create a new next hop server

In , type a name for the first Access Gateway.Name

In , type the virtual server IP address of the Access Gateway proxy in the second DMZ.IP address

In , type the port number, click , and click .Port Create Close If you are using a secure port, such as 443, select . This check box is enabled by default.Secure

Each Access Gateway installed in the first DMZ must be configured to communicate with all Access Gateway proxy appliances installed in the second DMZ.

1.

2.

1.

2.

3.

1.4.6. Step 6: Binding the Access Gateway in the Second DMZ Globally or to a Virtual Server

Updated: 2010-03-03

After you configure the Access Gateway in the second hop, you can bind it to either the Access Gateway global level or to virtual servers configured on the Access Gateway in the first DMZ.

Perform this procedure on each appliance installed in the second DMZ.

In the Access Gateway Policy Manager, do one of the followingUnder / , expand the node for Configured Resources Policies Access Gateway Global

Under / , expand the node for and then expand Configure Resources Policies Virtual Serverthe node for a virtual server in the list

Under / , under , click and drag a configured server to Available Resources Policies Next Hop Servers under or .Next Hop Server Access Gateway Global Virtual Servers

1.4.7. Step 7: Configuring the Access Gateway to Handle the STA and ICA Traffic

Updated: 2010-03-03

When you deploy the Access Gateway in a double-hop DMZ, you must configure the Access Gateway in the first DMZ to handle communications with the STA and ICA traffic appropriately. The server running the STA can be bound either globally or to a virtual server.

Configure the Access Gateway in the first DMZ to communicate with the STA running in the internal network. When the STA is configured, you can bind the STA either globally or to a virtual server.

In the Access Gateway Policy Manager, do one of the followingUnder / , expand the node for Configured Resources Policies Access Gateway Global

Under / , expand the node for and then expand Configure Resources Policies Virtual Serverthe node for a virtual server in the list

Click and under , click .STA Servers Related Tasks Bind new STA server

In , type the path to the server running the STA, such as http:// or http://URL mycompany.com ipAddress, and click .Create

1.4.8. Step 8: Opening the Appropriate Ports on the Firewalls

Updated: 2010-03-03

You must ensure that the appropriate ports are open on the firewalls to support the connections occurring in a double-hop DMZ deployment.

Several different connections occur among the various components involved in a double-hop DMZ deployment. For a detailed discussion of the connection process, see Communication Flow in a Double-Hop

.DMZ Deployment

The following figure shows common ports that can be used in a double-hop DMZ deployment. Review the tables below to determine which ports to open through each firewall in your environment.

Figure 1. Ports in a double-hop DMZ deployment

The table below shows the connections that occur through the first firewall and the ports that must be open to support the connections:

Connections through the first firewall Ports used

The Web browser from the Internet connects to the Access Gateway in the first DMZ.

Note that the Access Gateway includes an option to redirect connections that are made on port 80 to a secure port. If this option is enabled on the Access Gateway, you can open port 80 through the first firewall. When a user makes an unencrypted connection to the Access Gateway on port 80, the Access Gateway automatically redirects the connection to a secure port.

Open TCP port 443 through the first firewall.

XenApp Plug-ins from the Internet connects to the Access Gateway in the first DMZ.

Open TCP port 443 through the first firewall.

The table below shows the connections that occur through the second firewall and the ports that must be open to support the connections:

Connections through the second firewall Ports used

The Access Gateway in the first DMZ connects to the Web Interface in the second DMZ.

Open either TCP port 80 for an unsecure connection or TCP port 443 for a secure connection through the second firewall.

The Access Gateway in the first DMZ connects to the Access Gateway in the second DMZ.

Open TCP port 443 for a secure SOCKS connection through the second firewall.

If you enabled authentication on the Access Gateway in the first DMZ, this appliance might need to connect to an authentication server in the internal network.

Open the TCP port on which the authentication server listens for connections. Examples include port 1812 for RADIUS and port 389 for LDAP.

The table below shows the connections that occur through the third firewall and the ports that must be open to support the connections:

Connections through the third firewall Ports used

The Web Interface in the second DMZ connects to the For each of these three connections:

XML Service hosted on a server in the internal network. Open either port 80 for an unsecure connection or port 443 for a secure connection through the third firewall.The Web Interface in the second DMZ connects to the

STA hosted on a server in the internal network.

The Access Gateway in the second DMZ connects to the STA residing in the secure network.

The Access Gateway in the second DMZ makes an ICA connection to a published application on a server in the internal network.

Open TCP port 1494 to support ICA connections through the third firewall.

If you enabled session reliability on XenApp, open TCP port 2598 instead of 1494.

If you enabled authentication on the Access Gateway in the first DMZ, this appliance may need to connect to an authentication server in the internal network.

Open the TCP port on which the authentication server listens for connections. Examples include port 1812 for RADIUS and port 389 for LDAP.

1.4.9. Step 9: Managing SSL Certificates in a Double-Hop DMZ Deployment

Updated: 2010-03-03

You must install the SSL certificates necessary to secure (encrypt) the connections among components in a double-hop DMZ deployment.

In a double-hop DMZ deployment, several different types of connections occur among the various components involved in the deployment. There is no end-to-end SSL encryption of these connections. However, each connection can be encrypted individually.

Encrypting a connection requires you to install the appropriate SSL certificate (either a trusted root or a server certificate) on the components involved in the connection.

The table below shows the connections that occur through the first firewall and the SSL certificates required to encrypt each of these connections. Encrypting the connections through the first firewall is mandatory to secure traffic sent over the Internet.

Connections through the first firewall

Certificates required for encryption

The Web browser from the Internet connects to the Access Gateway in the first DMZ.

The Access Gateway in the first DMZ must have an SSL server certificate installed.

The Web browser must have a root certificate installed that is signed by the same CA as the server certificate on the Access Gateway.

XenApp Plug-ins from the Internet connects to the Access Gateway in the first DMZ.

The certificate management for this connection is the same as the Web browser to Access Gateway connection described above. If you installed the certificates to encrypt the Web browser connection, this connection is also encrypted using those certificates.

The table below shows the connections that occur through the second firewall and the SSL certificates required to encrypt each of these connections. Encrypting these connections enhances security but is not mandatory.

Connections through the second firewall


The Access Gateway in the first DMZ connects to the Web Interface in the second DMZ.

The Web Interface must have an SSL server certificate installed.

The Access Gateway in the first DMZ must have a root

1.

2.

3.

certificate installed that is signed by the same CA as the server certificate on the Web Interface.

The Access Gateway in the first DMZ connects to the Access Gateway in the second DMZ.

The Access Gateway in the second DMZ must have an SSL server certificate installed.

The Access Gateway in the first DMZ must have a root certificate installed that is signed by the same CA as the server certificate on the Access Gateway in the second DMZ.

The table below shows the connections that occur through the third firewall and the SSL certificates required to encrypt each of these connections. Encrypting these connections enhances security but is not mandatory.

Connections through the third firewall


The Web Interface in the second DMZ connects to the XML Service hosted on a server in the internal network.

If the XML Service runs on Microsoft Internet Information Services (IIS) server on the XenApp server, an SSL server certificate must be installed on the IIS server.

If the XML Service is a standard Windows service (does not reside in IIS), an SSL server certificate must be installed within the SSL Relay on the server.

The Web Interface must have a root certificate installed that is signed by the same CA as the server certificate installed on either the Microsoft IIS server or the SSL Relay.

The Web Interface in the second DMZ connects to the STA hosted on a server in the internal network.

The certificate management for this connection is the same as the Web Interface to XML Service connection described immediately above. You can use the same certificates to encrypt this connection. (The server certificate must reside on either the Microsoft IIS server or the SSL Relay. A corresponding root certificate must be installed on the Web Interface.)

The Access Gateway in the second DMZ connects to the STA hosted on a server in the internal network.

The SSL server certificate management for the STA in this connection is the same as described for the two previous connections discussed in this table. (The server certificate must reside on either the Microsoft IIS server or the SSL Relay.)

The Access Gateway in the second DMZ must have a root certificate installed that is signed by the same CA as the server certificate used by the STA and XML service.

The Access Gateway in the second DMZ makes an ICA connection to a published application on a server in the internal network.

An SSL server certificate must be installed within the SSL Relay on the server hosting the published application.

The Access Gateway proxy in the second DMZ must have a root certificate installed that is signed by the same CA as the server certificate installed within the SSL Relay.

2. Configuring DNS Virtual Servers

Updated: 2010-03-02

To configure a DNS virtual server, you specify a name and IP address. Like the Access Gateway virtual server, an IP address must be assigned to the DNS virtual server. However, this IP address must be on the internal side of the targeted network so that all internal addresses are resolved properly by clients. The DNS port must also be specified.

In the configuration utility, in the navigation pane, expand and click Virtual Servers and Services.Virtual Servers

In the details pane, click .Add

3.

4.

5.

6.

1.

2.

3.

4.

5.

6.

7.

8.

9.

1.

In , type a name for the virtual server.Name

In , type the IP address of the DNS server.IP Address

In , type the port on which the DNS server listens.Port

In , select and click .Protocol DNS Create

Finally, associate the DNS virtual server with the Access Gateway. There are two different methods by which this can be accomplished. The virtual server can either be tied globally to the Access Gateway or on a per virtual server basis, depending on the needs of your Access Gateway.

3. Resolving DNS Name Servers Located in the Secure Network

Updated: 2010-02-10

If your DNS server is located in the secure network behind a firewall and the firewall is blocking ICMP traffic, you cannot test connections to the server due to the request being blocked by the firewall. You can resolve this by creating a non-directly addressable DNS virtual server on the Access Gateway, creating a DNS service with a custom DNS Monitor that resolves to a known FQDN and then binding the service to the virtual server.

Configure a DNS virtual server and DNS service only if your DNS server is located behind a firewall.

First, configure the DNS service and DNS Monitor and then create the DNS virtual server.

To configure a DNS service and DNS Monitor

In the configuration utility, in the navigation pane, expand and click Virtual Servers and Services.Virtual Servers

In the details pane, click .Add

In , type a name for the service.Name

In , select .Protocol DNS

In , type the IP address of the DNS server.IP Address

In , type the port number.Port

On the tab, click .Services Add

On the tab, under , select , click , click and then click .Monitors Available dns Add Create Close

In the dialog box, click and then click .Create Virtual Server (Load Balancing) Create Close

Next, create the DNS virtual server using the procedure and bind the Configuring DNS Virtual ServersDNS service to the virtual server.

To bind a DNS service to a DNS virtual server

In the dialog box, on the tab, click , Configure Virtual Service (Load Balancing) Services Addselect the , click , and then click .DNS service Create Close

4. Using Operators and Operands in Policy Expressions

Updated: 2010-03-02

An operator identifies the operation on which an object performs on it operands. Some qualifiers limit which operators are available. The following table briefly describes each operator:

Operator Description

==, !=, EQ, NEQ These operators test for exact matches. They are case-sensitive (‘‘cmd.exe’’ is NOT EQUAL to ‘‘cMd.exe’’). These operators are useful for creating permissions to allow particular strings that meet an exact syntax, but exclude other strings.

GT This operator is used for numerical comparisons; it is used on the length of the URLs and query strings.

CONTAINS, NOTCONTAINS These operators perform checks against the specified qualifier to determne if the specified string is contained in the qualifier. These operators are not case-sensitive.

EXISTS, NOTEXISTS These operators check for the existence of particular qualifier. For example, these operators can be applied to HTTP headers to determine if a particular HTTP header exists or if the URL Query exists.

CONTENTS This operator checks if the qualifier exists and if it has contents (that is, whether or not a header exists and has a value associated with it, no matter what the value).

Qualifier Operator Operand Action Example

Method EQ/NEQ Required

Standard HTTP Methods

Supported methods

GET, HEAD, POST, PUT, DELETE OPTIONS, TRACE, CONNECT

Verifies the incoming request method to the configured method.

Method EQ GET

URL EQ/NEQ Required

URL (Format: /[prefix][*][.suffix])

Verifies the incoming URL with the configured URL

URL EQ / foo*.asp

URL EQ /foo*

URL EQ /*.asp

URL EQ /foo.asp

CONTAINS/NOTCONTAINS Required

Any String (in Quotes)

Verifies the incoming URL for the presence of the configured pattern.

(Includes URL and URL query.)

URL CONTAINS ‘ZZZ’

URL LEN GT Required

Length (as an integer value)

Compares the incoming URL length with the configured length.

(Includes URL and URL query.)

URLLEN GT 60

URL

QUERY



Optional

Length and offset

Verifies the incoming URL query for the presence of the configured pattern.

Used similarly to CONTENTS.

If no option is specified, the whole URL query after the pattern is used.

If

URLQUERY CONTAINS ‘ZZZ’

options are present, only the length of the query after the pattern is used.

The offset is used to indicate from where to start the search for the pattern

URL QUERY LEN GT Required

Length (as an integer value)

Compares the incoming URL query length with the configured length.URLQUERYLN GT 60

URL TOKENS EQ, NEQ Required

URL Tokens (Supported URL Tokens =, +, %, !, &, ?)

Compares the incoming URL for the presence of configured tokens. A backward slash (\) must be entered in front of the question markURLTOKENS EQ ‘% , +, &, \?’

VERSION EQ, NEQ Required

Standard HTTP versions.

(Valid http version strings HTTP/1.0, HTTP/1.1)

Compares the incoming request’s HTTP version with the configured HTTP version.VERSION EQ HTTP/1.1

HEADER EXISTS/NOTEXISTS None Examines the incoming request for the presence of the HTTP header.Header Cookie EXISTS



Optional

Length and offset

Verifies the incoming request for the presence of a configured pattern in the specific header.

Used similarly to CONTENTS.

If no option is specified, the whole HTTP header value after the pattern is used.

If options are present, only the length of the header after the pattern is used.

The offset is used to indicate from where to start the search for the pattern.

Header Cookie CONTAINS "&sid"

CONTENTS Optional

Length and offset

Uses the contents of the HTTP header.

If no option is specified, the whole HTTP header value is used.

Header User-Agent CONTENTS

If options are present, only the length of the header starting from the offset is used.

SOURCEIP EQ/NEQ Required: IPAddress

Optional: netmask

Verifies the source IP address in the incoming request against the configured IP address. If the optional subnet mask is specified, the incoming request is verified against the configured IP address and subnet mask.

Sourceip EQ 192.168.100.0 -netmask 255.255.255.0

DESTIP EQ/NEQ Required: IPAddress

Optional: netmask

Verifies the destination IP address in the incoming request against the configured IP address. If the optional subnet mask is specified, the incoming request is verified against the configured IP address and subnet mask.

Sourceip EQ 192.168.100.0 -netmask 255.255.255.0

SOURCEPORT EQ/NEQ Required: Port Number

Optional: Port Range

Verifies the source port number in the incoming request against the configured port number.

SOURCEPORT EQ 10-20

DESTPORT EQ/NEQ Required: Port Number

Optional: Port Range

Verifies the destination port number in the incoming request against the configured port number.

DESTPORT NEQ 80

CLIENT.SSL.VERSION EQ/NEQ Required

SSL version

Checks the version of the SSL/TLS version being used in the secure connection.

CLIENT.SSL.VERSION EQ SSLV3

CLIENT.CIPHER.TYPE EQ/NEQ Required

Client Cipher type

Checks for the type of the cipher being used (export or non-export).

CLIENT.CIPHER.TYPE EQ EXPORT

CLIENT.CIPHER.BITS EQ, NEQ, GE, LE, GT, LT Required

Client Cipher bits

Checks for the key strength of the cipher being used.

CLIENT.CIPHER.BITS GE 40

CLIENT.CERT EXISTS, NOTEXISTS Checks whether or not the client sent a valid certificate during the SSL handshake.CLIENT.CERT EXISTS

CLIENT.CERT.VERSION EQ, NEQ, GE, LE, GT, LT Client Certificate Version

Checks the version of the client certificate.

CLIENT.CERT.VERSION EQ 2

CLIENT.CERT.SERIALNUMBER EQ/NEQ Required

Client Certificate Serial Number

Checks the serial number of the client certificate. The serial number is treated as a string.

CLIENT.CERT.SER IALNUMBER EQ 2343323

CLIENT.CERT.SIGALGO EQ/NEQ Required

Client Certificate Signature Algorithm

Checks the signature algorithm used in the client certificate.

CLIENT.CERT.SIGALGO EQ md5WithRSAEncryption

CLIENT.CERT.SUBJECT CONTAINS, NOTCONTAINS Required

Client Certificate Subject

Optional

Length, Offset

Checks the subject field of the client certificate.

CLIENT.CERT.SUBJECT CONTAINS CN= Access_Gateway

CLIENT.CERT.ISSUER CONTAINS, NOTCONTAINS Required

Client Certificate Issuer

Optional

Length, Offset

Checks the issuer field of the client certificate.

CLIENT.CERT.ISSUER CONTAINS O=VeriSign

CLIENT.CERT.VALIDFROM EQ, NEQ, GE, LE, GT, LT Required

Date

Checks the date from which the client certificate is valid.

Valid date formats are:

Tue, 05 Nov 1994 08:12:31 GMT

Tuesday, 05-Nov-94 08:12:31 GMT

Tue Nov 14 08:12:31 1994

CLIENT.CERT.VALIDFROM GE ‘Tue Nov 14 08:12:31 1994’

CLIENT.CERT.VALIDTO EQ, NEQ, GE, LE, GT, LT Required

Date

Checks the date until which the client certificate is valid.

Valid date formats are:

Tue, 05 Nov 1994 08:12:31 GMT

Tuesday, 05-Nov-94 08:12:31 GMT

CLIENT.CERT.VALIDTO GE ‘Tue Nov 14 08:12:31 1994’

Tue Nov 14 08:12:31 1994

5. Configuring Server-Initiated Connections

Updated: 2010-03-02

For each user logged on to the Access Gateway with IP addresses enabled, the DNS suffix is appended to the user name and a DNS address record is added to the appliance’s DNS cache. This helps in referencing users with a DNS name instead of remembering the IP addresses of the users.

When an IP address is assigned to a user’s session, it is possible to connect to the user’s client device from the internal network. For example, users connecting with Remote Desktop or a VNC client can access the user’s client device for diagnosing a problem application. It is also possible for two remotely logged on Access Gateway user’s with internal network IP addresses to communicate with each other through the Access Gateway. Allowing discovery of the internal network IP addresses of the logged on users on the appliance aids in this communication.

A remote user can use the ping command to discover the internal network IP address of a user who could be logged on to the Access Gateway at that time. The command for this is:

ping <username.domainname>

A server can initiate a connection to a client in many different ways. These can either be TCP or UDP connections. The connections can originate from an external system in the internal network or from another computer logged on to the Access Gateway. The internal network IP address assigned to each client logged on to the Access Gateway is used for these connections. The different types of server-initiated connections that the Access Gateway supports are described below.

For these types of connections, the server has prior knowledge about the client’s IP address and port and makes a connection to it. This connection is intercepted by the Access Gateway.

In these type of connections, the client makes an initial connection to the server and the server connects to the client on a port that is known or derived from the first configured port.

In this scenario, the client device makes an initial connection to the server and then exchanges ports and IP addresses with the server using an application-specific protocol where this information is embedded. This enables the Access Gateway to support applications such as active FTP connections.

The port command is used in an active FTP and certain Voice over IP protocols.

The Access Gateway supports plug-in to plug-in connections through the use of the internal network IP addresses. With this type of connection, two Access Gateway clients that use the same Access Gateway can initiate connections with each other. An example of this is using instant messaging applications, such as Windows Live Messenger or Yahoo! Messenger.

If a user logged on to the Access Gateway does not execute a clean logoff (the logoff request did not reach the appliance), the user can log on again using any device and replace the previous session with a new session. This feature might be beneficial in deployments where one IP address is appended per user.

When an inactive user logs on to the Access Gateway for the first time, a session is created and an IP address is assigned to the user. If the user logs off but the logoff request gets lost or the client fails to perform a clean logoff, the session is maintained on the system. If the user tries to log on again from the same device or another device, after successful authentication, a transfer logon dialog box is presented to the user. If the user chooses to transfer logon, the previous session on the Access Gateway is closed and a new session is created. The transfer of logon is active for only two minutes after logoff and if logon is attempted from multiple devices simultaneously, the last logon attempt is the one that replaces the original session.

6. Enabling Access Gateway Plug-in Logging

Updated: 2010-03-02

You can configure the Access Gateway Plug-in to log all errors to a text file. The Access Gateway Plug-in logs all of its major activities into a log file. These are stored on the user device. Two files are created:

1.

2.

hooklog< >.txtnum

nssslvpn.txt

The hooklog<num>.txt file logs interception messages generated by the Access Gateway Plug-in and the nssslvpn.txt file finds errors with the plug-in. You can also send these files to Citrix customer support for assistance.

Note: The hooklog.txt files are not deleted automatically. Citrix recommends deleting the files periodically.

User logs are now located in the following directories in Windows:

Windows XP (all users): %SystemDrive%:\Documents and Settings\All Users\Application Data\Citrix\AGEE

Windows XP (user-specific): %SystemDrive%:\Documents and Settings\%username%\Local Settings\Application Data\Citrix\AGEE

Windows Vista (all users): %SystemDrive%:\ProgramData\Citrix\AGEE

Windows Vista (user-specific): %SystemDrive%:\Users\%username%\AppData\Local\Citrix\AGEE

Windows 7 (all users): %SystemDrive%:\ProgramData\Citrix\AGEE

Windows 7 (user-specific): %SystemDrive%:\Users\%username%\AppData\Local\Citrix\AGEE

You can use these log files to troubleshoot the Access Gateway Plug-in. Users can email the log files to technical support if problems are encountered.

In the dialog box, users can set the level of logging for the Access Gateway Plug-in. The Configurationlogging levels are:

Record error messages

Record event messages

Record Access Gateway Plug-in statistics

Record all errors, event messages, and statistics

To enable logging

On the user device, right-click the Access Gateway icon in the notification area and click .Configure Access Gateway

Click the tab, select the log level, and click .Trace OK

Note: You must be logged on to the Access Gateway to open the dialog box.Configuration

7. Configuring FIPS 140-2 on the Model 9000 FIPS Series

Updated: 2010-03-03

FIPS 140-2 is a standard issued by the United States National Institute of Standards and Technologies. FIPS 140-2 specifies the security requirements for a cryptographic module that is used within a security system that protects sensitive information in computer and telecommunication systems. The Access Gateway Model 9000 FIPS Series complies with the second version of this standard, FIPS-140-2.

7.1. How FIPS 140-2 Works

Updated: 2010-03-03

The FIPS 140-2 is a cryptographic module that allows you to configure additional security on the Access Gateway. FIPS 140-2 is configured by creating two passwords and creating a FIPS key in the Hardware Security Module. The FIPS key is an RSA public-private key pair. The Hardware Security Module provides a secure location for storing the private key for the Access Gateway.

To configure the Access Gateway to use FIPS 140-2, a secure certificate signed by a Certificate Authority (CA) must be installed on the Access Gateway. If you do not have a signed certificate, create a Certificate Signing Request and send it to a public CA, such as Verisign or Thawte. Citrix recommends installing the

1.

2.

signed certificate on the Access Gateway before configuring FIPS 140-2. For more information about certificates, see .Installing and Managing Certificates

The private key is associated with a server certificate that is signed by a CA. You can install the private key in the Hardware Security Model using the FIPS wizard or using the configuration utility.

Note: Only an administrator who logs on to the Access Gateway using nsroot (the administrative user name) can change the passwords and install the private key in the Hardware Security Module.

The following table summarizes the differences between the Access Gateway and the FIPS 140- 2 appliance.

Setting Access Gateway FIPS 140-2

Private key storage On the hard drive On the FIPS card

Cipher support All ciphers FIPS-approved ciphers

Accessing private keys From the hard drive Not accessible

Configuring FIPS 140-2 is similar to configuring a non-FIPS appliance. However, the processes differ, due to the presence of the Hardware Security Model on the Access Gateway FIPS 140-2 appliance. After completing the basic settings on the Access Gateway, configure the Hardware Security Module.

7.2. Configuring the Hardware Security Module

Updated: 2010-03-03

When you configure the Hardware Security Module for the first time, it must be initialized. During initialization, you change the default passwords.

The Hardware Security Module comes with two preconfigured passwords. These passwords are called the Security Officer password and the user password.

The Security Officer password allows you to configure all services, and install and initialize the Hardware Security Module. The user password allows you to configure services only.

The default values for the passwords are:

Security Officer password - sopin123

User password - userpin123

Note: When changing the Security Officer password and the user password for the first time, specify sopin123 as the old Security Officer password.

Citrix recommends changing the passwords on the Hardware Security Module before configuring the module. The Hardware Security Module can be configured only by the appliance administrator and should be configured before you run the FIPS 140-2 appliance for the first time.

When you configure the Hardware Security Module for the first time, you configure the passwords. The initial configuration also erases all the existing data on the Hardware Security Module.

Note: Due to security constraints, the passwords for the Hardware Security Module cannot be retrieved. Store a copy of the password safely. If you need to initialize the Hardware Security Module, you need to specify this password as the old Security Officer password.

To initialize the Hardware Security Module

In the configuration utility, in the navigation pane, expand and click .SSL FIPS

Click .Initialize HSM

3.

4.

5.

6.

1.

2.

3.

1.

2.

3.

4.

5.

In , type a new password.Security Officer (SO) Password

In , type , which is the default password.Old SO Password sopin123

In , type , which is the default password.User Password userpin123

In , type or a label of your choice and click .HSM Label FIPS-140-2 Level-2 OK

Important: After the Hardware Security Module is initialized, save the Access Gateway configuration. If this is not done and the appliance is restarted, the FIPS 140-2 card will not function. Any subsequent attempt to change the Security Officer password locks the card.

7.3. Creating Private Keys for FIPS

Updated: 2010-03-03

When the Hardware Security Module is configured, you need to create a FIPS 140-2 private key. This is an RSA key and is associated with a signed certificate from a Certificate Authority (CA). The private keys are stored in the Hardware Security Module. To work with FIPS 140-2, the private key cannot be stored on the hard drive of the Access Gateway.

You can create a private key using either the FIPS Wizard or the Configuration Wizard.

The private key must be paired with a signed server certificate from a Certificate Authority. If you do not have a server certificate, you can create a Certificate Signing Request from with the FIPS Wizard.

If you do have a signed certificate, Citrix recommends creating the private key using the configuration utility.

The FIPS Wizard allows you to configure the following:

Create a new private key or import an existing one

Create a Certificate Signing Request

Create the certificate

Install the certificate

To start the FIPS Wizard


In the details pane, under , click .SSL Certificates Overview FIPS wizard

Click and follow the directions in the wizard.Next

Note: If you do not have a signed certificate, use the Certificate Signing Request that is in the FIPS wizard. After creating the CSR, exit the wizard. When you receive the signed certificate back from the Certificate Authority, you can run the FIPS wizard again to install the certificate and the private key.

To create a FIPS 140-2 key using the configuration utility


In the details pane, on the tab, click .FIPS Keys Add

In , type the name of the key.Fips Key Name

The modulus is the key-bit length. Citrix recommends a modulus size of 1024.In , type .Modulus 1024

Under , select and click .Exponent F4 Create The FIPS key is stored in the Hardware Security Module of the Access Gateway.

7.3.1. Exporting FIPS 140-2 Keys

Updated: 2010-03-03

You can export a private key to the hard drive of the Access Gateway. Private keys are exported for use in a high-availability pair or if you want to create a backup of the private key.

1.

2.

3.

4.

1.

2.

3.

4.

5.

1.

2.

3.

4.

5.

Note: When configuring a high availability pair that uses FIPS 140-2, each Access Gateway must have the same private key and server certificate. Citrix recommends that you create a backup of any key created on the FIPS 140-2 Hardware Security Module.


On the tab, click .FIPS Keys Export

Under , select the key you want to export.FIPS Key Name

The exported file is stored in In , type the name of the file to be exported and click .File Name Exportthe /nsconfig/ssl directory by default. If you choose to use any other directory, you must specify the complete path to the location. You can also click to start the file explorer to navigate to Browseany location on the Access Gateway.

Important: To avoid errors when importing a FIPS 140-2 key, when you export the key, make sure that the name of the exported key is the same as the original key name when it was created.

If a private key on the Hardware Security Module is deleted, the associated server certificates cannot be used because the private key is associated with the server certificate. When the private key is deleted, you cannot create the same key a second time.

7.3.2. Importing FIPS 140-2 Keys

Updated: 2010-03-03

You can transfer an existing server certificate and private key to the Access Gateway and the Hardware Security Module. For example, you have a certificate and private key on a Windows server that is running Internet Information Services (IIS). You export the certificate and private key from IIS and import it to the Access Gateway and then import the private key to the Hardware Security Module.

You can use an existing FIPS 140-2 key with the Access Gateway. The existing FIPS 140-2 key needs to be imported into the Hardware Security Module.


On the tab, click .FIPS Keys Import

Next to , select .Import From FIPS key file

In , type the name of the FIPS 140-2 key to be created.FIPS Key Name

In , type the name of the FIPS 140-2 key to be imported and click .Key File Name Import

Note: The default location is the /nsconfig/ssl directory. If the file is located in another directory, you must specify the complete path to the location. You can use also click to launch the Browsefile explorer and navigate to any location on the Access Gateway.

7.3.3. Importing External Keys

Updated: 2010-03-03

In addition to transferring FIPS 140-2 keys, you can also transfer external private keys from the hard drive to the Hardware Security Module. External keys are created outside the Hardware Security Module. To import an external key into the Hardware Security Module, you need to use an intermediate key, also known as a wrap key within the Hardware Security Module. You can use one wrap key to import multiple private keys.

To generate a wrap key


On the tab, click .Wrap Keys Add

In , type the name of the wrap key.Wrap Key Name

In , type the password to be used for the wrap key.Password

In , type the salt string to be used for the wrap key and click .Salt Create

To convert the external key into the PKCS8 Format

1.

2.

3.

4.

5.

6.

7.

1.

2.

3.

4.

5.

6.

7.

1.

2.

3.

4.

5.

Before importing an external key, you first need to convert it to the PKCS8 format. The external key is encrypted with the wrap key before it is imported into the Hardware Security Module.



Next to , click and click .Import From Pkcs8 file Convert

In , click and navigate to the private key.Key Name (Pkcs8 format) Browse

In , click and navigate to the private key.Private Key Path Browse

Under , select the format to which the external key is saved.Key Format

In , type the password used to encrypt the key, click , and then click .Password Convert Import

To import an external private key as a FIPS key

After converting the private key to the PKCS8 format, import the internal key to the Hardware Security Model.



Click .Import From Pkcs8 file

In , type the name of the FIPS key to be created.FIPS Key Name

In , type the name of the FIPS key to be imported.Key File Name

Under , select the wrap key to be used for the import.Wrap Key Name

In , type the initialization vector to be used for importing the key, such as wrapkey123, and click .IV Create

Note: For security reasons, delete the external private key from the hard disk after you import it into the Hardware Security Module.

7.4. Configuring High Availability with FIPS 140-2

Updated: 2010-03-03

In a high availability configuration, the private key is not propagated to the secondary Access Gateway appliance. After creating the private key on the primary appliance, it needs to be copied to the secondary appliance. The steps for transferring the private key are:

Initializing the primary and secondary appliances

Creating the FIPS private key on the primary appliance

Exporting the server certificate and FIPS private key from the primary appliance

Importing the server certificate and FIPS private key to the secondary appliance

This is also known as .secure information management

If you have two Access Gateway appliances configured as a high availability pair, the same private key and server certificate must reside on each appliance.

You can use the FIPS wizard to import certificates from an Internet Information Services (IIS) server or from the primary Access Gateway appliance. During the wizard, select Import existing private key as FIPS keyand then select the private key. Before running the FIPS wizard, create the wrap key that is used for importing private keys. Citrix recommends using the FIPS wizard to import the private key.

You can also import the private key using the configuration utility.


On the tab, click .FIPS Info Enable SIM

In , type the file name and path on the source system where the FIPS 140-Certificate File Name2 certificate is stored.

In , type the file name and path on the source system where the FIPS 140-2 Key Vector File Namekey vector is stored.

5.

6.

In , type the location for storing the secret data on the target system.Target Secret File Name

In , type the location for storing the secret data on the target system and click Source Secret File Name.OK

Note: The secret file on the source and target system is the file on the system to which the FIPS key is copied before it is transferred or received.

access gateway

Documents

access gateway appliances

access gateway plugin

term access gateway

controls access

dmz deployment

dmz configuration

dmz note

demilitarized zone dmz