Hi, On Fri, Mar 26, 2021 at 11:30:31AM +0100, Antonio Quartulli wrote: > We have two options now: > 1) extend documentation (basically what part of this patch is doing); > 2) rework this feature entirely. > > If we go with 2 I guess we don't even need 1. > > I'd go with 2, because this feature as it is now is not really > meaningful to me.
Well, "not really meaningful" depends a bit on what "this feature" might
be.
The original feature (disallow recursive routing) was needed because it
prevents a CPU meltdown under certain conditions
- the VPN server IP address is part of the network that is routed
inside the tunnel (due to "redirect-gateway" or just because it is
part of an ISP block)
- the outgoing interface flaps or changes, and the OS removes the
"bypass route"
- packets sent by OpenVPN are sent by the OS to the tunnel interface,
re-encapsulated by OpenVPN, forever
This breaks setups where "OpenVPN traffic" is handled specially (route-policy
on Linux, VRF routing, protected socket), and users *want* to access the
VPN server IP via the tunnel - like, because there is http traffic on the
same machine that is not accessible "around".
So, --enable-recursive-routing was added to allow "suspicious looking
traffic" through the tunnel, under the "I know what I am doing" rule of
shooting-your-own-foot.
The existing debug info gives too little information to differenciate
"is this openvpn traffic or not?" but I find the extra code needed to
log this to be excessive for the benefit - but, yeah, thinking more through
it, since that code got written already, we *should* use it to only
block OpenVPN traffic ("same proto and dest port") and permit everything
else if the OS sends it our way.
And document more so users do not get confused more than needed :-)
(And no, adding #ifdef is not a useful approach)
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
