Description of problem: I can't connect this morning to our normal corporate OpenVPN (tried two different endpoints) and noticed that yesterday I'd had a NetworkManager-openvpn update. I'm using the nm-applet (from an xfce desktop) to connect. Version-Release number of selected component (if applicable): NetworkManager-openvpn-1.2.4-1.fc24.x86_64 NetworkManager-1.2.2-2.fc24.x86_64 How reproducible: Seems 100% Steps to Reproduce: 1. Connect to preconfigured OpenVPN Actual results: Apparently connects; lock shown on the icon; but no traffic passes; noticed: nm-openvpn[1963]: Bad LZO decompression header byte: 42 repeatedly in logs Expected results: A working connection. Additional info: I've not tried rolling back yet.
OK, a bit more debugging. 1) My logs have the warning: Jul 12 08:56:32 dgilbert-t530 nm-openvpn[1963]: WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo' that wasn't in yesterday's logs (journalctl -b-1 -u NetworkManager | grep -i lzo) The nm-applet didn't show it as being on; so I tried turning it on and it didn't help - so I turned it back *off* and both that comp-lzo warning and the Bad LZO decompression warning have gone. But I still don't get connectivity. 2) It looks like I'm not getting the route added that the server sent over; I can see the IP Config Get reply, and see it has a Static Route entry (and that looks the same as yesterdays that worked), but 'ip route' doesn't show the route; if I add it manually it's working.
The routing fixed itself after a reboot; so I think the only problem was that it was incorrectly turning lzo on even when I didn't originally have it enabled and which cleared when I turned it off on the gui and back on.
For reference, I am seeing this as well. I can confirm that I see Jul 11 10:53:41 atlantis nm-openvpn[3941]: WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo' followed by Jul 11 10:57:49 atlantis nm-openvpn[3941]: Bad LZO decompression header byte: 42 And although it states it has connected to the corporate vpn it has not. Downgrading to NetworkManager-openvpn-1:1.2.2-1.fc24.x86_64 from NetworkManager-openvpn-1:1.2.4-1.fc24.x86_64 fixed it. I haven't (yet) tried the turning compression off/on again in the gui.
Tried compression on/off and a reboot and it still doesn't connect for me.
(In reply to Nick Cross from comment #4) > Tried compression on/off and a reboot and it still doesn't connect for me. Has the 'comp-lzo' warning and 'Bad LZO decompression header' warning gone for you or is it still there? Dave
Annoyingly its still there. I thought the recent Fed update might resolve it as well as there were bugs that might related to this? (bug 1327284)
(In reply to Nick Cross from comment #6) > Annoyingly its still there. I thought the recent Fed update might resolve it > as well as there were bugs that might related to this? (bug 1327284) Hmm if you've got those warnings then it sounds like it's not turned the compression off for you. It's a bit difficult to know exactly which bit of fiddling did it for me; I think I tried turning it on and reconnecting, then when that failed turning it off and reconnecting.
I believe you're right. I think I'll have to have extended play with it at home when I have more time :-(
Are you using Gnome or KDE to connect? I have openvpn-2.3.11-1.fc24.x86_64 plasma-nm-openvpn-5.6.5-2.fc24.x86_64 NetworkManager-openvpn-1.2.2-1.fc24.x86_64 and that works fine. But with later NetworkManager-openvpn it fails (even after further attempts with different comp-lzo settings etc).
(In reply to Nick Cross from comment #9) > Are you using Gnome or KDE to connect? xfce :-) > I have > > openvpn-2.3.11-1.fc24.x86_64 > plasma-nm-openvpn-5.6.5-2.fc24.x86_64 > NetworkManager-openvpn-1.2.2-1.fc24.x86_64 > > and that works fine. But with later NetworkManager-openvpn it fails (even > after further attempts with different comp-lzo settings etc). NetworkManager-openvpn-gnome-1.2.4-1.fc24.x86_64 NetworkManager-openvpn-1.2.4-1.fc24.x86_64 openvpn-2.3.11-1.fc24.x86_64 network-manager-applet-1.2.0-1.fc24.x86_64 nm-connection-editor-1.2.0-1.fc24.x86_64 I start the VPN using the nm-applet widget, which seems to come from network-manager-applet. Editing seems to be done by nm-connection-editor. Dave
Thanks for that! I installed NetworkManager-openvpn-gnome network-manager-applet and configured using them my VPN targets as per your instructions. Interestingly "comp-lzo=no" then disappeared from /etc/NetworkManager/system-connections/ovpn-* And now I have a successful connection. My guess is while the network-manager-applet correctly edited the connection to remove the option the kde version didn't?
(In reply to Nick Cross from comment #11) > Thanks for that! > > I installed NetworkManager-openvpn-gnome network-manager-applet and > configured using them my VPN targets as per your instructions. Interestingly > "comp-lzo=no" then disappeared from > /etc/NetworkManager/system-connections/ovpn-* > > And now I have a successful connection. > > My guess is while the network-manager-applet correctly edited the connection > to remove the option the kde version didn't? Possibly; now I used to use KDE as well (back in f22 days) which makes me wonder if I used to have the 'comp-lzo=no' and that's the problem, perhaps this new nm-openvpn doesn't understand that? There's this comment in the source (properties/auth-helpers.c) but I don't know the details; if (NM_IN_STRSET (value, "yes", "adaptive")) { /* the UI currently only supports "--comp-lzo yes" or omitting the "--comp-lzo" * flag. * * Internally, we also support "--comp-lzo [adaptive]" and "--comp-lzo no" * which have different meaning for openvpn. */ widget = GTK_WIDGET (gtk_builder_get_object (builder, "lzo_checkbutton")); gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (widget), TRUE); }
That comment comes from Thomas's b37fda commit; Thomas what do you reckon? Is this a behaviour with a comp-lzo=no - perhaps the KDE setup was setting that and then breaks on this upgrade? Dave
Is this related? : https://bugs.kde.org/show_bug.cgi?id=365816
I am also experiencing this issue on KDE (using the KDE applet). I tried to manually remove comp-lzo=no in my /etc/NetworkManager/system-connections/ file, but when I used the KDE applet to connect I guess it changed it back to the way it used to be. I then tried to edit it by hand and use the nmcli tool to bring the VPN up, and it came back again. Any ideas for alternative workarounds to using the Gnome applet?
I downgraded to NetworkManager-openvpn-1.2.2-1.fc24 and that resolved the issue for me. https://bodhi.fedoraproject.org/updates/FEDORA-2016-73f517cf1a
@Randy : as per comment 11 I reconfigured my connections using the gnome applet. I then removed NetworkManager-openvpn-gnome network-manager-applet and have since been able to connect successfully using KDE. Although I daren't touch the KDE configuration as I suspect its not handling the options correctly. Possibly this commit http://commits.kde.org/plasma-nm/31bcd5f2cffd1c19fbd10ab0f4172f2d82eff194 from the bug referenced on comment 14 might help
Comment 11 also worked for me. Some diagnostic tips if it connects but doesn't route: 1) ip address show dev tun0 Get the IP address 2) ping <<tun_ip_address>> The pings worked for me 3) ip route | grep tun0 Get the gateway (the "via " argument) 4) ping <<tun_gateway_ip_address>> The pings failed for me 5) Try: openvpn --config <<openvpn_config_file>> If it works, the interaction is with NetworkManager and OpenVPN
I have same experience, workaround from comment 11 solved the issue for me.
I also removed plasma-nm
plasma-nm used to put comp-lzo=no if the checkbox was not checked (opposed to nm-connection-editor that sets nothing). But networkmanager-openvpn worked with that because it was only interested in comp-lzo=yes. However, with https://git.gnome.org/browse/network-manager-openvpn/commit/?id=2ecf18c25a7bee7f0122d9d666a7e11cd8b55ea3 commit, networkmanager-openvpn pays attention to all comp-lzo values and thus comp-lzo=no setting added with plasma-nm really became "--comp-lzo no" passed to openvpn. Nevertheless, the mentioned plasma-nm commit https://quickgit.kde.org/?p=plasma-nm.git&a=commit&h=31bcd5f2cffd1c19fbd10ab0f4172f2d82eff194 should fix the issue, because it adds a combobox to the checkbox, and puts comp-lzo=something to the configuration only if the checkbox is checked.
I filed an issue against plasma-nm (for KDE) to ask for that patch to be backported. Perhaps we each need to report this problem against the specific NM widgets we use and mark them each as blocking this issue?
plasma-nm users: please test the plasma-nm updates in Bodhi from https://bugzilla.redhat.com/show_bug.cgi?id=1365663 and report on Bodhi if they work for you. Jan Grulich was kind enough to backport the patch that Blueowl mentioned for us to try out!
I agree with the analysis of comment 21. Together with a new nm-openvpn, an explicit comp-lzo=no setting is now interpreted differently from an absent comp-lzo setting. plasma-nm UI should be updated [1], to either support all 4 options that openvpn support [2]. Alternativly, it should behave like nm-connection-editor which only supports 2 options a boolean checkbox, but where an unchecked comp-lzo option means not "comp-lzo=no" but ~no comp-lzo~. [1] https://quickgit.kde.org/?p=plasma-nm.git&a=commit&h=31bcd5f2cffd1c19fbd10ab0f4172f2d82eff194 [2] https://git.gnome.org/browse/network-manager-openvpn/commit/?id=2ecf18c25a7bee7f0122d9d666a7e11cd8b55ea3 [3] https://git.gnome.org/browse/network-manager-openvpn/diff/properties/auth-helpers.c?id=2ecf18c25a7bee7f0122d9d666a7e11cd8b55ea3 This only affects users who used plasma-nm to create a connection and now have in their connection wrongly "comp-lzo=no". See the output of `nmcli connection show $OVPN_CONNECTION`. I think the fix here is to edit the connection and remove the comp-lzo setting -- for example by editing the connection in nm-connection-editor. It's bad to break existing connections, but IMO it is really caused by a subtle bug in plasma-nm. So I think the acceptable fix is to require the user to fix the wrongly created connection.
this is now fixed in upstream nm-openvpn: https://bugzilla.gnome.org/show_bug.cgi?id=769177#c7
NetworkManager-openvpn-1.2.4-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9565d84a71
NetworkManager-openvpn-1.2.4-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-645466c626
NetworkManager-openvpn-1.2.4-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-9565d84a71
NetworkManager-openvpn-1.2.4-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-645466c626
NetworkManager-openvpn-1.2.4-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
NetworkManager-openvpn-1.2.4-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.