[Openvpn-devel,v4,6/7] options: enable IPv4 redirection logic only if really required
| Message ID | 20200530000600.1680-7-a@unstable.cc |
|---|---|
| State | Superseded |
| Headers |
Return-Path: <openvpn-devel-bounces@lists.sourceforge.net> Delivered-To: patchwork@openvpn.net Delivered-To: patchwork@openvpn.net Received: from director7.mail.ord1d.rsapps.net ([172.28.255.1]) by backend30.mail.ord1d.rsapps.net with LMTP id QHlWBNij0V5CLQAAIUCqbw for <patchwork@openvpn.net>; Fri, 29 May 2020 20:07:52 -0400 Received: from proxy7.mail.ord1c.rsapps.net ([172.28.255.1]) by director7.mail.ord1d.rsapps.net with LMTP id kPY4BNij0V7lBwAAovjBpQ ; Fri, 29 May 2020 20:07:52 -0400 Received: from smtp36.gate.ord1c ([172.28.255.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by proxy7.mail.ord1c.rsapps.net with LMTP id UILeA9ij0V4TXQAAknS3pQ ; Fri, 29 May 2020 20:07:52 -0400 X-Spam-Threshold: 95 X-Spam-Score: 0 X-Spam-Flag: NO X-Virus-Scanned: OK X-Orig-To: openvpnslackdevel@openvpn.net X-Originating-Ip: [216.105.38.7] Authentication-Results: smtp36.gate.ord1c.rsapps.net; iprev=pass policy.iprev="216.105.38.7"; spf=pass smtp.mailfrom="openvpn-devel-bounces@lists.sourceforge.net" smtp.helo="lists.sourceforge.net"; dkim=fail (signature verification failed) header.d=sourceforge.net; dkim=fail (signature verification failed) header.d=sf.net; dmarc=none (p=nil; dis=none) header.from=unstable.cc X-Suspicious-Flag: YES X-Classification-ID: 99fd9748-a209-11ea-ad18-5452006630bd-1-1 Received: from [216.105.38.7] ([216.105.38.7:43600] helo=lists.sourceforge.net) by smtp36.gate.ord1c.rsapps.net (envelope-from <openvpn-devel-bounces@lists.sourceforge.net>) (ecelerity 4.2.38.62370 r(:)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id F9/6F-07033-7D3A1DE5; Fri, 29 May 2020 20:07:51 -0400 Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from <openvpn-devel-bounces@lists.sourceforge.net>) id 1jep1s-0001GA-Va; Sat, 30 May 2020 00:07:12 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <a@unstable.cc>) id 1jep1h-0001EY-0V for openvpn-devel@lists.sourceforge.net; Sat, 30 May 2020 00:07:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:MIME-Version:References: In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=OJwSA0bOEQ2wWtZxHS3zNTOGiolR/BaHkoD16iLqMbk=; b=TWHlbt+4S7ALgyYOhwx3hE5Pvf KhvWh81TWdfLxj/XOAN/twCuDu31jIBQnUPNkl7VGE6vO16Nu9u9HUF0MEEpwKQPyFOUTqsJAkVlz 4zU3iOw1/5NsTNf07JD5Nb8vdp6j5D3teSC8f5sVg6gfkboheJcruXAvw1KOKfjC+DVA=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-Id: Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=OJwSA0bOEQ2wWtZxHS3zNTOGiolR/BaHkoD16iLqMbk=; b=IzUa3sQxOnwgk8O9bcuz2nEDzo Gd6MRZ2ntvk9JDhA4Mq2b9lm6U/vGgTzRbO4yOBcnangLNUo2HZVU8hbHnNop6Ew2YpUK1A0O4JAB d1zl2htDB8I3EMzjbel5sw8nEvUfrASZ7Z+sGArsMX+7fzS1QPEuLimqe4UwdKs86w9k=; Received: from s2.neomailbox.net ([5.148.176.60]) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1jep1d-000Jzi-6U for openvpn-devel@lists.sourceforge.net; Sat, 30 May 2020 00:07:00 +0000 From: Antonio Quartulli <a@unstable.cc> To: openvpn-devel@lists.sourceforge.net Date: Sat, 30 May 2020 02:05:59 +0200 Message-Id: <20200530000600.1680-7-a@unstable.cc> In-Reply-To: <20200530000600.1680-1-a@unstable.cc> References: <20200530000600.1680-1-a@unstable.cc> MIME-Version: 1.0 X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: openvpn.net] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record 0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1jep1d-000Jzi-6U Subject: [Openvpn-devel] [PATCH v4 6/7] options: enable IPv4 redirection logic only if really required X-BeenThere: openvpn-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: <openvpn-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/options/openvpn-devel>, <mailto:openvpn-devel-request@lists.sourceforge.net?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=openvpn-devel> List-Post: <mailto:openvpn-devel@lists.sourceforge.net> List-Help: <mailto:openvpn-devel-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/openvpn-devel>, <mailto:openvpn-devel-request@lists.sourceforge.net?subject=subscribe> Cc: Antonio Quartulli <antonio@openvpn.net> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: openvpn-devel-bounces@lists.sourceforge.net X-getmail-retrieved-from-mailbox: Inbox |
| Series |
Allow IPv6-only tunnels
|
|
Commit Message
Antonio Quartulli
May 29, 2020, 2:05 p.m. UTC
From: Antonio Quartulli <antonio@openvpn.net> If no IPv4 redirection flag is set, do not enable the IPv4 redirection logic at all so that it won't bother adding any useless IPv4 route. Trac: #208 Signed-off-by: Antonio Quartulli <antonio@openvpn.net> --- Changes from v4: - move error message modification to previous patch Changes from v3: - patchset rebased on top of pre-ipv6-only patchset src/openvpn/options.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
Comments
Hi, On Sat, May 30, 2020 at 02:05:59AM +0200, Antonio Quartulli wrote: > From: Antonio Quartulli <antonio@openvpn.net> > > If no IPv4 redirection flag is set, do not enable the IPv4 > redirection logic at all so that it won't bother adding any > useless IPv4 route. > > Trac: #208 > Signed-off-by: Antonio Quartulli <antonio@openvpn.net> I can see why we want this - I tried to connect to a "v6-only-in-tunnel" server over v4, specifying "redirect-gateway !ipv4 ipv6", and it tried to install a v4 /32 redirect route... Sun Jun 7 13:20:43 2020 net_route_v4_add: 199.102.77.82/32 via 193.149.48.190 dev [NULL] table 0 metric -1 ... which is harmless, but "unnecesary fumbling" is not desirable. The reason why I'm a bit unhappy about applying it is that it will change behaviour for the "redirect-private" case, and that might break people's setups. For "redirect-gateway" or "redirect-gateway def1" (etc), it will not change anything. Can we make this conditional in a way that does not break "redirect-private"? (I used to use "redirect-private" to handle overlapping IPv4 routes without actually redirecting the whole gateway - think "VPN server is on 192.0.2.1 and you want to push 'route 192.0.2.0/24'". IPv6 handles this automatically, but v4 needs "redirect-private" for that to work) thanks :) gert
Hi,
On Sun, Jun 07, 2020 at 01:25:01PM +0200, Gert Doering wrote:
> Can we make this conditional in a way that does not break "redirect-private"?
A very simple patch would be
if (streq(p[0], "redirect-gateway"))
{
options->routes->flags |= RG_REROUTE_GW;
}
+ if (streq(p[0], "redirect-private"))
+ {
+ options->routes->flags |= RG_ENABLE;
+ }
and then take your patch as-is ("redirect-gateway with no options" would
set RG_REROUTE_GW, which, if not cleared by !ipv4, would set RG_ENABLE
later on, while "redirect-private" sets the RG_ENABLE itself).
Alternatively, set RG_ENABLE at the top (always), and clear it for "!ipv4"
else if (streq(p[j], "!ipv4"))
{
options->routes->flags &= ~(RG_REROUTE_GW|RG_ENABLE);
}
... this should do the same thing, with less code convolutions.
Configs that have *both* "redirect-private" and "redirect-gateway !ipv4 ipv6"
would still be broken. But I'm not sure such a config is well-defined
in the first place.
gert
diff --git a/src/openvpn/options.c b/src/openvpn/options.c index 7556e7ee..3798731e 100644 --- a/src/openvpn/options.c +++ b/src/openvpn/options.c @@ -6591,7 +6591,14 @@ add_option(struct options *options, /* we need this here to handle pushed --redirect-gateway */ remap_redirect_gateway_flags(options); #endif - options->routes->flags |= RG_ENABLE; + /* enable IPv4 redirection logic only if at least one IPv4 flag is set. + * For instance, when "redirect-gateway !ipv4 ipv6" is specified no + * IPv4 redirection should be activated. + */ + if (options->routes->flags) + { + options->routes->flags |= RG_ENABLE; + } } else if (streq(p[0], "block-ipv6") && !p[1]) {