Freerdp: Cannot connect through RD Gateway

[r-barnett]

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\System32LogFiles\HTTPERRhttperr1.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: /g: /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
  
  

[akallabeth]

this indeed sounds like an issue with the gateway. Did you trace the http requests on the server side? The response Retries exceeded is from the gateway, so maybe some rate limiting or similar is kicking in?

[r-barnett]

These are test gateways, so they have no load to speak of and during my tests I'm the only one trying to connect. Connections from the Windows client and the HTML 5 client succeed. Connections from xfreerdp using RPC also work. It's only the HTTP requests from xfreerdp that fail.

I have scoured the gateways for logs of any sort that are relevant to the failed requests, but have only found the one type of entry I provided above. If there is some other way to trace the gateway's activity, I'd be interested in trying it.

FWIW, the Retries exceeded message comes from the second call to http_response_recv() in rdg_establish_data_connection(). The first call gets a 401 response.

[akallabeth]

That sounds like authentication issues.
There are a few differences between MSTSC and FreeRDP to check:

• FreeRDP does currently not support kerberos
• FreeRDP does not implicitly send domain data, so maybe you´re just using the wrong credentials? (try adding a domain)

I´m asking because we also have some test setups here and the connection close case only occurs if user, domain or password are wrong.

[r-barnett]

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?

[akallabeth]

No, it uses a different transport. (http uses a hackish minimal http request/response with authentication in freerdp) whereas rpc just tunnels the whole rdp with authentication just like direct connections use.
so yes, would be really interested in what is wrong here too :/

[r-barnett]

I guess it's nice to have an interesting problem, but I was hoping someone would tell me what we're doing wrong. :-)

When you say "connection close case", are you referring specifically to that second http_response_recv() call returning a NULL? I was hoping that that case could flip the rpcFallback flag so that it would try RPC. (I tried that and it works for my case.) However, maybe that's not a good idea if that case happens with bad credentials.

[akallabeth]

yes, that is the issue with automatic fallback :/
only thing I can suggest for your case is a small script doing that fallback if the first try fails (or just always use RPC) but nothing that we can fix here shortly.

[CeeMac-git]

Not sure if it's related or not but since the last week or so I am no longer able to connect via any RDG 2012 R2 upwards which used to work fine. Have there been any updates recently that could have changed how RDG connections are processed? I'll try adding /gt:rpc to see if that makes any difference in my case.

[akallabeth]

@CeeMac-git no updates on our side. No issues with. 2016 and 2019 too, need to check 2012 but was working here too, unlike for the thread starter.

[CeeMac-git]

@akallabeth thanks. Can you confirm your version and how you're using it, e.g standalone or with remmina? I'll double check against my setup. It just seems odd that it stopped working as we haven't made any changes to our RDG environments either. Unless it's environmental and some other update to my PC is causing issues.

[akallabeth]

@CeeMac-git xfreerdp and some custom clients based on freerdp, have not tried remmina for a few weeks. Used to work flawlessly, but can check later.

[r-barnett]

@CeeMac-git , I'm curious whether you're getting the same error. Also, we don't currently have a 2012R2 gateway, so I can't compare to that case.

[akallabeth]

@r-barnett @CeeMac-git just confirmed, our test setups work correctly with http. Seems to be a setting with authentication (are there any specific settings/policies on your server regarding that?)

[r-barnett]

Our problems began at installation time, so pretty much all defaults. We've poked around with all the settings we could find related to authentication and found nothing that had any impact. This doesn't mean there isn't any issue there though, so if you have something specific to check, I'll look into it.

[akallabeth]

@r-barnett well, our test setups are also quite 'default' but it seems they still differ :/

[r-barnett]

Yea, just wish I knew what it was.

[CeeMac-git]

@akallabeth I'll do some testing this evening. This was working with remmina a week or so ago, no changes to RDG / RDS collection.

[CeeMac-git]

@akallabeth so, from /buildconfig
This is FreeRDP version 2.0.0-dev5 (n/a)

