NetworkManager since 15.10 break VPN Support

Bug #1517452 reported by Martin
42
This bug affects 8 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Confirmed
High
Unassigned

Bug Description

Release: lsb_release -rd
Description: Ubuntu 15.10
Release: 15.10

Package Version:
apt-cache policy network-manager
network-manager:
  Installiert: 1.0.4-0ubuntu5.1
  Installationskandidat: 1.0.4-0ubuntu5.1

apt-cache policy systemd
systemd:
  Installiert: 225-1ubuntu9
  Installationskandidat: 225-1ubuntu9

What you expected to happen:

If I start a VPN-Client like Junipers NetworkConnect or openconnect, I expect a VPN-tunnel with a tun-device and the corresponding routes via this device.

What happened instead:

After a successful connection to the vpn gateway the VPN-Client gets informed about routes it should create on the client from the VPN gateway and performs the routing change. Systemd then seems to notify NetworkManager (NM) about the new interface (in my case tun0). NM now does its magic to the newly created tun0 which is not configuered in NetworkManager.conf. After this only the host route to the tun0 device is left.
There also seems to be a timing issue. About every 10th time NM is faster then i.e. the vpnc-scripts and routing is set up properly.

It is possible to tell NM in /etc/NetworkManager/NetworkManager.conf to ignore tun0 via this:
[keyfile]
unmanaged-devices=interface-name:tun0

Then however it is unclear to me how a VPN-Configuration with NM would work if tun0 is ignored.
In my case users have the opportunity to use Junipers NC which is not supported by NM so a standalone client has to be used, but also could want use openvpn via NM. As for now I assume both is not possible.

1: I think it is necessary to be able to use both ways.
2: It took me quite a while to find out why there where no proper routes. It is essential to tell people how to work around this.
3: systemd-netword is _not_ running on these machines. I would like to understand why NM behaves like this.
4: For testing I used wicd to see if there is a difference. And it is. wicd does not mess with the vpn routes.

Let me know if you need more information.

NetworkManager.conf:

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false
#dns=dnsmasq

[keyfile]
unmanaged-devices=interface-name:tun0

journal: journalctl -u NetworkManager

NetworkManager[859]: <info> (tun0): new Tun device (carrier: OFF, driver: 'tun', ifindex: 6)
NetworkManager[859]: <info> devices added (path: /sys/devices/virtual/net/tun0, iface: tun0)
NetworkManager[859]: <info> device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found.
NetworkManager[859]: <info> (tun0): link connected
NetworkManager[859]: <info> keyfile: add connection in-memory (968e1d17-6272-4a1d-9cfa-d2db26ef9607,"tun0")
NetworkManager[859]: <info> (tun0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
NetworkManager[859]: <info> (tun0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
NetworkManager[859]: <info> Device 'tun0' has no connection; scheduling activate_check in 0 seconds.
NetworkManager[859]: <info> (tun0): Activation: starting connection 'tun0' (968e1d17-6272-4a1d-9cfa-d2db26ef9607)
NetworkManager[859]: <info> (tun0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
NetworkManager[859]: <info> (tun0): device state change: prepare -> config (reason 'none') [40 50 0]
NetworkManager[859]: <info> (tun0): device state change: config -> ip-config (reason 'none') [50 70 0]
NetworkManager[859]: <info> (tun0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
NetworkManager[859]: <info> (tun0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
NetworkManager[859]: <info> (tun0): device state change: secondaries -> activated (reason 'none') [90 100 0]
NetworkManager[859]: <info> (tun0): Activation: successful, device activated.

Tags: wily
Martin (linux-support)
tags: added: wily
Revision history for this message
Martin (linux-support) wrote :

Maybe good to know:
In 15.04 and before this worked as expected. Since then no changes where made to the configuration, client and server.

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
summary: - Systemd + NerworkManager since 15.10 break VPN Support
+ Systemd + NetworkManager since 15.10 break VPN Support
Martin (linux-support)
summary: - Systemd + NetworkManager since 15.10 break VPN Support
+ NetworkManager since 15.10 breaks VPN Support
summary: - NetworkManager since 15.10 breaks VPN Support
+ NetworkManager since 15.10 break VPN Support
Changed in network-manager (Ubuntu):
importance: Undecided → High
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.