PPTP plugin for network manager sets wrong routing table entries

[Kuropka]

Binary package hint: network-manager-pptp

Dear developers,

I noticed the following nasty bug with my Ubuntu 7.04 Feisty Fawn when I try to connect to the VPN-PPTP secured wireless network at the University of Potsdam campus via the PPTP plugin of the network manager: After creating the PPTP connection with VPN-server the internet connection doesn't work. The reason is that after the connection is established, the route to the VPN-Server is changed in a way that all packages to the VPN server are send to the networks gateway instead of to the VPN server. Therefore the connection does not work and after slightly more then a minute the PPTP-demon decides to break the connection because he do not get any echo responses. Additionally to this, the network manager applet does not show that the connection breaks.

You can reproduce this bug on our campus by doing the following:

1. Use the network manager and activate the “Universitaet Potsdam ZEIK” network.

2. Activate the VPN-Connection from the file “UP-ZEIK.pcf” (see attachment or below)

Execution of “route -n” results in:

Kernel IP Routentabelle

Ziel Router Genmask Flags Metric Ref Use Iface

172.16.3.253 172.16.3.254 255.255.255.255 UGH 0 0 0 eth0

172.16.2.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0

169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0

0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0

The problem is that the VPN-Server 172.16.3.253 is routed via the Gateway 172.16.3.254.

MANUAL SOLUTION:

The manual solution to this problem is to simply change the routing table within 60 seconds after the VPN connection is established (after the applet stopped the animation sequence which indicates that the connection phase is ongoing). To properly change the routing table the following commands have to be entered from the user “root”:

route del 172.16.3.253

route add 172.16.3.253 dev eth0

This results in the following routing table:

172.16.3.253 0.0.0.0 255.255.255.255 UH 0 0 0 eth0

172.16.2.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0

0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0

Hint: eth0 is the WLAN interface on my laptop... this might differ from your laptop.

BUG SOLUTION PROPOSALS

a) Please correct the routing strategy of the PPTP applet.

b) Alternatively: Please provide at least a possibility to manually set the route in the parameters of the VPN-connection.

In case you need a tester at the location, please do not hesitate to contact me.

Best regards,
Dominik

[Kuropka (d2)]

[main]

Description=UP-ZEIK

Connection-Type=pptp

PPTP-Server=vpn.wlan.rz.uni-potsdam.de

Use-Peer-DNS=yes

Encrypt-MPPE=yes

Encrypt-MPPE-128=yes

Compress-MPPC=no

Compress-Deflate=no

Compress-BSD=no

PPP-Lock=yes

Auth-Peer=no

Refuse-EAP=no

Refuse-CHAP=no

Refuse-MSCHAP=no

MTU=1500

MRU=1500

LCP-Echo-Failure=10

LCP-Echo-Interval=10

PPP-Custom-Options=

Peer-DNS-Over-Tunnel=no

X-NM-Routes=

Use-Routes=no

[cyd (cyd)]

hello i have a problem with pptp i can't connect to any vpn server

Inbound IN=wlan0 OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:00:00 SRC="SERVEURIPADRESS" DST=192.168.1.101 LEN=61 TOS=0x00 PREC=0x00 TTL=58 ID=19997 PROTO=47

is the destination adress correct ? it is a local address

why is Mac address so long ?

[cyd (cyd)]

thanks if anyone can help

[Craig Box (craig.box)]

On the final page in the properties dialog (Routing), there is an option "Only use the VPN connection for these addresses". Setting these influences the output, which in my case looks like this

X-NM-Routes=10.7.0.0/24
Use-Routes=yes

These aren't set in your file, as above. Set this to reflect only the networks you wish to route to, and your problem will go away.

[Craig Box (craig.box)]

Expected behaviour.

[Kuropka (d2)]

Dear Craig,

I really do not understand how the usage of "Only use the VPN connection for these addresses" shall help me in my case, since my problem is NOT to define that only 172.16.3.253 has to be routed through the VPN/PPTP connection. It's exactly the opposite. So please tell me, how do I express that EVERYTHING has to be routed via the VPN/PPTP connection EXCEPT 172.16.3.253 ? Where can I find a documentation for the meaning of the X-NM-Routes String?

Thank you and best regards,
Dominik

[Craig Box (craig.box)]

If you don't define routes to use over the tunnel it will set a default route - all traffic will go over the tunnel.

You can't set exclusions to that - what you have to do is tell NetworkManager which networks are at the other end of your tunnel - eg 192.168.0.0/24 - then it will create a route for only that network, and not a default route.

