| Message ID | 20211108135314.148-1-lstipakov@gmail.com |
|---|---|
| State | Superseded |
| Headers |
Return-Path: <openvpn-devel-bounces@lists.sourceforge.net> Delivered-To: patchwork@openvpn.net Delivered-To: patchwork@openvpn.net Received: from director12.mail.ord1d.rsapps.net ([172.27.255.8]) by backend30.mail.ord1d.rsapps.net with LMTP id eK0wBGami2GlIQAAIUCqbw (envelope-from <openvpn-devel-bounces@lists.sourceforge.net>) for <patchwork@openvpn.net>; Wed, 10 Nov 2021 06:00:54 -0500 Received: from proxy3.mail.iad3a.rsapps.net ([172.27.255.8]) by director12.mail.ord1d.rsapps.net with LMTP id GIkPBGami2EMJAAAIasKDg (envelope-from <openvpn-devel-bounces@lists.sourceforge.net>) for <patchwork@openvpn.net>; Wed, 10 Nov 2021 06:00:54 -0500 Received: from smtp27.gate.iad3a ([172.27.255.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by proxy3.mail.iad3a.rsapps.net with LMTPS id 6PpyNmWmi2FRYgAAYaqY3Q (envelope-from <openvpn-devel-bounces@lists.sourceforge.net>) for <patchwork@openvpn.net>; Wed, 10 Nov 2021 06:00:53 -0500 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: smtp27.gate.iad3a.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; dkim=fail (signature verification failed) header.d=gmail.com; dmarc=fail (p=none; dis=none) header.from=gmail.com X-Suspicious-Flag: YES X-Classification-ID: 78696136-4215-11ec-8112-525400358560-1-1 Received: from [216.105.38.7] ([216.105.38.7:57330] helo=lists.sourceforge.net) by smtp27.gate.iad3a.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 D6/14-18199-466AB816; Wed, 10 Nov 2021 06:00:53 -0500 Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.94.2) (envelope-from <openvpn-devel-bounces@lists.sourceforge.net>) id 1mklKL-0005Im-4A; Wed, 10 Nov 2021 10:59:37 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <lstipakov@gmail.com>) id 1mklKD-0005Ia-8r for openvpn-devel@lists.sourceforge.net; Wed, 10 Nov 2021 10:59:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=qpG+ux/5eDIy4C4kLRrpTvFNozKFdQnMKoiJnO2Mpbs=; b=VjZFEUeeRa+W4u8tEcEjx3+QC6 Um+ELBh3rBJGqkJPCT9RMibhw6jCOXB/dflWcER7FGCIe14F1prpR4SGYgbQog5rWlaTpfwBxfR15 elSjhybsXXVLx8Ho/nzMtOqhBivEo5hXAldltKF8ESPduKbURjOTxKoUtg/GwjTN097I=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=qpG+ux/5eDIy4C4kLRrpTvFNozKFdQnMKoiJnO2Mpbs=; b=T4umxENv2vpsHjQjrPaYzTonXR YyJ/gnfkkUK5vSg/ZlzmQAc69vPLcxtcjYEOqniPvyxiUODXJ9TaaLc4mMVFJaBkxYKsDVXQEwpSk 7xw7GIzjjKHqBXkmQkPPnMlZXZFSkeDl5Upk/VrBcgNlWKpppTkDbmfaPtbcgafVvnqM=; Received: from mail-wr1-f41.google.com ([209.85.221.41]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) id 1mklK9-00025g-1p for openvpn-devel@lists.sourceforge.net; Wed, 10 Nov 2021 10:59:29 +0000 Received: by mail-wr1-f41.google.com with SMTP id t30so3230012wra.10 for <openvpn-devel@lists.sourceforge.net>; Wed, 10 Nov 2021 02:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id; bh=qpG+ux/5eDIy4C4kLRrpTvFNozKFdQnMKoiJnO2Mpbs=; b=dMyuCXMluKPchpEkUlteuiuRnOX5RADxiz6jMFWGxO1krd46FiePXEesBCMnvKxVuD wsq05ODUadyYgxCT5B64PhYRHhY8M5doq26lK9ttTJI8YJPKJLHuxM50C7fm+ESEpqIq WDMPoS2m8Ke0Yq3NNeuu/RD7ELsHirEsPEm//hlDoPmphXcPpkcbAdLcTmLziOcUTlZJ ckVK0crUsqiX2zS+03E7DQF3ITz+vKit+OVlOfBBYw2r3WmWo/FB8ZsfgF3dWCY/ZhMi zwxVsxbmga5qGiZ7hDMq3kqkQHOnvuhKNj3YrSVJXTDE7PC4nFQvcSvT43IW8d9lZhRy jBZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=qpG+ux/5eDIy4C4kLRrpTvFNozKFdQnMKoiJnO2Mpbs=; b=ea6RPIWwi4XKbEKOGb2911CYcZGUa8fEGI5gBoQPYzeBif+wObED6boC3Y47jhUedB wOZUdQpdzDiJLF6AXJ/DEdzZI/qVuymf7ys7m53trxst+ffSLcABPhUc3RNPCAGxZ9+2 4/vu7zeGvEsN20i9/6Kc8nId87D2bvGARfl4Q4cNWDzmfTRNdREY2SCOlF8fhcInwHN0 dmVAqjK9ApeRAuDjmjzJ7gb0bS13SzGYgj+jVvF+tw8M3K0VNWi6ia8SBq4cUW0v8XJB sEQZmf29MtgQqLhniCiHHnrmOBeZb45FxqK66APJoGNYOc9E1wH4XEi3I/E59jqsXFfV s1gQ== X-Gm-Message-State: AOAM530nFFGKUo/47ieBQNKfAny+2Zm9+xy9g38FXbQVKJhikL00/ROv /YGG1GoqvAenpnzONZdy6MSRT3q3St4= X-Google-Smtp-Source: ABdhPJzwhmk3tLot9RN1MkRukXOzhXfCDs8KRdiZzxiNE14rtkRB/oGsLRYCw7H0vN6MSCa7IghcSw== X-Received: by 2002:adf:c986:: with SMTP id f6mr19738027wrh.216.1636541958440; Wed, 10 Nov 2021 02:59:18 -0800 (PST) Received: from LAPTOP-4L3N7KFS.localdomain (nat1.panoulu.net. [185.38.2.1]) by smtp.gmail.com with ESMTPSA id n1sm6158916wmq.6.2021.11.10.02.59.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Nov 2021 02:59:18 -0800 (PST) From: Lev Stipakov <lstipakov@gmail.com> To: openvpn-devel@lists.sourceforge.net Date: Mon, 8 Nov 2021 15:53:14 +0200 Message-Id: <20211108135314.148-1-lstipakov@gmail.com> X-Mailer: git-send-email 2.17.1 X-Spam-Report: Spam detection software, running on the system "util-spamd-1.v13.lw.sourceforge.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: From: Lev Stipakov When /30 subnet is pushed (like in the case of OpenVPN Cloud), DHCP server address is calculated to be the same as local address, which causes collision and therefore connection is not established. Content analysis details: (0.3 points, 6.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.41 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider [lstipakov[at]gmail.com] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.5 DATE_IN_PAST_24_48 Date: is 24 to 48 hours before Received: date -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.41 listed in wl.mailspike.net] X-Headers-End: 1mklK9-00025g-1p Subject: [Openvpn-devel] [PATCH] tun: improve DHCP server address calculation for small subnets 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: Lev Stipakov <lev@openvpn.net> MIME-Version: 1.0 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 |
[Openvpn-devel] tun: improve DHCP server address calculation for small subnets
|
|
Commit Message
Lev Stipakov
Nov. 8, 2021, 2:53 a.m. UTC
From: Lev Stipakov <lev@openvpn.net> When /30 subnet is pushed (like in the case of OpenVPN Cloud), DHCP server address is calculated to be the same as local address, which causes collision and therefore connection is not established. To fix that, use openvpn3 approach, which sets DHCP server address to a network address for small subnets Signed-off-by: Lev Stipakov <lev@openvpn.net> --- src/openvpn/tun.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Comments
This can be considered as a bugfix ("Cannot use openvpn2 as OpenVPN
Cloud connector") so could go into release/2.5 too.
ke 10. marrask. 2021 klo 12.59 Lev Stipakov (lstipakov@gmail.com) kirjoitti:
>
> From: Lev Stipakov <lev@openvpn.net>
>
> When /30 subnet is pushed (like in the case of OpenVPN Cloud),
> DHCP server address is calculated to be the same as local address,
> which causes collision and therefore connection is not established.
>
> To fix that, use openvpn3 approach, which sets DHCP server
> address to a network address for small subnets
>
> Signed-off-by: Lev Stipakov <lev@openvpn.net>
> ---
> src/openvpn/tun.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
> index 28f803ec..994e3751 100644
> --- a/src/openvpn/tun.c
> +++ b/src/openvpn/tun.c
> @@ -6363,7 +6363,9 @@ tuntap_dhcp_mask(const struct tuntap *tt, const char *device_guid)
> }
> else
> {
> - ep[2] = dhcp_masq_addr(tt->local, tt->remote_netmask, -1);
> + int prefix_len = netmask_to_netbits2(tt->adapter_netmask);
> + /* use network address as DHCP server for small subnets, otherwise last address before broadcast */
> + ep[2] = dhcp_masq_addr(tt->local, tt->remote_netmask, prefix_len < 28 ? -1 : 0);
> }
> }
> else
> --
> 2.23.0.windows.1
>
Hi, On Wed, Nov 10, 2021 at 6:01 AM Lev Stipakov <lstipakov@gmail.com> wrote: > From: Lev Stipakov <lev@openvpn.net> > > When /30 subnet is pushed (like in the case of OpenVPN Cloud), > DHCP server address is calculated to be the same as local address, > which causes collision and therefore connection is not established. > > To fix that, use openvpn3 approach, which sets DHCP server > address to a network address for small subnets > > Signed-off-by: Lev Stipakov <lev@openvpn.net> > --- > src/openvpn/tun.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c > index 28f803ec..994e3751 100644 > --- a/src/openvpn/tun.c > +++ b/src/openvpn/tun.c > @@ -6363,7 +6363,9 @@ tuntap_dhcp_mask(const struct tuntap *tt, const char > *device_guid) > } > else > { > - ep[2] = dhcp_masq_addr(tt->local, tt->remote_netmask, -1); > + int prefix_len = netmask_to_netbits2(tt->adapter_netmask); > + /* use network address as DHCP server for small subnets, > otherwise last address before broadcast */ > + ep[2] = dhcp_masq_addr(tt->local, tt->remote_netmask, > prefix_len < 28 ? -1 : 0); > } > } > else > -- Why not just use 0 offset always? Perpetuating this dance of 0 offset in some cases, -1 otherwise is not a way forward. Also see my patch from 2015 that never got any traction. I have lost touch with the context, so, I'm not sure whether this addresses the same (apart from code changes) or something related. https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/1449454660-20050-1-git-send-email-selva.nair%40gmail.com/#msg34674818 Also: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13413.html and other messages in that thread. Selva <div dir="ltr"><div dir="ltr">Hi,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 10, 2021 at 6:01 AM Lev Stipakov <<a href="mailto:lstipakov@gmail.com" target="_blank">lstipakov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">From: Lev Stipakov <<a href="mailto:lev@openvpn.net" target="_blank">lev@openvpn.net</a>><br> <br> When /30 subnet is pushed (like in the case of OpenVPN Cloud),<br> DHCP server address is calculated to be the same as local address,<br> which causes collision and therefore connection is not established.<br> <br> To fix that, use openvpn3 approach, which sets DHCP server<br> address to a network address for small subnets<br> <br> Signed-off-by: Lev Stipakov <<a href="mailto:lev@openvpn.net" target="_blank">lev@openvpn.net</a>><br> ---<br> src/openvpn/tun.c | 4 +++-<br> 1 file changed, 3 insertions(+), 1 deletion(-)<br> <br> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c<br> index 28f803ec..994e3751 100644<br> --- a/src/openvpn/tun.c<br> +++ b/src/openvpn/tun.c<br> @@ -6363,7 +6363,9 @@ tuntap_dhcp_mask(const struct tuntap *tt, const char *device_guid)<br> }<br> else<br> {<br> - ep[2] = dhcp_masq_addr(tt->local, tt->remote_netmask, -1);<br> + int prefix_len = netmask_to_netbits2(tt->adapter_netmask);<br> + /* use network address as DHCP server for small subnets, otherwise last address before broadcast */<br> + ep[2] = dhcp_masq_addr(tt->local, tt->remote_netmask, prefix_len < 28 ? -1 : 0);<br> }<br> }<br> else<br> --</blockquote><div><br></div><div>Why not just use 0 offset always? Perpetuating this dance of 0 offset in some cases, -1 otherwise is not a way forward. Also see my patch from 2015 that never got any traction. I have lost touch with the context, so, I'm not sure whether this addresses the same (apart from code changes) or something related.</div><div><br></div><div><a href="https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/1449454660-20050-1-git-send-email-selva.nair%40gmail.com/#msg34674818">https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/1449454660-20050-1-git-send-email-selva.nair%40gmail.com/#msg34674818</a><br></div><div><br></div><div>Also: <a href="https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13413.html">https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13413.html</a> and other messages in that thread.</div><div><br></div><div>Selva</div></div></div>
Hi, > Why not just use 0 offset always? Perpetuating this dance of 0 offset in some cases, -1 otherwise is not a way forward. Also see my patch from 2015 that never got any traction. I have lost touch with the context, so, I'm not sure whether this addresses the same (apart from code changes) or something related. > > https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/1449454660-20050-1-git-send-email-selva.nair%40gmail.com/#msg34674818 > > Also: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13413.html and other messages in that thread. Thanks for pointing me out to this, obviously I missed your original patch and that discussion. I don't know why there is an offset in the first place for both openvpn2 and openvpn3, there is probably some reason for it? I wanted to be on the safe side and use a network address for some cases only (small subnet). If you think it is safe to always use 0, let's do that - I can send V2. I tried to apply your patch but it doesn't apply anymore - tun.c has changed a lot since 2015. What comes to discussion about getting rid of the offset option - since the syntax is like this: --ip-win32 dynamic [offset] [lease-time] we cannot just remove [offset] since we might break configurations which set [lease-time].
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index 28f803ec..994e3751 100644 --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -6363,7 +6363,9 @@ tuntap_dhcp_mask(const struct tuntap *tt, const char *device_guid) } else { - ep[2] = dhcp_masq_addr(tt->local, tt->remote_netmask, -1); + int prefix_len = netmask_to_netbits2(tt->adapter_netmask); + /* use network address as DHCP server for small subnets, otherwise last address before broadcast */ + ep[2] = dhcp_masq_addr(tt->local, tt->remote_netmask, prefix_len < 28 ? -1 : 0); } } else