Jump to content
Welcome to our new Citrix community!

Citrix ADC in double-hop integration with Intune


Recommended Posts

Hello all and happy new year to everybody!

A partner wants to implement Citrix ADC in a double-hop DMZ scenario integrated with Microsoft Intune. Is the Intune integration supported in a double-hop scenario? If this is supported, are Windows 10 mobile devices (I haven't seen any documentation regarding the supported operating systems) in the support list?

Link to comment
Share on other sites

A double-hop NSG config ONLY support ICA Proxy (XA/XD/CVAD integrations) and does not do any other VPN functions or clientless access.  So you can get access to any published XA/XD/CVAD desktop or app from any device running a Citrix Receiver/Workspace App, but no clientless web sites OR full vpn connections are supported.

 

For CVAD connections, you then lose support for EDT (DTLS) and connections will be SSL and TCP:2598/1494 only. 

 

Link to comment
Share on other sites

Thanks a lot for your prompt response.

In the double hop scenario we, of course, have two sets of ADCs, one acting as a GW for authentication and the other as ICA proxy, correct? So, each one is performing different functions. My query is why can't they act independently and have the second one residing in the 2nd DMZ collecting the ICA traffic and proxying it to the resources while the first one would authenticate on top of other things (integration with CEM or Intune for instance)? Most probably, I am missing some pieces of the puzzle in order to have the full picture and the limitations that double hop is bringing to the game.

Link to comment
Share on other sites

Let me clarify, yes for a double hop dmz you have 2 sets of ADCs.  For the Gateway (vpn vserver deployment specifically),  the front facing pair runs the vpn vserver on VIP1 with the authentication policies, session policies, sta configuration, it will then be configured with a next hop gateway which identifies the VIP of the vpn vserver on the back facing pair.  The back facing pair runs a vpn vserver on a VIP2. This VIP2 is only accessible from the SNIP on the front facing NS pair and will receive specific traffic from vpn1 already ssl to proxy to the actual destinations in the backend.  This vpn vserver has a VIP and CERT, but NO authentication policies, NO session policies, and NO STA list. It handles the traffic sent by the first vpn vserver.  IT's properties have authentication OFF (as it doesn't process this, the first ns does) but its has a setting Double Hop Gateway enabled. Which is what defines this as a double hop gateway (aka gateway proxy).  

 

More on the communication flow below.

 

So for the specific vpn vserver (VPN1) on the front facing NS, this vserver can only function in ICA Proxy mode and not do full vpn functionality.

 

However, you can deploy other vpn vserver or lb vservers on either NetScaler that function fully...it just depends on how you want to cross your firewalls at that point.

 

 

But what you describe where the "front gw does authentication" and the back one "does ICA Proxy" isn't what really happens in the Double Hop Gateway flow.  The purpose of the second gateway is to receive already SSL traffic from the front gateway and traverse the back firewall to actual destinations. BUT it is only handling some of the gateway transactions and not all of them. Meaning it doesn't work without the front gateway doing its part to.

 

If you think about regular ICA Proxy as consisting of the following communication phases (traditional/non double hop):

1) User Authentication/Resource enumeration:  which involves client to gateway, gateway to strorefront, and then storefront XML Broker communication

2) Resource Launch REQUEST phase (where the icon is clicked):  which involves client to gateway, gateway to storefront, and storefront to XML broker to figure out where to send you (and then storefront makes sta requests to generate ICA file)

3) ICA connection phase:  After the ICA file is handed off from storefront to gateway and returned to client, client connects to gateway SSL or DTLS, gateway redeems sta ticket, and then gateway redeems sta ticket, AND then gateway proxies traffic to the VDA destination (2598/1494 tcp or udp depending)

 

So when the double hop gateway is deployed, the communication is separated:

1).  User authentication/Resource Enumeration:  Client talks to VPN1 (front gateway). This NS IS THE ONLY ONE that talks to authentication services and forwards traffic to SToreFront. StoreFront talks to XML brokers and returns list to the front-facing NS to return list of resources to users.

 

2) User launch request (to get ICA file):  Request goes to VPN1 (front gateway).  This Gateway still is the only one who talks to STOREFRONT.  StoreFront then talks to xml brokers normally, retrieves vda destination, requests STA ticket from xml brokers and generates ICA file in gateway mode. REturns file to gateway and then gateway returns to client.

 

## At this point, the first 2 phases of communication have involved the VPN1 and storefront only. The second gateway has not participated yet (as it only handles sta redemption and the proxy to VDA destinations.)

 

3) ICA Connection Phase:  Client connects to VPN1.  VPN1 now forwards the client request to VPN2 as SSL traffic.  The second gateway VPN2 is then responsible for redeeming the STA ticket against the STA servers (XML brokers), because the first gateway tells it where to go.  Once it has this, it will then broker traffic to the VDA destination.

Communication during the ICA proxy phase is:  client to vpn1  SSL , vpn1(snip1 actually) to vpn2 SSL, vpn2(snip2 actually) to vda destination over TCP:2598 or 1494.

 

The double hop gateway only handles some of the traffic flow, while depending on vpn1 to handle all the gateway config and authentication/storefront communication.

Storefront will NEVER know about the double hop gateway and in fact the double hop deployment isn't "seen" in the storefront's understanding of the gateway integration.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Link to comment
Share on other sites

Correct - the VPN functionality doesn't allow a client to establish an ssl connection to vpn1 and then have vpn1 send ssl to vpn2 to then proxy to backend.

IT just wasn't designed for that, as the Double Hop Gateway functionality was a originally implemented to replace the same functionality present in our legacy Secure Gateway (ICA only) double hop configuration.

 

IT is a specific gateway communication flow that only supports the ICA Proxy communication and does not do the rest of the vpn functionality.  The second gateway isnt aware of a double-hop for vpn and would expect to see the start of a vpn tunnel connection and not be a continuation point.

Link to comment
Share on other sites

Second thought, the fact that you are doing CEM aka XenMobile, most client connections are a hybrid of Ica Proxy and micro VPN,so Double Hop Gateway is NOT supported for the CEM/XM functions either.  Didn't realize this was a EndpointManagement question or I would have noted that at the beginning...i just thought your were doing win mobile with receiver/workspace app, sorry for not asking about CEM sooner.

 

If you direct users to gateway + storefront with a Citrix Receiver/Workspace App without SecureHUB, then the double hop will work but the gateway can't do the vpn tunnels in this config.  I don't think using the MAM only communication without MDM will work via SecureHub in ica only mode, i think you would need the regular Receiver/Workspace app so mobile is just like traditional ica proxy.

 

You could use the second netscaler to load balance the authentication and storefront/mam traffic, so the first gateway communicates to destinations in the back DMZ instead of the internal network. But you would still need to resolves STA's and the final vda/vpn destinations from the front gateway, so it won't solve much for you.

 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...