Bug 1294309 - Regression: Does not set default route, traffic unprotected
Regression: Does not set default route, traffic unprotected
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: NetworkManager-openvpn (Show other bugs)
23
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Lubomir Rintel
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-26 14:05 EST by Dimitris
Modified: 2016-04-02 14:09 EDT (History)
8 users (show)

See Also:
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 15:55:00 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 759892 None None None 2015-12-29 07:44 EST

  None (edit)
Description Dimitris 2015-12-26 14:05:47 EST
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 14:43:49 EST
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 03:41:37 EST
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 06:16:18 EST
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 06:20:07 EST
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 15:54:25 EST
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-20 23:49:44 EST
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 16:27:49 EST
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 17:01:34 EST
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 14:09:30 EDT
Hi Thomas,

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

Note You need to log in before you can comment on or make changes to this bug.