touch-packages team mailing list archive

[Martin <1517452@xxxxxxxxxxxxxxxxxx>]

s/systemd/dbus/

It's dbus not systemd.

** Summary changed:

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

** Summary changed:

- NetworkManager since 15.10 breaks VPN Support
+ NetworkManager since 15.10 break VPN Support

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1517452

Title:
  NetworkManager since 15.10 break VPN Support

Status in network-manager package in Ubuntu:
  Confirmed

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1517452/+subscriptions