FreeRDP: Cannot connect through RD Gateway

Describe the bug

When trying to connect through an in-house RD Gateway on Windows Server 2019 (or 2016), xfreerdp fails with ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED.

This works when using an RD Gateway in Azure. Of course that suggests a problem with the in-house RD Gateways; however, I’ve spent days trying to find a difference in the server configurations without success. Colleagues with more Windows experience than I have also spent time looking for problems on the in-house servers. We’ve tried tweaking various things. We’ve also looked for information in logs on the server. The only thing I’ve found is C:\Windows\System32\LogFiles\HTTPERR\httperr1.log which contains entries like this corresponding to the failed connections: “2020-01-16 13:30:12 xxx.xxx.xxx.xxx 37854 xxx.xxx.xxx.xxx 443 HTTP/1.1 RDG_OUT_DATA /remoteDesktopGateway/ - - - Request_Cancelled -”

Looking at NTLM debug output from xfreerdp and packet traces, I can see that the gateway initializes an NTLM challenge, but is responding to the response from xfreerdp with an RST packet, so it seems to be just closing the connection and xfreerdp is getting nothing back.

A workaround is to use /gt:rpc. In this case the connection is successful. However, since I can’t find anything wrong with the gateway configuration and I need this to work in the general case, I’m loathe to hardcode the transport protocol. So, at a minimum, I’d propose a small expansion to the RPC fallback logic to deal with a lack of response to the NTLM reply.

To Reproduce xfreerdp /v:<target_host> /g:<gateway_host> /log-level:TRACE

Expected behavior

xfreerdp should connect through the gateway to the specified host.

Application details

Version of FreeRDP: current master and various others dervied from some point since 2.0.0-rc4, including the ones recently included in Fedora 31.
Command line used: see above
output of /buildconfig This is FreeRDP version 2.0.0-dev5 (20ff1a5b4) Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=OFF HAVE_AIO_H=1 HAVE_EXECINFO_H=1 HAVE_FCNTL_H=1 HAVE_INTTYPES_H=1 HAVE_JOURNALD_H=TRUE HAVE_MATH_C99_LONG_DOUBLE=1 HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK=ON HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIB=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL= HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H=1 HAVE_SYS_FILIO_H= HAVE_SYS_MODEM_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H= HAVE_SYS_STRTIO_H= HAVE_SYS_TIMERFD_H=1 HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 HAVE_XI_TOUCH_CLASS=1 WITH_ALSA=ON WITH_CAIRO=OFF WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CLANG_FORMAT=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CUPS=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_RDPGFX=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF_AVAILABLE=0 WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DIRECTFB=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=OFF WITH_GFX_H264=OFF WITH_GPROF=OFF WITH_GSM=ON WITH_GSSAPI=OFF WITH_ICU=OFF WITH_IPP=OFF WITH_JPEG=ON WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=ON WITH_MACAUDIO=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_OPENCL=OFF WITH_OPENH264=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=ON WITH_PCSC=ON WITH_PROFILER=OFF WITH_PULSE=ON WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=0 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=0 WITH_SANITIZE_THREAD=ON WITH_SANITIZE_THREAD_AVAILABLE=1 WITH_SERVER=OFF WITH_SERVER_INTERFACE=ON WITH_SMARTCARD_INSPECT=OFF WITH_SOXR=OFF WITH_SSE2=ON WITH_SWSCALE=OFF WITH_THIRD_PARTY=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=0 WITH_WAYLAND=OFF WITH_WINPR_TOOLS=ON WITH_X11=ON WITH_X264=OFF WITH_XCURSOR=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XKBFILE=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XSHM=ON WITH_XV=ON WITH_ZLIB=ON Build type: Release CFLAGS: -fPIC -Wall -Wno-unused-result -Wno-unused-but-set-variable -Wno-deprecated-declarations -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -fno-omit-frame-pointer -DWINPR_DLL Compiler: GNU, 9.2.1 Target architecture: x64
OS version connecting to: Windows Server 2019 (and 2016)
If available the log output from a run with /log-level:trace [13:42:38:350] [17622:17623] [INFO][com.freerdp.core] - freerdp_connect:freerdp_set_last_error_ex resetting error state [13:42:38:350] [17622:17623] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr [13:42:38:350] [17622:17623] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd [13:42:38:350] [17622:17623] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx [13:42:38:350] [17622:17623] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr [13:42:38:351] [17622:17623] [DEBUG][com.freerdp.client.x11] - Searching for XInput pointer device [13:42:38:351] [17622:17623] [DEBUG][com.freerdp.client.x11] - Pointer device: 11 [13:42:38:355] [17622:17623] [DEBUG][com.freerdp.primitives] - primitives benchmark result: [13:42:38:509] [17622:17623] [DEBUG][com.freerdp.primitives] - * generic= 51 [13:42:38:660] [17622:17623] [DEBUG][com.freerdp.primitives] - * optimized= 130 [13:42:38:660] [17622:17623] [INFO][com.freerdp.primitives] - primitives autodetect, using optimized [13:42:38:662] [17622:17623] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE [13:42:38:662] [17622:17623] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE [13:42:38:662] [17622:17623] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE [13:42:38:662] [17622:17623] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE [13:42:38:662] [17622:17623] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: TRUE [13:42:38:662] [17622:17623] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE [13:42:38:662] [17622:17623] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_NLA [13:42:38:662] [17622:17623] [DEBUG][com.freerdp.core.nego] - Attempting NLA security [13:42:38:668] [17622:17623] [INFO][com.freerdp.core] - freerdp_tcp_connect:freerdp_set_last_error_ex resetting error state [13:42:38:668] [17622:17623] [DEBUG][com.freerdp.core] - connecting to peer xxx.xxx.xxx.xxx [13:42:38:681] [17622:17623] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA [13:42:38:681] [17622:17623] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312] [13:42:38:682] [17622:17623] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313] [13:42:38:683] [17622:17623] [ERROR][com.freerdp.core.gateway.http] - http_response_recv: Retries exceeded [13:42:38:683] [17622:17623] [ERROR][com.freerdp.core.nego] - Protocol Security Negotiation Failure [13:42:38:683] [17622:17623] [ERROR][com.freerdp.core] - rdp_client_connect:freerdp_set_last_error_ex ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x0002000C] [13:42:38:683] [17622:17623] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure Desktop (please complete the following information):

