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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