[cyd (cyd)]

For me, it is not possible to connect to a vpn i have just one message :

cannot connect ->

tryed on DDWRT can connect with windows
tryed on FORTIGATE : can connect with windows

the route doesn't help

I have connected one with nm but doesn't work anymore, wath can i do to
test ?
wich option can i try ??

Thanks,
Cyril

Le mardi 15 mai 2007 à 09:20 +0000, Craig Box a écrit :
> If you don't define routes to use over the tunnel it will set a default
> route - all traffic will go over the tunnel.
>
> You can't set exclusions to that - what you have to do is tell
> NetworkManager which networks are at the other end of your tunnel - eg
> 192.168.0.0/24 - then it will create a route for only that network, and
> not a default route.
>

[Kuropka (d2)]

Dear Craig,

I tried to make it work properly by the usage of "Only use the VPN connection for these addresses", but it simply does not work. The reason is: the PPTP applet always creates the following WRONG routing entry, regardless what I put into the X-NM-Routes field:

172.16.3.253 172.16.3.254 255.255.255.255 UGH 0 0 0 eth0

I vote for considering this behaviour as a bug or at least as a feature request, since as long as this problem is not solved I am unable to setup a proper PPTP connection which is a real reduction of functionality. I kindly ask you to reopen this issue.

By the way, I really do not understand why the usage of PPTP-VPN is so complicated under Linux. Under Windows and Mac its so easy... I just need to enter the VPN-server name login and password and everything works. Can anybody explain me why this is so complicated with Linux? (this is not a critics, I am just wondering what's the reason behind this difficulties)

Thank you and best regards,
Dominik

[Craig Box (craig.box)]

Cyril, please read http://pptpclient.sourceforge.net/howto-diagnosis.phtml - and if you can't solve your problem, raise a new bug.

Kuropka: it's difficult because the Windows and Mac clients assume you're connecting to a Windows server. The Linux client, based on PPP, lets you connect to anything, with any options. If it defaulted to Windows-friendly defaults, which my new version of the package does, it would go a long way.

I am not sure why that host route is created, so will raise a bug upstream with the author. He's been AFK for a while though so I'm not sure what luck we may have.

[Kuropka (d2)]

Thank you very much for the info and the forwarding of the problem to the upstream. Please tell me if I can help some how (e.g. by doing some testing).

[Craig Box (craig.box)]

reopened at request.

[tommytwoeyes (tommytwoeyes)]

Craig,

I have also tried using the "Only use the VPN connection for these addresses" option to prevent all traffic from being routed over the VPN connection.

From the output of routes I can tell that it has created a route solely for the destination at the other end of the tunnel, but I am still having my internet connection interrupted whenever I connect to the VPN.

Here is the output of the routes command:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
64.69.223.27 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

Could this be a bug, or have I made an error?

Thanks!
Tom

[Craig Box (craig.box)]

Which is your destination address? Shouldn't there be some routes on ppp0?

[tommytwoeyes (tommytwoeyes)]

The destination address is 64.69.223.27. I would think there should be a
route on ppp0, but I don't understand why there isn't one.

Before I checked the "Only use the VPN connection for these addresses" box
and entered 64.69.223.27/27, the default route was sending everything over
ppp0.

Thanks for your help! Much appreciated!

Tom

On 7/24/07, Craig Box <email address hidden> wrote:
>
> Which is your destination address? Shouldn't there be some routes on
> ppp0?
>
> --
> PPTP plugin for network manager sets wrong routing table entries
> https://bugs.launchpad.net/bugs/113622
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Craig Box (craig.box)]

Try adding the route with 'route add' from the command line.

I suspect that it will fail because you're trying to add a route using a
host address when you need to use a network number - which, according to
jodies.de/ipcalc, is 64.69.223.0/27.

[tommytwoeyes (tommytwoeyes)]

Thanks Craig.

I looked at the man page for route, but as far as I could tell, there isn't
a way to specify which interface to use when adding a route. Please forgive
my ignorance. I am a total n00b when it comes to networking.

Thanks
Tom

On 7/24/07, Craig Box <email address hidden> wrote:
>
> Try adding the route with 'route add' from the command line.
>
> I suspect that it will fail because you're trying to add a route using a
> host address when you need to use a network number - which, according to
> jodies.de/ipcalc, is 64.69.223.0/27.
>
> --
> PPTP plugin for network manager sets wrong routing table entries
> https://bugs.launchpad.net/bugs/113622
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Craig Box (craig.box)]

