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
