Jump to content
Welcome to our new Citrix community!

GSLBURL Bug?


Gregor Blaj

Recommended Posts

Hi,

 

I haven't seen anything about the below issue being fixed in newer StoreFront releases, but it seems like a bug to me.

 

1. Set the GSLBURL for a NetScaler Gateway definition in StoreFront and propagate the changes.

2. Connections from the Gateway, to the original URL (citrix.company.com) and the GSLB URL (site1.company.com), start failing ('Cannot complete your request').

3. Remove the GSLBURL for the NetScaler Gateway definition.

4. Connections still failing with the same error.

5. Restart services, reset IIS, reboot servers etc... Error still present.

6. Re-create the NetScaler Gateway definition in StoreFront, propagate the changes.

7. Starts working again.

 

I'm not sure why the GSLBURL specified (site1.company.com) didn't work, or what persisted once I reverted the setting, but I'm including the relevant logs below. Has anyone come across this before?

 

  • StoreFront: 1811
  • NetScaler: 12.0 60.10
  • CallBack URL: Blank
  • vServer IP: Blank
  • SSO Domain (Session Profile): Set to domain NETBIOS name.
  • Trusted Domains in SF: Configured, including the above.
  • Other gateways specified in StoreFront: Working the whole time as usual.

 

Error 1:

Quote

 

The AG Web Service at: http://localhost/ failed with the following error. This endpoint will be ignored until: 16/09/2019 10:41:15 a.m.
Citrix.DeliveryServices.Authentication.CitrixAGBasic.Exceptions.AGCommunicationException, Citrix.DeliveryServices.Authentication.CitrixAGBasic, Version=3.17.0.0, Culture=neutral, PublicKeyToken=null
A communication error occurred while attempting to contact the NetScaler Gateway authentication service at http://localhost/. Check that the authentication service is running.
   at Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.AGClient.GetAccessInfo(String sessionId, String username, String domain)
   at Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.CitrixAGBasicWebService.GetAccessInfo(String sessionId, String username, String domain)

System.Net.WebException, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
The request failed with the error message:
--
<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found <a HREF="http://localhost/Citrix/centralWeb/">here</a></body>
--.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at Citrix.DeliveryServices.Authentication.CitrixAGBasic.AGAuthService.AuthenticationServiceSoap.GetAccessInformation(String sessionId, String username, String domain)
   at Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.AGClient.GetAccessInfo(String sessionId, String username, String domain)

 

 

Error 2:

Quote

None of the AG callback services responded

 

Error 3:

Quote

 

A CitrixAGBasic Login request has failed.
Citrix.DeliveryServicesClients.Authentication.AG.AGAuthenticatorException, Citrix.DeliveryServicesClients.Authentication, Version=3.17.0.0, Culture=neutral, PublicKeyToken=null
Authenticate encountered an exception.
   at Citrix.DeliveryServicesClients.Authentication.AG.AGAuthenticator.Authenticate(HttpRequestBase clientRequest, Boolean& passwordSupplied)
   at Citrix.Web.AuthControllers.Controllers.GatewayAuthController.Login()

System.Net.WebException, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
The remote server returned an error: (403) Forbidden.
Url: https://127.0.0.1/Citrix/centralAuth/CitrixAGBasic/Authenticate
ExceptionStatus: ProtocolError
ResponseStatus: Forbidden
   at System.Net.HttpWebRequest.GetResponse()
   at Citrix.DeliveryServicesClients.Utilities.HttpHelpers.ReceiveResponse(HttpWebRequest req)
   at Citrix.DeliveryServicesClients.Authentication.TokenIssuingClient.RequestToken(String url, RequestToken requestToken, String primaryToken, String languages, CookieContainer cookieContainer, IEnumerable`1 acceptedResponseTypes, IDictionary`2 additionalHeaders)
   at Citrix.DeliveryServicesClients.Authentication.AG.AGAuthenticator.Authenticate(HttpRequestBase clientRequest, Boolean& passwordSupplied)

 

 

Cheers.

Link to comment
Share on other sites

3 hours ago, Vamsi Krishna Kanduri said:

It looks like SSO to the storefront is failing.

Please paste the configuration of session profile.

 

Thanks,

Vamsi

 

Hi Vamsi,

 

Session Profile config below. I'm not sure why this would be related to the ADC config, if the only changes made are adding an additional URL to StoreFront?

add vpn sessionAction ICA-SF-WI -defaultAuthorizationAction ALLOW -SSO ON -icaProxy ON -wihome "https://storefront.domain.com/Citrix/centralWeb" -ntDomain CONTOSO

Cheers.

Link to comment
Share on other sites

  • 4 weeks later...

Hi Warnox

 

It sounds like you are experiencing a known issue we have discovered and now fixed in current releases of STF.  Luckily there is a very simple workaround in the affected versions from 3.9 upwards to the fix release using the Storefront admin console.  

