Citrix Secure gateway SSL error 43

[ctxuser]

Citrix Secure gateway SSL error 43, we are having to reboot the CSG to allow user to connect. This is the error message that pops up after loggin on nfuse and clicking the published apps icon, all ica client are 8.00.
I've checked the citrix knowledge base, they came up with this solution alas, there is no such think in the registery and also the check box to protect Citrix Metaframe has been checked. Here is the citrix article link :

http://support.citrix.com/kb/entry!...tegoryID=118&entryID=2286&fromSearchPage=true

Is there an XP server, in my case the ica clients need to connect to backend 2000 server Citrix MF FR1 upgraded to FR2

Any ideas as to how to resolve this please, many thanks in advance.

 

[scanjam]

From memory this was an STA issue where the CSG wasnt communicating with the STA and getting an "invalid/unexpected response"

Do you get all green ticks when you run the CSG Diagnostics program on the CSG server?

 

[ctxuser]

I'm not entirely sure as to whether to run the Diagnostic tools on a live CSG or not, what effect this would have on the CSG live server. How can I re enact this error type on a Test CSG and STA server and then carry out the Diagnostic tool while on a Test ? Please help ...thanks very much in advance ....

 

[scanjam]

in my opinion, running this program will not drop connections or adversly affect the server in anyway.

it simply checks if the following are setup correctly.

1. Certificate for the

httpS://(servername).(domainname)

2. ability to contact the citrix Secure Ticket Authority (usually installed on a domain controller or internal citrix box)
3. ability to contact the web interface (usually installe don the CSG box)

I just tested my session to the CSG box while running the diagnostics check and didnt loose any connections, erverything still running A OK, but if you are still unsure then always best to try in test lab.

You can find the CSG Diagnostics tool usually (im assuming this is a Microsoft implementation of the CSG?)

"C:\Program Files\Citrix\Citrix Secure Gateway\CSGTest.exe"

hope this helps.
Cheers

James

 

[ctxuser]

Thanks very much James, For this specific information, I will try these steps on Test lab and replicate these on live CSG. Also re-assuring is the fact that your test on live CSG server affected no ica session.. I'll post my findings and resolution if any via this thread/forum. Thanks

 

[ctxuser]

Updates on my findings after running the Daignostic tool test on our live servers after verifying the run on our test lab...
1. Certificate for the

httpS://(servername).(domainname)

2. ability to contact the citrix Secure Ticket Authority (usually installed on a domain controller or internal citrix box)
3. ability to contact the web interface (usually installe don the CSG box)
all test came back " GREEN " ..what else could be the problem or a solution..After viewing the event log this is what I found ...

**The description for Event ID ( 3207 ) in Source ( CtxSecGwy ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: 180.180.0.173:2627, invalid-ticket, STA01**

Sometimes, you just have to forget your head and grab your balls ...!

 

[scanjam]

is it just this one user having issues? does it only happen from their one PC, or whatever the device or location the user uses?

IS the CSG behind a firewall (software or hardware?)

I know this isnt foolproof but can the computer you are connecting from telnet to port 443 on the CSG box?

I can telnet to 443 on ours from all sources so im assuming that you must or should be able too?? perhaps its worth a try.

;-\

 

[ctxuser]

Thanks very much scanjam for your effort in this matter, in order of questions: This affects two more user e.g.

**The description for Event ID ( 3207 ) in Source ( CtxSecGwy ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: 10.2.135.5:1183, invalid-ticket, STA01.**

Yes, it is behind a firewall, though I must stress that after running the Diagnostic tool on CSG, that all the lights were "GREEN"...No Telnet port has been enabled on the firewall, all other users are connecting alright with no problems..

My question here is what can we/one make of the event id..3207, what is it refering to ? ant ideas..many thanks in advance...


Sometimes, you just have to forget your head and grab your balls ...!

 

[ctxuser]

This problem just won't go away...

** The description for Event ID ( 3207 ) in Source ( CtxSecGwy ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: 180.180.248.23:4234, invalid-ticket, STA01.**

Any Ideas please...



Sometimes, you just have to forget your head and grab your balls ...!

 

[scanjam]

other things you might be able to try

install the STA on another machien in the domain, (even though all green ticks come up in the CSG diagnostics)

Install the version 8.0 client on the gateway server as well... (this "magically" fixed an issue we were having on the gateway server after someone changed the IIS settings)

i know they are long shots, but unfortunately im all out of ideas, my gateway server hasa number of tghe above error messages that you are referencing and its working fine, so i wouldnt worry about the 3207's...

 

[ctxuser]

Thanks very much scamjam, I'll practice all of the above hints on the test lab to verify the effects of all of these b4 approaching our live servers...I'll post my findings on this thread.

Sometimes, you just have to forget your head and grab your balls ...!

 

[KCDave03]

friend, you might want to take a look at the client side, this may be an issue with the Terminal Server licenses. Sometimes the MSLicense key on the client will need to be deleted for proper operation to be returned.

 

[ctxuser]

Hi KCDave03, Could you be a bit more specific please, where on the client side do you begin to look for MSlicense, how/where do you look for stored licenses on the client side. As for the server side our Terminal services 2000 has got permanent licenses. Are you saying that client locally store TS licenses for some period?, where do I remove if cached the stored license. Registry perhaps ? where ? please explain... Thanks very much in advance.

Sometimes, you just have to forget your head and grab your balls ...!

 

[KCDave03]

yes, that's what I'm saying. i have had several clients who have experienced connection problems because the local license could not be updated. i have success in reconnecting them by having them delete this key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing

you should try it, could be that's the problem you're seeing.

 

[ctxuser]

Updates on my findings regarding this problem..First I've ensured our live STA server time is syncronising with CSG time..I'm focusing on invalid/ticket hence why the connection was being dropped. You might want to have a look at the Citrix link as well. I'm holding on to this b4 I do anything drastic on our live servers...
CSG3207 Service received error [invalid-ticket] from STA or Authentication Service [STA01], Client IP [206.39.121.77:1157] connection dropped.

Do not interpret some “Ticket NOT found” messages as an attack.. The Win32 ICA Client may attempt to reconnect to a disconnected session if the user’s network connection is dropped momentarily. The Auto Client Reconnect feature does not work for Citrix Secure Gateway users because during each reconnection attempt, the client resubmits the used STA ticket with which it originally connected. The client usually attempts to reconnect three or more times before giving up, so you will see three or more “Ticket NOT found” messages referencing the same ticket in the STA log for each occurrence of this problem. Client reconnection attempts are characterized by the attempted reuse of a previously successful ticket:

So, simply disconnect users and ask them to reconnect as supposed to restart our server every now and again. I'll try this for a while if it works then fine otherwise I'll post this problem again in the future..

Regards..!

Sometimes, you just have to forget your head and grab your balls ...!