You can use 'dev', but if you specify 'gw' and then the IP address of
your tunnel it will work this out for you automatically.

[Launchpad Janitor (janitor)]

[Expired for network-manager-pptp (Ubuntu) because there has been no activity for 60 days.]

[Christian Ober-Blöbaum (cob)]

Hi!

Since this bug was closed automatically and not marked fixed, I wonder if it is still an issue since I am still using 0.6.3 (from feisty, where the bug is still there) and do not want to upgrade without knowing that it will be worth the hassle...

[Kuropka (d2)]

I am using Ubuntu 7.04 Feisty and this is still an issue for me and all other members of my university campus. I hope it will be fixed with the next Ubuntu version... I am still waiting for the Beta to test it.

[Craig Box (craig.box)]

On 26/09/2007, Kuropka <email address hidden> wrote:
>
> I am using Ubuntu 7.04 Feisty and this is still an issue for me and all
> other members of my university campus. I hope it will be fixed with the
> next Ubuntu version... I am still waiting for the Beta to test it.

The plugin hasn't changed substantially between releases. (The upstream
author is MIA.)

There may be some more love in Hardy as NM 0.7 may be out by then. There is
also another MOTU who is interested in working on this package post-Gutsy.

However, I've not yet seen any hard, duplicable evidence, that this is
actually a bug. Please feel free to point me at any.

[Kuropka (d2)]

Okay, I can agree with calling it not a bug, but it is definatelly a missing feature which makes Ubuntu hard to use for noobs. The problem is that people have to set the route manually (e.g. by invoking an extra script, in time withing 60 secs) after connecting to the WLAN with the plugin. For noobs it would be much easier if this updating of the route could be somehow integrated into the plugin (e.g. as an additional parameter or option) and distributed within a PCF-File.

[Craig Box (craig.box)]

On the last tab of the dialog (from memory), there is a dialog for doing
exactly this!

[Christian Ober-Blöbaum (cob)]

Craig,

are you thinking of one of the two options on the routing tab? I think neither of them does delete the wrong route and sets the correct one so that after the connection is established it would be indeed usable. But since exactly this is the desired behaviour for the main use case (click "connect" and just use the connection) I would call this a bug. The average ubuntu user just sees the current behaviour as "not working".

Ideally when connecting the routes should be set correctly and there could be an option under the mentioned routing tab to disable the automatic route setting so that expert users that do not want other connections to be interrupted have the possibility to configure the desired behaviour.

In the current state the behaviour is unfriendly for the "average user" that does not know anything about routing but friendly to "experts" that certainly know how to do things manually anyway.
And since there is no explanation or warning message that the connection is not yet usable and more steps have to be taken for this, it is indeed a bug because the behaviour is quite far from the expected one.

Greetings,
Christian.

[Craig Box (craig.box)]

So, to summarize what you are saying: adding a route in this dialog works,
but it also creates a "default route", which it does not delete?

This is definitely an upstream issue.

[Christian Ober-Blöbaum (cob)]

Almost: it is possible to create a routing entry using the dialog so that specific addresses are routed through the tunnel. But additionally it creates a wrong routing entry like this (which tries to route the pptp server over the gateway):

172.16.3.253 172.16.3.254 255.255.255.255 UGH 0 0 0 eth0

which is wrong and has to be deleted (route del 172.16.3.253) and replaced by an entry for the interface:
route add 172.16.3.253 dev eth0
resulting in:
172.16.3.253 0.0.0.0 255.255.255.255 UH 0 0 0 eth0

Only after doing these two steps manually it is possible to use the pptp interface.

But I agree with you that this is an upstream issue.

Christian.

[Craig Box (craig.box)]

OK. I've raised this upstream as
http://bugzilla.gnome.org/show_bug.cgi?id=481620.

I think I understand the problem now:

NetworkManager expects the server you are connecting to to be behind your
default gateway, so when it creates a default route over the server, it
creates a host route to that machine, via the GW.

However, if the server is ON your local network, then it creates a route
incorrectly via your gateway.

Is this a correct summary?

[Kuropka (d2)]

I am not an expert in this stuff, but the mail above seems to summarize it correctly.

[Christian Ober-Blöbaum (cob)]

That exactly summarizes the problem Craig - thanks for your patience and for reporting the problem to upstream.

Christian.

[kultex (kult-ex-gmx)]

My problem now (Ubuntu + Xubuntu 7.10) is quite the same - I got Network-Manager-PPTP working correctly - the tunnel is established, but it eats the rest of my Internetconnection - I found a post, where it is described to work correctly by unchecking "Use Peer DNS", "Exclusive Device Lock", "Peer DNS through Tunnel". This does not work for me in Version 7.10.

I unchecked all three points, but still all traffic goes through the tunnel - and as soon as I want to choose under Routing "Only use VPN connection for theses addresses" and add just one number or letter - the apply butten is not any more available.

Generally I want to say, that choosing networkmanager-pptp instead of pptpconfig was a very bad decison - it was working perfectly - you cold choose the routing - edit the network routes - all perfect and with this stupid thing you can do nothing!!!! and nothing works!!!!!

"On distributions that support NetworkManager, pptpconfig is deprecated in favour of the PPTP Plugin for Network Manager. On Ubuntu and derivatives the package name is network-manager-pptp."

http://quozl.linux.org.au/pptp/pptpconfig/0-README.phtml

[Craig Box (craig.box)]

There is no real upstream work being done on this plugin.

Someone with some programming bent needs to adopt it as a pet project for the required changes to really be implemented, I'm afraid. Perhaps a Google Summer of Code sponsorship might happen, or Red Hat/Canonical might decide they have a commercial interest in good Windows VPN support on their client OS. Until then we're at the whim of those who are prepared to do the work themselves.

[kultex (kult-ex-gmx)]

This I do not understand - to have good windows VPN support is a must for small offices to change to Linux. I have quite a lot of adminstrator friends, who want to change now (because of Vista), they ask me which linux distribution they should take - and all ask, is PPTP working. I know pptp is not very safe, but the servers (either linux or windows) are using it. So it seems I have to recomand good old debian, which still is working with pptpconfig - quite a pitty (there is no automation for restriced drivers ...but still this is better than having pptp not working)

[Matthias (m-kaeppler)]

I have the exact same problem with NetworkManager, network-manager-pptp and Ubuntu Hardy.

Problem summary:
NM creates bad routing entries, where all packages are forwarded to the VPN server as a gateway instead of the PPTP tunnel endpoint.

Funny thing is, if you correct the routing table by hand, e.g. "route add default gw <tunnel_ep_IP>", it will work for a couple of requests, but after a while the custom entry will be purged from the routing table and you will have to enter it again... Plus, if you repeat this procedure a couple of times, sooner or later the networking will break down completely with the error message:

"SIOCADDRT: No such process"

only a restart of the NM process will fix this from there on. Looks to me as if NM+PPTP is fundamentally broken in Ubuntu. I have heard reports of it working flawlessly on SUSE and ZenWalk.

[Yura Tolstik (yltsrc)]

i am confirm this bug with ubuntu8.04 and network-manager-pptp network-manager-pptp 0.7~~svn20080928t225540-0ubuntu1.

after connect NM set wrong routing table

[Craig Box (craig.box)]

Still not fixed upstream as per http://bugzilla.gnome.org/show_bug.cgi?id=481620.

[Craig Box (craig.box)]

... is now.

If a new package can be built, we can have it tested - unsure about getting it into Intrepid though?

[Matthias (m-kaeppler)]

glad to hear that this is fixed now, thanks for the information Craig. I hope it will make it into Intrepid as some kind of hotfix, since Intrepid packages have already been frozen if I'm not mistaken.

[JazzyPenguin (jazzy-clarinet)]

Some News From Intrepid, I guess the fix didn't make it into the final release. With a routing entry I can get HTTP traffic to be routed through the default gateway. As tested by external IP address checkers correctly reporting my (and not my office IP address). With the VPN running I can use remote desktop protocols to machines on the office subnet (192.168.57.150) so that has to be working too. However, HTTP traffic is slower (i.e. web pages take longer to load) with the VPN running despite being routed via the default gateway. In addition one particular subnet address, that of the VPN server and office router (192.168.57.2), gets routed via my default gateway (192.168.15.5). The attached file shows my routing after issuing "route" in terminal with and without the VPN running. IP of the office X'd out for security reasons only, it showed the correct address. My routing table entry in the VPN is address = 192.168.57.0 Prefix = 24. My understanding is that any traffic to any IP address starting 192.168.57.XXX should be routed via the VPN. Why is traffic to 192.168.57.2 being directed over the default gateway, but traffic to other IP addresses in the subnet is correctly trafficked via the ppp0. Is this a bug in the VPN's routing table or some more global routing issue. Could my browser be using the VPN connection to resolve DNS thus slowing down web access? If so why.

[Niconux (hachet-nicolas)]

Hello World (and people ;) )

Using Intrepid and trying to establish a VPN to my linux pptp server, I got some trouble with the routing table.

Before the connection, route -n gives :
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.123.0 0.0.0.0 255.255.255.0 U 2 0 0 wlan0
0.0.0.0 192.168.123.254 0.0.0.0 UG 0 0 0 wlan0

This is correct as my private network is 192.168.123.0/24 and my wifi interface wlan0

Then after the connection, route -n gives :
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.10 192.168.123.254 255.255.255.255 UGH 0 0 0 wlan0
88.191.52.170 192.168.123.254 255.255.255.255 UGH 0 0 0 wlan0
192.168.123.0 0.0.0.0 255.255.255.0 U 2 0 0 wlan0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0

In the IPv4 section, I let tried several options to ignore the automatic route changes ... without success.

So I have to manually change the route as follows to enable access to my server through the vpn and access to internet through my lan:
route del 192.168.1.10
route add 192.168.1.10 dev ppp0
route del -net 0.0.0.0 gw 0.0.0.0 dev ppp0
route add -net 0.0.0.0 gw 192.168.123.254 dev wlan0

It's working just as it should then we can remove the entry pointing to the server:
route del 88.191.52.170

I can find a way to specify the interface in the routing section of the vpn configuration of NM ... did I miss something or is there a hidden feature ? Maybe a missing feature ?

Anyway, I don't get it why the default gateway is re-routed through my ppp0 interface ...

Does anyone have a clue ?

Thanks a lot for your time,

Nicolas

[Craig Box (craig.box)]

@Nicolas: Your problem is a bug, which has been fixed in the upstream source code, but not fixed in the Ubuntu packages. Someone will need to build a new package for you to test. I don't have the ability to do so now, but keep an eye on this bug report, and it should happen soon.

[Alexander Sack (asac)]

Nicolas, I think your bug is about not properly applied manual IP4Settings. So if you tried to setup your routes manually. That would be bug 303165.

[Jonas Hörsch (coroa)]

Hey everyone,

i'm sorry, i don't know about the current status of the initial bug reported as several different workcases have mingled here since then, and my nm7.0 has already become old (testing portage tree of gentoo)

the original bug was, as i understood:
the route to the PPTP server has to pass over a (local) gateway, f.ex. 192.168.178.1 in my case. when nm-pptp is connected to the server it resets the default route to point to the pptp server (correct behaviour as no specific routing info is configured).

But doesn't set a host route to the pptp server which would use the original (local) gateway, so that the connection between pptp-client and server is severed and expires after a timeout.

This bug still applies to my nm-pptp installation (networkmanager pptp 0.7.0).

It can be solved, by a script in /etc/ppp/ip-up.d/50-nm-vpn.sh:

[ ${6:0:8} = "nm-pptp-" ] || exit 0 # makes sure we only touch nm-pptp- connections
VPNNAME=$(ps -C pppd -o args= | cut -d ' ' -f 4) # obtains the hostname or ip of the pptp-server (will not work with multiple connections!!!)
VPNIP=$(ping -c1 $VPNNAME | grep PING | sed 's/^[^(]*(\([^)]*\)).*$/\1/') # resolves its ip
ip route add $(ip route get $VPNIP | sed 's/^\(.*\)cache.*$/\1/') # corrects the routing info

which uses 'ip route get <ip of the pptp server>' to find the correct routing configuration to reach the server.

[Patrik Nilsson (nipatriknilsson)]

Below are three connection attempts which failed the first time to properly connect to the VPN-server. Most often the default route is not set properly and when hung up not all routing entries were always deleted.

The pptp-plugin reported every time that the connection succeeded.

patrik@ubuntu:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
213.232.200.166 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0
213.232.200.200 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0
213.232.200.200 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0
1.2.96.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.255.0 U 2 0 0 wlan0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 wlan0
patrik@ubuntu:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
213.232.200.166 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0
213.232.200.200 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0
213.232.200.200 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0
1.2.96.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.255.0 U 2 0 0 wlan0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
patrik@ubuntu:~$

patrik@ubuntu:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
213.232.200.166 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0
213.232.200.166 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0
213.232.200.200 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0
213.232.200.200 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0
1.254.6.14 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.255.0 U 2 0 0 wlan0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0
patrik@ubuntu:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
213.232.200.166 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0
213.232.200.166 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0
213.232.200.200 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0
213.232.200.200 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0
1.2.96.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.255.0 U 2 0 0 wlan0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0

patrik@ubuntu:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
...