This article explains how the communication flow works when we configure NetScaler in double hop with StoreFront.

Instructions

Logon Process

 First NetScaler Gateway packet flow ( Second NetScaler will not come into picture till the apps are enumerated)

1.      The user starts his browser and connects (via hostname) to the external IP address of the NetScaler Gateway FQDN of the first hop. The NSG will authenticate and sends it to the StoreFront
2. The StoreFront in the second DMZ receives the request 
3. StoreFront will validate the user based on his credentials 
4. The StoreFront on the second DMZ sends the credentials to a server on the internal network hosting the XML service.
5. The XML Service authenticates the user and receives a list of published applications the user has access to. This list will be send back to the StoreFront.
6. The StoreFront will generates a page with the “published apps” and sends the page through the NetScaler in first DMZ back to the user

Starting Process

1.      The user clicks his application and the request will be forwarded to the StoreFront
2. The SF again contacts the XML service to determine which XenApp server will handle the request. The XML service returns the IP number.
3. The SF then contacts the Secure Ticketing Authority (STA) to switch the IP address for a Session Ticket. The STA saves the IP address and sends a session ticket to the SF. (The XML and STA server don’t have to be the same server)
4. The SF generates an ICA file with the STA session ticket and the FQDN of the NSG in the first DMZ. This ICA file is send back to the user through the NSG in the first DMZ. As you see the application I clicked was Mozilla Firefox and the FQDN is of the first hop

5. The plugin on the machine of the user reads the ICA file and initiates an ICA connection with the session ticket to the first hop NS in the first DMZ.
6. The NS  in the first DMZ sends the Session Ticket through the NS in the second DMZ to the STA for validation. As you can notice below that the First NS sent the same ticket to the 10.104.23.83 which is the ip of the second hop NS and notice that the request has the Host header of 10.104.23.149 which is the STA server, Based on this host header the second hop will understand that I need to send the request to this STA server ( since second hop doesn’t have any STA configuration)

7. The STA validates the ticket and sends the IP address of the XenApp server to the NS in the first DMZ.

You can see that packet 36455 is the same decrypted packet send by first NS is received on this NS and this Second NS made a request to the original STA server 10.104.23.149 in the next packet 36456

In the Next packet on the same second hop you can notice that a response is received from the STA server that the Xenapp server is 10.104.23.149 on port 1494. And the same request is forwarded to the first hop NS in the next packet 36461 ( Remember in my lab both the Xenapp server and STA are same and that’s why we are seeing the same ip 10.104.23.149)

8. The NS in the first DMZ establishes an ICA connection to the IP address of the XenApp server, These connection will be sent/Proxied to the Second Hop NS and the first hop NS will not try to make connection to xenapp directly. As we can see the first hop DMZ proxied all ICA connection to the second hop 10.104.23.83 and the second hop NS will forward the ICA traffic to the actual xenapp servers.

In the below trace taken on Second Hop you can notice in Green color that the traffic is coming to this hop 10.104.23.83 and this NS is actually making connection to the actual xenapp server 10.104.23.149 as shown in Pink color

9. The XenApp server sends an acknowledgement back to the Second Hop NS ( acting as proxy) which will be sent to the first ho NS . Then the SSL/TLS handshake between the CAG in the first DMZ and the XenApp client will be completed.  The ICA session is established and all traffic will flow

CTX113250 - Required Ports for Citrix NetScaler Gateway in DMZ Setup
CTX101810 - Communication Ports Used by Citrix Technologies