Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1294309

Summary: Regression: Does not set default route, traffic unprotected
Product: [Fedora] Fedora Reporter: Dimitris <dimitris>
Component: NetworkManager-openvpnAssignee: Lubomir Rintel <lkundrak>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 23CC: choeger, dcbw, dwt, huzaifas, lkundrak, psimerda, steve, thaller
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: NetworkManager-1.0.10-2.fc23 NetworkManager-openvpn-1.0.8-1.fc23 NetworkManager-openvpn-1.0.8-1.fc22 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-01-08 20:55:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dimitris 2015-12-26 19:05:47 UTC
Description of problem:

Default route is not changed to go through the VPN tunnel.

Version-Release number of selected component (if applicable):

1.0.8-1.fc23

How reproducible:

Every time

Steps to Reproduce:
1. server configured to push redirect-gateway

2. client configured/left to defaults of accepting routes from server:
[ipv4]
dns-search=
method=auto

3. When I start the VPN connection, my default route stays though the local WLAN:

default via 192.168.1.1 dev wlp3s0  proto static  metric 600 
10.24.24.6 dev tun0  proto kernel  scope link  src 10.24.24.6  metric 50 
<VPN server addr> via 192.168.1.1 dev wlp3s0  proto static  metric 600 
192.168.1.0/24 dev wlp3s0  proto kernel  scope link  src 192.168.1.192  metric 600 
192.168.124.0/24 dev virbr0  proto kernel  scope link  src 192.168.124.1 


Actual results:

Default route remains unchanged

Expected results:

Default route used to (last checked roughly a month ago) be through VPN tunnel.

Additional info:

Comment 1 Dimitris 2015-12-26 19:43:49 UTC
Running openvpn client from a terminal with:

sudo openvpn --remote <VPN server> --nobind --dev tun --cipher AES-256-CBC --auth SHA256 --auth-nocache --remote-cert-tls server --reneg-sec 0 --persist-key --persist-tun --client --ca /etc/openvpn/root_ca_cert.pem --cert /etc/openvpn/my_vpn_chain.pem --key /etc/openvpn/my_vpn_key.pem

leaving nm-openvpn-service-openvpn-helper out of the loop, resutls in the correct routing table (server is pushing redirect-gateway):

default via 10.24.24.5 dev tun0 
10.24.24.1 via 10.24.24.5 dev tun0 
10.24.24.5 dev tun0  proto kernel  scope link  src 10.24.24.6 
<VPN server> via 192.168.1.1 dev wlp3s0 
192.168.1.0/24 dev wlp3s0  proto kernel  scope link  src 192.168.1.192  metric 600 
192.168.124.0/24 dev virbr0  proto kernel  scope link  src 192.168.124.1

Comment 2 Thomas Haller 2016-01-05 08:41:37 UTC
The gnome issue 759892 was bisected to be related to (but not caused by) http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=df4e535 .
That patch was not part of 1.0.8-1.

You said that you have the issue with 1.0.8-1.fc23. I suspect it was actually 1.0.10-1.fc23, because 1.0.8-1.fc23 was in testing (never reached stable) and was updated to 1.0.10-1.fc23 on the 23rd December.

Comment 3 Fedora Update System 2016-01-06 11:16:18 UTC
NetworkManager-1.0.10-2.fc23 NetworkManager-fortisslvpn-1.0.8-1.fc23 NetworkManager-openconnect-1.0.8-1.fc23 NetworkManager-openswan-1.0.8-1.fc23 NetworkManager-openvpn-1.0.8-1.fc23 NetworkManager-vpnc-1.0.8-1.fc23 network-manager-applet-1.0.10-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-2ae867c402

Comment 4 Fedora Update System 2016-01-06 11:20:07 UTC
NetworkManager-1.0.10-2.fc22 NetworkManager-fortisslvpn-1.0.8-1.fc22 NetworkManager-openconnect-1.0.8-1.fc22 NetworkManager-openswan-1.0.8-1.fc22 NetworkManager-openvpn-1.0.8-1.fc22 NetworkManager-vpnc-1.0.8-1.fc22 network-manager-applet-1.0.10-1.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-efc06edc85

Comment 5 Fedora Update System 2016-01-08 20:54:25 UTC
NetworkManager-1.0.10-2.fc23, NetworkManager-fortisslvpn-1.0.8-1.fc23, NetworkManager-openconnect-1.0.8-1.fc23, NetworkManager-openswan-1.0.8-1.fc23, NetworkManager-openvpn-1.0.8-1.fc23, NetworkManager-vpnc-1.0.8-1.fc23, network-manager-applet-1.0.10-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 6 Fedora Update System 2016-01-21 04:49:44 UTC
NetworkManager-1.0.10-2.fc22, NetworkManager-fortisslvpn-1.0.8-1.fc22, NetworkManager-openconnect-1.0.8-1.fc22, NetworkManager-openswan-1.0.8-1.fc22, NetworkManager-openvpn-1.0.8-1.fc22, NetworkManager-vpnc-1.0.8-1.fc22, network-manager-applet-1.0.10-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

Comment 7 Dennis W. Tokarski 2016-01-27 21:27:49 UTC
Hi, can I request this bug be reopened? I'm asking here because
I suspect this problem is/was tightly related to Bug 1275012,
and because of something Thomas Haller said here in comment #2.

Current behavior using (and note these are the latest offered
in the repos as of this writing)

  NetworkManager-1.0.10-2.fc23.x86_64
  NetworkManager-openvpn-1.0.8-1.fc23.x86_64

is that upon startup a default route is set through the OpenVPN
tunnel, consistent with the fix announced above.

However, the old default route is still left in place per
Dimitris' report in bug 1275012. 

Thomas' observation that 1.0.8-1.f23 was never released when
in fact it's currently in the F23 repo makes me wonder if there's
a version skew problem

Should there be a NetworkManager-openvpn-1.0.10-2.fc23 available?

Or is the retention of the old default route deliberate?

Comment 8 Thomas Haller 2016-01-27 22:01:34 UTC
Hi Dennis,

I commented on bug 1275012. That one there is possibly not a bug (or at least, it's not clear yet why it would be an issue).


> However, the old default route is still left in place per
> Dimitris' report in bug 1275012.

right. Which has nothing to do with this bug (1294309).
Your issue is indeed bug 1275012, but maybe you can elaborate there *why* it is actually an issue for you?


This bug here, doesn't have enough debug logs to confirm it definitely, but chances are pretty high that it is fixed by NetworkManager-1.0.10-2.



NetworkManager core and libraries are backward compatible with (VPN) plugins, thus it's just fine that your plugin version is lower. Also, the bug was not in the plugin itself.
Finally, an upstream 1.0.10 release of network-manager-openvpn package doesn't even exist because since 1.0.8 there weren't enough relevant changes.



Does this answer your questions? :)

Comment 9 Dennis W. Tokarski 2016-04-02 18:09:30 UTC
Hi Thomas,

Thanks for the clarification, yes questions answered. I will comment further in 1275012.