http://bugzilla.opensuse.org/show_bug.cgi?id=929463 Bug ID: 929463 Summary: NetworkManager and VPN. Routing table with wrong entries, connection doesn't work. Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: 32bit OS: openSUSE 13.2 Status: NEW Severity: Major Priority: P5 - None Component: Network Assignee: bnc-team-screening@forge.provo.novell.com Reporter: lorenzodes@fastwebnet.it QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36 Build Identifier: After some hours (and a few DHCP renegotiations and/or VPN reconnects) a wrong routing entry is added by NetworkManager (or one of its modules) which prevents the vpn service from reconnecting. At that point there's no default route. This is the normal and working routing table: (The IP of the problematic PC is 192.168.2.25, its gateway is 192.168.2.128) << Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.8.0.9 0.0.0.0 UG 1024 0 0 tun0 10.8.0.1 10.8.0.9 255.255.255.255 UGH 1024 0 0 tun0 10.8.0.9 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 <IP of VPN> 192.168.2.128 255.255.255.255 UGH 1 0 0 eth0 192.168.1.0 192.168.2.128 255.255.255.0 UG 1 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
This is the one that is produced by the bug: << Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface <IP of VPN> 0.0.0.0 255.255.255.255 UH 1024 0 0 eth0 192.168.1.0 192.168.2.128 255.255.255.0 UG 1 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
(the one with 192.168.1.0 is a static route that I added, I don't think it is relevant to the problem).
Reproducible: Always Steps to Reproduce: 1.Use NetworkManager to connect to the internet 2.Use NetworkManager to conect to the VPN server 3.Wait a few hours (sometimes it takes up to a whole day) Actual Results: Routing table is broken, the VPN service is unable to connect to the server and normal connection is not working due to the missing default route. At that point the NetworkManager shows the VPN as active, but it is not. To make things work again I have to manually remove the wrong route and restart the connection via the NetworkManager applet. Expected Results: NetworkManager should not be adding wrong routing entries. This is an extract of the NM logs that shows the bug when it happens << 2015-04-24T02:33:00.372563+02:00 linux-vf0c NetworkManager[774]: DHCPREQUEST on eth0 to 192.168.2.128 port 67 (xid=0x7ef88965) 2015-04-24T02:33:01.723976+02:00 linux-vf0c NetworkManager[774]: DHCPACK from 192.168.2.128 (xid=0x7ef88965) 2015-04-24T02:33:01.725757+02:00 linux-vf0c NetworkManager[774]: <info> (eth0): DHCPv4 state changed renew -> renew 2015-04-24T02:33:01.726069+02:00 linux-vf0c NetworkManager[774]: <info> address 192.168.2.25 2015-04-24T02:33:01.726371+02:00 linux-vf0c NetworkManager[774]: <info> plen 24 (255.255.255.0) 2015-04-24T02:33:01.726681+02:00 linux-vf0c NetworkManager[774]: <info> gateway 192.168.2.128 2015-04-24T02:33:01.726976+02:00 linux-vf0c NetworkManager[774]: <info> server identifier 192.168.2.128 2015-04-24T02:33:01.727252+02:00 linux-vf0c NetworkManager[774]: <info> lease time 21600 2015-04-24T02:33:01.727539+02:00 linux-vf0c NetworkManager[774]: <info> nameserver '192.168.2.128' (...) 2015-04-24T02:33:01.728118+02:00 linux-vf0c NetworkManager[774]: bound to 192.168.2.25 -- renewal in 10359 seconds. 2015-04-24T02:33:01.807970+02:00 linux-vf0c NetworkManager[774]: <error> [1429835581.806795] [platform/nm-linux-platform.c:1714] add_object(): Netlink error adding 0.0.0.0/0 via 10.8.0.21 dev tun0 metric 1024 mss 0 src user: Unspecific failure 2015-04-24T02:33:01.808332+02:00 linux-vf0c NetworkManager[774]: <error> [1429835581.807014] [platform/nm-linux-platform.c:1714] add_object(): Netlink error adding 0.0.0.0/0 via 10.8.0.21 dev tun0 metric 1024 mss 0 src user: Unspecific failure 2015-04-24T02:33:01.808990+02:00 linux-vf0c NetworkManager[774]: <error> [1429835581.807055] [nm-policy.c:676] update_ip4_routing(): Failed to set default route. 2015-04-24T02:33:01.809473+02:00 linux-vf0c NetworkManager[774]: inet default table main 2015-04-24T02:33:01.809832+02:00 linux-vf0c NetworkManager[774]: priority 0x400 protocol static 2015-04-24T02:33:01.810138+02:00 linux-vf0c NetworkManager[774]: nexthop via 10.8.0.21 dev 5 2015-04-24T02:33:01.810435+02:00 linux-vf0c NetworkManager[774]: inet default table main 2015-04-24T02:33:01.810744+02:00 linux-vf0c NetworkManager[774]: priority 0x400 protocol static 2015-04-24T02:33:01.811051+02:00 linux-vf0c NetworkManager[774]: nexthop via 10.8.0.21 dev 5 2015-04-24T02:33:01.820927+02:00 linux-vf0c nm-dispatcher: Dispatching action 'dhcp4-change' for eth0 (...) 2015-04-24T02:33:33.052455+02:00 linux-vf0c nm-openvpn[1135]: [TG-OVPN-CA] Inactivity timeout (--ping-restart), restarting 2015-04-24T02:33:33.052888+02:00 linux-vf0c nm-openvpn[1135]: SIGUSR1[soft,ping-restart] received, process restarting (...) 2015-04-24T02:33:38.059063+02:00 linux-vf0c nm-openvpn[1135]: Attempting to establish TCP connection with [AF_INET]<IP of VPN>:443 [nonblock] 2015-04-24T02:33:42.061830+02:00 linux-vf0c nm-openvpn[1135]: TCP: connect to [AF_INET]<IP of VPN>:443 failed, will try again in 5 seconds: No route to host 2015-04-24T02:33:51.069848+02:00 linux-vf0c nm-openvpn[1135]: TCP: connect to [AF_INET]<IP of VPN>:443 failed, will try again in 5 seconds: No route to host 2015-04-24T02:34:00.078808+02:00 linux-vf0c nm-openvpn[1135]: TCP: connect to [AF_INET]<IP of VPN>:443 failed, will try again in 5 seconds: No route to host (...)
-- You are receiving this mail because: You are on the CC list for the bug.