How would you solve the following: Internal users should connect through a GW, Single Factor => portal.domainA.com External users should connect through a GW on the same NetScaler, 2FA => portal.domainB.com No connections without a GW. Internal users can access external Address portal.domainA.com only via Proxy. I tried to solve this with a listen policy (Authentification is fine, however internal users have to do ICA over proxy, which is not nice) When using two seperate vServers and IPs I struggle with the storefront configuration for CWA.

That means no Storefront connections are allowed? Everything is getting routed via GW?

I just have internal DNS to point to 1 Gateway Virtual Server, and have external dns point to a different Gateway Virtual server.

@Jeff Riechers in this case the external dns domain should not be handled by internal dns. So i cannot point the internal requests to the 2nd vserver....

You can on your nFactor policy expression set a condition based on your client.ip.src.in_subnet (or any other condition) to use a different flow if true. I did that.

Why are you using different domain names for floating users? Why not use the same DNS domain name? You could create a stub zone DNS for the external domain name internally that points the gateway to the internal site, and everything else on that domain would get forwarded to the external DNS servers.

@Jeff Riechers dns is not in my hand, there is a security policy that no split-dns is allowed. @jvitech this would in my case result that all internal users access the vserver via proxy.. as they cant reach the public vserver directly

I would also do split DNS here for a smooth CWA. After you use the browser to start your app, prob solve :)

"I tried to solve this with a listen policy (Authentification is fine, however internal users have to do ICA over proxy, which is not nice)" ... so you would like to authenticate with gateway and then allow direct connections from client to VDA, bypassing the gateway?

This is literally what nFactor was built for. Use a policy to determine inside or outside and control the logins through a AAA vserver then pass the authenticated user over to gateway.

Do you want to force internal users via gateway for auth reasons or just traffic routing reasons? We have setups where internal users connect/auth at StoreFront but traffic is sent via gateway for firewall and routing reasons https://docs.citrix.com/en-us/storefront/current-release/configure-manage-stores/optimal-hdx-routing.html

@Richard Faulkner not in my case. When using nFactor, internal and external users have to connect initially to the same GW vserver. Also ICA traffic is routed through this vserver. Internal users cant reach (or reach only through proxy) the external gw. So this i not practicable.

@Marco Zimmermann nFactor is for authentication, not gateway. I can put a AAA vserver in front of any resource that is front-end on a NetScaler. Even one that does not have it’s own authentication method. Create the AAA vserver, bind it to an authentication profile, and bind the authentication profile to any lb or cs vserver. Portal.domaina.com can be an lb or Cs vserver.

@Richard Faulkner and this will work with native CWA connection? Diving into @Daniel Marsh s solution: Here is the benefit (if I get that right) that by SF config only ONE (the external) gateway is assigned via configuration. The internal gateway is used by modifiying SF config and is not ticked at "remote access". So for an external CWA, beacons decide if the internal service could be reached, if not, the external GW is used. For an internal user Authentification is on SF-level, redirecting the ica traffic to the internal GW. Thats exactly what I need. Will test this now..

I just went through this with customer testing. If you connect to storefront internal and use a DIFFERENT url for the gateway, it will autodetect and switch. However, if you use the same address for Gateway and Storefront you get cached auth and connection issues. For customers I have had to search for certain wake from sleep events in the event log and run a process to close out all the Citrix Workspace instances and relaunch them to force a new re-auth.

Still struggeling with this. I added the internal GW with "external only" unchecked. Connecting to SF and launch an application routes the traffic through internal GW. perfect. However when I now connect to the external GW with a browser (session profile to the same SF server and Store) SF also writes the internal GW into the ICA file. My dirty solution is now to replace the internal GW with a rewrite policy on the external NetScaler. This seems to work fine (but is maybe unsupported)..

Marco you should be able to have StoreFront differentiate the gateways by adding the VIP of each NS Gateway to the Gateway config in StoreFront, even if they are launching via the same URL. You may need to setup dedicated callback URLs for each depending on if callback is needed for your auth scenario