Re: Strange VPN problems

[Rick Jones <rick activeservice co uk>]

--On 06 November 2008 06:42 -0500 Dan Williams <dcbw redhat com> wrote:
¦ 
¦ Is 192.168.7.128 the address of the VPN server?

Yes

¦ > NM clearly doesn't insert a route to the VPN server (192.168.7.128). 
¦ 
¦ But it should; if it doesn't there's a bug.  There's currently a bug
¦ where, upon DHCP renewal, NM will flush that host route to the VPN
¦ gateway.  I'm trying to fix that right now.

Sounds like it could be the problem. The VPN server is also the DHCP server, and I guess the client renews the lease on each connection.
¦ 
¦ > It has also zapped the default route. Has this been fixed in a later
¦ > build?
¦ 
¦ If there are any custom routes sent by the VPN server (pptp doesn't have
¦ this capability) or entered by you in the IP4 Routes dialog, NM assumes
¦ that you do not want the VPN to be the default connection (if it was,
¦ any custom routes would be completely redundant).  I don't think that's
¦ the case here, your issue looks like a bug.

AFAIK the server is not doing anything fancy with routes. Prior to establishing the VPN, the default route is to the MB host address:

0.0.0.0         10.36.193.0     0.0.0.0         UG    0      0        0 ppp0

When the VPN is up, this entry has gone, replaced by something that looks to me like a meaningless route:

0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp1

Standard pptp leaves the default route alone, as it should.

¦ Any idea what SVN revision your NM is based on?

The package id on ppa.launchpad.net is 0.7~~svn20081018t105859-0ubuntu2-nm2-hardy1. I guess that's from SVN dated 2008/10/18, the other numbers don't mean anything to me.

I've can confirm that routing is the sole cause of the problem - if I make the VPN connection in NM, then immediately enter the missing routes manually, it all works and stays connected, echo packets function, etc.

-- 
Cheers
Rick