Re: openvpn fixes against svn 3140

[Dan Williams <dcbw redhat com>]

On Thu, 2007-12-06 at 16:25 +0000, Jon Escombe wrote:
> ----- "Dan Williams" <dcbw redhat com> wrote:
> > On Thu, 2007-12-06 at 13:25 +0000, Jon Escombe wrote:
> > > ----- "Jon Escombe" <lists dresco co uk> wrote:
> > > > I'll try to debug the ppp case further, see what's different 
> > > > there that it's not liking..
> > > 
> > > Appears that openvpn just doesn't like the way the default route is
> > set up by the ppp connection
> > 
> > Tambet has a patch that may fix this; it makes stuff set up routes
> > correctly with PPP devices.  Not sure yet if layering openVPN on top
> > screws that up yet though.
> > 
> > Dan
> > 
> 
> I think I'm getting my head around this a bit more now..
> 
> So I've got three basic issues in the routing/vpn setup -
> 
> 1) when using a ppp connection, pppd doesn't specify a gateway address in the default route (at least not for my Vodafone UMTS connection). This  prevents openvpn from recognising/changing the gateway. Hopefully the patch you mention above will resolve this if NM is initiating the ppp connection. I think it should just be a case of setting the interface address as the gateway if none is already specified..
> 
> 2) openvpn and NM are both trying to setup the routes after connection, I believe thats why there's an error message in the log. Perhaps we should be passing the --route-noexec parameter to stop openvpn manipulating the routes itself? 

Yeah, openvpn should _not_ be setting up routes itself.  It should hand
those routes back to NM so that NM can make intelligent decisions on
what to do; for example let the user override those routes.  It's
routine to do this with vpnc, because many sysadmins will just say
"everything must go through VPN" and that's something that should be
able to be overridden, if users so desire.

> 3) As I'm using a TAP device type and therefore effectively bridged onto my vpn server subnet, my default route needs to include the gateway to get off that subnet. This is available as the route_vpn_gateway environment variable, but it's not picked up by NM. Not sure whether this would also be required for a TUN connection?

Ah, that might be it.  Not sure what to do here off the top of my head
though.

Dan