Hi, On Wed, Aug 24, 2016 at 10:12:54AM +0200, Jan Just Keijser wrote: > may I suggest to make this configurable,
Well...
> i.e. the user can specify
> whether rec routed packets should be dropped? I'm afraid that we might
> end up with code that drops packets that really should not be dropped -
> people do weird things with routing: in 99% of the cases in error, but
> in 1% of the cases because they want to do something funky.
There is no way that this might ever work(*).
If your tunnel gateway is 1.2.3.4, and you send packets to 1.2.3.4 into
the tunnel, how are these going to arrive?
Packet goes to TUN, is ecapsulated, and sent to 1.2.3.4.
1.2.3.4 route points to TUN, so packet goes to TUN, gets another layer
of openvpn, and is sent to 1.2.3.4.
1.2.3.4 route points to TUN, so packet goes to TUN, gets a *third* layer
of openvpn, and is sent to 1.2.3.4.
repeat, until the packet hits 1500 byte MTU, and gets fragmented into
*two* packets that loop forever...
gert
(*) it will work if and only if there are multiple routing tables involved,
that is, packets sent by openvpn itself are not subject to the routing
tables that would move packets *into* the tunnel - so the Android client
wouldn't need it (VPN API takes care of this), and with the work on
Github #13 to suport network name spaces on linux and multiple routing
tables on *BSD, there are indeed scenarios where this makes sense...
... so you're right, v3 needs to have an option...
(This started out really small and simple :-) )
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
signature.asc
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
