openvpn

openvpn copied to clipboard

By using this option the user can decide which routing table should be used by OpenVPN.

Benefits:

1. No need for dedicated up/down scripts to archive that behavior
2. cleaner routing setup / dedicated tables for different instances
3. Ease of use - mark all packets that should use the tunnel using an iptables rule and apply an ip rule that all marked packets should use the routing table containing the route entries for the/that tunnel
4. By using (3) it is possible to switch the packet flow between vpn tunnel and other routing targets (eg. direct connection, second tunnel, etc.) without changing the routing tables
5. By using (3) killing the tunnel client means also interrupting the connection for the tunneled clients (having the default routes mixed with the route entries from OpenVPN results in a fall back to the former routes if the OpenVPN client gets (accidentally) killed and that may lead to a security problem).

Draw backs: This option works only on LINUX with iproute2 support enabled (enable_iproute2).

This would be very useful for policy-based routing - I'm having to use shell scripts to implement this at the moment and it can get a bit messy.

Hi,

sorry for not reponding to this earlier - we don't usually do git pull requests, so this one totally got overlooked (formal way is to send patch to openvpn-devel).

There is one detail that you might want to think about - in redirect_default_route_to_vpn(), the first call to add_route3() is installing a host route to ensure that redirected default gateways do not affect talking to the OpenVPN server (host route to previous default gateway). I do not think this one should have the "table" argument, as the route really should go to the routing table openvpn itself is living in.

The other detail that I'm slightly unhappy about is the introduction of a new "table" argument to half the functions in route.c, but being very specific about Linux and "table xxx" - we might want this to be more general to permit NS_NET namespaces on Linux, or routing table numbers on the BSDs... but I have no really good idea how to tackle this. Hiding it in "struct tuntap _tt" might make the patch set smaller, but is not exactly the right thing to do (_and* would fail the redirect_default_route_to_vpn() case).

Anyway - and please rebase to current git master, as all the new IPv6 routing stuff make this not trivially apply anymore :-) - thanks

so - what about this? To be able to review it, it would at least need to be rebased to git master, and address the comment above.

ahm, sorry.

changed the job and became a father... and lost track of a hell lot of things.

I try to work on the issue in the next days. But maybe the whole thing needs a conceptual overhaul - if I recall the 'how it was done' correctly it was more a Linux specific hack then a solution. For Linux namespaces could do the trick now-days. And as far as I red BSD Jails could be used as the interface to add a per openvpn instance specific routing table.

Should we discuss the concept or should I go and rebase & fix the old stuff?

kr

hecke

On 05/30/2016 09:14 PM, Gert Doering wrote:

so - what about this? To be able to review it, it would at least need to be rebased to git master, and address the comment above.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/OpenVPN/openvpn/pull/13#issuecomment-222542954, or mute the thread https://github.com/notifications/unsubscribe/ABicnRTG97RzZUD3GyVQ1SPcOo4_PRqNks5qGzcbgaJpZM4BlPET.

Moved forward to master and addressed issue one.

To solve the second issue (LINUX specific table argument added to route-functions) we should discuss the whole concept first.

@orivej already started to work on a namespace based solution (https://github.com/OpenVPN/openvpn/issues/60) that could be seen as an extension to the table-based approach as you can still have different tables in Linux namespaces - so you may use them together. The use of namespaces and/or different routing tables addresses different use cases with inert pros and cons so both mechanics should be implemented - imho.

Maybe we could combine the attributes of LINUX namespaces, freeBSD fibs and named LINUX routing tables into some common context - or - with other words: lets hide it in a struct...

I would happily takeover the freeBSD/setfib - part.

kr,

hecke

Hi,

On Thu, Aug 11, 2016 at 03:11:18PM -0700, hecke wrote:

Maybe we could combine the attributes of LINUX namespaces, freeBSD fibs and named LINUX routing tables into some common context - or - with other words: lets hide it in a struct...

Something like that sounds like a good plan. So the generic code will not need any (larger) changes, and the platform specific bits can then address what they need (and it's good that you already noticed #60, so it's not wasting effort by duplicating work)

There's a few interesting aspects here - figure out which namespace/rt/fib the "outside connection" should be (openvpn talking to the server), and if that is different from the "inside" namespace/rt/fib, we can skip the whole "redirect default gateway" dance of figuring out what the current default route is, installing a host route, installing two /1s (for IPv4), etc - because that's all no longer needed if the "inside default route" is not affecting "outside" packets anyway.

I would happily takeover the freeBSD/setfib - part.

Cool :-)

gert

USENET is not the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [email protected] fax: +49-89-35655025 [email protected]

There's a few interesting aspects here - figure out which namespace/rt/fib the "outside connection" should be (openvpn talking to the server), and if that is different from the "inside" namespace/rt/fib, we can skip the whole "redirect default gateway" dance of figuring out what the current default route is, installing a host route, installing two /1s (for IPv4), etc - because that's all no longer needed if the "inside default route" is not affecting "outside" packets anyway.

The inside namespace may already have a default gateway, so this redirection may be necessary, but in case of setns and presumably setfib OpenVPN can handle this situation without any changes, and the only change necessary is the support for routing tables without default gateway, which was the final piece of #60: https://github.com/OpenVPN/openvpn/pull/60/commits/30cd19697e76142577cf44187a54649e093690d2

Hi,

On Fri, Aug 12, 2016 at 01:36:04AM -0700, Orivej Desh wrote:

The inside namespace may already have a default gateway, so this redirection may be necessary,

Replacement / re-installation of the default route, yes (possibly).

But not the "set up a host route to be able to still reach the VPN server" part, which is only needed "outside" - and that's actually the trickier part.

For the default route, one could make "def1" a requirement (install not a /0 default, but two /1 routes) - so an existing default route "inside" would never be a problem either...

gert

USENET is not the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [email protected] fax: +49-89-35655025 [email protected]

Closing this PR as this is old and requires to be reimplemented anyway. OpenVPN now features "SITNL" which already supports specifying the routing table.

Adding a new option is what's missing and should be reimplemented.

Should anybody be willing to work on this task, please send the resulting patch to the mailing list.