StoreFront in a Double-Hop DMZ – Communication Flow

/, XenApp, XenDesktop/StoreFront in a Double-Hop DMZ – Communication Flow

StoreFront in a Double-Hop DMZ – Communication Flow

Share this post

Today I would like to focus on the communication process in the configuration where StoreFront is located in second DMZ. To learn about all remaining StoreFront deployments see my previous post StoreFront location – in DMZ or Not in DMZ ?

Some organizations require an extra layer of security for servers located in the internal network and implement solution based on three firewalls to protect their internal networks. This network configuration is called a double-hop DMZ.

How a Double-Hop Deployment Works

You can deploy StoreFront servers together with  NetScaler Gateway appliances in a double-hop DMZ to control access to servers running Citrix XenApp or XenDesktop located in the secure network. The example of such configuration is shown in figure 1.

Figure 1

The connections in a double-hop deployment occur as follows:

  • Users connect to NetScaler Gateway in the first DMZ by using a web browser and by using Citrix Receiver to select a published application.
  • Citrix Receiver starts on the user device. The user connects to NetScaler Gateway to access the published application running in the server farm in the secure network.

   Note: Worx Home and the NetScaler Gateway Plug-in are not supported in a double-hop DMZ deployment. Only Citrix Receiver is used for user connections.

  • NetScaler Gateway in the first DMZ handles user connections and performs the security functions of an SSL VPN. This NetScaler Gateway encrypts user connections, determines how the users are authenticated, and controls access to the servers in the internal network.
  • NetScaler Gateway in the second DMZ serves as a NetScaler Gateway proxy device. This NetScaler Gateway enables the ICA traffic to traverse the second DMZ to complete user connections to the server farm. Communications between NetScaler Gateway in the first DMZ and the Secure Ticket Authority (STA) in the internal network are also proxied through NetScaler Gateway in the second DMZ.

The user connection process occurs in one continuous flow, but can be split in the four phases:

  • Authenticating Users
  • Creating a Session Ticket
  • Starting Citrix Receiver
  • Completing the Connection

The steps that occur in the user connection process to either StoreFront or the Web Interface are shown in figure 2. In the secure network, computers running XenApp or XenDesktop are also running the Secure Ticket Authority (STA), XML Service, and published applications.

Figure 2

Authenticating Users

Authenticating users is the first step of the user connection process in a double-hop DMZ deployment. The figure 3 shows the user connection process in this deployment.

Figure 3

 

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

  1. A user types the address of NetScaler Gateway in a web browser to connect to NetScaler Gateway in the first DMZ. If you enabled logon page authentication on NetScaler Gateway, NetScaler Gateway authenticates the user.
  2. NetScaler Gateway in the first DMZ receives the request.
  3. NetScaler Gateway redirects the web browser connection to the StoreFront.
  4. The StoreFront sends the user credentials to the Citrix XML Service running in the server farm in the internal network.
  5. The Citrix XML Service authenticates the user.
  6. 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.

Note:
If you enable authentication on NetScaler Gateway, the appliance sends the NetScaler Gateway logon page to the user. The user enters authentication credentials on the logon page and the appliance authenticates the user. NetScaler Gateway then returns the user credentials to the Web Interface.
If you do not enable authentication, NetScaler Gateway does not perform 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 NetScaler Gateway passes the user credentials back to the Web Interface.

Creating a Session Ticket

