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:
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
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.
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
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
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.
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.
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?
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? :)
Hi Thomas, Thanks for the clarification, yes questions answered. I will comment further in 1275012.