This post is more than 5 years old
25 Posts
0
181160
Secure Gateway issue
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
25 Posts
1
January 10th, 2014 07:00
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
378 Posts
0
January 8th, 2014 09:00
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
25 Posts
0
January 8th, 2014 09:00
Hi Andrew,
Thanks
Yes, both connections have already EOPx disabled in pntsc.
DELL-Andrew W1
378 Posts
0
January 8th, 2014 10:00
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
378 Posts
0
January 10th, 2014 07:00
My pleasure