CFLAGS: -g -O2 -fdebug-prefix-map=/build/freerdp2-ULbysn/freerdp2-2.0.0~git202002281153

So it does look like its a version that was released a couple of weeks ago.

I've tried running with /gt:rpc and that didnt help so it's possible I have a different problem to @r-barnett .

The error I'm getting for non-rpc connection is:
[22:50:58:096] [3940:3941] [ERROR][com.freerdp.core.connection] - Timeout waiting for activation

and for /gt:rpc
[22:55:03:455] [4072:4073] [INFO][com.freerdp.core.gateway.tsg] - TS Gateway Connection Success
[22:55:14:872] [4072:4073] [ERROR][com.freerdp.core.connection] - Timeout waiting for activation

Is there an easy way to roll back to the version prior to 2.0.0~git202002281153

Do you want me to raise a new Issue for this?

[akallabeth]

@CeeMac-git this looks more like a configuration issue on the gateway, as this message Timeout waiting for activation means there is no response from the server after the connection was established.

[CeeMac-git]

Morning @akallabeth I would agree with you except the issue is consistent across 3 different environments all of different versions that all used to work. It's all very strange. Is there way I can install a previous version of freerdp to test against?

[akallabeth]

@CeeMac-git you can always build an older version from git, but I don´t know how you build in the first place ;)

[CeeMac-git]

@akallabeth installing through apt (Linux mint) still a bit new to the whole build from git thing but I'll give it a go if I can find the right commit/branch/tag. Presumably 2.0.0-dev4 was the previous iteration?

[akallabeth]

@CeeMac-git https://github.com/FreeRDP/FreeRDP/wiki/Compilation, try the dpkg-buildpackage method for debian based ones, so you can build your own nightly

[CeeMac-git]

@akallabeth was just looking at that. Will give it ago!

[akallabeth]

@CeeMac-git you can start with the 2.0.0-rc4 tag and use git bisect to do a binary search for a version that stopped working (if it works with the older one)

[CeeMac-git]

Thanks @akallabeth will report back if I find anything

[CeeMac-git]

@akallabeth I can confirm that a fresh build from the 2.0.0-rc4 tag works on all my RDG/RDS environments. With the git bisect, presumably I'll have to build from each commit before I can test and mark good/bad? Also what's the best way to get the sha of the commits to run bisect against?

[akallabeth]

@CeeMac-git interesting. Yes, you need to build. You only need 2 starting revisions, the rest is up to bisect (it will print you the sha of the first faulty on once complete)

[CeeMac-git]

@akallabeth and I get the starting revisions from..... :D I've only really done this with gerrit before so I'm a little unsure on some of the git commands. Might take me a while to get some results as I've not much free time over the next few days but I'll come back with something.

[akallabeth]

@CeeMac-git master ;)

[akallabeth]

@CeeMac-git will check if I can get my hands in w2k12. Can't be much, but it seems to do something different to 2k16 and 2k19 I have for testing

[CeeMac-git]

@akallabeth yeah Microsoft made a lot of changes between 2012 and 2016 around RDS including adding new RPC routines. 2016/2019 are very similar. FYI I'm testing against a 2012R2 environment with 2FA and a 2016 environment no 2FA. Both work on rc4 and don't work on dev5. I can try against a 2019 if I can find the one that's not configured for published apps.

[akallabeth]

@CeeMac-git that is interesting. Can you post the configuration for the 2016 somewhere?
A setup to reproduce is 70% of the work ;)

[CeeMac-git]

@akallabeth if you can let me know specifically what info you need I'll try dig it out on Monday.

[CeeMac-git]

@akallabeth I think the pertinent configuration options are as below, let me know if you want/need anything else. This is from a 2016 RDG set up:

Configure the deployment

• RD Gateway
  Logon method: Password Authentication
  Use RD Gateway credentials for remote computers - ticked
  Bypass RD Gateway server for local addresses - unticked

Collection Properties

