Bug 1417169 - NetworkManager OpenVPN pushed routes are ignored
Summary: NetworkManager OpenVPN pushed routes are ignored
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager-openvpn
Version: 25
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-27 12:06 UTC by Giovanni Tirloni
Modified: 2021-04-28 23:18 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-12 10:39:30 UTC
Type: Bug


Attachments (Terms of Use)
openvpn manual - pushed routes work (4.41 KB, text/plain)
2017-02-11 22:38 UTC, Giovanni Tirloni
no flags Details
nm openvpn - pushed routes error (10.16 KB, text/plain)
2017-02-11 22:38 UTC, Giovanni Tirloni
no flags Details
nm openvpn - pushed routes error - tracing enabled (73.56 KB, text/plain)
2017-02-11 22:39 UTC, Giovanni Tirloni
no flags Details
pfsense openvpn server configuration (1.47 KB, text/plain)
2017-02-11 22:44 UTC, Giovanni Tirloni
no flags Details
openvpn manual - verbose output (22.58 KB, text/plain)
2017-02-11 22:53 UTC, Giovanni Tirloni
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 758702 0 None None None 2017-06-02 16:01:49 UTC

Description Giovanni Tirloni 2017-01-27 12:06:43 UTC
Description of problem:

When connecting to a OpenVPN server that pushes additional routes, these are ignored and only the immediate link is added as a route.

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.25.1    0.0.0.0         UG        0 0          0 wlp3s0
10.244.200.5    0.0.0.0         255.255.255.255 UH        0 0          0 tun0
192.168.25.0    0.0.0.0         255.255.255.0   U         0 0          0 wlp3s0
192.168.25.1    0.0.0.0         255.255.255.255 UH        0 0          0 wlp3s0
192.168.122.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr0
205.xxx.xxx.10  192.168.25.1    255.255.255.255 UGH       0 0          0 wlp3s0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.244.200.6  netmask 255.255.255.255  destination 10.244.200.5


This server pushes connections for other networks (10.0.0.0/24 and 172.16.12.0/24 in this case), and they are not added to the routing table.

When running OpenVPN manually, the routes are added as expected.

