desktop-packages team mailing list archive

[pureblood <1423546@xxxxxxxxxxxxxxxxxx>]

I think I might have the same issue. This is the "route -n" output of my computer:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.10.100.3     0.0.0.0         UG    1024   0        0 eth0
10.10.96.0      0.0.0.0         255.255.248.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0

This is the "route -n" output of my computer after connecting to the VPN:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     1024   0        0 vpn0
10.10.96.0      0.0.0.0         255.255.248.0   U     0      0        0 eth0
69.173.118.0    0.0.0.0         255.255.254.0   U     0      0        0 vpn0
69.173.127.3    10.10.100.3     255.255.255.255 UGH   1      0        0 eth0
69.173.127.3    0.0.0.0         255.255.255.255 UH    1024   0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0

This is the "route -n" output of my computer after disconnecting from the VPN:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.10.100.3     0.0.0.0         UG    1024   0        0 eth0
10.10.96.0      0.0.0.0         255.255.248.0   U     0      0        0 eth0
69.173.127.3    0.0.0.0         255.255.255.255 UH    1024   0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0

As you can see, after disconnection from the VPN, this extra line remains:
69.173.127.3    0.0.0.0         255.255.255.255 UH    1024   0        0 eth0

Which seems to be what is causing the problem, as it makes it impossible to reach IP address 69.173.127.3 which is exactly the IP address of the VPN server. By manually removing this extra line with the following command:
sudo route delete 69.173.127.3

The routing table reverses to its original configuration:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.10.100.3     0.0.0.0         UG    1024   0        0 eth0
10.10.96.0      0.0.0.0         255.255.248.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0

And I am now able again to initiate the VPN connection. This issue was
not present before upgrading to vivid vervet, so I am not sure what the
original behavior in utopic unicorn was.

-- 
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/1423546

Title:
  [vivid] unable to manage vpn after vpn goes down

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  Just upgraded from utopic to vivid and this is a regression

  How to reproduce:
  1. Use Wi-Fi that requires (pptp) VPN
  2. Wait until VPN goes down

  What happens:
  I cannot manage VPN, that is re-enable the downed VPN. Disconnecting the Wi-Fi does not help either, it seems the VPN is in a 'stuck' state

  What should have happened:
  Like before, the UI should allow me to re-enable the VPN

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