GNOME Bugzilla – Bug 741139
Stale IP configs in DNS manager if VPN restarts and sends invalid IP config
Last modified: 2016-09-26 11:50:24 UTC
If the VPN connects successfully, then something happens and it reconnects and upon reconnect sends an invalid IP config (either v4 or v6), then the old IP configs will not be removed from the DNS manager. des. 04 23:30:34 envy.fud.no nm-openvpn[31214]: /usr/libexec/nm-openvpn-service-openvpn-helper tun0 1500 1541 100.64.48.6 100.64.48.5 restart des. 04 23:30:34 envy.fud.no NetworkManager[31091]: <info> VPN connection 'testvpn' (IP Config Get) reply received. nm_vpn_connection_config_get() - the generic config is valid, and is set to expect IPv4 and IPv6 configs. This clears the IPv4 config: LOG_INVALID_ARG (NM_VPN_PLUGIN_CONFIG_HAS_IP4); } ---> g_clear_object (&priv->ip4_config); val = g_hash_table_lookup (config_hash, NM_VPN_PLUGIN_CONFIG_HAS_IP6); so now priv->ip4_config is NULL, but it has never been removed from the DNS manager. des. 04 23:30:34 envy.fud.no NetworkManager[31091]: <info> VPN connection 'testvpn' (IP4 Config Get) reply received. des. 04 23:30:34 envy.fud.no NetworkManager[31091]: <error> [1417732234.580219] [vpn-manager/nm-vpn-connection.c:1220] nm_vpn_connection_ip4_config_get(): invalid IP4 config received! des. 04 23:30:34 envy.fud.no NetworkManager[31091]: <warn> VPN connection 'testvpn' did not receive valid IP config information. nm_log_warn (LOGD_VPN, "VPN connection '%s' did not receive valid IP config information.", nm_connection_get_id (priv->connection)); _set_vpn_state (connection, STATE_FAILED, NM_VPN_CONNECTION_STATE_REASON_IP_CONFIG_INVALID, FALSE); when the VPN transitions to STATE_FAILED, the policy does this: ip4_config = nm_vpn_connection_get_ip4_config (vpn); if (ip4_config) { /* Remove the VPN connection's IP4 config from DNS */ nm_dns_manager_remove_ip4_config (priv->dns_manager, ip4_config); } but since the VPN IP4 config is NULL, the old config is never removed from the DNS manager.
Created attachment 292160 [details] [review] vpn-dns-hack.patch I don't like this patch, but it should fix the issue. We should figure out how to handle reconnect/reconfig failure better.
I can confirm that the patch fixes the issue, the DNS server gets removed from resolv.conf after the VPN tunnel goes down. However, as shown below, it still fails to actually reconnect, but I guess that's another bug. des. 05 15:45:40 envy.fud.no nm-openvpn[6529]: [greed.fud.no] Inactivity timeout (--ping-restart), restarting des. 05 15:45:40 envy.fud.no nm-openvpn[6529]: SIGUSR1[soft,ping-restart] received, process restarting des. 05 15:45:42 envy.fud.no nm-openvpn[6529]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. des. 05 15:45:42 envy.fud.no nm-openvpn[6529]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts des. 05 15:45:42 envy.fud.no nm-openvpn[6529]: UDPv4 link local: [undef] des. 05 15:45:42 envy.fud.no nm-openvpn[6529]: UDPv4 link remote: [AF_INET]87.238.35.145:1194 des. 05 15:45:42 envy.fud.no nm-openvpn[6529]: [greed.fud.no] Peer Connection Initiated with [AF_INET]87.238.35.145:1194 des. 05 15:45:45 envy.fud.no nm-openvpn[6529]: Preserving previous TUN/TAP instance: tun0 des. 05 15:45:45 envy.fud.no nm-openvpn[6529]: /usr/libexec/nm-openvpn-service-openvpn-helper tun0 1500 1541 100.64.48.6 100.64.48.5 restart des. 05 15:45:45 envy.fud.no NetworkManager[6406]: <info> VPN connection 'testvpn' (IP Config Get) reply received. des. 05 15:45:45 envy.fud.no NetworkManager[6406]: <info> VPN connection 'testvpn' (IP4 Config Get) reply received. des. 05 15:45:45 envy.fud.no NetworkManager[6406]: <error> [1417790745.294500] [vpn-manager/nm-vpn-connection.c:1235] nm_vpn_connection_ip4_config_get(): invalid IP4 config received! des. 05 15:45:45 envy.fud.no NetworkManager[6406]: <warn> VPN connection 'testvpn' did not receive valid IP config information. des. 05 15:45:45 envy.fud.no nm-openvpn[6529]: NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device. des. 05 15:45:45 envy.fud.no NetworkManager[6406]: ** Message: Terminated openvpn daemon with PID 6529. des. 05 15:45:45 envy.fud.no NetworkManager[6406]: <error> [1417790745.330648] [platform/nm-linux-platform.c:2323] link_change(): Netlink error changing link 103: <DOWN> mtu 0 (1) driver 'unknown' udi '/sys/devices/virtual/net/tun0': No such device des. 05 15:45:45 envy.fud.no NetworkManager[6406]: <error> [1417790745.331779] [platform/nm-linux-platform.c:1844] delete_object(): Netlink error deleting 100.64.48.6/32 lft forever pref forever lifetime 149-0[4294967295,4294967295] ptp 100.64.48.5 dev tun0 src kernel: No such device (-31) des. 05 15:45:45 envy.fud.no NetworkManager[6406]: <error> [1417790745.331843] [platform/nm-linux-platform.c:1844] delete_object(): Netlink error deleting 2001:db8::1000/64 lft forever pref forever lifetime 149-0[4294967295,4294967295] dev tun0 src kernel: No such device (-31) des. 05 15:45:45 envy.fud.no nm-openvpn[6529]: TUN/TAP device tun0 opened des. 05 15:45:45 envy.fud.no nm-openvpn[6529]: /usr/libexec/nm-openvpn-service-openvpn-helper tun0 1500 1541 100.64.48.10 100.64.48.9 init des. 05 15:45:45 envy.fud.no NetworkManager[6406]: <info> (tun0): device state change: activated -> unmanaged (reason 'removed') [100 10 36] des. 05 15:45:45 envy.fud.no NetworkManager[6406]: <info> (tun0): deactivating device (reason 'removed') [36] des. 05 15:45:45 envy.fud.no NetworkManager[6406]: <info> (tun0): carrier is OFF des. 05 15:45:45 envy.fud.no NetworkManager[6406]: <info> (tun0): new Tun device (driver: 'tun' ifindex: 104) des. 05 15:45:45 envy.fud.no NetworkManager[6406]: <info> (tun0): exported as /org/freedesktop/NetworkManager/Devices/5 des. 05 15:45:45 envy.fud.no nm-openvpn[6529]: Initialization Sequence Completed des. 05 15:45:45 envy.fud.no nm-openvpn[6529]: SIGTERM[hard,] received, process exiting des. 05 15:46:05 envy.fud.no NetworkManager[6406]: <info> VPN service 'openvpn' disappeared
(In reply to comment #1) > Created an attachment (id=292160) [details] [review] > vpn-dns-hack.patch > > I don't like this patch, but it should fix the issue. We should figure out how > to handle reconnect/reconfig failure better. G_STMT_START {} G_STMT_END And move g_clear_object() inside the if() block? There are other places where we call g_clear_object (&priv->ip4_config); What is the reason not use CLEAR_IP4_CONFIG() there too?
(In reply to comment #3) > (In reply to comment #1) > > Created an attachment (id=292160) [details] [review] [details] [review] > > vpn-dns-hack.patch > > > > I don't like this patch, but it should fix the issue. We should figure out how > > to handle reconnect/reconfig failure better. NMDnsManager could hold a weak reference to all the configs (and remove them when the object gets disposed). But actually it gets ugly (complicated) when you are inside an NMDnsManager function, and call anything that has external consequences (such as update_dns()), and then a config gets unrefed...
Just curious if there has been any progress on getting this patch into Git master? It's the only thing that prevents me from using a pristine unpatched NM, these days... Tore
This bug remains in NM v1.0.2, but its impact is much less than before. While the DNS server from the VPN remains after the VPN got torn down, it gets moved to the bottom of /etc/resolv.conf, where it doesn't do much harm.
Should be fixed by: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=641e8b00fea2503acbcd5c8c942ed751a6607469 Please reopen if it still happens.