Jump to content
Welcome to our new Citrix community!

Weird thing: STA servers down, reboot fixed it. FQDN-STAs wonky.


Hendrik Klinge

Recommended Posts

Hi everyone.

I just spent a few hours tackling a weird and annoying problem. And I'd be happy about your input.

 

 

I was on site with a customer on Friday to do some network related stuff.

 

Now on this Monday he called me: External XenDesktop access was not working anymore. Login was fine, application enumeration was fine, ICA-file download was fine, but session establishment failed with "Error 1110".

 

We found that the STA servers were DOWN in the NetScaler GUI. Well, if no STA, then no XenDesktop. Makes sense.

 

 

 

The STAs were entered like this:

https://ctx7cont01.example.local DOWN (Red light icon)

https://ctx7cont02.example.local DOWN (Red light icon)

 

But: When we entered them as IPs they were UP:

https://172.16.1.1 UP (Green light icon)

https://172.16.1.2 UP (Green light icon)

https://ctx7cont01.example.local DOWN (Red light icon)

https://ctx7cont02.example.local DOWN (Red light icon)

 

So I said: AHA! Must be a name resolution thing!

-> Nope. While indeed these names did NOT resolve on the NSCLI (but did on the BSDCLI), fixing that did NOT solve this.

 

What did solve this?!?

-> Reboot. 

-> Then things looked like this:

https://172.16.1.1 UP (Green light icon)

https://172.16.1.2 UP (Green light icon)

https://ctx7cont01.example.local UP (Green light icon)

https://ctx7cont02.example.local UP (Green light icon)

 

 

But NOW for the really weird thing:

We managed to reliably REPRODUCE a problem here:
Step 1: From the 4 entries I threw out the IPs. Then I threw out the cont01 FQDN and immediately readded it -> RED LIGHT! (Even after waiting several seconds.)
Step 2: THEN I added the IP for that controller -> Green light for the IP AND the FQDN. -> What?!?
Step 3: Then I was able the throw out that IP again -> Green light for FQDN remains.
 
Questions:
* Why is the FQDN entry DOWN after I first add it?
* Why does the FQDN entry come UP after I add a corresponding IP entry?
* Why does the FQDN entry STAY UP after I remove the corresponding IP entry?
 
Bonus questions:
* Why can we reproduce this now after reboot? Why did this NOT work before we rebooted? (Then the FQDN entry did not come UP ever.)
* How can I determine when the FQDN STA servers first changed to DOWN? nslog? nsconmsg?
 
 
Further details:
* Hardware appliances as HA pair.
* Firmware NS11.0 64.34.nc
 
 
Further reading:
There have been multiple entries STA status here on the forums. None with a satisfying answer.
* 2013-06-07, http://discussions.citrix.com/topic/331190-netscaler-gateway-virtual-srever-sta-down/ -> FQDN down, IP down. Reboot fixed it. Deeper reason unknown.
* 2016-03-15, http://discussions.citrix.com/topic/370955-ns-110-build-62-10-sta-fqdn-appears-down-bug/ -> FQDN down, IP up. Several replies. Unsolved.
* http://support.citrix.com/article/CTX132334/, Secure Ticket Authority (STA) Status is Marked DOWN for NetScaler Gateway Virtual Server -> did not completely work through that one.

 

 

 
 
Hope I'm making sense here. Looking forward to your replies,
Hendrik
 
Link to comment
Share on other sites

@Carl:

Thanks. I looked through the release notes but I only found one entry that seems to point in the general direction. And I don't think that's what's wrong in my case.

 

Is this the Bug you meant? -> Bug#560476:

 

Release Notes for Build 49.16 of NetScaler 11.1 Release.html:

The STA and nextHop VPN parameters can now be configured using FQDN instead of just the IP address.

The STA server is used for authorizing ICA connections and NextHop is used for specifying the second-hop in a "double-hop" Gateway deployment.

[From Build 47.14] [# 560476, 566511]

 

That's not the one for me.

 

The 11.1 man page says this:

man addvpnnextHopServer:

       nextHopIP
              IP address of the NetScaler Gateway proxy in the second DMZ.
 
       nextHopFQDN
              FQDN of the NetScaler Gateway proxy in the second DMZ. 

 

And this does not apply for us. Since we were using SINGLE hop. And we require FQDN because we use HTTPS to access the STA. (And inside the cert, I think, we only have the FQDN and not the IP.)

Link to comment
Share on other sites

  • 1 year later...
  • 2 years later...

I know this is an old post, but it is one of the first ones that came up, so I will add my comment hear.  I am running 12.1.57.18 and noticed that I can add an STA as fqdn initially but later it goes down.  After testing I was able to see that it was going down following an HA failover.  The communication would use TLS1.2 when working, after 1 or 2 failovers I could see the client hello from the NS using ssl3 even though ssl3 is disabled on all ssl vservers on the NS.  I am also using 2 Gateways, one for HDX/Authentication and one for just HDX to eliminate the second pin prompt for smart card authentication.  Once the STA's go down, they have to be removed from both GW's before they can be added back using fqdn.  I have an open case and asked them to escalate it as a bug.

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