• Security
  Security Layer: Negotiate
  Encryption Layer: Client Compatible
  Allow connections only from computers running Remote Desktop with Network Level Authentication - ticked

[akallabeth]

@CeeMac-git can´t reproduce, got these settings here :/
do you have some test account that I could connect to? Would love to debug the data stream and check what is going on.

[CeeMac-git]

@akallabeth - no can do on the test account unfortunately, it would breach corporate policy.

Let me see what I can find with git-bisect. It could be related to how freerdp was built in the reminna PPA even. I might jump straight to a clean build from master and test that first actually.

Are there any other settings you can think of that might be relevant?

[CeeMac-git]

@akallabeth what parameters do you build with? (assuming cmake of course)

[akallabeth]

dpkg-buildpackage, aka the nightly build

[akallabeth]

details in packaging/deb/freerdp-nightly/rules

[CeeMac-git]

does that use a specific set of build options for the various WITH_* settings?

[akallabeth]

there are no real options that influence, except WITH_KRB5 or WITH_GSSAPI with enables kerberos support (still experimental/broken, so disable)

[CeeMac-git]

OK. will try the nightly as a blind control to see if the issue persists as well then.

[akallabeth]

@CeeMac-git you might want to merge https://github.com/FreeRDP/FreeRDP/pull/5757 for a test, it fixes a few issues and imroves logging.
(Still not production ready, but could help in diagnosing the problem)

[CeeMac-git]

@akallabeth is there a cherry pick for that or a tag I can fetch?

[AAlchemy]

Hate to be a "me too". I am also having this problem with ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED. Sadly /gt:rpc doesn't even work around it.

[CeeMac-git]

@akallabeth just compiled from master following the same process as I did for rc4 tag and I'm back with "timeout waiting for activation"

Tested against 2016 RDG/RDS

This is FreeRDP version 2.0.0-dev5 (3b673be37)

I'll try tun a git bisect over the next few days if I have time.

[CeeMac-git]

@akallabeth results of the git bisect are in:

`a48e7f8b473f2d97e0eb5b6a1011507888c5e837 is the first bad commit
commit a48e7f8b473f2d97e0eb5b6a1011507888c5e837
Author: Norbert Federa [e-mail]
Date: Thu Feb 20 17:26:27 2020 +0100

core: fix endless loops waiting for activation

There are two loops polling the transport pdu receiver in non-blocking mode
when waiting for reaching CONNECTION_STATE_ACTIVE rdp state.

In case of an invalid pdu size in the tpkt header this leaded to an endless
loop, utilizing 100% of a cpu core.

Added a sleep and limited the max loop time to the tcp ack timout value.

:040000 040000 8257297ff16159cdbe6948ab1981e6e2f545b0a8 8f90568164f0a0e8409bbfe7e028f01aa09351a5 M libfreerdp
`
Its probably worth noting that I'm on a Satellite Broadband link at home where I'm having this issue with an average RTT of 600-700ms. It can take a good few seconds for the Remote Desktop session to activate so I wonder if the introduced changes are ageing out the connection attempt a little too aggressively?

Let me know if you need me to try anything else or require more info.

[CeeMac-git]

@akallabeth So, I've done some tinkering and if I set settings->TcpAckTimeout = 15000 in ./libfreerdp/core/settings.c with commit a48e7f8b4 checked out, that seems to fix the issue. I managed to get it down to 12000 but that prove inconsistent, whereas so far 15000 seems to work repeatedly in the limited tests i've run (basically 3 in a row).

[CeeMac-git]

@akallabeth I can confirm changing this setting in master also seems to fix my issue.

[akallabeth]

@CeeMac-git ok, yes, high latency links are always an issue :/ Now back the the issues the others in this thread face.

[akallabeth]

@r-barnett I´ve dug a bit into this, the fault you receive (Request_Cancelled) is sent from the server, so it strengthens my theory that some policy on the server is not satisfied.
I´d guess some policy regarding your HTTP server regarding ddos or similar is a bit too tight as FreeRDP does 1 or 2 more requests than mstsc.

