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 Desktop
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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to