Disconnects from Secure Gateway, Logging on the wrong server

Running Citrix Secure Gateway, 3.3.4, Web Interface 5.4.2.59 and XenApp 6.5.  We have 11 different servers running CSG/WI that point to the same XenApp 6.5 farm.

We recently updated 2 of our Citrix Secure Gateway's to 3.3.4.  There have been a few different issues.  We have noticed an increase of the following in our logs which has impacted the user experience.

(OS 10054)An existing connection was forcibly closed by the remote host.  : core_output_filter: writing data to the network

SSL handshake from client failed

Service received error invalid-ticket from STA STATICKET, client IP IP.x.x.x connection dropped.
An error occurred when processing incoming CGP downstream data
[info] CGP forwarding session stopped: client IP [IP.x.x.x:8471], username [user@domain], destination server [IP.x.x.x:2598], resource [Application].
[info] Request STA STATICKET to resolve ticket for client IP IP.x.x.x.
[warn] Service received error invalid-ticket from STA STATICKET, client IP IP.x.x.x connection dropped.
An error occurred when processing incoming CGP downstream data
(70007)The timeout specified has expired: apr_pollset_poll Fail: timed out.
[warn] SSL handshake from client failed
(70007)The timeout specified has expired: apr_pollset_poll Fail: timed out.


We have ensured that the IP's are the same.  We are allowing TLS 1.0, TLS 1.1 and TLS 1.2 in the Secure Gateway.  We previously had this set to TLS 1.0 prior to the CSG 3.3.4 patch.

We have also seen that after updating one of the CSG's and ensuring Windows Patch levels are up to date, Reg Settings are indeed allowing TLS 1.0, 1.1 and 1.2 at the server level, that if we try to actually go to the IP to test, ie.   https://10.x.x.x/Citrix/XenApp/.. It Will bring up the page, let you login and execute apps.  The Access logs on A where we're testing show up in the Access Logs.  But the Error logs on A don't show any traffic from this direct attempt. These connections are logged on the B server.

We have our CSG's behind a F5 Load Balancer.  We have node A disabled and not online in the pool.  Isn't making sense why this is getting logged on the wrong server in the 'error' log.

Any insight to this issues that seemed to start after the update to 3.3.4 is appreciated.

Thanks
jnordengAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Dirk KotteSECommented:
seems your F5 sent the session to the wrong server.
possible it don't recognize the citrix session or you use new IP's for the STA.
0
jnordengAuthor Commented:
Thanks for your quick response.  If the node is disabled, the F5 shouldn't send traffic to it and the confusing part is the Access log on A where the user should be shows that application for the user.  I have verified we are using the same IP's as we were previously.

Any ideas for the disconnects, internal errors and general problems with CSG?  

Thanks
0
OyeComoVaCommented:
I would ask if the CSG diagnostics all check out and you have in fact restricted the TLS protocols to include TLS 1.0, 1.1 & 1.2? Also, does your cert check out (not expired) etc.? If so you should make sure that that your XenApp servers are configured for these protocols i.e. "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols".

Another important aspect of a proper TLS connection would be on the client side. Is their IE settings in order? There are settings in IE which aid in the connection process, protocols in the Advanced Tab is one of them, You should build a recommended settings sheet for your users. They will also require a proper CA in their workstation setup and to make things smoother for them, have them add your WI site to their trusted Sites.

As far as CSG errors are concerned, we routinely recognize false positives which are generated by our scanning and monitoring software.

hope this helps.

Dave
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
jnordengAuthor Commented:
Thank you for your feedback.  It is appreciate and helpful to understand what could be contributing to the problem.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Citrix

From novice to tech pro — start learning today.