Secure Gateway issue

Question

I have an issue with connecting through the Secure Gateway. The following error occurs when accesing the environment using the Secure Gateway - The environment runs 2 Secure Gateway servers (load balanced using Fortigate) - The Secure Gateway servers are configured to run both Connection Broker and RDP using the same IP adress - Its configured to use a wild card ssl certificate I can succesfully use pntsc (from the outside) and retreive the assgined desktop (over the Secure Gateway). The client is configured like below (same FQDN is used that matched the wildcard cert) The proxy for Connection Broker and Proxy for RDP traffic use the same IP and port, which is accesible from the outside since I can succesfully conect the broker through the Secure Gateway, what could be the issue with the RDP proxy part? Specifc settings for Fortigate? The log of the RD Gateway shows the following at the time the error: 10:56:19 - 2924 : 2772 - [972]Security Context OK 10:56:19 - 2924 : 2772 - [972]SSL negotiation ok 10:56:19 - 2924 : 2772 - [972]Extra data after SSL negotiation 10:56:19 - 2924 : 2772 - [972]Read data, 569 bytes 10:56:19 - 2924 : 2772 - ticket-full client, broker auth required = true 10:56:19 - 2924 : 2772 - [972]CProxyThread::validateTicket: ticket timeout=300, connect window=15 10:56:19 - 2924 : 2772 - [972]CProxyThread::validateTicket: CTicketCache::handleConnectMsg returned 3 10:56:19 - 2924 : 2772 - [972]CProxyThread::validateTicket: Ticket not found in cache, validating ticket with broker... 10:56:19 - 2924 : 2772 - [972]CProxyThread::validateTicket: Successfully validated ticket 10:56:19 - 2924 : 2772 - [972]CProxyThread::validateTicket: After validating, call to addTicketAfterValidateIf returned 4 10:56:19 - 2924 : 2772 - [972]CProxyThread::validateTicket: Ticket added, connection was not owned or current thread added to owners after validating 10:56:19 - 2924 : 2772 - [816]CProxyThread::ConnectToServer: Disabling nagle algorithm 10:56:19 - 2924 : 2772 - ***[972,816]Thread Handle 00000478, Id 00000ad4 10:56:19 - 2924 : 2772 - [972,816]Start: 1/8/2014 9:56:19.112 10:56:19 - 2924 : 2772 - [972,816]From NL, XXXX, XXXXXXXXX, XXX, XXXX XX, XXXX, XXXX, Wildcard SSL, *.XXX.nl@10.38.78.75, to 10.3.72.32:3389 10:56:29 - 2924 : 2772 - [972,816]Server Recv 0 10:56:29 - 2924 : 2772 - [972]CTicketCache::handleProxyEnd returned 10 10:56:29 - 2924 : 2772 - [972,816]proxy done from client 0 bytes, from server 0 bytes 10:56:29 - 2924 : 2772 - [972]SSL Server Channel cleanup 10:56:29 - 2924 : 2772 - [972]37 bytes of handshake data sent 10:56:29 - 2924 : 2772 - [972]0000  15 03 01 00 20 4b e5 5a:96 c2 e0 a6 1e 7a 1d 89  .... K.Z.....z.. 10:56:29 - 2924 : 2772 - [972] clean up done. 10:56:29 - 2924 : 2772 - [972,816]thread end. Any clues?

fberson · Accepted Answer

For people with the same issue, we managed to get it working by using the Source IP Hash option in the Fortigate. Thanks Andrew for the quick support!

DELL-Andrew W1 · Answer

Hello,

When you used PNTSC, I see that EOPx is disabled.

With your other connection, the one that fails, do you have EOPx disabled here too?

If not, try disabling it and trying again. Let me know if it works then.

Thanks, Andrew

fberson · Answer

Hi Andrew, Thanks Yes, both connections have already EOPx disabled in pntsc.

DELL-Andrew W1 · Answer

Hello, I've raised this as a case and sent you some advanced logging options. Lets work on the SR and then post our findings here Thanks,Andrew.

DELL-Andrew W1 · Answer

My pleasure

vWorkspace

Was this post helpful?