Public bug reported:
Binary package hint: network-manager
# apt-cache policy network-manager network-manager-pptp pptp-linux ppp
network-manager:
Installed: 0.7.1~rc4.1.cf199a964-0ubuntu2
Candidate: 0.7.1-0ubuntu1ocdc3+jaunty
Version table:
0.7.1-0ubuntu1ocdc3+jaunty 0
500 http://ocdc.hursley.ibm.com beta/jaunty Packages
*** 0.7.1~rc4.1.cf199a964-0ubuntu2 0
500 http://mirrors.us.kernel.org jaunty/main Packages
100 /var/lib/dpkg/status
network-manager-pptp:
Installed: 0.7.1~rc4.20090316+bzr23-0ubuntu3
Candidate: 0.7.1~rc4.20090316+bzr23-0ubuntu3
Version table:
*** 0.7.1~rc4.20090316+bzr23-0ubuntu3 0
500 http://mirrors.us.kernel.org jaunty/universe Packages
100 /var/lib/dpkg/status
pptp-linux:
Installed: 1.7.2-1
Candidate: 1.7.2-1
Version table:
*** 1.7.2-1 0
500 http://mirrors.us.kernel.org jaunty/main Packages
100 /var/lib/dpkg/status
ppp:
Installed: 2.4.5~git20081126t100229-0ubuntu2
Candidate: 2.4.5~git20081126t100229-0ubuntu2
Version table:
*** 2.4.5~git20081126t100229-0ubuntu2 0
500 http://mirrors.us.kernel.org jaunty/main Packages
100 /var/lib/dpkg/status
# uname -a
Linux ds 2.6.28-15-generic #48-Ubuntu SMP Wed Jul 29 08:53:35 UTC 2009 x86_64
GNU/Linux
I'm connecting from one LAN (192.168.1.x) to another (9.x.x.x) through a
proprietary vpn, then using NetworkManager's PPTP vpn plugin to connect to a
third one (10.x.x.x) through a pptp gateway in the second one (9.x.x.x).
local wifi card (wlan0) address: 192.168.1.64
lan gateway: 192.168.1.254
lan subnet: 192.168.1.0 (netmask 255.255.255.0)
first vpn (tun0) address: 9.76.10.27
first vpn subnet: 9.0.0.0 (netmask 255.0.0.0)
first vpn client: at&t global network client (agnclient)
second vpn gateway: 9.30.138.171, windows server 2003 pptp remote access server
second vpn subnet: 10.160.0.0 (netmask 255.255.0.0)
second vpn local (ppp0) address: 9.30.138.111
second vpn remote point-to-point address: 9.30.138.110
second vpn client: NetworkManager with PPTP plugin, configured to only add the
route: 10.160.0.0 nm 255.255.0.0 dev ppp0
While connected to the first vpn , before connecting to the second,
here's the route to the second gateway:
$ ip route show | grep 9.30.138.171
$ ip route get 9.30.138.171
9.30.138.171 dev tun0 src 9.76.40.155
cache mtu 1362 advmss 1322 hoplimit 64
And the 10.160.0.0 subnet going through the default lan router as
expected:
$ ip route show | grep 10.160
$ ip route get 10.160.2.2
10.160.2.2 via 192.168.1.254 dev wlan0 src 192.168.1.64
cache mtu 1500 advmss 1460 hoplimit 64
So far so good. Now after connecting to the pptp vpn at 9.30.138.171
with NetworkManager, as NM starts trying to connect (and before it can
reach the server), it already adds an explicit route:
$ ip route show | grep 9.30.138.171
9.30.138.171 dev tun0 scope link src 9.76.40.155
after it connects to the vpn gateway, ppp0 comes up with the local
address of 9.30.138.111 and the 10.160.0.0 subnet route gets
established:
$ ip route show | grep ppp
9.30.138.110 dev ppp0 proto kernel scope link src 9.30.138.111
10.160.0.0/16 dev ppp0 proto static scope link
but NM messes up the route to the gateway itself:
$ ip route show | grep 9.30.138.171
9.30.138.171 via 192.168.1.254 dev wlan0 proto static
9.30.138.171 dev tun0 scope link src 9.77.157.83
$ ip route get 9.30.138.171
9.30.138.171 via 192.168.1.254 dev wlan0 src 192.168.1.64
cache mtu 1500 advmss 1460 hoplimit 64
There should be no explicit route to 9.30.138.171, least of all to wlan0, which
is the wrong interface in this case. As a result, no traffic goes through the
vpn tunnel and I can't even reach 9.30.138.171 until I remove the wlan0 route
with
# route del 9.30.138.171 gw 192.168.1.254 dev wlan0
Removing the other, extraneous route is innocuous, since there was already
another route to it when the at&t client established the tun0 connection:
# route del 9.30.138.171 dev tun0
# ip route show| grep tun0
9.0.0.0/8 via 9.65.15.7 dev tun0 scope link
** Affects: network-manager (Ubuntu)
Importance: Undecided
Status: New
--
NetworkManager adds incorrect routes to VPN gateway
https://bugs.launchpad.net/bugs/413868
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
