ip4 static routes added in NetworkManager UI fail and prevent connection

Bug #1608646 reported by Jeremy Akers
112
This bug affects 24 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

lsb_release -rd:
Description: Ubuntu 16.04.1 LTS
Release: 16.04

Network Settings package version in Software Center:
15.04.0+16.04.20160705-0ubuntu1

Prior to upgrading to 16.04 LTS I was running 14.04 LTS. Using the "Edit Connections..." menu option I had created a custom Ethernet connection that had some custom routes added. These routes are required for me to connect to certain resources on a local network while using Wifi for basic internet. (Physical network locked down, no Internet access available)

I've attached a screenshot showing the routes. These routes were working great in 14.04 (And prior releases of Ubuntu).

However, upon upgrading to 16.04, I noticed this connection would no longer "connect". It would just silently fail. I noticed that if I deleted my custom routes, it would work, but I need those in order to connect to my required network services.

When I try to connect with the routes in place, the connection silently fails in the NetworkManager UI (I get no error message in the UI) but I took a look at syslog and found these:

Aug 1 08:15:19 jeremy-ThinkPad-X1-Carbon-4th NetworkManager[2868]: <error> [1470057319.7268] platform-linux: do-add-ip4-route[2: 10.104.0.0/16 0]: failure 101 (Network is unreachable)
Aug 1 08:15:19 jeremy-ThinkPad-X1-Carbon-4th NetworkManager[2868]: <error> [1470057319.7271] platform-linux: do-add-ip4-route[2: 10.105.0.0/16 0]: failure 101 (Network is unreachable)
Aug 1 08:15:19 jeremy-ThinkPad-X1-Carbon-4th NetworkManager[2868]: <error> [1470057319.7272] platform-linux: do-add-ip4-route[2: 10.51.35.0/24 0]: failure 101 (Network is unreachable)
Aug 1 08:15:19 jeremy-ThinkPad-X1-Carbon-4th NetworkManager[2868]: <error> [1470057319.7273] platform-linux: do-add-ip4-route[2: 10.140.76.0/24 0]: failure 101 (Network is unreachable)
Aug 1 08:15:19 jeremy-ThinkPad-X1-Carbon-4th NetworkManager[2868]: <info> [1470057319.7281] device (enp0s31f6): state change: ip-config -> failed (reason 'config-failed') [70 120 4]
Aug 1 08:15:19 jeremy-ThinkPad-X1-Carbon-4th NetworkManager[2868]: <warn> [1470057319.7289] device (enp0s31f6): Activation: failed for connection 'Windstream'
Aug 1 08:15:19 jeremy-ThinkPad-X1-Carbon-4th NetworkManager[2868]: <info> [1470057319.7309] device (enp0s31f6): state change: failed -> disconnected (reason 'none') [120 30 0]

Now, if I remove the custom routes from the UI, then I can connect. I them manually add the routes using the "ip" command:

sudo /sbin/ip route add 10.104.0.0/16 dev enp0s31f6
sudo /sbin/ip route add 10.105.0.0/16 dev enp0s31f6
sudo /sbin/ip route add 10.51.35.0/24 dev enp0s31f6
sudo /sbin/ip route add 10.140.76.0/24 dev enp0s31f6

This is able to add the routes successfully. So there has to be some problem in the new implementation of NetworkManager in 16.04, because these routes worked in 14.04 and they still work in 16.04 if I just manually add them from the command line.

For now I can work around this issue by manually adding these routes from the command line every time I connect.

Revision history for this message
Jeremy Akers (irwinr12) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in network-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
Ikuya Awashiro (ikuya-fruitsbasket) wrote :

You may set 0.0.0.0 to gateway and work good.

Revision history for this message
Sebastian Marsching (sebastian-marsching) wrote :

The workaround suggested by Ikuya Awashiro (setting the gateway for the route to 0.0.0.0) does not work for me. The problem persits even after applying this workaround. The VPN connection is only established when all static routes are deleted from the configuration.

Revision history for this message
Esel (glumpad) wrote :

For me it works when I enter no Gateway

Revision history for this message
jno (jnoster) wrote :
Revision history for this message
jno (jnoster) wrote :

Message is:
Mar 28 10:40:18 jno-ThinkPad-W500 NetworkManager[899]: <error> [1490686817.9316] platform-linux: do-add-ip4-route[11: 172.17.0.0/16 50]: failure 101 (Сеть недоступна)

Revision history for this message
Qianqian Fang (fangq) wrote :

I have exactly the same. can't access my University's vpn on my new laptop running 10.04. vpn works without any issue on another laptop running 14.04.

I am wondering if I can rollback vpnc and the necessary packages back to 14.04? need to use vpn to connect to work computers.

using the above workaround (leave Gateway blank), I get the following error when trying to connect via vpn:

ERROR: getaddrinfo: Temporary failure in name resolution

Revision history for this message
apetrelli (antonio-petrelli) wrote :

