Netscaler Double Hop Explained

I  Tested the Doublehop  configuration today with 10.1 and 10.5 Netscaler Version.  There are lot of confusion on this topic regarding the configuration and packet flow. so this document will help you in future case analysis.

Configurations:-

In the First Hop NS you need to have following configurations

·        Double hop should be unchecked

·        Authentication need to be enabled

·        Session Policy to be bound and pointing to the Storefront or WI server. Remember till storefront apps enumeration the work is only done by first hop NS so all configuration are required on the First hop

 

·        Under Published App you need to add the second hop NS under Next hop Server with port as 443 and Secure is checked. The moment you configure Next Hop this NS will understand that it’s the first NS in the double hop environment

            Also the STA need to be configured on the First hop NS ( Remember STA will show down untill you configure the second hop NS because untill then the connection won’t be proxied)

Second Hop Configuration:-

For testing I used first hop as 10.1.129.x firmware and second hop as 10.5.56.x firmware and it worked so we can say that dual hop the firmware need not be same.

In the Second hop the only configuration you need to have is set Double Hop enabled or true. No need to configure STA , Session policy or Authentication as this hop is only acting as a proxy.

 

Communication Flow
So the first thing that you need to understand is how the communication process works.
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