The upstream bug got closed as resolved in 2016

** Changed in: network-manager (Ubuntu)
       Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1513437

Title:
  Incorrect default routing after vpnc completes

Status in NetworkManager:
  Unknown
Status in network-manager package in Ubuntu:
  Fix Released

Bug description:
  We're using vpnc with a password + one time token at work so I run it
  from the command line.  I've been using it for years, this laptop is
  probably 2 years old, upgrading ubuntu every half year and I've never
  had this issue before I upgraded to 15.10.

  I've put set +x in the vpnc-script, and I'm also tailing syslog in the
  same window.  Got this trace after being accepted, towards the end:

  + set_default_route
  + /sbin/ip route
  + fix_ip_get_output
  + + grepsed -e ^default
   s/ /\n/g
  Nov  5 11:16:54 niclan-lap NetworkManager[724]: <info>  Device 'tun0' has no 
connection; scheduling activate_check in 0 seconds.
  Nov  5 11:16:54 niclan-lap NetworkManager[724]: <info>  (tun0): Activation: 
starting connection 'tun0' (498de0c1-9fe8-43fc-82ac-3d4e1bcbbf2f)
  + sed -ne 1p;/via/{N;p};/dev/{N;p};/src/{N;p};/mtu/{N;p}

  HERE the correct default routing is installed:

  + /sbin/ip route replace default dev tun0
  + /sbin/ip route flush cache

  And at this point network manager pounces (this is the very next line
  of the console (from tail -f syslog):

  Nov  5 11:16:54 niclan-lap NetworkManager[724]: <info>  (tun0): device state 
change: disconnected -> prepare (reason 'none') [30 40 0]
  + [ -n  ]
  + [ -n  -o -n  ]
  + [ -n 194.19.44.43 195.204.29.42 ]
  + modify_resolvconf_manager
  + NEW_RESOLVCONF=
  + NEW_RESOLVCONF=
  nameserver 194.19.44.43
  + NEW_RESOLVCONF=
  nameserver 194.19.44.43
  nameserver 195.204.29.42
  + [ -n  ]
  Nov  5 11:16:54 niclan-lap NetworkManager[724]: <info>  (tun0): device state 
change: prepare -> config (reason 'none') [40 50 0]
  + echo 
  nameserver 194.19.44.43
  nameserver 195.204.29.42
  + /sbin/resolvconf -a tun0

  Major networkmanager action:

  Nov  5 11:16:54 niclan-lap NetworkManager[724]: <info>  (tun0): device state 
change: config -> ip-config (reason 'none') [50 70 0]
  Nov  5 11:16:54 niclan-lap NetworkManager[724]: <info>  (tun0): device state 
change: ip-config -> ip-check (reason 'none') [70 80 0]
  Nov  5 11:16:55 niclan-lap NetworkManager[724]: <info>  (tun0): device state 
change: ip-check -> secondaries (reason 'none') [80 90 0]
  Nov  5 11:16:55 niclan-lap NetworkManager[724]: <info>  (tun0): device state 
change: secondaries -> activated (reason 'none') [90 100 0]
  Nov  5 11:16:55 niclan-lap NetworkManager[724]: <info>  (tun0): Activation: 
successful, device activated.
  Nov  5 11:16:55 niclan-lap dbus[743]: [system] Activating via systemd: 
service name='org.freedesktop.nm_dispatcher' 
unit='dbus-org.freedesktop.nm-dispatcher.service'
  Nov  5 11:16:55 niclan-lap systemd[1]: Starting Network Manager Script 
Dispatcher Service...
  Nov  5 11:16:55 niclan-lap dbus[743]: [system] Successfully activated service 
'org.freedesktop.nm_dispatcher'
  Nov  5 11:16:55 niclan-lap systemd[1]: Started Network Manager Script 
Dispatcher Service.
  Nov  5 11:16:55 niclan-lap nm-dispatcher: Dispatching action 'up' for tun0
  Nov  5 11:16:55 niclan-lap systemd[1]: Reloading OpenBSD Secure Shell server.
  Nov  5 11:16:55 niclan-lap systemd[1]: Reloaded OpenBSD Secure Shell server.
  + run_hooks post-connect
  + HOOK=post-connect
  + [ -d /etc/vpnc/post-connect.d ]
  + exit 0
  VPNC started in background (pid: 8778)...
  root@niclan-lap:/etc/vpnc#

  At this point I cannot reach resources through the VPN.

  root@niclan-lap:/etc/vpnc# /sbin/ip route
  default via 10.99.64.1 dev wlan0  proto static  metric 600 
  10.21.50.0/24 dev tun0  scope link 
  10.99.64.0/23 dev wlan0  proto kernel  scope link  src 10.99.64.195  metric 
600 
  169.254.0.0/16 dev wlan0  scope link  metric 1000 
  193.69.44.30 via 10.99.64.1 dev wlan0  src 10.99.64.195 
  194.19.44.87 via 10.99.64.1 dev wlan0  proto dhcp  metric 600 
  Nov  5 11:18:51 niclan-lap wpa_supplicant[1358]: nl80211: 
send_and_recv->nl_recvmsgs failed: -33

  As we see the default routing is through the wlan0 instead of tun0.
  So the default routing set in the vpnc-script is already removed. I
  can only speculate to _what_ removed it, but network-manager seems to
  have been active at the time.

  So I add the routing again:

  root@niclan-lap:/etc/vpnc# /sbin/ip route replace default dev tun0
  root@niclan-lap:/etc/vpnc# /sbin/ip route flush cache

  root@niclan-lap:/etc/vpnc# /sbin/ip route
  default dev tun0  scope link 
  default via 10.99.64.1 dev wlan0  proto static  metric 600 
  10.21.50.0/24 dev tun0  scope link 
  10.99.64.0/23 dev wlan0  proto kernel  scope link  src 10.99.64.195  metric 
600 
  169.254.0.0/16 dev wlan0  scope link  metric 1000 
  193.69.44.30 via 10.99.64.1 dev wlan0  src 10.99.64.195 
  194.19.44.87 via 10.99.64.1 dev wlan0  proto dhcp  metric 600 

  The routing table is now correct I would say, at least I reach the
  resources inside the vpn without issue.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.10
  Package: vpnc 0.5.3r550-2
  ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3
  Uname: Linux 4.2.0-16-generic x86_64
  ApportVersion: 2.19.1-0ubuntu4
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Thu Nov  5 11:58:20 2015
  InstallationDate: Installed on 2013-11-07 (727 days ago)
  InstallationMedia: Kubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
  SourcePackage: vpnc
  UpgradeStatus: Upgraded to wily on 2015-10-26 (9 days ago)
  modified.conffile..etc.vpnc.default.conf: [deleted]

To manage notifications about this bug go to:
https://bugs.launchpad.net/network-manager/+bug/1513437/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to