On Thu, Dec 1, 2016 at 3:07 AM, Gert Doering <g...@greenie.muc.de> wrote:

> On Wed, Nov 30, 2016 at 11:06:02PM +0100, Arne Schwabe wrote:
> > Slight correction. We actually set on Android but Android
> > *always* translates that into a and a 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.

Openvpn-devel mailing list

Reply via email to