I think that putting 0.0.0.0 works for someone (like me) because, when using this route, a broadcast is sent, both to the original interface and tun0.

Revision history for this message
Andrey Semakin (and-semakin) wrote :

I also have this issue. My PPTP connection was working fine and then I probably added some routes. And now I can't connect. Attach output from 'journalctl -u NetworkManager.service' command.

description: updated
information type: Public → Public Security
information type: Public Security → Public
Revision history for this message
Martin Wildam (mwildam) wrote :

Same issue still on 18.04 bionic

Revision history for this message
Martin Wildam (mwildam) wrote :

Setting gateway in route to 0.0.0.0 helped in my case also, many thanks to apetrelli (antonio-petrelli).

Revision history for this message
Michael Gale (mishagale) wrote :

I'm not sure if this is actually the same bug, but I fixed an issue with the same symptoms, documenting here for the sake of those who come after me:

The NetworkManager tool asks you to input a subnet mask in "dotted-quad" format, however, if you look at the config file created for the connection in /etc/NetworkManager/system-connections, you see that it converts it to /CIDR notation.

However, I had input some routes which didn't actually properly map to a CIDR network specification, which was causing the ip-route add command to fail with an "RTNETLINK answers: Invalid argument" error message.

Correcting or removing these routes fixed my issue.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Michael Gale, your issue is different to the OP's one. The routes the OP has entered are all CIDR notable, he even uses CIDR when entering them via command line.

So please report a new bug, showing which routes you have entered and how they end up in /etc/NetworkManager/system-connections.

In addition, you could report a bug upstream, suggesting to let the rutes be saved in /etc/NetworkManager/system-connections in dotted-quad notation if they cannot be represented in CIDR notation.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Could anyone who still has this problem supply a list of the routes he has entered and how he has entered them and also attach the /etc/NetworkManager/system-connections file to this bug report? Thanks.

Changed in network-manager (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for network-manager (Ubuntu) because there has been no activity for 60 days.]

Changed in network-manager (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Rocus van Oosten (rocus) wrote :
Download full text (4.1 KiB)

I would like to revive this bug report.

I will describe the problem in detail.

I run an ovpn script from the command line and everything goes well.

The ovpn file:

client
dev tun
remote nl.vpn.******.org 443
resolv-retry infinite
nobind
persist-key
persist-tun
auth-nocache
mute-replay-warnings
route 10.0.1.0 255.255.255.0 10.0.2.136
route 10.0.0.0 255.255.255.0 10.0.2.136
route-delay 5
verb 3
explicit-exit-notify 5
remote-cert-tls server
cipher AES-256-CBC
comp-lzo no
proto udp
key-direction 1

I left out certivicates because they are here irrelevant.

The route table before the execution of openvpn is:

Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.2.136 0.0.0.0 UG 100 0 0 enp3s0
10.0.2.0 0.0.0.0 255.255.255.0 U 100 0 0 enp3s0

10.0.2.136 is my home router.

After the execution of sudo openvpn <ovpn file> the route table is:

Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.17.76.1 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 10.0.2.136 0.0.0.0 UG 100 0 0 enp3s0
10.0.0.0 10.0.2.136 255.255.255.0 UG 0 0 0 enp3s0
10.0.1.0 10.0.2.136 255.255.255.0 UG 0 0 0 enp3s0
10.0.2.0 0.0.0.0 255.255.255.0 U 100 0 0 enp3s0
10.17.76.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
128.0.0.0 10.17.76.1 128.0.0.0 UG 0 0 0 tun0
213.152.162.73 10.0.2.136 255.255.255.255 UGH 0 0 0 enp3s0

This looks a bit complicated to me but it is working. Note the two lines for the networks 10.0.1.0/24 and 10.0.0.0/24.
They are needed to divert traffic for those networks to my home router 10.0.2.136.
Traffic for my home network 10.0.2.0/24 stays in the home network.
All other traffic goes to the tun0 device (the vpn provider).

In the Network Manager I imported the ovpn file and the resulting network manager file /etc/NetworkManager/system-connections/vpnnl file is:

id=provider_UDP-443
uuid=88baf716****
type=vpn
autoconnect=false
permissions=

[vpn]
cert-pass-flags=0
cipher=AES-256-CBC
comp-lzo=no-by-default
connection-type=tls
dev=tun
key=***.pem
remote=nl.vpn.provider.org:443
remote-cert-tls=server
ta-dir=1
service-type=org.freedesktop.NetworkManager.openvpn

[ipv4]
dns-search=
method=auto
route1=10.0.1.0/24,10.0.2.136
route2=10.0.0.0/24,10.0.2.136

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

I left out some statements concerning security and privacy. Note the two route statements.
When I make the vpn connection with this connections file I get the error message:
connection failed because VPN service returned invalid configuration.

When I remove the two route statements in the network-manager/ edit connections section the connection is properly made but ofcourse without the two route statements in the route table:

Destination Gat...

Read more...

Rocus van Oosten (rocus)
Changed in network-manager (Ubuntu):
status: Expired → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.