← Back to team overview

desktop-packages team mailing list archive

[Bug 1517452] Re: Systemd + NetworkManager since 15.10 break VPN Support


** Summary changed:

- Systemd + NerworkManager since 15.10 break VPN Support
+ Systemd + NetworkManager since 15.10 break VPN Support

You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.

  Systemd + NetworkManager since 15.10 break VPN Support

Status in network-manager package in Ubuntu:

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

  Package Version:
  apt-cache policy network-manager
    Installiert:           1.0.4-0ubuntu5.1
    Installationskandidat: 1.0.4-0ubuntu5.1
  apt-cache policy  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:

  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.





  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.

To manage notifications about this bug go to: