NetworkManager adds incorrect routes to VPN gateway
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
network-manager (Ubuntu) |
Expired
|
Low
|
Unassigned |
Bug Description
Binary package hint: network-manager
# apt-cache policy network-manager network-
network-manager:
Installed: 0.7.1~rc4.
Candidate: 0.7.1-0ubuntu1o
Version table:
0.
500 http://
*** 0.7.1~rc4.
500 http://
100 /var/lib/
network-
Installed: 0.7.1~rc4.
Candidate: 0.7.1~rc4.
Version table:
*** 0.7.1~rc4.
500 http://
100 /var/lib/
pptp-linux:
Installed: 1.7.2-1
Candidate: 1.7.2-1
Version table:
*** 1.7.2-1 0
500 http://
100 /var/lib/
ppp:
Installed: 2.4.5~git200811
Candidate: 2.4.5~git200811
Version table:
*** 2.4.5~git200811
500 http://
100 /var/lib/
# 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
tags: | added: vpn |
Thanks for taking the time to report this bug and helping to make Ubuntu better. Could you please open a terminal and execute: apport-collect 413868 ? It will attach the necessary information to this report. Also you can submit more information for it by looking to https:/ /wiki.ubuntu. com/DebuggingNe tworkManager , Thanks in advance.