Jump to content
Welcome to our new Citrix community!

Netscaler 12 double-hop configuration


Sean Ritter

Recommended Posts

I've found a few articles on this subject such as:  https://docs.citrix.com/en-us/netscaler-gateway/12/double-hop-dmz/ng-double-dmz-install-con.html but they aren't very detailed.

 

I have a fully functioning Netscaler gateway in our internal DMZ with a XenApp 7.15 environment.  All is working well.

 

I have now been tasked with adding another Netscaler in the external DMZ to send the traffic to the internal Netscaler.  Port 443 only.

 

The external Netscaler is up and running.  Next I need to configure the VIP and configure it to pass 443 traffic to the internal Netscaler.

Link to comment
Share on other sites

The NetScaler Gateway guide also has a section specifically on double-hop dmz deployments (though it references WI instead of storefront), same config.

https://docs.citrix.com/en-us/netscaler-gateway/12/double-hop-dmz.html

 

NSGateway1 in the public facing DMZ is configured almost identically as the regular config, but you configure the NSGateway2 vpn vserver VIP (aka the gateway proxy) as the next hop server.  Additionally, under the vpn vserver settings (top node, then more), double-hop is OFF and authentication is ON.  All sta, session policies, authentication policies are bound to the front (external facing netscaler).  The NSG1 handles all authentication, communication to storefront and sends ICA proxy traffic over SSL to the vpn vserver on NSG2.

 

NSGateway2 in the second dmz (internal-facing) will have a vpn vserver in gateway proxy mode, which means it is set so that the authentication setting is OFF (under vpn vserver properties at the top) and its double-hop setting is ON.  This one will make the actual STA communications to the STA destinations and proxy the connections to the VDA's.  It has no authentication or session policies configured on it (instead that is handled by the first gateway) and no sta list (also on the first gateway).

 

The admin guide section above will show you where the Double-Hop, Authentication properties are in the GUI and where to configure the next-hop server destination.

 

From StoreFront's perspective, it only needs to know the gateway FQDN of the vpn vserver on NSG1 (external facing) and the callback address would map to this gateway's FQDN or to a backend IP on the NSG1 netscaler.  StoreFront won't ever receive communication from the gateway proxy on NSG2.

Link to comment
Share on other sites

16 hours ago, Rhonda Rowland1709152125 said:

 

From StoreFront's perspective, it only needs to know the gateway FQDN of the vpn vserver on NSG1 (external facing) and the callback address would map to this gateway's FQDN or to a backend IP on the NSG1 netscaler.  StoreFront won't ever receive communication from the gateway proxy on NSG2.

 

Thank you for the very helpful reply!  This is where I am concerned.  The only firewall rule that was allowed to be implemented was 443 from the VIP on NSG1 to the VIP on NSG2.  Will it still work as you described?

Link to comment
Share on other sites

  • 5 weeks later...

Thanks, I believe everything is set correctly now.  However after logging into NSG1, I am receiving "Http/1.1 Internal Server Error 43531".  I checked name resolution and the storefront and STA can be resolved.  The STA is showing down.  I also read where sometimes replacing the hostnames with IPs in the session policies helps, that didn't work in this case.  I am also using a self-signed test certificate on NSG1 for testing at the moment.  I am not sure if that may be causing this.

Link to comment
Share on other sites

This would be easier to troubleshoot if you could summarize the config and all details as there are a lot of moving parts on the double hop dmz. I'll try to upload a reference diagram later.  

 

For troubleshooting, beyond the checklist below. You may need to check syslog on both netscalers for errors, the event viewer on Storefront, and probably run a nstrace to really know for sure.  

When the error occurs, are you still seeing the /vpn/index.htm or are you seeing /citrix/<storenameweb> in the URL. That may help you see if you are getting from gateway to storefront or not.

 

I'll refer to ns1 or vpn1 as the public facing ns/gateway and ns2/vpn2 as the second hop gateway.

Config summary (checklist style, to maybe help see what is wrong.)

ON NS1 (VPN1):

  1. VPN1 should have the cert with the FQDN. 
  2. The vpn vserver properties on VPN1 should be authentication:ON, doublehop:OFF
  3. Double check that your session policy(ies) are properly configured for ICA Proxy and storefront integration.  (Double check the storefron path in use and that it is the appropriate web path for your store.)
  4. Double check that your STA's are listed individually
  5. Verify that this NetScaler sees VPN2 (vpn vip) as the Next Hop NetScaler
  6. Make sure this NetScaler can perform your authentication and group extraction. 
  7. This is also the one that will talk to StoreFront.  This is the NetScaler vpn vserver and SNIP/VIP that storefront will need to "see" as the NS Gateway FQDN.
  8. Confirm this NetScaler can resolve storefront, sta, and vda FQDNs to IP adresses as it may also need to be configured with the DNS IP to use for resolutions (like the domain controller).