OS: Fedora 31 and others Additional context

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 63 (36 by maintainers)

Most upvoted comments

@pptaszni FreeRDP already allows adjusting the timeout without recompile 😉

/timeout:<time in ms>             Advanced setting for high latency links:
                                      Adjust connection timeout, use if you
                                      encounter timeout failures with your

akallabeth on Jul 31, 2020

Not sure if the same root cause, but I experienced similar problems - Timeout waiting for activation - trying to connect with NLA using 2 ssh tunnels (remote tunnel from Windows RDP server + local tunnel from Linux RDP client), but without RDP gateway. With com.freerdp.core.nla debug prints I could see that the timeout occurred right after auth token transmission:

[17:03:15:954] [22:23] [DEBUG][com.freerdp.core.nla] - Sending Authentication Token
[17:03:15:954] [22:23] [DEBUG][com.freerdp.core.nla] - 0000 4e 54 4c 4d 53 53 50 00 01 00 00 00 b7 82 08 e2 NTLMSSP.........
[17:03:15:955] [22:23] [DEBUG][com.freerdp.core.nla] - 0016 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[17:03:15:955] [22:23] [DEBUG][com.freerdp.core.nla] - 0032 06 01 b1 1d 00 00 00 0f                         ........
[17:03:15:955] [22:23] [DEBUG][com.freerdp.core.nla] - [length=40]

and then timeout. I increased TcpAckTimeout 1000 times and it seems to work now.

diff --git a/libfreerdp/core/settings.c b/libfreerdp/core/settings.c
index 25d2390c0..5e0916e27 100644
--- a/libfreerdp/core/settings.c
+++ b/libfreerdp/core/settings.c
@@ -566,7 +566,7 @@ rdpSettings* freerdp_settings_new(DWORD flags)
        settings->TcpKeepAliveRetries = 3;
        settings->TcpKeepAliveDelay = 5;
        settings->TcpKeepAliveInterval = 2;
-       settings->TcpAckTimeout = 9000;
+       settings->TcpAckTimeout = 9000000;

        if (!settings->ServerMode)
        {

Doesn’t look like a “solution” though.

pptaszni on Jul 31, 2020

The Windows laptop I’m connecting from is in a separate untrusted domain. When using the Windows client I specify the domain name, username, and password.

With xfreerdp, I use /u: /p: and /d: and just adding /gt:rpc to the command line results in a successful connection.

I also suspected an authentication problem and unsuccessfully tried to find a problem related to that in the gateway configuration. I didn’t discover that RPC works until later. Does that use a different authentication method?

r-barnett on Mar 4, 2020