This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 447246 - NetworkManager and VPNC Routing tables conflict
NetworkManager and VPNC Routing tables conflict
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
9
All Linux
low Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-18 23:54 EDT by Naresh
Modified: 2008-11-28 12:49 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-28 12:49:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
NetworkManager system log (10.54 KB, text/plain)
2008-05-18 23:54 EDT, Naresh
no flags Details
NetworkManager and VPNC startup , DHCP Renew Logs (10.77 KB, text/plain)
2008-06-10 00:09 EDT, Naresh
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 545912 None None None Never

  None (edit)
Description Naresh 2008-05-18 23:54:08 EDT
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)
Comment 1 Naresh 2008-05-18 23:54:08 EDT
Created attachment 305891 [details]
NetworkManager system log
Comment 2 Naresh 2008-05-18 23:56:10 EDT
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@qualcomm.com>
>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.
Comment 3 jarki 2008-05-28 14:44:54 EDT
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.
Comment 4 Naresh 2008-05-29 03:49:58 EDT
This is the only bug which makes me shift to Fedora 8 as i always work on VPN.
Comment 5 jarki 2008-05-29 09:17:08 EDT
Yes, true - there's no feasible workaround for this - other than use different OS.
Comment 6 Dan Williams 2008-06-02 16:58:42 EDT
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?
Comment 7 jarki 2008-06-03 09:36:12 EDT
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.
 
Comment 8 jarki 2008-06-03 09:51:22 EDT
The problem reproduces ~ 45 minutes after vpn connection was started - so not
"immediately". 
Comment 9 Dan Williams 2008-06-03 12:58:22 EDT
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?
Comment 10 jarki 2008-06-03 15:33:38 EDT
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.
Comment 11 Dan Williams 2008-06-03 15:55:02 EDT
can you attach your vpnc.conf file? (xxxxx out the passwords and username of course)
Comment 12 Naresh 2008-06-05 00:03:52 EDT
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 ###.###.###.### 

Comment 13 Naresh 2008-06-10 00:09:15 EDT
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.
Comment 14 Naresh 2008-06-12 08:28:44 EDT
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
Comment 15 Naresh 2008-06-12 08:52:47 EDT
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.
Comment 16 Naresh 2008-06-17 01:41:31 EDT
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.
Comment 17 jarki 2008-06-17 09:25:07 EDT
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.

Comment 18 Naresh 2008-06-18 03:20:01 EDT
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.
Comment 19 jarki 2008-06-18 09:31:37 EDT
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
Comment 20 jarki 2008-07-01 09:31:32 EDT
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.

Comment 21 jarki 2008-07-24 14:45:54 EDT
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'
---------------

Comment 22 jarki 2008-07-31 06:57:54 EDT
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.
Comment 23 Stefan Becker 2008-09-08 03:21:48 EDT
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.
Comment 24 Stefan Becker 2008-10-13 09:31:51 EDT
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@qualcomm.com>
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.
Comment 25 Stefan Becker 2008-10-14 16:17:25 EDT
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.
Comment 26 Stefan Becker 2008-10-14 17:16:19 EDT
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)
Comment 27 Dan Williams 2008-10-15 11:55:22 EDT
Stefan, can you file a separate bug about the SELinux issue?
Comment 28 jarki 2008-11-18 02:41:33 EST
Applied the svn4293 (Nov 14 2008) and haven't had problems so far:)
So the issue seems to be fixed.
Comment 29 Stefan Becker 2008-11-27 15:03:52 EST
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.

Note You need to log in before you can comment on or make changes to this bug.