[CeeMac-git]

thanks @akallabeth and sorry @r-barnett for highjacking the thread, hope you get your issue resolved.

[r-barnett]

@akallabeth, did you find the Windows component that generates the "Request_Cancelled" message?

FWIW, we set up another RDS 2016 farm in a different test lab and have the same problem with it.

[akallabeth]

@r-barnett As I can still not reproduce your issue, no.

[In-Flight]

freerdp-2.0.0_rc4

Old Certificate details:
    Subject:     CN = #######
    Issuer:      CN = #######
    Thumbprint:  f6:fc:26:ca:0f:49:9a:ac:44:1c:4e:9a:10:14:c4:00:09:26:67:9c

Before update and after downgrade is work fine:

[20:34:08:507] [20312:20313] [ERROR][com.winpr.timezone] - Unable to get current timezone rule
[20:34:24:815] [20312:20313] [INFO][com.freerdp.gdi] - Local framebuffer format  PIXEL_FORMAT_BGRX32
[20:34:24:815] [20312:20313] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_RGB16
[20:34:24:823] [20312:20313] [INFO][com.winpr.clipboard] - initialized POSIX local file subsystem

freerdp-2.1.1

New Certificate details:
    Common Name: #######
    Subject:     CN = #######
    Issuer:      CN = #######
    Thumbprint:  b0:ae:d0:b3:d9:3d:00:7f:9c:d0:04:7a:02:36:ad:c7:23:fc:65:9d:22:52:0d:9b:a1:cd:03:07:42:ab:e0:f4

After update:

[20:24:00:001] [16310:16311] [INFO][com.freerdp.core] - freerdp_connect:freerdp_set_last_error_ex resetting error state
[20:24:00:001] [16310:16311] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr
[20:24:00:001] [16310:16311] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
[20:24:00:001] [16310:16311] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[20:24:00:310] [16310:16311] [INFO][com.freerdp.primitives] - primitives autodetect, using optimized
[20:24:00:312] [16310:16311] [INFO][com.freerdp.core] - freerdp_tcp_is_hostname_resolvable:freerdp_set_last_error_ex resetting error state
[20:24:00:312] [16310:16311] [INFO][com.freerdp.core] - freerdp_tcp_connect:freerdp_set_last_error_ex resetting error state
[20:24:00:488] [16310:16311] [WARN][com.freerdp.crypto] - Certificate verification failure 'unable to get local issuer certificate (20)' at stack position 0
[20:24:00:488] [16310:16311] [WARN][com.freerdp.crypto] - CN = #######
[20:24:01:190] [16310:16311] [ERROR][com.winpr.timezone] - Unable to get current timezone rule
[20:24:09:506] [16310:16311] [ERROR][com.freerdp.core.connection] - Timeout waiting for activation

P.S. Processed downgrade from 2.1.1 to 2.0.0_rc4 (Gentoo X64 4.19.97), 2.0.0-r1 also NOT worked.
P.P.S. Server: Windows 7 x64 SP1

[akallabeth]

@In-Flight so after downgrade it also did not work anymore? Sorry, your last sentence is a bit confusing.

[In-Flight]

@In-Flight so after downgrade it also did not work anymore? Sorry, your last sentence is a bit confusing.

After downgrade RDP connection working normally, just as it did before the update. I think the problem is in switching from SHA1 to SHA256 of Thumbprint and associated key storage.

Up: I was told that this might be the problem https://support.microsoft.com/en-us/help/4472027/2019-sha-2-code-signing-support-requirement-for-windows-and-wsus I will be check later.

[akallabeth]

@In-Flight sorry, no, this is a local storage related change (no change at all for the connection)

[akallabeth]

@In-Flight if you have time and can compile FreeRDP yourself, you could do a git bisect and find out with which commit it stopped working for you

[akallabeth]

@In-Flight the Timeout waiting for activation I´ve seen with some resource exhaustion server side (too many simultaneous sessions logged in)

[pptaszni]

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.

[akallabeth]

@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