Re: [Openvpn-devel] [PATCH applied] Re: Force 'def1' method when --redirect-gateway is done through service

[Selva N. <sel...@gm...>]

Hi,

On Thu, Dec 1, 2016 at 3:07 AM, Gert Doering <ge...@gr...> wrote:

> On Wed, Nov 30, 2016 at 11:06:02PM +0100, Arne Schwabe wrote:
> > Slight correction. We actually set 0.0.0.0/0 on Android but Android
> > *always* translates that into a 0.0.0.0/1 and a 128.0.0.0/1 rule.
> >
> > We could do the same and do the translation in the interactive service
> > instead of OpenVPN itself.
>
> We could, but that wouldn't solve the issue of OpenVPN trying to
> remove the existing default route (which we would have to special-case-and-
> ignore) and reinstall it later on (which must not be translated to
> 2x /1, but ignored as well).
>
> The service code doesn't know whether a route is "for the VPN API" or
> "for anything else" (which openvpn on "non VPN API" platforms always
> could do) so this would be a much more intrusive change...


I think it could work like this:

In DeleteRoute()
   if dest == 0/0 delete routes to 0/1 and 128/1
   (ignore any "route does not exist" error)

In AddRoute() <-- this function doesn't currently exist
   if dest == 0/0 add routes to 0/1 and 128/1
   (this will add two extra routes when default gateway is restored, but
cant hurt)

In this scenario, route to 0/0 is never touched by the service.

When we ask the service to:
   delete default route to gw --> nothing happens unless there were routes
to 0/1 and 128/1
   add default route through tun  --> adds routes to 0/1 and 128/1 via tun
   delete default route through tun --> OK
   add default route to gw --> adds routes to 0/1 and 128/1 via gw

When process exits/crashes, the service thread exits and the extra routes
to 0/1 and 128/1 get removed. If service crashes those routes will remain,
not ideal, but safe, I suppose.

Did I overlook something?

Not that I like it. Wonder how android does it.

Selva