Description of problem: When using network manager with VPNC, if the NIC(eth0,wlan0) renews the DHCP lease, NetworkManager overwrites the routing tables and the VPN connection becomes dead Version-Release number of selected component (if applicable): [nareshv@fallenAngel ~]$ rpm -qa NetworkManager\* NetworkManager-glib-0.7.0-0.9.3.svn3623.fc9.i386 NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386 NetworkManager-vpnc-0.7.0-0.7.7.svn3627.fc9.i386 NetworkManager-gnome-0.7.0-0.9.3.svn3623.fc9.i386 NetworkManager-openvpn-0.7.0-10.svn3632.fc9.i386 How reproducible: Always Steps to Reproduce: 1. Connect to Wired or Wireless networks which supports lease 2. Connect to VPN (cisco) gateway, before the lease is expired 3. After the lease expires, wlan0,eth0 will auto-renew the IP address, the same time VPN connection will go dead Actual results: VPN connection will be dead, the moment ip address is auto renewed by NetworkManager on wlan0,eth0 Expected results: Presence of lease on the actual NIC should not break the VPN connection Additional info: Attached is the Networkmanager system log which explains the session with these steps 1. connected to WLAN 2. connected to VPN 3. WLAN lease is renewed 4. disconnected VPN as its hung (This case is working prefectly in Fedora 8)
Created attachment 305891 [details] NetworkManager system log
Comment on attachment 305891 [details] NetworkManager system log >May 19 08:38:41 fallenAngel NetworkManager: <info> Activation (wlan0) starting connection 'Auto XXXXXX' >May 19 08:38:41 fallenAngel NetworkManager: <info> (wlan0): device state change: 3 -> 4 >May 19 08:38:41 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... >May 19 08:38:41 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started... >May 19 08:38:41 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... >May 19 08:38:41 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. >May 19 08:38:41 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting... >May 19 08:38:41 fallenAngel NetworkManager: <info> (wlan0): device state change: 4 -> 5 >May 19 08:38:41 fallenAngel NetworkManager: <info> Activation (wlan0/wireless): access point 'Auto XXXXXXX' has security, but secrets are required. >May 19 08:38:41 fallenAngel NetworkManager: <info> (wlan0): device state change: 5 -> 6 >May 19 08:38:41 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete. >May 19 08:38:45 fallenAngel NetworkManager: <info> (wlan0): supplicant connection state change: 2 -> 1 >May 19 08:38:49 fallenAngel NetworkManager: Missing or invalid key management >May 19 08:38:49 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... >May 19 08:38:49 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started... >May 19 08:38:49 fallenAngel NetworkManager: <info> (wlan0): device state change: 6 -> 4 >May 19 08:38:49 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... >May 19 08:38:49 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. >May 19 08:38:49 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting... >May 19 08:38:49 fallenAngel NetworkManager: <info> (wlan0): device state change: 4 -> 5 >May 19 08:38:49 fallenAngel NetworkManager: <info> Activation (wlan0/wireless): connection 'Auto XXXXXXX' has security, and secrets exist. No new secrets needed. >May 19 08:38:49 fallenAngel NetworkManager: <info> Config: added 'ssid' value 'XXXXXXXX' >May 19 08:38:49 fallenAngel NetworkManager: <info> Config: added 'scan_ssid' value '1' >May 19 08:38:49 fallenAngel NetworkManager: <info> Config: added 'key_mgmt' value 'WPA-PSK' >May 19 08:38:49 fallenAngel NetworkManager: <info> Config: added 'psk' value '<omitted>' >May 19 08:38:49 fallenAngel NetworkManager: <info> Config: added 'proto' value 'WPA RSN' >May 19 08:38:49 fallenAngel NetworkManager: <info> Config: added 'pairwise' value 'TKIP CCMP' >May 19 08:38:49 fallenAngel NetworkManager: <info> Config: added 'group' value 'WEP40 WEP104 TKIP CCMP' >May 19 08:38:49 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete. >May 19 08:38:49 fallenAngel NetworkManager: <info> Config: set interface ap_scan to 1 >May 19 08:38:49 fallenAngel NetworkManager: <info> (wlan0): supplicant connection state change: 1 -> 2 >May 19 08:38:50 fallenAngel NetworkManager: <info> (wlan0): supplicant connection state change: 2 -> 3 >May 19 08:38:50 fallenAngel NetworkManager: <info> (wlan0): supplicant connection state change: 3 -> 4 >May 19 08:38:50 fallenAngel kernel: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready >May 19 08:38:51 fallenAngel NetworkManager: <info> (wlan0): supplicant connection state change: 4 -> 5 >May 19 08:38:51 fallenAngel NetworkManager: <info> (wlan0): supplicant connection state change: 5 -> 6 >May 19 08:38:51 fallenAngel NetworkManager: <info> (wlan0): supplicant connection state change: 6 -> 7 >May 19 08:38:51 fallenAngel NetworkManager: <info> Activation (wlan0/wireless) Stage 2 of 5 (Device Configure) successful. Connected to wireless network 'XXXXXXXX'. >May 19 08:38:51 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) scheduled. >May 19 08:38:51 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) started... >May 19 08:38:51 fallenAngel NetworkManager: <info> (wlan0): device state change: 5 -> 7 >May 19 08:38:51 fallenAngel NetworkManager: <info> Activation (wlan0) Beginning DHCP transaction. >May 19 08:38:51 fallenAngel NetworkManager: <info> dhclient started with pid 2682 >May 19 08:38:51 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) complete. >May 19 08:38:51 fallenAngel dhclient: Internet Systems Consortium DHCP Client 4.0.0 >May 19 08:38:51 fallenAngel dhclient: Copyright 2004-2007 Internet Systems Consortium. >May 19 08:38:51 fallenAngel dhclient: All rights reserved. >May 19 08:38:51 fallenAngel dhclient: For info, please visit http://www.isc.org/sw/dhcp/ >May 19 08:38:51 fallenAngel dhclient: >May 19 08:38:51 fallenAngel NetworkManager: <info> DHCP: device wlan0 state changed (null) -> preinit >May 19 08:38:51 fallenAngel dhclient: Listening on LPF/wlan0/00:13:02:cb:8e:b1 >May 19 08:38:51 fallenAngel dhclient: Sending on LPF/wlan0/00:13:02:cb:8e:b1 >May 19 08:38:51 fallenAngel dhclient: Sending on Socket/fallback >May 19 08:38:54 fallenAngel dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6 >May 19 08:38:56 fallenAngel dhclient: DHCPOFFER from 192.168.1.1 >May 19 08:38:56 fallenAngel dhclient: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 >May 19 08:38:56 fallenAngel dhclient: DHCPACK from 192.168.1.1 >May 19 08:38:56 fallenAngel dhclient: bound to 192.168.1.3 -- renewal in 1501 seconds. >May 19 08:38:56 fallenAngel NetworkManager: <info> DHCP: device wlan0 state changed preinit -> bound >May 19 08:38:56 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 4 of 5 (IP Configure Get) scheduled... >May 19 08:38:56 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 4 of 5 (IP Configure Get) started... >May 19 08:38:56 fallenAngel NetworkManager: <info> address 192.168.1.3 >May 19 08:38:56 fallenAngel NetworkManager: <info> netmask 255.255.255.0 >May 19 08:38:56 fallenAngel NetworkManager: <info> broadcast 192.168.1.255 >May 19 08:38:56 fallenAngel NetworkManager: <info> gateway 192.168.1.1 >May 19 08:38:56 fallenAngel NetworkManager: <info> nameserver '192.168.1.1' >May 19 08:38:56 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) scheduled... >May 19 08:38:56 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 4 of 5 (IP Configure Get) complete. >May 19 08:38:56 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) started... >May 19 08:38:57 fallenAngel NetworkManager: <info> (wlan0): device state change: 7 -> 8 >May 19 08:38:57 fallenAngel NetworkManager: <info> Policy set (wlan0) as default device for routing and DNS. >May 19 08:38:57 fallenAngel NetworkManager: <info> Activation (wlan0) successful, device activated. >May 19 08:38:57 fallenAngel NetworkManager: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete. >May 19 08:38:57 fallenAngel nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/05-netfs' exited with error status 1. >May 19 08:39:36 fallenAngel console-kit-daemon[2019]: WARNING: Couldn't read /proc/2542/environ: Error reading file '/proc/2542/environ': No such process >May 19 08:39:50 fallenAngel NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.vpnc'... >May 19 08:39:50 fallenAngel NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 2782 >May 19 08:39:50 fallenAngel kernel: tun: Universal TUN/TAP device driver, 1.6 >May 19 08:39:50 fallenAngel kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk> >May 19 08:39:50 fallenAngel NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' just appeared, activating connections >May 19 08:40:00 fallenAngel NetworkManager: <info> VPN plugin state changed: 3 >May 19 08:40:00 fallenAngel NetworkManager: <info> VPN connection 'Connection XYZ' (Connect) reply received. >May 19 08:40:00 fallenAngel kernel: tun0: Disabled Privacy Extensions >May 19 08:40:04 fallenAngel NetworkManager: <info> VPN connection 'Connection XYZ' (IP Config Get) reply received. >May 19 08:40:04 fallenAngel NetworkManager: <info> VPN Gateway: xx.xx.xx.xx >May 19 08:40:04 fallenAngel NetworkManager: <info> Tunnel Device: tun0 >May 19 08:40:04 fallenAngel NetworkManager: <info> Internal IP4 Address: aa.bb.cc.dd >May 19 08:40:04 fallenAngel NetworkManager: <info> Internal IP4 Netmask: 255.255.254.0 >May 19 08:40:04 fallenAngel NetworkManager: <info> Internal IP4 Point-to-Point Address: aa.bb.cc.dd >May 19 08:40:04 fallenAngel NetworkManager: <info> Maximum Segment Size (MSS): 0 >May 19 08:40:04 fallenAngel NetworkManager: <info> Internal IP4 DNS: aa.bb.cc.ee >May 19 08:40:04 fallenAngel NetworkManager: <info> Internal IP4 DNS: aa.bb.cc.ff >May 19 08:40:04 fallenAngel NetworkManager: <info> Internal IP4 DNS: aa.bb.cc.gg >May 19 08:40:04 fallenAngel NetworkManager: <info> Internal IP4 DNS: aa.bb.cc.hh >May 19 08:40:04 fallenAngel NetworkManager: <info> DNS Domain: 'blah.blah.com' >May 19 08:40:04 fallenAngel NetworkManager: <info> Login Banner: >May 19 08:40:04 fallenAngel NetworkManager: <info> ----------------------------------------- >May 19 08:40:04 fallenAngel NetworkManager: <info> (null) >May 19 08:40:04 fallenAngel NetworkManager: <info> ----------------------------------------- >May 19 08:40:05 fallenAngel NetworkManager: <info> VPN connection 'Connection XYZ' (IP Config Get) complete. >May 19 08:40:05 fallenAngel NetworkManager: <info> VPN plugin state changed: 4 >May 19 09:03:57 fallenAngel dhclient: DHCPREQUEST on wlan0 to 192.168.1.1 port 67 >May 19 09:03:57 fallenAngel dhclient: DHCPACK from 192.168.1.1 >May 19 09:03:57 fallenAngel dhclient: bound to 192.168.1.3 -- renewal in 1575 seconds. >May 19 09:03:57 fallenAngel NetworkManager: <info> DHCP: device wlan0 state changed bound -> renew >May 19 09:03:57 fallenAngel NetworkManager: <info> address 192.168.1.3 >May 19 09:03:57 fallenAngel NetworkManager: <info> netmask 255.255.255.0 >May 19 09:03:57 fallenAngel NetworkManager: <info> broadcast 192.168.1.255 >May 19 09:03:57 fallenAngel NetworkManager: <info> gateway 192.168.1.1 >May 19 09:03:57 fallenAngel NetworkManager: <info> nameserver '192.168.1.1' >May 19 09:03:58 fallenAngel NetworkManager: <info> Policy set (wlan0) as default device for routing and DNS. >May 19 09:09:25 fallenAngel NetworkManager: <info> Policy set (wlan0) as default device for routing and DNS.
I have the same problem, so VPN connection will go dead when eth0 will auto-renew the IP address. Fresh Fedora 9 installation, default settings. No problem with Fedora 8 with the same hardware.
This is the only bug which makes me shift to Fedora 8 as i always work on VPN.
Yes, true - there's no feasible workaround for this - other than use different OS.
Hmm, that doesn't seem to ever happen to me even though I use vpnc and wifi all the time at work. Are you starting the VPN from the nm-applet menu, or manually with /sbin/vpnc?
I don't use wifi (wireless). I use wired connection. The problem reproduces constantly with /sbin/vpnc or /usr/bin/vpnc and with cisco vpnclient (V4.8). With Fedora 8 there wasn't any issues with this.
The problem reproduces ~ 45 minutes after vpn connection was started - so not "immediately".
Any reason you're using vpnc manually and not with the NM vpnc plugin? When using NM, NM may not preserve custom routes, though updates to NM will help this issue for you by only removing routes for devices NM controls. NM will always control the default route while it is active though (by design). So if the NM vpnc plugin works for you I'd suggest that route since I know that does not have this issue. Have you tried it? Do you require the proprietary Cisco VPN client or can you use vpnc?
NM vpnc plugin does not work for me - can't log in. I have used Cisco VPN client on RH, FC1, FC2..., Fedora 8. It has worked fine. On Fedora 9 I hit this problem first time. Tried vpnc too because Cisco VPN client didn't worked. Assume Cisco VPN client should work because it has worked with previous Fedora and RH versions. I hope we get filer (Naresh) comments too.
can you attach your vpnc.conf file? (xxxxx out the passwords and username of course)
I am trying this from both 1) NetworkManager and 2) Command line. 1) When i use this from NetworkManager, most of the times it just exits without any printing any kinda dialog, no 'system tray' icon progress displayed. 'no lock icon' is displayed in the system tray. 2) When i use it manually from the command line it works pretty well, vpnc starts without any problems. But after that if the lease behind the tun0 (like wlan0,eth0) renewed, both the tun0 and wlan0 still be active, but vpn connection dies. I have the simplest vnc configuration file. [nareshv@fallenAngel ~]$ cat /etc/vpnc/work.conf Xauth username ########################## IPSec ID ###################### IPSec secret ################################################# IPSec gateway ###.###.###.###
Created attachment 308768 [details] NetworkManager and VPNC startup , DHCP Renew Logs I am able to reproduce the problem each and every time i connect to the network. Here is the Latest log which describes these steps 1. connect to wifi (using NetworkManager) 2. connect to vpn (using NetworkManager) 3. wifi lease renewed 4. tun0 becomes dead (it can't send any packets out). .. please help check this.
I see a new NetworkManager package built on koji.fedoraproject.org, downloaded and installed the new RPMS. Testing if this fixes the problem... stay tuned. [root@fallenAngel ~]# rpm -qa NetworkManager\* NetworkManager-gnome-0.7.0-0.10.svn3747.fc9.i386 NetworkManager-0.7.0-0.10.svn3747.fc9.i386 NetworkManager-vpnc-0.7.0-0.7.7.svn3627.fc9.i386 NetworkManager-glib-0.7.0-0.10.svn3747.fc9.i386
The new package didn't seem to help. I still see the dead vpn connection after wlan0 IP got renewed. I see the following errors(at the end of the below log) after i disconnected the vpnc from the NetworkManager tray icon context menu. Jun 12 18:11:59 fallenAngel dhclient: DHCPREQUEST on wlan0 to 192.168.1.1 port 67 Jun 12 18:11:59 fallenAngel dhclient: DHCPACK from 192.168.1.1 Jun 12 18:11:59 fallenAngel NetworkManager: <info> DHCP: device wlan0 state changed bound -> renew Jun 12 18:11:59 fallenAngel NetworkManager: <info> address 192.168.1.2 Jun 12 18:11:59 fallenAngel NetworkManager: <info> netmask 255.255.255.0 Jun 12 18:11:59 fallenAngel NetworkManager: <info> gateway 192.168.1.1 Jun 12 18:11:59 fallenAngel NetworkManager: <info> nameserver '192.168.1.1' Jun 12 18:11:59 fallenAngel dhclient: bound to 192.168.1.2 -- renewal in 1481 seconds. Jun 12 18:12:00 fallenAngel NetworkManager: <info> Policy set (wlan0) as default device for routing and DNS. GqJun 12 18:15:18 fallenAngel vpnc[3044]: select: Interrupted system call Jun 12 18:15:18 fallenAngel vpnc[3044]: terminated by signal: 15 Jun 12 18:15:18 fallenAngel NetworkManager: nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx >= 0' failed Jun 12 18:15:18 fallenAngel NetworkManager: nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx >= 0' failed Jun 12 18:15:19 fallenAngel NetworkManager: <info> Policy set (wlan0) as default device for routing and DNS.
It seems that the above mentioned packages in comment #14 works when vpnc is started from cmdline. I was not experiencing vpn-disconnects when ran vpnc from command line.
Are those above koji packages official F9 packages? I have the latest F9 updates applied and I have rpm -qa NetworkManager\* NetworkManager-gnome-0.7.0-0.9.4.svn3675.fc9.i386 NetworkManager-vpnc-0.7.0-0.7.7.svn3627.fc9.i386 NetworkManager-0.7.0-0.9.4.svn3675.fc9.i386 NetworkManager-glib-0.7.0-0.9.4.svn3675.fc9.i386 So seems the koji packages differ from official packages. But those koji packages may resolve my problem too, so need to know if I can apply them safely manually with rpm command.
I guess the packages built on koji were gpg signed and promoted to the official fedora repository. I keep a close watch on koji, to see whats coming into F9. I think you can safely install the packages from koji "yum localinstall Networkmanager*.rpm --nogpg" will do. Let me know if vpn works for ya.
Thanks. Seems the koji package tag is updates-candidate. Will still wait the final update packages and test then. But the changelog looks promising: - Enable connection sharing - Respect VPN-provided routes
Those Koji packages didn't resolve my problem.. Seems someone has hit the same issue on June with Fedora 8 (kernel-2.6.25.4-10.fc8) http://www.nabble.com/Wireless-connection-drops-spontaneously-when-idle-td17733802.html ==> So go back to Fedora 8 may not option either. Hope the issue is fixed in Fedora 10.
Applied the latest NetworkManager version from Koji, but didn't helped. Accidentally the VPN connection worked in this morning - so no one break after 40-45 minutes as usual. Thought what could be the reason and the difference. The difference was that I started the VPN connection about 30 minutes after boot Fedora (machine) - not "immediately" after boot - as I do normally. Looked the messages file closely and compared thinks on another Fedora 9 installation, noticed that the problem is not with VPN but the problem is with eth0/DHCP. The problem is that NetworkManager will do one "extra" 'device eth0 state changed bound -> renew'. If I don't use VPN, just DHCP connection, this renew happens ~ 20 minutes after reboot. If you take the VPN connection (or some other connection) after 20 minutes when renew has been already done, the VPN works perfectly. So you don't need the VPN connection to see what happens here wrongly. NetworkManager should not do that extra renew. In my case the messages file looks like this 20 minutes after boot Fedora 9: ----------------------------- Jul 24 20:12:38 localhost ntpd[2312]: Listening on interface #5 eth0, aaa.aaa.aaa.aaa#123 Enabled Jul 24 20:31:44 localhost dhclient: DHCPREQUEST on eth0 to 10.249.0.1 port 67 Jul 24 20:31:44 localhost dhclient: DHCPACK from 10.249.0.1 Jul 24 20:31:44 localhost NetworkManager: <info> DHCP: device eth0 state changed bound -> renew Jul 24 20:31:44 localhost NetworkManager: <info> address aaa.aaa.aaa.aaa Jul 24 20:31:44 localhost NetworkManager: <info> prefix 23 (255.255.254.0) Jul 24 20:31:44 localhost NetworkManager: <info> gateway bbb.bbb.bbb.b Jul 24 20:31:44 localhost NetworkManager: <info> nameserver 'ccc.ccc.c.cc' Jul 24 20:31:44 localhost NetworkManager: <info> nameserver 'ddd.ddd.d.dd' Jul 24 20:31:44 localhost NetworkManager: <info> domain name 'domain.aaa' ---------------
Disabled NetworkManager and switched to 'network' service. Now the ethernet (and VPN) works perfectly for me - no extra renews or similar anymore. I think NetworkManager was default first time in F9. That's why I didn't had issues with network in F8 (where 'network' service was/is default). Hope NetworkManager works properly in Fedora 10 (especially if it's default) because ethernet is a fundamental (basic) issue which is expected to be worked. Thanks.
This problem also affects external VPN solutions, e.g. SSL VPNs. So NetworkManager needs not only to check the internal VPN status, i.e. a VPN plugin is active, but also check for external VPN connections. One idea might be to check for 2 default routes (one to eth0/wlan0, one to tun0). Another might be just to check for the existance of a default route over a tunX interface. Added gnome bug 545912 as external reference.
Upstream bug was fixed and SVN NetworkManager-0.7.0-0.11.svn4175 is available on koji. I rebuilt NetworkManager-vpnc-0.7.0-0.10.svn4175 from the SRPM myself for F9 as it is still missing from koji. But now VPN can't create any connection :( NM fails with error "VPN plugin failed" after entering the user password: Oct 13 16:19:31 l3f1199 NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.vpnc'... Oct 13 16:19:31 l3f1199 NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' started(org.freedesktop.NetworkManager.vpnc), PID 2947 Oct 13 16:19:32 l3f1199 kernel: tun: Universal TUN/TAP device driver, 1.6 Oct 13 16:19:32 l3f1199 kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk> Oct 13 16:19:32 l3f1199 NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' just appeared, activating connections Oct 13 16:19:32 l3f1199 NetworkManager: <info> VPN plugin state changed: 1 Oct 13 16:19:42 l3f1199 NetworkManager: <info> VPN plugin state changed: 3 Oct 13 16:19:43 l3f1199 NetworkManager: <info> VPN connection 'XXXXX' (Connect) reply received. Oct 13 16:19:43 l3f1199 NetworkManager: <info> VPN plugin failed: 1 Oct 13 16:19:43 l3f1199 NetworkManager: <info> VPN plugin state changed: 6 Oct 13 16:19:43 l3f1199 NetworkManager: <info> VPN plugin state change reason: 0 Oct 13 16:19:43 l3f1199 NetworkManager: <WARN> connection_state_changed(): Could not process the request because no VPN connection was active. Oct 13 16:19:43 l3f1199 NetworkManager: <WARN> nm_system_replace_default_ip4_route(): replace_default_ip4_route() returned error Success (0) Oct 13 16:19:43 l3f1199 NetworkManager: <info> Policy set 'Auto WIVO' (wlan0) as default for routing and DNS. If I call vpnc by hand for the same connection everything is fine.
I rebuilt NetworkManager-vpnc-0.7.0-0.11.svn4175 from koji for F9. Now I can connect with vpnc again. But the route problem is still not solved completely: Oct 14 23:07:50 l3f1199 NetworkManager: <info> VPN plugin state changed: 3 Oct 14 23:07:50 l3f1199 NetworkManager: <info> VPN connection 'XXXXX' (Connect) reply received. Oct 14 23:07:53 l3f1199 NetworkManager: <info> VPN connection 'XXXXX' (IP Config Get) reply received. Oct 14 23:07:53 l3f1199 NetworkManager: <info> VPN Gateway: <GW address> Oct 14 23:07:53 l3f1199 NetworkManager: <info> Tunnel Device: tun0 Oct 14 23:07:53 l3f1199 NetworkManager: <info> Internal IP4 Address: 10.162.253.224 Oct 14 23:07:53 l3f1199 NetworkManager: <info> Internal IP4 Prefix: 24 Oct 14 23:07:53 l3f1199 NetworkManager: <info> Internal IP4 Point-to-Point Address: 10.162.253.224 Oct 14 23:07:53 l3f1199 NetworkManager: <info> Maximum Segment Size (MSS): 0 Oct 14 23:07:53 l3f1199 NetworkManager: <info> Static Route: 10.162.252.0/23 Next Hop: 10.162.252.0 Oct 14 23:07:53 l3f1199 NetworkManager: <info> Internal IP4 DNS: 172.21.141.108 Oct 14 23:07:53 l3f1199 NetworkManager: <info> Internal IP4 DNS: 172.21.141.110 Oct 14 23:07:53 l3f1199 NetworkManager: <info> Internal IP4 DNS: 172.21.139.30 Oct 14 23:07:53 l3f1199 NetworkManager: <info> DNS Domain: 'XXXXX' $ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface <GW address> 192.168.3.1 255.255.255.255 UGH 0 0 0 wlan0 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 10.162.253.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0 But when the DHCP is renewed I get this: Oct 14 22:57:03 l3f1199 dhclient: DHCPREQUEST on wlan0 to 192.168.3.1 port 67 Oct 14 22:57:03 l3f1199 dhclient: DHCPACK from 192.168.3.1 Oct 14 22:57:03 l3f1199 NetworkManager: <info> DHCP: device wlan0 state changed bound -> renew Oct 14 22:57:03 l3f1199 NetworkManager: <info> address 192.168.3.5 Oct 14 22:57:03 l3f1199 NetworkManager: <info> prefix 24 (255.255.255.0) Oct 14 22:57:03 l3f1199 NetworkManager: <info> gateway 192.168.3.1 Oct 14 22:57:03 l3f1199 NetworkManager: <info> nameserver '192.168.3.1' Oct 14 22:57:03 l3f1199 NetworkManager: <info> domain name 'localdomain' Oct 14 22:57:03 l3f1199 dhclient: bound to 192.168.3.5 -- renewal in 6733 seconds. Oct 14 22:57:04 l3f1199 NetworkManager: <WARN> nm_system_replace_default_ip4_route_vpn(): replace_default_ip4_route() returned error Success (0) Oct 14 22:57:04 l3f1199 NetworkManager: <info> Policy set 'XXXXX' (tun0) as default for routing and DNS. $ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 10.162.252.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0 So the route to the VPN gateway is lost and therefore the VPN connection no longer works.
There also seems to be a SELinux problem: nm-vpnc-service is not allowed to kill vpnc and therfore the daemon keeps running: Oct 15 00:13:06 l3f1199 setroubleshoot: SELinux is preventing nm-vpnc-service (NetworkManager_t) "signull" to <Unknown> (vpnc_t). For complete SELinux messages. run sealert -l 97e371ff-dd92-4022-bb54-0265cc9b8a3a Summary: SELinux is preventing nm-vpnc-service (NetworkManager_t) "signull" to <Unknown> (vpnc_t). Detailed Description: SELinux denied access requested by nm-vpnc-service. It is not expected that this access is required by nm-vpnc-service and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:NetworkManager_t:s0 Target Context system_u:system_r:vpnc_t:s0 Target Objects None [ process ] Source nm-vpnc-service Source Path /usr/libexec/nm-vpnc-service Port <Unknown> Host l3f1199 Source RPM Packages NetworkManager-vpnc-0.7.0-0.11.svn4175.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-95.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name l3f1199 Platform Linux l3f1199 2.6.26.5-45.fc9.i686 #1 SMP Sat Sep 20 03:45:00 EDT 2008 i686 i686 Alert Count 2 First Seen Tue Oct 14 22:59:08 2008 Last Seen Wed Oct 15 00:13:06 2008 Local ID 97e371ff-dd92-4022-bb54-0265cc9b8a3a Line Numbers Raw Audit Messages host=l3f1199 type=AVC msg=audit(1224018786.173:55): avc: denied { signull } for pid=13789 comm="nm-vpnc-service" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:vpnc_t:s0 tclass=process host=l3f1199 type=SYSCALL msg=audit(1224018786.173:55): arch=40000003 syscall=37 success=no exit=-13 a0=35f1 a1=0 a2=35f1 a3=bf9dfedc items=0 ppid=7505 pid=13789 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nm-vpnc-service" exe="/usr/libexec/nm-vpnc-service" subj=system_u:system_r:NetworkManager_t:s0 key=(null)
Stefan, can you file a separate bug about the SELinux issue?
Applied the svn4293 (Nov 14 2008) and haven't had problems so far:) So the issue seems to be fixed.
Retested with NetworkManager-vpnc-0.7.0-0.11.svn4326.fc10.i386 NetworkManager-0.7.0-0.12.svn4326.fc10.i386 VPN connection now survives a DHCP renewal of the underlying network interface. IMHO this error can be closed.