GNOME Bugzilla – Bug 702154
No possibility to disable DTLS from the GUI
Last modified: 2020-11-12 14:35:10 UTC
Due to an unknown issue, openconnect DTLS connections do not work reliably on one of the computers I have here. While the network manager configuration dialog offers a lot of options to configure the connection, it does not include one that disables DTLS.
What is the failure mode for DTLS? Does it actually manage to make a connection, but then you lose packets? Or are you only concerned because it *tells* you about attempting to set up DTLS connections, and failing to do so? The idea is that you should never really *have* to disable DTLS manually...
Once a DTLS connection is established, the connection works for the first couple of minutes, but then gets slower and slower until it breaks down completely. It's not quite clear what the source of the problem is. Checking the network traffic on a packet level, it seems that my router fragments the UDP packets, but then fails to re-assemble the fragmented responses correctly. Strangely enough, if two fragments A and B have to be transmitted back to my end point, it only seems to transmit B (yes, the second fragment) and not A. Why it does that I do not know, but the only thing that seems to help is to disable DTLS.
If you reduce the MTU, does that work better? There is supposedly some MTU-discovery that can be done over the DTLS connection with DPD packets; we should look into that. I've actually seen problems with fragment loss before, and in some cases it's been a network driver bug. When a packet is fragmented, you end up with the two resulting packets being sent in *very* quick succession; something that rarely happens otherwise. So you hit race conditions in drivers that don't expect to see a new packet before they've finished processing the previous one. Is this router under your control? It's also vaguely possible that the issue is on the receiving end, but that's less likely. I'm not entirely averse to having a switch to disable DTLS though; patches welcome. Putting it into the config without a UI for it is a no-brainer, and I think we can even expose it in the UI. The GNOME "dumb it down" braindamage hasn't extended to VPN configuration... yet :)
No, does not. Reducing the MTU delays the problem, but does not solve it. It is actually network dependent and not end-point (client) depenent. DTLS works fine within the network of the university, but it does not work from my own access point at home, i.e. the connection is broken somewhere between my access point, the telecom network and the university network. Note further that OpenVPN did not have this issue, even though it also uses UDP tunneling - it is only OpenConnect that creates problems. Concerning the "GNOME" "dumb it down" approach, I afraid that it got so much dumped down that I left Gnome 3 alone because it was more or less unusable for me, but xfce also uses the gnome network manager.
(In reply to Thomas Richter from comment #2) > Once a DTLS connection is established, the connection works for the first > couple of minutes, but then gets slower and slower until it breaks down > completely. It's not quite clear what the source of the problem is. Checking > the network traffic on a packet level, it seems that my router fragments the > UDP packets, but then fails to re-assemble the fragmented responses > correctly. Strangely enough, if two fragments A and B have to be transmitted > back to my end point, it only seems to transmit B (yes, the second fragment) > and not A. Why it does that I do not know, but the only thing that seems to > help is to disable DTLS. I'm confused by this, because it's entirely written as if your router is sending packets to *itself* so I can't tell which direction any of this is in. I have seen problems with the Cisco ASA, where it fails to correctly receive out-of-order packets. With dual bonded ADSL lines, I've seen a large packet get fragmented by OpenConnect into two packets on the VPN. One full-sized packet A, and one shorter packet B. They each go out on different physical connections, and packet B reaches the Cisco ASA first. And then packet A is dropped because of the Cisco bug. Is that what you're seeing? It was reported to Cisco a year or two ago, and I think they might actually get round to fixing it this year sometime...
Previously on Ubuntu 14.04, openconnect via network-manager would work fine to my $WORK VPN, however, after upgrading to 16.04 it seems openconnect via network-manager now fails - BUT if I manually run openconnect via the command-line *with the --no-dtls option* then that works fine. So it would be really useful to have some way of specifying this for network-manager so I could use it to launch openconnect from the GUI etc, and not have to manually invoke openconnect on the command-line.
David is there anything I can do to help progress this?
I am also having this issue. OpenConnect connects and simple packets like ICMP work fine, but more complex traffic like TLS and websockets fail. Passing --no-dtls to the openconnect command resolves the issue. I've found running the Slack websocket test works to prove that the --no-dtls option fixes the issue. https://slack.com/help/test All "Web Socket" tests will fail using openconnect via CLI or NM GUI without the --no-dtls option passed. All tests pass when using --no-dtls. -Brian
(In reply to Brian from comment #8) > I am also having this issue. OpenConnect connects and simple packets like > ICMP work fine, but more complex traffic like TLS and websockets fail. > Passing --no-dtls to the openconnect command resolves the issue. > > I've found running the Slack websocket test works to prove that the > --no-dtls option fixes the issue. > > https://slack.com/help/test > > All "Web Socket" tests will fail using openconnect via CLI or NM GUI without > the --no-dtls option passed. All tests pass when using --no-dtls. > > > -Brian To add to the above, this is on Fedora 25.
A workaround to ALWAYS run openconnect with '--no-dtls': sudo mv /usr/sbin/openconnect /usr/sbin/openconnect.real echo '#!/bin/bash' | sudo tee /usr/sbin/openconnect echo '/usr/sbin/openconnect.real --no-dtls "$@"' | sudo tee -a /usr/sbin/openconnect sudo chmod +x /usr/sbin/openconnect This way when run from network manager --no-dtls is automatically set. This is clearly not ideal and will be overwritten on the next package update - so a 'correct' solution would be preferred instead of this hack.
(In reply to David Woodhouse from comment #1) > What is the failure mode for DTLS? Does it actually manage to make a > connection, but then you lose packets? Or are you only concerned because it > *tells* you about attempting to set up DTLS connections, and failing to do > so? In my case it's UDP packets (from mosh) being dropped and stalling the connection. > The idea is that you should never really *have* to disable DTLS manually... So, is the underlying issue (that of packets being dropped) ultimately a defect in the Cisco VPN device (configuration) or is this an openconnect defect?
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).