02-Oct-2017
20:22
- last edited on
01-Jun-2023
13:55
by
JimmyPackets
We have a problem where the user clicks on a link in a webtop which is a native RDP link, their application opens but the connection fails. Tcpdumps show for failed connections client traffic arrives at the F5 but never leaves it. For successful connections they stay up for a long time. We cannot see why they are failing when the backend resource is available and accessible.
VDI debug logs ~ https://gist.github.com/rtfmoz/58d82b0887146ea3a2310eb32fea1428
The failed connections just sit there until they time out with the error
"Your computer cannot connect to the Remote Desktop Gateway server.
Contact your network administrator for assistance."
Solved! Go to Solution.
08-Oct-2017
19:07
- last edited on
05-Jun-2023
21:42
by
JimmyPackets
Summary
Native RDP connections that use SSO variables fail to work reliably.
Version
BIG-IP 13.0.0 HF2
Symptoms
RDP connections intermittently fail to connect. The following message appears when you try to connect to the RDP session.
"Your computer cannot connect to the Remote Desktop Gateway server.
Contact your network administrator for assistance."
This occurs under the following conditions
Workaround
Choose one of the following options:
Option 1: Enabled the virtual server to listen on all VLANS.
Option 2: Disable CMP on the virtual server - see K14358 Option 3: Virtual Edition only, set vCPU to one.Solution
Hotfix to address this issue.
02-Oct-2017 20:44
The same native RDP connection can fail, then work, then fail to connect.
03-Oct-2017 03:07
Hi Kevin,
On my configuration, Native RDP fails when I configure SSO. it work like a charm without this configuration.
03-Oct-2017 06:36
Have you applied the default certificate on VS?
03-Oct-2017 15:20
No, using a valid SSL certificate. For everyone elses knowledge ... a valid SSL cert is required by native RDP for the MSRDP client to trust the RDP file. This is because APM signs the RDP file with the SSL private key of the virtual server.
03-Oct-2017 06:36
Have you applied the default certificate on VS?
03-Oct-2017 15:20
No, using a valid SSL certificate. For everyone elses knowledge ... a valid SSL cert is required by native RDP for the MSRDP client to trust the RDP file. This is because APM signs the RDP file with the SSL private key of the virtual server.
04-Oct-2017 16:58
** Updated Answer Above **
04-Oct-2017 18:51
I am testing the cmp disable with vCPU=2 tomorrow as I am not certain demoting a virtual server to tmm0 will disable threaded execution across tmm0.1/0.2/...
06-Oct-2017 13:12
Disabling CMP is a successful workaround. We went back to vCPU = 2 and disabled CMP on the virtual server and all our RDPw/SSO connections are still working.
08-Oct-2017 19:08
F5 have come back to us on this issue. Enable the virtual on all VLAN's. Updated solution posted.
08-Oct-2017
19:07
- last edited on
05-Jun-2023
21:42
by
JimmyPackets
Summary
Native RDP connections that use SSO variables fail to work reliably.
Version
BIG-IP 13.0.0 HF2
Symptoms
RDP connections intermittently fail to connect. The following message appears when you try to connect to the RDP session.
"Your computer cannot connect to the Remote Desktop Gateway server.
Contact your network administrator for assistance."
This occurs under the following conditions
Workaround
Choose one of the following options:
Option 1: Enabled the virtual server to listen on all VLANS.
Option 2: Disable CMP on the virtual server - see K14358 Option 3: Virtual Edition only, set vCPU to one.Solution
Hotfix to address this issue.
08-Oct-2017 23:05
Hi,
Thank you for the update.
Even if the last workaround is better than previous, in some circumstances, one of previous can help.
I suggest to add in workaround section previous ones (disable sso, disable cmp on VS)
09-Oct-2017 03:59
Updated to reflect alternative workarounds.
07-Jun-2018 04:50
I am still having this issue running 13.1.0.2, in my situation the vs is running in a non-default route domain.
F5 confirmed we are dealing with bug ID 623036 - Native RDP proxy does not work if Virtual Server is in non-default route domain and CMP enabled. This bug is linked to bug ID6 17929 Support non-default route domains when connecting to other tmm over backplane.
Unfortunately no fix is available yet.