ON NS2 (VPN2)

  1. This VPN vserver still needs a cert bound (i think)
  2. The vpn vserver properties for this one should be authentication: OFF, doublehop:ON.
  3. No authentication policies are bound.
  4. No Session policies are bound.
  5. No STA list is configured (though it is my understanding that this is the one that will proxy the sta communication on behalf of vpn1 - verify)
    Therefore if you are using STA's by name, this one will also need to resolve names to IPs, so test it for name resolution an possibly ensure it also has a DNS server IP to use for resolutions.
  6. After configuring the Second Hop Gateway, if the STAs still show as down, add a route on the Second Hop appliance (NS2) to the SNIP of the First Hop, to ensure both SNIP (First Hop) and Gateway VIP (Second Hop) can reach one another.

On StoreFront:

  1. From StoreFront, it will need the Gateway FQDN for vpn1.  The SNIP or VIP for traffic coming from NS1. And its list of STA's.
  2. Beacons may also need to be adjusted if source SNIP is not identified.
  3. View of communication flow from StoreFront perspective:  https://support.citrix.com/article/CTX222591
  4. Regular storefront's gateway config validations apply and may include: passthrough from gateway, remote access integration, gateway/sta list is correct (as noted in step 1)

Communication Issues could be network/firewall/acl related or could still be a misconfiguration.

 

From a networking standpoint, the NS1 will need to reach the authentication destinations via the eternal firewall from either its NSIP (HA pair) or SNIP, depending on if you are load balancing LDAP or not.  NS1 SNIP will need to be able to reach StoreFront(s) over SSL:443.  NS1 SNIP will need to reach the vpn2 vip via SSL:443.

 

On NS2, it should be able to send/receiver between its vpn vip and the SNIP of the NS1 (SSL:443).  Its backend SNIP should reach the STA's over HTTP:80 or HTTPS:443.  And it will need to reach all VDA's over 2598 (TCP)/(UDP) or 1494 (TCP)/(UDP). Assuming the TCP flow is working, you can then figure out if any tweaks are needed for DTLS/UDP handling.

 

Anyway, you may have to run traces on both NetScalers to see where in the process you are failing to being identifying the config or network issue that is the problem.

 

 

 

 

 

Link to comment
Share on other sites

  • 2 years later...
On 6/15/2018 at 5:36 PM, Rhonda Rowland1709152125 said:

No STA list is configured (though it is my understanding that this is the one that will proxy the sta communication on behalf of vpn1 - verify)

  

On 6/15/2018 at 5:36 PM, Rhonda Rowland1709152125 said:

o STA list is configured (though it is my understanding that this is the one that will proxy the sta communication on behalf of vpn1 - verify)

 

 

Hi Rhonda Rowland

 

I'm in doubt in step 5 - on the second netscaler (internal facing):

- seams like that this documentation says that STAs must be set on the first NetScaler (internet facing)  - https://docs.citrix.com/en-us/citrix-gateway/12-1/double-hop-dmz/ng-double-dmz-install-con/ng-double-dmz-install-sta-traffic-tsk.html

 

- seams like that this documentation says that STA's communications are proxyed thought to the second NS (STAs are set on public facing NS and proxyid by the internal facing NS until the STA Server) - https://docs.citrix.com/en-us/citrix-gateway/12-1/double-hop-dmz/ng-double-dmz-install-con/ng-double-dmz-install-open-ports-tsk.html

 

- In this documentation, Citrix says that the internal facing NS doesn't have the STA configured (in the Section "Starting Process" - step 6 (because the second hop does not have any STA configuration) - https://support.citrix.com/article/CTX201290.

 

I tried to set STA's on both NetScalers but the communication is ever started by the internet facing NS's SNIP to STA Server (I could check this on tcpdump).

I tried to set STA only in the internal facing NetScaler, but the user receives the STA error during application launch.

My impression is that the STA connection doesn't run in proxy mode but is ever started directed from the internet facing NetScaler to the STA Server.

 

I think the alternative to respect the communication flow between DMZ would be create a reverse proxy for each one STA server on the Second DMZ (aka External_DMZ > Internal_DMZ > LAN connection flow).

 

Any ideas on that?

 

Thank you.

 

Link to comment
Share on other sites

7 minutes ago, Alessandro Miotto Marques1709152314 said:

I'm in doubt in step 5 - on the second netscaler (internal facing):

- seams like that this documentation says that STAs must be set on the first NetScaler (internet facing)  - https://docs.citrix.com/en-us/citrix-gateway/12-1/double-hop-dmz/ng-double-dmz-install-con/ng-double-dmz-install-sta-traffic-tsk.html

 

