http_response_recv: Retries exceeded - Protocol Security Negotiation Failure

[wvdmheen]

Hi all,

I'm having trouble connecting to a Windows Server 2019 RDS server at one of our clients. We've gone through all the logging we could find on the customer's RDS server but we didn't find any clear reason.

First I was running freerdp 2.2.0 on Ubuntu 20.04.3. I've attached the buildconfig in a txt file. When trying to connect I get ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x0002000C].

The trace log shows:
[11:54:52:654] [38080:38082] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[11:54:52:654] [38080:38082] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
[11:54:52:671] [38080:38082] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313]
[11:54:52:690] [38080:38082] [ERROR][com.freerdp.core.gateway.http] - http_response_recv: Retries exceeded
[11:54:52:691] [38080:38082] [ERROR][com.freerdp.core.nego] - Protocol Security Negotiation Failure
[11:54:52:691] [38080:38082] [ERROR][com.freerdp.core] - rdp_client_connect:freerdp_set_last_error_ex ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x0002000C]
[11:54:52:691] [38080:38082] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure

This issue seems very much the same as the one r-barnett reported here: #5937.
I tried adding credentials using /u /d and /p but that doesn't make a difference. I also tried /gt:rpc but that ends up in an error because of a 302 redirect, exactly like reported here: #4014.

After installing freerdp 2.7.0, the trace logs changed but unfortunately still ends up in the same error:

[13:45:19:825] [6696:6697] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[13:45:19:825] [6696:6697] [DEBUG][com.winpr.sspi.NTLM] - change state from NTLM_STATE_INITIAL to NTLM_STATE_INITIAL
[13:45:19:825] [6696:6697] [DEBUG][com.winpr.sspi.NTLM] - change state from NTLM_STATE_INITIAL to NTLM_STATE_NEGOTIATE
[13:45:19:825] [6696:6697] [DEBUG][com.winpr.sspi.NTLM] - Write flags [0xe20882b7] NTLMSSP_NEGOTIATE_UNICODE|NTLMSSP_NEGOTIATE_OEM|NTLMSSP_REQUEST_TARGET|NTLMSSP_NEGOTIATE_SIGN|NTLMSSP_NEGOTIATE_SEAL|NTLMSSP_NEGOTIATE_LM_KEY|NTLMSSP_NEGOTIATE_NTLM|NTLMSSP_NEGOTIATE_ALWAYS_SIGN|NTLMSSP_NEGOTIATE_EXTENDED_SESSION_SECURITY|NTLMSSP_NEGOTIATE_VERSION|NTLMSSP_NEGOTIATE_128|NTLMSSP_NEGOTIATE_KEY_EXCH
[13:45:19:825] [6696:6697] [DEBUG][com.winpr.sspi.NTLM] - change state from NTLM_STATE_NEGOTIATE to NTLM_STATE_CHALLENGE
[13:45:19:825] [6696:6697] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
[13:45:19:841] [6696:6697] [DEBUG][com.winpr.sspi.NTLM] - Read flags [0xe2898235] NTLMSSP_NEGOTIATE_UNICODE|NTLMSSP_REQUEST_TARGET|NTLMSSP_NEGOTIATE_SIGN|NTLMSSP_NEGOTIATE_SEAL|NTLMSSP_NEGOTIATE_NTLM|NTLMSSP_NEGOTIATE_ALWAYS_SIGN|NTLMSSP_TARGET_TYPE_DOMAIN|NTLMSSP_NEGOTIATE_EXTENDED_SESSION_SECURITY|NTLMSSP_NEGOTIATE_TARGET_INFO|NTLMSSP_NEGOTIATE_VERSION|NTLMSSP_NEGOTIATE_128|NTLMSSP_NEGOTIATE_KEY_EXCH
[13:45:19:841] [6696:6697] [DEBUG][com.winpr.sspi.NTLM] - change state from NTLM_STATE_CHALLENGE to NTLM_STATE_AUTHENTICATE
[13:45:19:841] [6696:6697] [DEBUG][com.winpr.sspi.NTLM] - Write flags [0xe288b235] NTLMSSP_NEGOTIATE_UNICODE|NTLMSSP_REQUEST_TARGET|NTLMSSP_NEGOTIATE_SIGN|NTLMSSP_NEGOTIATE_SEAL|NTLMSSP_NEGOTIATE_NTLM|NTLMSSP_NEGOTIATE_DOMAIN_SUPPLIED|NTLMSSP_NEGOTIATE_WORKSTATION_SUPPLIED|NTLMSSP_NEGOTIATE_ALWAYS_SIGN|NTLMSSP_NEGOTIATE_EXTENDED_SESSION_SECURITY|NTLMSSP_NEGOTIATE_TARGET_INFO|NTLMSSP_NEGOTIATE_VERSION|NTLMSSP_NEGOTIATE_128|NTLMSSP_NEGOTIATE_KEY_EXCH
[13:45:19:841] [6696:6697] [DEBUG][com.winpr.sspi.NTLM] - change state from NTLM_STATE_AUTHENTICATE to NTLM_STATE_FINAL
[13:45:19:841] [6696:6697] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_E_OK [0x00000000]
[13:45:19:853] [6696:6697] [ERROR][com.freerdp.core.gateway.http] - http_response_recv: Retries exceeded
[13:45:19:853] [6696:6697] [ERROR][com.freerdp.core.nego] - Protocol Security Negotiation Failure
[13:45:19:853] [6696:6697] [ERROR][com.freerdp.core] - rdp_client_connect:freerdp_set_last_error_ex ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x0002000C]
[13:45:19:853] [6696:6697] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure

Can anyone provide any insight or maybe something to test?

freerdp220-buildconfig.txt
freerdp220log.txt
freerdp270-buildconfig.txt
freerdp270log.txt

[akallabeth]

Gateway connection? Are there some webserver policies in place? [13:45:19:853] [6696:6697] [ERROR][com.freerdp.core.gateway.http] - http_response_recv: Retries exceeded is suspicious

[wvdmheen]

Hi @akallabeth, I'm sorry I'm fairly new to this. Can you give me a bit more information on what I can check or ask? I've already asked for a network diagram to figure out what pieces this puzzle has.

[akallabeth]

1. this is a http NTLM authentication handshake. (exact number of exchanged messages depends on implementation/version supported by client and server)

What you try is:
client -> gateway -> rdp server

you fail at client -> gateway

While there are a few things you can try client side such as:

1. does the gateway have the same credentials as the rdp server you try to connect to or are they different?
2. which gateway type is in use? ( you might just try to use /gt:rpc, /gt:http and /gt:http,no-websockets to see if any of these works
3. else you will most likely need to check with the gateway administrator:
   1. the reason for the disconnect (maybe there is something in the gateway log)
   2. there are some connection policies in place to prevent malicious logon (they can sometimes be set too restrictive so that legit things get blocked as well)

[pwshfan]

@akallabeth Bumping this thread as I'm experiencing the same issue of all of sudden, without changing anything on the gateway side.
The issue is random, meaning that I can get that error but after some retries the connection might go through.

When xfreerdp returns the ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x0002000C] the Gateway logs this error Http transport: IN channel could not find a corresponding OUT channel

forcing a protocol for the gt type doesn't help

[ghollisjr]

I can confirm experiencing this bug while accessing a Windows RDP through a gateway as well. After repeatedly trying to connect, I was able to get 1 out of ~30 attempted logins to somehow go through using RPC and forcing TLS to 0, but so far I've only had the one anomalous success.

[akallabeth]

we´ve improved the gateway transport with 3.0.0-rc0 maybe you have more luck with that.
From what I can tell from the logs so far is a too aggressive brute force detection on the gateway (blocking the authentication)
not much we can do here.