Preserve client's default route if networks conflict

[santjago]

In case of networks conflict when server pushes a route to client that overlaps client's default route path client's Internet connection becomes useless untill OpenVPN link drops by timeout (if any). That'd be best an option like 'route-protect def1' for clients' config that'd mean:

add the metric 1 most specific path route to current default gateway through current device of client's network stack to preserve Internet connectivity in case server pushes any route that overlaps current default gateway route (if not present yet)'

That could solve an uncommon but unresolvable configuration where:

• client's local net IF is 172.16.86.167/22
• client's default route is 172.16.84.1
• server pushes a route '172.16.84.0 255.255.255.0' on successful connect

I guess people'd better optionally sacrifice 172.16.84.1 on remote tunneled network than total internet connectivity if random hotel network's administrator made BINGO of one's private address space.

[Samuli Seppänen]

Wouldn't it make more sense to fix the problem, i.e. overlapping of the two networks? I'm not sure if we want to try to make overlapping routes suck less. Perhaps cron2 could chime in here...

[Gert Döring]

I'm not sure I understand the proposed solution with the metric, but whatever we do, it will blow up for someone using overlapping networks. We *could* refuse to install a route that overlaps with the default gateway (by checking for "is the default gateway inside this network?").

[Gert Döring]

Copying in plaisthos. Isn't this something you did for the new Android client?

[plaisthos]

I do something similar. I calculate an non overlapping route from the included and excluded routes (​http://code.google.com/p/ics-openvpn/source/browse/main/src/main/java/de/blinkt/openvpn/core/NetworkSpace.java) and then don't install the excluded routes.

[Gert Döring]

Mmmmh. Coming back to this, after looking the other way for way too long.

Not sure this is completely solvable.

Overlaps of "the vpn server is in one of the pushed networks" can be fixed with redirect-private.

Fixing the "the gateway is in one of the pushed networks" would require either "just ignore that route" (fairly easy) or "split the route into fragments all around the default gateway" (8 routes for a /24).

Metric is not going to help. A more-specific network (/24 vs. /22) will always be preferred, no matter what metric is set.

Adding a more-specific host route for the gateway ("gateway /32 ON DEVICE LAN") would work, but setting up such a route is very system dependent = different code for all supported operating systems = testing and maintenance heavy. So, not going there.

Making this a feature wish for 2.6 - "look at incoming routes, detect conflicts with local gateway address, and either reject route or split it up".

(Of course the best approach is to use IPv6 and stop using private IP space left and right of the VPN... just sayin)

[Gert Döring]

The planned "rework routing and OS <-> routing layer" work did not happen in the pre-2.6 timeframe. Bumping to 2.7