Re: Strange VPN problems

[Dan Williams <dcbw redhat com>]

On Thu, 2008-11-06 at 12:09 +0000, Rick Jones wrote:
> --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
> 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

mobile broadband I assume?

> 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

No, this is a default route through the VPN, which is expected, since
there aren't any custom routes either sent by the VPN server or added by
you.  If there are no custom routes, everything will be sent through the
VPN because you have not told NetworkManager what specific routes to use
the VPN for.

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

Maybe, maybe not :)  It depends on policy.

Dan

> ¦ 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