Michael Payne

We have 4 gateways setup on NetScalers in 2 datacenters(2 per datacenter an internal and external gateway so we can control auth differently. We are using an Active-Active glsb setup for the Gateways with a single url. With a Storefront setup in each datacenter, the session policies for the gateway point to the unique name of the storefront lb server in the DC that gateway that resides. For external users this works how we want as the workspace app cannot resolve the dns name for the storefront server. The issue we're internal connections (mostly users on a VDI running published apps on that VDI). Once the Workspace app connects to a storefront, no matter which gateway it connects to, it keeps that storefront. So if the storefront it is connected goes down it errors out and requires a reset of the workspace app to pick up the other one from the other gateway. Ideally I'd like the workspace app to work like the browser does and connect to which ever gateway they get through GSLB. We setup an internal store so we can control the settings of the internal store differently from the external one. We've set it up with a beacon that's not valid internally so it always thinks it is outside. We've changed the authentication setup to only allow pass through from the gateway, keeps it from SSO. The goal is to make it completely redundant so if a gateway and/or a storefront it'll require no intervention on anyone to keep working. Are we trying to do something that's not possible?

moved to the gateway forum

We have 4 gateways setup on NetScalers in 2 datacenters(2 per datacenter an internal and external gateway so we can control auth differently. We are using an Active-Active glsb setup for the Gateways with a single url. With a Storefront setup in each datacenter, the session policies for the gateway point to the unique name of the storefront lb server in the DC that gateway that resides. For external users this works how we want as the workspace app cannot resolve the dns name for the storefront server. The issue we're internal connections (mostly users on a VDI running published apps on that VDI). Once the Workspace app connects to a storefront, no matter which gateway it connects to, it keeps that storefront. So if the storefront it is connected goes down it errors out and requires a reset of the workspace app to pick up the other one from the other gateway. Ideally I'd like the workspace app to work like the browser does and connect to which ever gateway they get through GSLB. We setup an internal store so we can control the settings of the internal store differently from the external one. We've set it up with a beacon that's not valid internally so it always thinks it is outside. We've changed the authentication setup to only allow pass through from the gateway, keeps it from SSO. The goal is to make it completely redundant so if a gateway and/or a storefront it'll require no intervention on anyone to keep working. Are we trying to do something that's not possible?

Working with Citrix, they told us not to use ping.citrix.com as a beacon any more. Even though their own documentation and it's added by default in the Storefront installation.

We've been fighting this issue for a few days this week. Users connect via the Workspace app (2203cu5) to a Gateway. On reset the workspace app allows one auth pass (nfactor radius) but the app never enumerates the apps and fails with either "Cannot Complete your request" or "Your apps are not available at this time. If we just close the workspace app and reopen it will sit and spin until it times out. Looking the the receiver logs, we it attempt a beacon check and starts with decideing and eventually gets to the point where the log reports "Location for store 4191981706 is NONE" and Location for URL is NONE. We have an open case with Citrix on this but they've not been too helpful so far. We initially saw this issue on Monday, but it went away on it's own (chalked it up to lingering DST change) and worked the rest of the day on Monday, then we got hit with it again on Tuesday. Worked with Citrix who found a deprecated expression in our receiver session policy, which we removed and things started working at once. We felt confident that it was the issue. We went all day on Wednesday with no issues (we were watching the receiver logs all day) How yesterday(Thursday) it started again, worked all day with Citrix and they are analyzing logs and such but they seem to not have seen this before. Before Monday everything everything was working without issue on this gateway and has for months without any changes to this gateway or our basic setup. Browser works fine and has no issues, which is our workaround and while I want to just make that the only supported method of lauching Citrix resources that's a fight for another day. We have also discovered that its only affecting the Windows workspace app and Linux(on igel) workspace app. The workspace app on the Mac's is not affected. Internally this isn't affecting anything but then inside the network it goes through a gateway only to connect directly to the internal storefront server. Has anyone seen this before? Or have any ideas of next troubleshooting steps we can attempt, or some buried log that might have an crumb for us to follow?

Current setup is having users connecting via VPN(PaloAlto) to the internal Storefront servers. We now implementing new Storefront servers and gateways split tunneling that connection to the external gateway as is "best practice" or at least used to be. We're being asked for data to show that it's better that way than our current method. I have a bit of internal tester data but I haven't had a lot of luck finding anything conclusive. Does anyone have any sources showing the benefits of a pure Citrix connection to a gateway without vpn overhead?

Thanks I watched that, the on-prem ADM does not have that menu structure(no securityapi gateway menu), making me think it's only available to the ADM Service in the cloud but not for on-prem ADM instances. I just haven't been able to find any documentation that says that. Basically a requirements list, if it's not available it's an easy answer to the question posed to me.

@Akhil Nair​ Yes that's what I'm envisioning.

I've been tasked with determining if an API gateway on Netscaler/ADM would allow a cloud based webapp to send an API call to our on-prem environment that makes a query against an on-prem db. The additional complexity is that they want to have Azure(where the webapp will reside) to perform the authentication and pass the it's token on through a gateway and allow the api call/query to process.