I'm misunderstanding your misunderstanding.  And its been a while since this was originally drafted, so I may have forgottent the context.  But your statement seems to say exactly what I said.  Feel free to clarify.  [edit] I re-read your post and realized you weren't the original poster in the thread and two figured out what you were asking. (sorry).  Basically, the question is whether the external VPN does the SNIP1 to STA's communication itself or internal VPN (SNIP2) does the STA communication.  I was under the impression of the latter.  But would have to run a trace to confirm. (Previously though this was the expected communication.)  [/edit]

 

Vpn1 (external facing) is the ONLY one with the configured STA list. In fact VPN1, is configured identically to a NON-double-hop config and has all authentication policies, session policies, authorization policies, and sta lists. AND it has the next-hop destination which points to the vpn vserver 2 on the vpn2 system (internal facing).

 

VPN2 is configured in double-hop mode and has no info on session policies, authentication policies, or STA lists.  (Also, STA's cannot be load balanced.)

 

When the STA request from client is sent to VPN 1, VPN 1 forwards the STA info (via SSL) to vpn2 and vpn2 then handles redemption from the specific sta servers.

VPN1 snip to vpn2 vpn vip is SSL.  VPN2 snip to STA destinations is whatever your STA protocol is set as.

 

VPN2 does the work, but VPN1 has the config.  This is confirmed from a trace.  The VPN2 (double hop gateway) proxies the STA and all ICA communication from VPN1 to the internal network.  And ONLY this communication.

 

 

Edited by Rhonda Rowland
clarified
Link to comment
Share on other sites

2 hours ago, Rhonda Rowland1709152125 said:

 

I'm misunderstanding your misunderstanding.  And its been a while since this was originally drafted, so I may have forgottent the context.  But your statement seems to say exactly what I said.  Feel free to clarify.

 

Vpn1 (external facing) is the ONLY one with the configured STA list. In fact VPN1, is configured identically to a NON-double-hop config and has all authentication policies, session policies, authorization policies, and sta lists. AND it has the next-hop destination which points to the vpn vserver 2 on the vpn2 system (internal facing).

 

VPN2 is configured in double-hop mode and has no info on session policies, authentication policies, or STA lists.  (Also, STA's cannot be load balanced.)

 

When the STA request from client is sent to VPN 1, VPN 1 forwards the STA info (via SSL) to vpn2 and vpn2 then handles redemption from the specific sta servers.

VPN1 snip to vpn2 vpn vip is SSL.  VPN2 snip to STA destinations is whatever your STA protocol is set as.

 

VPN2 does the work, but VPN1 has the config.  This is confirmed from a trace.  The VPN2 (double hop gateway) proxies the STA and all ICA communication from VPN1 to the internal network.  And ONLY this communication.

 

 

 

LOL sorry if I wasn't clear.

 

I think I'm seeing monitoring traffic from Vpn1 to STA.

 

Thanks for your reply.

 

Alessandro Marques.

Link to comment
Share on other sites

I don't think it was you (or at least not solely); i think I was rushing to answer on my break and just did not connect the dots of the original question until I re-read it.

 

I'm going to try to mock up a flow tonight with the trace to confirm whichever behavior is happening.  I don't have the lab with the actual double hop network in place, but should be able to confirm the trace. And if I'm wrong, will update you.

 

There were a few comments you made regarding settings that can't be combined, like the STA is still only ever specified on the front gateway.

 

The thing is if you are doing the trace, do you have the external vpn set with a "next hop" destination AND the internal vpn set with "double hop gateway" mode.  If not, you may not be doing double hop at all.

 

 

Link to comment
Share on other sites

12 hours ago, Rhonda Rowland1709152125 said:

I don't think it was you (or at least not solely); i think I was rushing to answer on my break and just did not connect the dots of the original question until I re-read it.

 

I'm going to try to mock up a flow tonight with the trace to confirm whichever behavior is happening.  I don't have the lab with the actual double hop network in place, but should be able to confirm the trace. And if I'm wrong, will update you.

 

There were a few comments you made regarding settings that can't be combined, like the STA is still only ever specified on the front gateway.

 

The thing is if you are doing the trace, do you have the external vpn set with a "next hop" destination AND the internal vpn set with "double hop gateway" mode.  If not, you may not be doing double hop at all.

 

 

Rhonda Rowland ,

 

I checked the trace and I could see that this traffic I was seeing (NetScaler > STA) wasn't regarding the NetScaler double-hop and nor about the STA monitoring traffic.

 

The traffic was about the Storefront callback url. In my lab configuration - Storefront/Controller/STA is installed in the same server.

 

Just to clarify - all connections (STA and ICA) is being proxied by the NetScaler hop configuration.

 

Thank you so much for your help!

 

Alessandro Marques.

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...