Creating the session ticket is the second stage of the user connection process in a double-hop DMZ deployment. During the session ticket creation stage, the following basic process occurs:

  1. The StoreFront communicates with both the XML Service and the Secure Ticket Authority (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.
  2. The STA saves the IP addresses of the servers that host the published applications. The STA then sends the requested session tickets to the StoreFront. 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.
  3. The StoreFront generates an ICA file for each of the published applications. The ICA file contains the ticket issued by the STA. The StoreFront then creates and populates a web page with a list of links to the published applications and sends this web page to the web browser on the user device.

Starting Citrix Receiver

Starting Citrix Receiver is the third stage of the user connection process in a double-hop DMZ deployment. The basic process is as follows:

  1. The user clicks a link to a published application in the StoreFront. The StoreFront sends the ICA file for that published application to the browser for the user device. The ICA file contains data instructing the web browser to start Receiver. The ICA file also contains the fully qualified domain name (FQDN) or the Domain Name System (DNS) name of the NetScaler Gateway in the first DMZ.
  2. The web browser starts Receiver and the user connects to NetScaler Gateway in the first DMZ by using the NetScaler Gateway name in the ICA file. Initial SSL/TLS handshaking occurs to establish the identity of the server running NetScaler Gateway

Completing the Connection

Completing the connection is the fourth and last stage of the user connection process in a double-hop DMZ deployment. During the connection completion stage, the following basic process occurs:

  • The user clicks a link to a published application in the StoreFront
  • The web browser receives the ICA file generated by the StoreFront and starts Citrix Receiver
  • Receiver initiates an ICA connection to NetScaler Gateway in the first DMZ.
  • NetScaler Gateway in the first DMZ communicates with the Secure Ticket Authority (STA) in the internal network to resolve the alias address in the session ticket to the real IP address of a computer running XenApp or StoreFront. This communication is proxied through the second DMZ by the NetScaler Gateway proxy.
  • NetScaler Gateway in the first DMZ completes the ICA connection to Reciever.
  • Receiver can now communicate through both NetScaler Gateway appliances to the computer running XenApp on the internal network.

The detailed steps for completing the user connection process are as follows:

  1. Receiver sends the STA ticket for the published application to NetScaler Gateway in the first DMZ.
  2. NetScaler Gateway in the first DMZ contacts the STA in the internal network for ticket validation. To contact the STA, NetScaler Gateway establishes a SOCKS or SOCKS with SSL connection to the NetScaler Gateway proxy in the second DMZ.
  3. The NetScaler 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 XenApp that hosts the published application
  4. The STA sends a response to the NetScaler Gateway proxy in the second DMZ, which is passed to NetScaler Gateway in the first DMZ. This response completes the ticket validation and includes the IP address of the computer that hosts the published application.
  5. NetScaler Gateway in the first DMZ incorporates the address of the XenApp server into the user connection packet and sends this packet to the NetScaler Gateway proxy in the second DMZ.
  6. The NetScaler Gateway proxy in the second DMZ makes a connection request to the server specified in the connection packet.
  7. The server responds to the NetScaler Gateway proxy in the second DMZ. The NetScaler Gateway proxy in the second DMZ passes this response to NetScaler Gateway in the first DMZ to complete the connection between the server and NetScaler Gateway in the first DMZ.
  8. NetScaler Gateway in the first DMZ completes the SSL/TLS handshake with the user device by passing the final connection packet to the user device. The connection from the user device to the server is established.
  9. ICA traffic flows between the user device and the server through NetScaler Gateway in the first DMZ and the NetScaler Gateway proxy in the second DMZ.
By | 2016-12-18T19:21:33+00:00 August 25th, 2014|StoreFront, XenApp, XenDesktop|3 Comments

About the Author:

I’m a Citrix Architect with 17 years experience in Microsoft and Citrix infrastructure. I have been working with Citrix since Metaframe 1.8 and my primary focus is on Server, Desktop and Application virtualisation with a preference for Citrix products. I’m an enthusiast of Citrix XenDesktop and Provisioning Server.

3 Comments

  1. Adrian May 5, 2015 at 9:40 am - Reply

    What about the requirement to have the StoreFront belonging to the AD domain of the Delivery Controllers. Does it mean all AD ports have to be opened from the second DMZ to the Secure Network?

  2. sylvain June 18, 2015 at 9:23 am - Reply

    step 12 : Receiver sends the STA ticket for the published application to NetScaler Gateway in the first DMZ.

    Can you confirm that a session ticket is always generated and inserted in the ica file sent back to the receiver, even in case where native windiws authentication is configured for applications published in storefront? It seems not to be the case : it seems that a session ticket is only generated and inserted in the ica file in case of login / password authentication form in storefront ?? Is it possible to force the generation of a session ticket in ica file in storefront server?

    Regards,

    Sylvain G.

  3. Ramesh B June 3, 2016 at 12:18 pm - Reply

    Dear Admin,

    Instead of Storefront name you have mention “NetScaler Gateway” in Figure 2.

    Please change.

Leave A Comment

To protect our website from spam. * Time limit is exhausted. Please reload the CAPTCHA.