Changing the 'Use this connection only for resources on its network' option has no effect (it only adds another default route through the VPN when it's unchecked).


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

openvpn-2.3.14-1.fc25.x86_64
NetworkManager-openvpn-1.2.6-1.fc25.x86_64
NetworkManager-openvpn-gnome-1.2.6-1.fc25.x86_64


How reproducible: Always


Steps to Reproduce:
1. Configure a OpenVPN connection in NetworkManager (to a server that pushes routes)
2. Verify that the routing table does not have the routes

Actual results: Pushed routes are not added

Expected results: Pushed routes are added


Additional info:

This is how NetworkManager is running OpenVPN on my machine:

/usr/sbin/openvpn --remote x.x.x.x 1194 udp --comp-lzo yes --nobind --dev tun --cipher AES-256-CBC --auth SHA256 --auth-nocache --tls-auth file.key 1 --reneg-sec 0 --verb 1 --syslog nm-openvpn --script-security 2 --up /usr/libexec/nm-openvpn-service-openvpn-helper --debug 0 8749 --bus-name org.freedesktop.NetworkManager.openvpn.Connection_25 --tun -- --up-restart --persist-key --persist-tun --management /var/run/NetworkManager/nm-openvpn-b96c0c67-a284-4936-8013-f3a1c5fbcd15 unix --management-client-user root --management-client-group root --management-query-passwords --auth-retry interact --route-noexec --ifconfig-noexec --client --pkcs12 file.p12 --auth-user-pass --user nm-openvpn --group nm-openvpn



And this is how I run OpenVPN manually:

openvpn --config sample.ovpn



With the sample.ovpn file having the following definitions:

dev tun
persist-tun
persist-key
cipher AES-256-CBC
auth RSA-SHA256
tls-client
client
resolv-retry infinite
remote x.x.x.x
proto udp
lport 0
verify-x509-name "host.example.com" name
auth-user-pass
pkcs12 file.p12
tls-auth file.key 1
ns-cert-type server
comp-lzo adaptive



Contents of the NetworkManager configuration file for this VPN in /etc/NetworkManager/system-connections:

[connection]
id=sample
uuid=b96c0c67-a284-4936-8013-f3a1c5fbcd15
type=vpn
autoconnect=false
permissions=user:username:;
secondaries=
timestamp=1485517181

[vpn]
auth=SHA256
ca=file.p12
cert=file.p12
cert-pass-flags=1
cipher=AES-256-CBC
comp-lzo=yes
connection-type=password-tls
key=file.p12
password-flags=1
remote=x.x.x.x
ta=file.key
ta-dir=1
username=username
service-type=org.freedesktop.NetworkManager.openvpn

[ipv4]
dns-search=
method=auto
never-default=true

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

Comment 1 Beniamino Galvani 2017-02-02 10:54:33 UTC
I can't reproduce the problem with

 openvpn-2.3.14-1.fc25.x86_64
 NetworkManager-openvpn-1.2.6-1.fc25.x86_64
 NetworkManager-1.4.4-3.fc25.x86_64

Can you please run 'nmcli general logging trace' as root, activate the VPN and attach logs from 'journalctl -u NetworkManager -e -b'? Thanks!

Comment 2 Giovanni Tirloni 2017-02-02 12:20:05 UTC
I cannot reproduce it anymore. Before opening this BZ, I rebooted the machine a couple of times and did the whole "wifi off; wifi on; vpn on; vpn off;" process a couple of times, and it always ignored the pushed routes.

I looked at the DNF logs and I don't see anything particularly relevant to NetworkManager or OpenVPN.

Thanks for trying to reproduce this issue. I believe this BZ can be closed.

Comment 3 Beniamino Galvani 2017-02-02 12:42:59 UTC
(In reply to Giovanni Tirloni from comment #2)
> Thanks for trying to reproduce this issue. I believe this BZ can be closed.

Ok, thanks.

Comment 4 Giovanni Tirloni 2017-02-11 22:37:44 UTC
I was able to rebuild the environment and reproduce the issue.

The issue happens when the OpenVPN server is configured to advertise a certain network as being local (10.10.10.10/24) and the pushed routes are for IPs within that range (10.10.10.{59,60,61,61}).

It seems these errors are relevant:

Feb 11 20:32:47 main NetworkManager[1101]: <debug> [1486852367.9674] platform: route: adding or updating IPv4 route: 10.10.10.59/32 via 192.168.0.1 dev 14 metric 50 mss 0 src vpn
Feb 11 20:32:47 main NetworkManager[1101]: <debug> [1486852367.9674] platform-linux: netlink: recvmsg: error message from kernel: Network is unreachable (101) for request 263
Feb 11 20:32:47 main NetworkManager[1101]: <error> [1486852367.9674] platform-linux: do-add-ip4-route[14: 10.10.10.59/32 50]: failure 101 (Network is unreachable)

Please see the attached files for more details.

Comment 5 Giovanni Tirloni 2017-02-11 22:38:18 UTC
Created attachment 1249407 [details]
openvpn manual - pushed routes work

Comment 6 Giovanni Tirloni 2017-02-11 22:38:44 UTC
Created attachment 1249408 [details]
nm openvpn - pushed routes error

Comment 7 Giovanni Tirloni 2017-02-11 22:39:09 UTC
Created attachment 1249409 [details]
nm openvpn - pushed routes error - tracing enabled

Comment 8 Giovanni Tirloni 2017-02-11 22:44:15 UTC
Created attachment 1249410 [details]
pfsense openvpn server configuration

Comment 9 Giovanni Tirloni 2017-02-11 22:53:37 UTC
Created attachment 1249423 [details]
openvpn manual - verbose output

Comment 10 Giovanni Tirloni 2017-02-11 22:56:07 UTC
The reasoning behind these pushed routes is that, for certain IPs, we don't want their traffic to go through the VPN but continue to go through the public Internet (because they are VoIP/SIP servers). There is one pushed route for the VPN server itself to avoid a loop once the VPN is established.

It seems running OpenVPN manually, the correct `ip route add` commands are executed.

Comment 11 Beniamino Galvani 2017-03-07 08:26:47 UTC
I see the problem now:

  push "route 10.10.10.10 255.255.255.255 net_gateway"

NM-openvpn at the moment does not support special route keywords as 'vpn_gateway', 'net_gateway' or 'remote_host'.

Comment 12 Eugene Kanter 2017-05-31 14:41:05 UTC
Not sure if related or relevant, before opening a new one wanted to ask about
https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/1603600

Comment 13 Thomas Haller 2017-06-02 16:01:49 UTC
Upstream bug for this feature (https://bugzilla.gnome.org/show_bug.cgi?id=758702).


> Feb 11 20:27:57 main NetworkManager[1101]: <info>  [1486852077.4032] vpn-connection[0x561d9082f740,2c6bd6fb-0ebd-44eb-a26e-4a42bda705f6,"EXAMPLE",13:(tun0)]: Data:   Static Route: 10.10.10.62/32   Next Hop: 192.168.0.1

it seems that openvpn calls the helper script with the special "net_gateway" already resolved. Instead, the helper would need to know that this is "net_gateway".

Comment 14 dptec 2017-10-31 12:51:06 UTC
this problem is present also on my version:

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

openvpn-2.4.3-1.fc25.x86_64
NetworkManager-openvpn-1.2.8-2.fc25.x86_64
NetworkManager-openvpn-gnome-1.2.8-2.fc25.x86_64


How reproducible: Always


Steps to Reproduce:
1. Configure a OpenVPN connection in NetworkManager (to a server that pushes routes)
2. Verify that the routing table does not have the routes

Actual results: Pushed routes are not added

Expected results: Pushed routes are added

Running openvpn manually all is correct.

Comment 15 Fedora End Of Life 2017-11-16 18:35:55 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 16 Fedora End Of Life 2017-12-12 10:39:30 UTC
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 17 Robert Story 2021-04-28 23:18:14 UTC
This is still an issue in Fedora 33, 

Apr 28 18:41:04 host nm-openvpn[2069577]: [myvpn] Peer Connection Initiated with [AF_INET6]2001:XXX
Apr 28 18:41:05 host nm-openvpn[2069577]: OpenVPN ROUTE: remote_host undefined
Apr 28 18:41:05 host nm-openvpn[2069577]: OpenVPN ROUTE: failed to parse/resolve route for host/network: remote_host

# rpm -qa|grep openvpn
NetworkManager-openvpn-1.8.12-1.fc33.1.x86_64
plasma-nm-openvpn-5.20.5-1.fc33.x86_64
openvpn-2.4.10-1.fc33.x86_64


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