After having set the Gateway and GSLB URLs via Powershell on your gateway objects then simply unregister the GSLB gateways and then re-register them all to the Stores they are bound to.  Alternatively upgrade to a higher release than 1811 as I believe we fixed this in 1903 or higher.  Moving to the latest release will definitely contain the bug fix.

See the attached screen shot of Configure Remote Access Settings.

Please follow all recommendations in this doc I wrote when configuring GSLB within StoreFront.  Pay particular attention to the concept of unique callback URLs per gateway and please also set the VIP for each GSLB gateway as this is needed to help StoreFront identify the gateways if they all have the same URL.

https://docs.citrix.com/en-us/storefront/current-release/integrate-with-citrix-gateway-and-citrix-adc/configure-two-gateway-urls.html

If you have any problems using the feature please contact me and I will assist you further.

Regards Mark

Remote Access Settings.jpg

Link to comment
Share on other sites

7 hours ago, Mark Dear said:

Hi Warnox

 

It sounds like you are experiencing a known issue we have discovered and now fixed in current releases of STF.  Luckily there is a very simple workaround in the affected versions from 3.9 upwards to the fix release using the Storefront admin console.  

After having set the Gateway and GSLB URLs via Powershell on your gateway objects then simply unregister the GSLB gateways and then re-register them all to the Stores they are bound to.  Alternatively upgrade to a higher release than 1811 as I believe we fixed this in 1903 or higher.  Moving to the latest release will definitely contain the bug fix.

See the attached screen shot of Configure Remote Access Settings.

Please follow all recommendations in this doc I wrote when configuring GSLB within StoreFront.  Pay particular attention to the concept of unique callback URLs per gateway and please also set the VIP for each GSLB gateway as this is needed to help StoreFront identify the gateways if they all have the same URL.

https://docs.citrix.com/en-us/storefront/current-release/integrate-with-citrix-gateway-and-citrix-adc/configure-two-gateway-urls.html

If you have any problems using the feature please contact me and I will assist you further.

Regards Mark

Remote Access Settings.jpg

 

Hi Mark,

 

Thanks for your reply.

 

I actually set this up in a vanilla lab over the weekend and was able to replicate the issue with even just a single gateway. This was both in 1811 and 1909, so I don't think the bug is resolved in the latest release?

 

Please note that in my setup a callback URL is not required, but I managed to get around the bug with the following steps.

 

1. Only a single gateway with a gateway URL configured on Netscaler definition in Storefront (GLSB URL, CallBack URL and vServer IP not configured). Everything working.
2. Set GSLB URL, Gateway connections stop working (Cannot Complete Request).
3. Set Callback URL, Gateway connections working again.
4. Remove Callback URL, everything still working.

Link to comment
Share on other sites

  • 4 months later...

Hi Warnox


Using DNS round robin to simulate GSLB while testing StoreFront.  This does not simulate or substitute for a real GSLB setup as Receiver for Web is a persistence web app and all HTTP requests for an individual web session should be directed to the same server not randomly distributed between 2 Gateways or 2 StoreFronts.  Please do not rely on this method to perform any kind of testing of GSLB gateways with StoreFront as it will cause issues with Receiver for Web.

I also understand that you can reproduce this issue with just a single gateway setup.  That matches what we already know about the issue and a fix was added back in 1906 which was intended to resolve this.  Given your reports and the fact the case is still open this does not seem to be the case.

Apologies that the expected fix is not working from 1906 onwards.  I have a developer and an escalation engineer (you are already working with him) looking into this case.

Here is the min steps needed to reproduce this issue and also to work around it
Create a gateway object via the console OR Powershell without a GSLB URL set.  
Set the GSLB URL via Powershell
Issue starts to occur after this....
Unregister the GSLB gateways and then re-register them all to the Stores they are bound to.
OR
Update the gateway object within StoreFront using the console by changing or adding any of the following....
Set the callback, set the VIP

These operations update the gateway model in StoreFront using the console and solve the issue.  Cannot complete request should no longer occur after this.

To clarify what Gateway config should be used within StoreFront when GSLB is used....

  • Callback URL is optional except when Smart Access is needed.  Then it MUST be used.
  • If Callback URL is to be used it MUST be unique per geo and GSLB gateway and should resolve to the correct VIP.
  • If using a real GSLB setup (not faked....) where multiple gateway objects share the same URL then you MUST set the VIP on each gateway.  Using the unique URL to access the gateway may well work without the VIP but when using the GSLB URL (shared by all gateways in the GSLB layer) then it is essential.
  • How can StoreFront determine which gateway the request came from using a URL shared by multiple gateways without the VIP set?  VIPs are unique per gateway object and StoreFront falls back to using it if the URL is in use by multiple gateway. 

This is why I recommended the VIP be set on the call we had.

Regards Mark

Link to comment
Share on other sites

  • 3 weeks later...

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