Freerdp: Connection from linux to Windows 10 not working after latest Win10 update (ERRCONNECT_CONNECT_TRANSPORT_FAILED)

[awdAvenger]

After a reboot due to an update last week, I can no longer connect to my Windows 10 Professional computer from my linux computer using xfreerdp.

I get the following output when trying to connect using the latest version from git (2a3e9996):

[09:19:16:178] [21254:21255] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 104: Connection reset by peer
[09:19:16:178] [21254:21255] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x2000D]
[09:19:16:178] [21254:21255] [ERROR][com.freerdp.client.x11] - Freerdp connect error exit status 1

This was with a simple command line with /u: and /v:. I have tried with /gt:rpc as well because I've seen somewhere else, but it didn't work.

Note that I can connect to this Windows 10 machine using the Remote Desktop Connection application in Windows XP, and xfreerdp is able to connect to the windows XP machine.

Winver.exe on the Windows 10 machine reports: Version 1511 (OS Build 10586.104).

Let me know if there's anything else that I can do.

[awdAvenger]

I can also note that the connection works fine with the 'rdesktop' utility.

[bmiklautz]

@awdAvenger i this via a gateway? Otherwise /gt wont bring anything. I just tested against a windows 10 test machine and did't see this problem.
Can you check if you see any error in the windows log after connecting? Also it might help us if you run xfreerdp with the environment variable WLOG_LEVEL set to DEBUG:

WLOG_LEVEL=DEBUG

[nfedera]

Also no issue here connecting to Windows 10 V.1511 Build 10586.104, neither with 2a3e999 nor with current master (b4b8239)

[awdAvenger]

This is not though a gateway, it's just a simple Win 10 Pro laptop, connected to a domain.

The output from xfreerdp with DEBUG is:

$ WLOG_LEVEL=DEBUG xfreerdp /u:JOTRON\knutid /v:knutid-laptop
[09:44:47:990] [10115:10115] [DEBUG][com.freerdp.client.common.cmdline] - windows: 0/1 posix: -1000/0 compat: 1/0
[09:44:47:993] [10115:10116] [DEBUG][com.freerdp.client.x11] - Searching for XInput pointer device
[09:44:47:993] [10115:10116] [DEBUG][com.freerdp.client.x11] - Pointer device: 10
[09:44:47:994] [10115:10116] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE
[09:44:47:994] [10115:10116] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE
[09:44:47:994] [10115:10116] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE
[09:44:47:994] [10115:10116] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE
[09:44:47:994] [10115:10116] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: TRUE
[09:44:47:994] [10115:10116] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE
[09:44:47:994] [10115:10116] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_NLA
[09:44:47:994] [10115:10116] [DEBUG][com.freerdp.core.nego] - Attempting NLA security
[09:44:47:018] [10115:10116] [DEBUG][com.freerdp.core.nego] - RequestedProtocols: 3
[09:44:47:021] [10115:10116] [DEBUG][com.freerdp.core.nego] - RDP_NEG_RSP
[09:44:47:021] [10115:10116] [DEBUG][com.freerdp.core.nego] - selected_protocol: 2
[09:44:47:021] [10115:10116] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_FINAL
[09:44:47:021] [10115:10116] [DEBUG][com.freerdp.core.nego] - Negotiated NLA security
[09:44:47:021] [10115:10116] [DEBUG][com.freerdp.core.nego] - nego_security_connect with PROTOCOL_NLA
[09:44:47:030] [10115:10116] [DEBUG][com.winpr.utils] - Could not open SAM file!
Password:
[09:44:52:034] [10115:10116] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[09:44:52:034] [10115:10116] [DEBUG][com.freerdp.core.nla] - Sending Authentication Token
[09:44:52:034] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0000 4e 54 4c 4d 53 53 50 00 01 00 00 00 b7 82 08 e2 NTLMSSP.........
[09:44:52:034] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[09:44:52:034] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0020 06 01 b1 1d 00 00 00 0f ........
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - Sending Authentication Token
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0000 4e 54 4c 4d 53 53 50 00 03 00 00 00 18 00 18 00 NTLMSSP.........
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0010 78 00 00 00 30 01 30 01 90 00 00 00 0c 00 0c 00 x...0.0.........
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0020 58 00 00 00 0c 00 0c 00 64 00 00 00 08 00 08 00 X.......d.......
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0030 70 00 00 00 10 00 10 00 c0 01 00 00 35 b2 88 e2 p...........5...
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0040 06 01 b1 1d 00 00 00 0f af 62 f8 f2 a5 de 14 70 .........b.....p
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0050 17 46 60 e6 8b 06 92 78 4a 00 4f 00 54 00 52 00 .F`....xJ.O.T.R.
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0060 4f 00 4e 00 6b 00 6e 00 75 00 74 00 69 00 64 00 O.N.k.n.u.t.i.d.
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0070 6e 00 6f 00 6e 00 65 00 47 a9 da 2b d1 05 86 59 n.o.n.e.G..+...Y
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0080 ac f5 16 c9 b4 f6 ad 09 4e 96 36 3a 3c ef b0 d1 ........N.6:<...
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0090 2a bd 2d 3b ac ba 22 65 9d 18 3d 30 31 1f 01 67 _.-;.."e..=01..g
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 00a0 01 01 00 00 00 00 00 00 4c ac 94 9f 96 73 d1 01 ........L....s..
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 00b0 4e 96 36 3a 3c ef b0 d1 00 00 00 00 02 00 0c 00 N.6:<...........
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 00c0 4a 00 4f 00 54 00 52 00 4f 00 4e 00 01 00 1a 00 J.O.T.R.O.N.....
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 00d0 4b 00 4e 00 55 00 54 00 49 00 44 00 2d 00 4c 00 K.N.U.T.I.D.-.L.
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 00e0 41 00 50 00 54 00 4f 00 50 00 04 00 18 00 4a 00 A.P.T.O.P.....J.
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 00f0 6f 00 74 00 72 00 6f 00 6e 00 2e 00 6c 00 6f 00 o.t.r.o.n...l.o.
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0100 63 00 61 00 6c 00 03 00 34 00 6b 00 6e 00 75 00 c.a.l...4.k.n.u.
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0110 74 00 69 00 64 00 2d 00 6c 00 61 00 70 00 74 00 t.i.d.-.l.a.p.t.
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0120 6f 00 70 00 2e 00 4a 00 6f 00 74 00 72 00 6f 00 o.p...J.o.t.r.o.
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0130 6e 00 2e 00 6c 00 6f 00 63 00 61 00 6c 00 05 00 n...l.o.c.a.l...
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0140 18 00 4a 00 6f 00 74 00 72 00 6f 00 6e 00 2e 00 ..J.o.t.r.o.n...
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0150 6c 00 6f 00 63 00 61 00 6c 00 07 00 08 00 4c ac l.o.c.a.l.....L.
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0160 94 9f 96 73 d1 01 06 00 04 00 02 00 00 00 0a 00 ...s............
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0170 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0180 00 00 09 00 2a 00 54 00 45 00 52 00 4d 00 53 00 ...._.T.E.R.M.S.
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 0190 52 00 56 00 2f 00 6b 00 6e 00 75 00 74 00 69 00 R.V./.k.n.u.t.i.
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 01a0 64 00 2d 00 6c 00 61 00 70 00 74 00 6f 00 70 00 d.-.l.a.p.t.o.p.
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[09:44:52:036] [10115:10116] [DEBUG][com.freerdp.core.nla] - 01c0 29 a6 82 81 50 78 6d 3c c0 13 b9 24 2c 1d f1 93 )...Pxm<...$,...
[09:44:55:976] [10115:10116] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 104: Connection reset by peer
[09:44:55:976] [10115:10116] [DEBUG][com.freerdp.core.transport] - transport_check_fds: transport_read_pdu() - -1
[09:44:55:976] [10115:10116] [DEBUG][com.freerdp.core.rdp] - transport_check_fds() - -1
[09:44:55:976] [10115:10116] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x2000D]
[09:44:55:976] [10115:10116] [ERROR][com.freerdp.client.x11] - Freerdp connect error exit status 1

On the windows side, I get an Audit Success message in the Security logs with a Login and then a Logoff right after that. Nothing else can be seen in the event viewer.

[nfedera]

Shoudn't you escape the domain separator? Maybe simply try xfreerdp /u:knutid /d:JOTRON

[awdAvenger]

I actually did escape it, not sure why that didn't show on the pasting. I tried with /d: as well, but it still doesn't work and I don't think it's directly related to authentication credentials, as Windows says it has authenticated successfully.

[nfedera]

Since you have a working and non-working revision you could use git bisect to identify the bad commit.

[awdAvenger]

Well, they are different applications, I know freerdp is a fork of rdesktop, but I think going back that far probably won't be helpful?

I compared Wireshark output of rdesktop and freerdp and found that both receive the same RST from Windows, but the rdesktop application then initiates another connection which then proceeds to complete the connection process. I cannot make much sense of the actual data sent though, as most appears to be binary structures and/or encrypted.

[bmiklautz]

@awdAvenger just to clarify FreeRDP < 1.0 was initially a fork but with 1.0 FreeRDP it was completely rewritten from scratch.
Regarding your problem can you try with /sec:rdp and/or with /sec:tls?

[awdAvenger]

With /src:rdp and /sec:tls it works!

[bmiklautz]

@awdAvenger so it seems that there is a problem with NLA in your case. I'd recommend using /sec:tls.

[awdAvenger]

So it would appear. I can work with the other security protocols, so thanks a lot for your help. If you decide to track down this issue more, let me know if you need some additional information.

[bmiklautz]

@awdAvenger may I ask what client you are on (distribution, system architecture)?

[nfedera]

@awdAvenger Do you also have the issue if you log on as a local user instead of a domain user? (Use something like xfreerdp /u:knutid /d:knutid-laptop /v:knutid-laptop). Also what have you configured in System Properties -> Remote Tab ?

[nfedera]

@awdAvenger You might also want to post a registry dump of the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

[awdAvenger]

I am on Arch Linux 64 bit, I used the package in the repositories, but I also tried to build the package from git. I tried to downgrade the package but it did not help, so I am pretty confident that that the change happened on the Windows side, unless a library freerdp depends on changed.

In the remote settings I have allowed remote connections and have not checked the 'Allow connections only from computers running with NLA'. No change from the defaults have been done to the users list. It says my user has access and the list is empty.

Connecting as my non-domain user works as well, even with NLA security.

I have attached the registry dump as requested.
regdump.zip

[nfedera]

@awdAvenger thx, this reg key is fine. However, if it works with a local user you seem to have some domain policies in place. Ask your Domain Administrator and/or run rsop.msc (elevated) to check the applied policies. Concentrate on entries under Computer Configuration -> Administrative Templates -> Windows Compnents -> Remote Desktop Services

[HenryJacques]

@awdAvenger @nfedera
I've already encountered such behaviour and indeed it had something to do with session allowed only on specific workstations.

In dsa.msc -> User properties window -> Account Tab -> Log on to

See
https://msdn.microsoft.com/en-us/library/bb742516.kerb02_big%28l=en-us%29.gif
and
http://windowsitpro.com/site-files/windowsitpro.com/files/archive/windowsitpro.com/content/content/104709/fig4_this_user_can_log_on_to.jpg

I've just tested it with a Windows 2012 R2 DC and a Windows 7 Entreprise.
If I put the netbios name of the workstation and I cannot login anymore using NLA (ERRCONNECT_TRANSPORT_FAILED).
If I use rdp, it works.

[nfedera]

@HenryJacques Thanks! Confirmed. @awdAvenger can you also confirm that this setting is enabled for your user? @HenryJacques However, even with Windows mstsc I'm not able to login via NLA if "Logon to .." is configured.

[awdAvenger]

I will try to check the user settings for my user. In the mean time, I can tell that I don't know if rdesktop used NLA at all. And the remote client on windows that worked was on Windows XP, and I don't think NLA is supported on that either.

[HenryJacques]

@nfedera with mstsc I cannot use NLA myself.
What kind of error do you have?
I've created a rdp file to configure specific option with mstsc:

• with negotiate security layer:i:0 I get an error message and cannot connect at all
• with negotiate security layer:i:1 I get no error, the remote session starts but do not automatically login. Instead I have the Windows session prompt. I have to re-enter the password and then it works

[HenryJacques]

@awdAvenger rdesktop doesn't support NLA.
Windows XP SP3 supports NLA but not from scratch, you have to do a special configuration.
See https://support.microsoft.com/en-en/kb/951608

[HenryJacques]

@nfedera to complete my previous post, I ran a wireshark session and I saw that mstc talks directly to the DC. I get a Kerberos Error (STATUS_INVALID_WORKSTATION) in both cases.
If negotiate security layer:i:1 is set, it only fall back to standard RDP security.

[nfedera]

@HenryJacques mstsc under Windows 10 shows better error messages. If I rdp from Windows 10 domain workstation A to win10 domain workstation B and the user has only B in the "Logon to" list mstsc reports: `The system administrator has limited the computers you can log on with. Try logging on at a different computer``. This does not seem to make any sense because the computer B is in the list. If I add both computers A and B to the "Logon to" list it works however.

