After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 604335 - do not fail silently for incompatible local and remote settings
do not fail silently for incompatible local and remote settings
Status: RESOLVED WONTFIX
Product: NetworkManager
Classification: Platform
Component: VPN: openvpn
git master
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
NetworkManager maintainer(s)
: 613154 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-12-11 05:17 UTC by Mathieu Trudel-Lapierre
Modified: 2014-01-02 16:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Mathieu Trudel-Lapierre 2009-12-11 05:17:46 UTC 
Initially reported here: https://bugs.edge.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/379073

When using nm-openvpn to connect to a OpenVPN server which is configured to use comp-lzo compression and the client option is _not_ configured to use comp-lzo the connection appears to be working, but actually is not. The only indication of a problem is the following line in daemon.log:

nm-openvpn[4429]: WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'

Steps to reproduce:
1. Set-up OpenVPN server with comp-lzo enabled
2. Set-up Ubuntu client through network manager with comp-lzo disabled
3. Connect to VPN

Actual result:
Connection appears to be up, but is not working.

Expected result:
- Network manager shows pop-up with error
or
- Network manager prompt user to enable comp-lzo and reconnect
Comment 1 Dan Williams 2010-02-01 23:07:36 UTC 
Unfortunately this would require screenscraping openvpn output, and openvpn is just too dumb to autonegotiate connection options.  Which is just plain stupid, but it's not my project.

I guess the only way to figure this out is to screenscrape openvpn output, which is really, really icky, or else to enhance openvpn to print these warnings out on the administrative interface, which is the much better option actually.  It should definitely be done, but I'd rather do it the right way...
Comment 2 Dan Williams 2010-03-24 08:26:23 UTC 
*** Bug 613154 has been marked as a duplicate of this bug. ***
Comment 3 Dan Winship 2014-01-02 16:07:04 UTC 
We need better error messages on VPN connection failure, but there's already a bug for that, and we don't want to try to deal with the general fact that OpenVPN configuration sucks.