On Fri, 2016-01-22 at 14:48 +0100, Adrian Freihofer wrote:
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?
Hi Adrian, sounds like a bug. Can you send the logfile with debugging enabled? For that edit /etc/NetworkManager/NetworkManager.conf to have [logging] level=DEBUG and restart NM. Then `journal -u NetworkManager` (or similar). The logfile should not contain sensitive information, but you might want to check on that before sending (depending on what you perceive as "sensitive"). Thank you, Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part