| Message ID | 20201225164214.22771-1-gert@greenie.muc.de |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [Openvpn-devel] Clarify --block-ipv6 intent and direction. | expand |
On 25/12/2020 16:42, Gert Doering wrote: > --block-ipv6 is a fairly special-purpose option, and only blocks packet > in the client->server option. This is implied by not ever mentioning > the other direction in the existing documentation, but not written down. > > Make this explicit, avoid confusion. > > Also, point why this option exist (avoid IPv6 leakage from dual-stacked > clients around IPv4-only VPN offerings). > > Trac: #1351 > > Signed-off-by: Gert Doering <gert@greenie.muc.de> > --- > doc/man-sections/vpn-network-options.rst | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/doc/man-sections/vpn-network-options.rst b/doc/man-sections/vpn-network-options.rst > index 26682789..711dfcc8 100644 > --- a/doc/man-sections/vpn-network-options.rst > +++ b/doc/man-sections/vpn-network-options.rst > @@ -21,7 +21,8 @@ routing. > For this option to make sense you actually have to route traffic to the > tun interface. The following example config block would send all IPv6 > traffic to OpenVPN and answer all requests with no route to host, > - effectively blocking IPv6. > + effectively blocking IPv6 (to avoid IPv6 connections from dual-stacked > + clients to leak around IPv4-only VPN services). > > **Client config** > :: > @@ -38,6 +39,12 @@ routing. > --push "redirect-gateway ipv6" > --block-ipv6 > > + Note: this option does not influence traffic sent from the server > + towards the client (neither on the server nor on the client side). > + This is not seen as necessary, as such traffic can be most easily > + avoided by not configuring IPv6 on the server tun, or setting up a > + server-side firewall rule. > + > --dev device > TUN/TAP virtual network device which can be :code:`tunX`, :code:`tapX`, > :code:`null` or an arbitrary name string (:code:`X` can be omitted for > LGTM Acked-by: Richard Bonhomme <tincanteksup@gmail.com>
Patch has been applied to the master and release/2.5 branch.
The commit message has been fixed (option -> direction) as discussed.
commit 8a8ee283aa7a4b409a9dafc082a6c65b5539308b (master)
commit 490203e6a7594ed946fe3158a694f80be2c18c9c (release/2.5)
Author: Gert Doering
Date: Fri Dec 25 17:42:14 2020 +0100
Clarify --block-ipv6 intent and direction.
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Richard Bonhomme <tincanteksup@gmail.com>
Message-Id: <20201225164214.22771-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21407.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
--
kind regards,
Gert Doering
diff --git a/doc/man-sections/vpn-network-options.rst b/doc/man-sections/vpn-network-options.rst index 26682789..711dfcc8 100644 --- a/doc/man-sections/vpn-network-options.rst +++ b/doc/man-sections/vpn-network-options.rst @@ -21,7 +21,8 @@ routing. For this option to make sense you actually have to route traffic to the tun interface. The following example config block would send all IPv6 traffic to OpenVPN and answer all requests with no route to host, - effectively blocking IPv6. + effectively blocking IPv6 (to avoid IPv6 connections from dual-stacked + clients to leak around IPv4-only VPN services). **Client config** :: @@ -38,6 +39,12 @@ routing. --push "redirect-gateway ipv6" --block-ipv6 + Note: this option does not influence traffic sent from the server + towards the client (neither on the server nor on the client side). + This is not seen as necessary, as such traffic can be most easily + avoided by not configuring IPv6 on the server tun, or setting up a + server-side firewall rule. + --dev device TUN/TAP virtual network device which can be :code:`tunX`, :code:`tapX`, :code:`null` or an arbitrary name string (:code:`X` can be omitted for
--block-ipv6 is a fairly special-purpose option, and only blocks packet in the client->server option. This is implied by not ever mentioning the other direction in the existing documentation, but not written down. Make this explicit, avoid confusion. Also, point why this option exist (avoid IPv6 leakage from dual-stacked clients around IPv4-only VPN offerings). Trac: #1351 Signed-off-by: Gert Doering <gert@greenie.muc.de> --- doc/man-sections/vpn-network-options.rst | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)