Freerdp: [tsocks] v2 client can't connect when v1 can

[truekonrads]

I can establish a connection v1 client (kali build), but cannot establish connectiong using v2 client:

On v1:
client versions:
/usr/bin/xfreerdp --version
This is FreeRDP version 1.1.0-beta1 (git n/a)
tsocks /usr/bin/xfreerdp /client-hostname:myhostname /u:domain\user '/p:password' /v:1.2.3.4 /cert-ignore -sec-nla +clipboard /h:600 /w:1024
loading channel cliprdr
connected to 1.2.3.4:3389

On v2:
tsocks /usr/local/bin/xfreerdp /client-hostname:myhostname /u:domain\user '/p:password' /v:1.2.3.4 /cert-ignore -sec-nla
[15:27:44:094] [13333:13334] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[15:28:00:947] [13333:13334] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_FAILED [0x00020006]
[15:28:00:947] [13333:13334] [ERROR][com.freerdp.core] - failed to connect to 1.2.3.4

[akallabeth]

Could you please add a little more information (as in which versions you're using and what you're connecting to)?
A run with /log-level:trace may also reveal additional information about the issue.

[truekonrads]

v2 build is today's git:
/usr/local/bin/xfreerdp --version
This is FreeRDP version 2.0.0-dev3 (9de311fee)

Trace logs:
[15:51:45:767] [13442:13443] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx
[15:51:45:768] [13442:13443] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[15:51:45:937] [13442:13443] [DEBUG][com.freerdp.client.x11] - Searching for XInput pointer device
[15:51:45:940] [13442:13443] [DEBUG][com.freerdp.client.x11] - Pointer device: 7
[15:51:45:961] [13442:13443] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE
[15:51:45:961] [13442:13443] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE
[15:51:45:961] [13442:13443] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE
[15:51:45:961] [13442:13443] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE
[15:51:45:961] [13442:13443] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: FALSE
[15:51:45:961] [13442:13443] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE
[15:51:45:961] [13442:13443] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_TLS
[15:51:45:961] [13442:13443] [DEBUG][com.freerdp.core.nego] - Attempting TLS security
[15:51:45:961] [13442:13443] [DEBUG][com.freerdp.core] - connecting to peer 1.2.3.4
[15:52:01:626] [13442:13443] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_FAILED [0x00020006]
[15:52:01:626] [13442:13443] [ERROR][com.freerdp.core] - failed to connect to 1.2.3.4

Windows version is: Microsoft Windows [Version 6.0.6002]

[akallabeth]

@truekonrads Ok, tested with same commit and /v:<ip> as well as /v:<url> no such issue.
You have changed the ip 1.2.3.4 from something you really used, or did you try to connect to that?

[akallabeth]

@truekonrads Oh, and you did enable something different to NLA authentication as you explicitly disable it?

[truekonrads]

@akallabeth the -sec-nla was a requirement as I don;t connect from a domain joined system and it didn't work withit enabled... the 1.2.3.4 is not the actual IP of course.

[truekonrads]

What is the timeout for declaring connection invalid? maybe that changed from version to version?

[akallabeth]

@truekonrads NLA does not have much to do with domains. Does it work if you omit that parameter?

[akallabeth]

@truekonrads Timeout is still 15 seconds

[truekonrads]

@akallabeth no change without the -sec nla. I was under the impression that NLA done via Kerberos and then if client has a krb ticket or not makes a difference...?

[akallabeth]

@truekonrads There is the option WITH_GSSAPI to enable kerberos, but NLA is an authentication mode. Anyway, you can do a nmap of the destination? this error code is only set if the server can not be resolved (if using an ip quite impossible) or the destination can not be reached (port closed/no server running on that IP).

[truekonrads]

@akallabeth the command line arguments are exactly the same, only difference is the binary - v1 or v2.

[akallabeth]

Ok, that is strange enough. Does it work with just /v and entering user/pwd afterward? Need to pinpoint this, can't reproduce with any server here :/

[hardening]

Isn't it related to the usage of tsocks ? Perhaps we're doing something in 2.0 that is not catched by tsocks ?

[truekonrads]

I tried with just /v: parameter (still under tsocks), with same effect. I also ran tcpdump to see if by chance any connections are direct,but no - it all goes through socks

[akallabeth]

confirmed, this is related to tsocks not working with current freerdp

[hardening]

BTW now you can use the socks proxy feature (/proxy:socks://user:pass@host:port)

[truekonrads]

@akallabeth I'm dying to know why - considering tsocks preloads an LD to hijack the usual system calls for establish connection.

[dashingvik]

BTW now you can use the socks proxy feature (/proxy:socks://user:pass@host:port)

@hardening
I am using proxy server on win server and facing same issue. Can you let me know how to use above mentioned parameter ?