networkmanager starts infinite number of VPN daemons

[Adrian Freihofer <adrian freihofer gmail com>]

Hi,

Setup an OpenVPN connection with NetworkManager 1.0.10 is not always painless... I ended up with a setup 
where an
infinite number of openvpn daemons tried to connect to one single server.
The problem seems to be that NetworkManager does not (or at least not in any case) stop a VPN connection 
(stop the
openvpn daemon) to a particular remote before setting up a new VPN connection (start an openvpn daemon) to 
the same
remote.


"systemd-cgls" shows many openvpn processes (most lines deleted)

├─1 /sbin/init
└─system.slice
...
  ├─NetworkManager.service
  │ ├─ 466 /usr/sbin/NetworkManager --no-daemon
  │ ├─1278 /usr/sbin/openvpn --remote nemp-server 1194 udp --comp-lzo --nobind --dev tun --cipher BF-CBC 
--auth-nocache
--remote-cert-tls server --reneg-sec 0 --syslog nm-openvpn --script-security 2 --up 
/usr/lib/networkmanager-openvpn/nm-
openvpn-service-openvpn-helper --tun -- --up-restart --persist-key --persist-tun --management
/var/run/NetworkManager/nm-openvpn-6aa02150-6f4f-4677-b53f-46b464487246 unix --management-client-user root 
--management-
client-group root --management-query-passwords --auth-retry interact --route-noexec --ifconfig-noexec 
--client --ca
/etc/openvpn/nempkeys/ca.crt --cert /etc/openvpn/nempkeys/I-mDeqEu.crt --key 
/etc/openvpn/nempkeys/I-mDeqEu.key --user
nm-openvpn --group nm-openvpn
  │ ├─2469 /usr/sbin/openvpn --remote nemp-server 1194 udp --comp-lzo --nobind --dev tun --cipher BF-CBC 
--auth-nocache
--remote-cert-tls server --reneg-sec 0 --syslog nm-openvpn --script-security 2 --up 
/usr/lib/networkmanager-openvpn/nm-
openvpn-service-openvpn-helper --tun -- --up-restart --persist-key --persist-tun --management
/var/run/NetworkManager/nm-openvpn-6aa02150-6f4f-4677-b53f-46b464487246 unix --management-client-user root 
--management-
client-group root --management-query-passwords --auth-retry interact --route-noexec --ifconfig-noexec 
--client --ca
/etc/openvpn/nempkeys/ca.crt --cert /etc/openvpn/nempkeys/RVg4sR2b.crt --key 
/etc/openvpn/nempkeys/RVg4sR2b.key --user
nm-openvpn --group nm-openvpn
  │ ├─2600 /usr/lib/networkmanager-openvpn/nm-openvpn-service
  │ ├─3296 /usr/sbin/openvpn --remote nemp-server 1194 udp --comp-lzo --nobind --dev tun --cipher BF-CBC 
--auth-nocache
--remote-cert-tls server --reneg-sec 0 --syslog nm-openvpn --script-security 2 --up 
/usr/lib/networkmanager-openvpn/nm-
openvpn-service-openvpn-helper --tun -- --up-restart --persist-key --persist-tun --management
/var/run/NetworkManager/nm-openvpn-6aa02150-6f4f-4677-b53f-46b464487246 unix --management-client-user root 
--management-
client-group root --management-query-passwords --auth-retry interact --route-noexec --ifconfig-noexec 
--client --ca
/etc/openvpn/nempkeys/ca.crt --cert /etc/openvpn/nempkeys/9-hJsBlB.crt --key 
/etc/openvpn/nempkeys/9-hJsBlB.key --user
nm-openvpn --group nm-openvpn
...



"ip address" shows many tun devices, some of them with equal IP addresses!
...
10: tun0: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc pfifo_fast qlen 100
    link/[65534] 
17: tun2: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc pfifo_fast qlen 100
    link/[65534] 
20: tun3: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/[65534] 
    inet 10.42.0.146 peer 10.42.0.145/32 brd 10.42.0.146 scope global tun3
       valid_lft forever preferred_lft forever
22: tun4: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/[65534] 
    inet 10.42.0.146 peer 10.42.0.145/32 brd 10.42.0.146 scope global tun4
       valid_lft forever preferred_lft forever
23: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/[65534] 
    inet 10.42.0.150 peer 10.42.0.149/32 brd 10.42.0.150 scope global tun1
       valid_lft forever preferred_lft forever
25: tun6: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/[65534] 
    inet 10.42.0.150 peer 10.42.0.149/32 brd 10.42.0.150 scope global tun6
       valid_lft forever preferred_lft forever
...



How to reproduce?
My application basically creates two connections using NetworkManager's dbus interface: Ethernet + WLAN. Then 
it creates
a VPN connection without explicitly specifying the interface used for VPN. NetworkManager does what it is 
expected to
do: Successfully setup the VPN. After that I remove the WLAN or the Ethernet connection (autoconnect=False) 
and I
replace the VPN configuration (new credentials, remote configuration remains) several times.

So far I do not understand which of the steps is the critical one. Before I try to solve the problem 
"somehow", I would
like to ask if somebody understands the described behavior based on the source code. May be somebody of you 
experts
could provide a patch I can test or give me a hint how I could fix it?

Thank you.
Regards,
Adrian