[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

I don't think remmina will be updated to 1.27 (1.26 would be enough). Usually the version of the package remain the same, only some patches get applied when needed. Browsers are exempt from that rule. Ubuntu maintainers might cherry pick this:

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

@t2t-exe some questions: is the error message exactly the one mentioned here? what version is the target rdp server (Windows7, Windows 10, Windows Server 2019, ..)? since you use a new remmina version, what is the tls security level set to? -- You received this bug notification because you are

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

I can confirm that 1.6.1+dfsg1-3ubuntu2 fixes the gateway issue -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to freerdp2 in Ubuntu. https://bugs.launchpad.net/bugs/1954970 Title: remmina "Cannot connect to the RDP server ... via TLS.

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

remmina will probably have a tls security level switch in the future. https://gitlab.com/Remmina/Remmina/-/commit/cf4d8f99ac258248b8e3f3a5314ae047a210a3e9 imo it would be cleaner to backport this instead of lowering the default security for everyone. In the next ubuntu version I think the will

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

@omriasta are you sure you did not use /sec:rdp? 2.6.1+dfsg1-3ubuntu1 does not contain the upstream patch and will 100% work over gateway if linked to openssl3 and using a tls based transport over rdp gateway (nla/ext/tls), but as said /sec:rdp always worked if the remote end allowed it The

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

I have built a version that includes my mentioned security level workaround. It's in ppa:saxl/freerdp2 With that this bug report should be addressed -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to freerdp2 in Ubuntu.

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

@blaze status 403 is quite strange, but afaik openssl1.1 is not in jammy. If you still have it this is because it probably does not get removed when updating. I will try to make a package that fixes both rdp gateway and windows < 8. It would be very useful if you (and probably others) would be

[Desktop-packages] [Bug 1970655] Re: ubuntu 22.04 fails connecting to a rdp server through a rdp gateway

I've build a package that includes the fix mentioned above in ppa:saxl/freerdp if someone can test if it works note however that a 2008r2 gateway probably fails with ERRCONNECT_TLS_CONNECT_FAILED since openssl3.0 is not compatible with 2008r2 on tls seclevel 1 anymore (#1954970). -- You

[Desktop-packages] [Bug 1970068] Re: L2TP+IPSec not working after upgrade to 22.04 LTS

*** This bug is a duplicate of bug 1951832 *** https://bugs.launchpad.net/bugs/1951832 this is probably not a duplicate but this https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/961 #1951832 does talk about a issue with xl2tpd, looking at this log output, the ppp session

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

ok, I created a bug report dedicated for the rdp gateway issue https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1970655 regarding the windows 6.1 tls issue (Windows 7 and Windows Server 2008 R2, probably also Vista and Server 2008) there is now an upstream report here

[Desktop-packages] [Bug 1970655] [NEW] ubuntu 22.04 fails connecting to a rdp server through a rdp gateway

Public bug reported: There is a regression in freerdp if linked/compiled against openssl 3 This has been fixed upstream with https://github.com/FreeRDP/FreeRDP/commit/9d7c20ce8fe50bd6de54e7480b5096761a510daf.patch The upstream bug report was https://github.com/FreeRDP/FreeRDP/issues/7797 This

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

reading the first message actually it would be better splitting out the gateway fix since this bug really talks about windows 2008r2. If you agree I will make a new report about the backport of the gateway fix -- You received this bug notification because you are a member of Desktop Packages,

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

The relevant change is SHA1 in openssl3 https://github.com/openssl/openssl/commit/aba03ae571ea677fc484daef00a21ca8f7e82708 SHA1 is, contrary to what someone would expect given that the documentation says: Level 4 Security level set to 192 bits of security. As a result RSA, DSA and DH keys

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

I just discovered that a direct tls connection to a windows 7 (=2008r2) rdp server indeed fails with ERRCONNECT_TLS_CONNECT_FAILED the error is that there is no cipher match (this probably happens also with a 2008r2 based rdp gateway server, but that someone would need to check) this however

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

again: a debug log output would be very useful. With a gateway there are actually two TLS handshakes. It would be useful what handshake fails. What version of RD Gateway are you using? If it is a 2008/2008R2 based one, is that even openssl3 compatible? (I checked that TLS1.0 is enabled on the

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

> I've been testing this patch and it didn't help in my case what would probably be useful in this thread if someone would post the output of ex. xfreerdp /v: /log-level:debug I know we are talk about remmina here, but it would be very strange if xfreerdp works and remmina doesn't. For me

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

https://github.com/FreeRDP/FreeRDP/pull/7822 addresses a gateway issue only, so if you don't use a gateway this will not fix anything for you. I just compiled the latest ubuntu 2.6.1 version with this patch applied and for me now gateway connections work -- You received this bug notification

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

it is now fixed upstream and in stable-2.0 https://github.com/FreeRDP/FreeRDP/pull/7823 https://github.com/FreeRDP/FreeRDP/pull/7822 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to freerdp2 in Ubuntu.

[Desktop-packages] [Bug 1968195] Re: websocket transport is never enabled

closed in tandem with #1968577. This was also backported to stable-2.0 branch ** Changed in: freerdp (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to freerdp in Ubuntu.

[Desktop-packages] [Bug 1968195] [NEW] websocket transport is never enabled

Public bug reported: freerdp supports an rdp gateway with websocket transport since 2.3.0. There was however a backport bug that never enabled this feature since the introduction to disable this feature (by /gt:auto,no-websockets) the relevant stable push is

[Desktop-packages] [Bug 1752670] [NEW] ppp 2.4.7-2+1ubuntu1 bionic mschap broken

Public bug reported: pppd 2.4.7-2+1ubuntu1 breaks vpn connections to Windows and Mikrotik Servers. It seams only mschap is broken. manually compiling https://github.com/paulusmack/ppp/ fixes it, so the problem seams to be downstream. Removing replace-vendored-hash-functions.patch seams to fix

[Desktop-packages] [Bug 1713226] Re: systemd-networkd messes up networking

The example 2 in my first posting is not an bug since the package contains /lib/systemd/network/80-container-host0.network. As I wrote this only affects systemd-nspawn containers the unexpected "thing" is that when you upgrade you do not expect a system wide configuration that is active in

[Desktop-packages] [Bug 1713226] Re: systemd-networkd messes up networking

Here are the files of the networkmanager systemd-networkd conflict (I already removed ifupdown, the problem is the same, so we say for sure networkmanager or systemd-networkd causes the problem) the output of ip a is the following: 1: lo: mtu 65536 qdisc noqueue state

[Desktop-packages] [Bug 1713226] Re: systemd-networkd messes up networking

this was a upgrade so the ifupdown problem should not happen with clean installs. How is the migration planned? If for example one will do a upgrade from 16.04 to the next 18.04 such problems are a clear show stopper since breaking the network for most servers will mean needing physical access.