[nfedera]

It even works for non-domain, non-windows clients. If I add both, the target computer (in domain) and the dns name of a (non domain) linux machine to a user's "Logon To ..." list in dsa.msc, xfreerdp /sec:nla from this linux pc to that windows 10 domain computer works perfectly fine.

So I guess we can close this issue - @awdAvenger ok ?

[HenryJacques]

@nfedera great finding! I'd never had thought to put the A computer in the allowed workstations list. Maybe in Microsoft's mind if you want to login on B and you're logged on A (with the same account though), you have to be able to open a session on A first...

I also have the same conclusion concerning your very last post, I can make it work with Linux and xfreerdp. If I put the hostname of my linux client in the authorized workstations list.

However, I think there is a bug: I use the /hostname:XXX option, and setting XXX in the workstation list doesn't work. I have to put the real hostname.

[nfedera]

@HenryJacques elaborate on the last sentence. There is no /hostname: option

[HenryJacques]

@nfedera sorry ;) I meant the /client-hostname: option

[nfedera]

@HenryJacques Ok, you were trying to fake it. It would have been embarrassing (for MS) if that actually worked. I don't think this is a bug ;)

[HenryJacques]

@nfedera Ok, this option is just meant as a fake? I used it in conjunction with the /drive: option so that there is a "friendly" name.
So, this is a normal behaviour for you?

[nfedera]

@HenryJacques In the client core data block (https://msdn.microsoft.com/en-us/library/cc240510.aspx) you can see the clientName field which is described as "name of the client computer.". FreeRDP sets this value to the hostname here and overwrites it here if /client-hostname is specified. So this isn't a secure setting and should not be trusted on the server and only be used as a client provided friendly name. And yes, for me it is normal behaviour that the server gives the peer name/address of the network connection priority over the name the client says that it has.

[bmiklautz]

Seems that this is not a FreeRDP bug, closing this issue.
@awdAvenger if it turns out it wasn't the problem you where hitting please re-open.

[HenryJacques]

@nfedera thanks for the clarification!

[ghabxph]

For people who may have this kind of issue:

In your Windows 10 Machine, Go to: System Properties > Remote > Uncheck "Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended)"

Then in your linux machine's terminal, type:
xfreerdp /sec:tls /u:{username} /v:{IP}

I have this kind of issue for a very very long time, and disabling NLA in my windows local machine, and forcing connection to TLS solves my problem.

I like to use xfreerdp because it has multi-monitor support, unlike remmina.

Hope this helps everyone.