From patchwork Wed Oct 12 14:59:14 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gert Doering X-Patchwork-Id: 2817 Return-Path: Delivered-To: patchwork@openvpn.net Delivered-To: patchwork@openvpn.net Received: from director11.mail.ord1d.rsapps.net ([172.31.255.6]) by backend30.mail.ord1d.rsapps.net with LMTP id wONOEnDWRmMefgAAIUCqbw (envelope-from ) for ; Wed, 12 Oct 2022 11:00:00 -0400 Received: from proxy17.mail.iad3b.rsapps.net ([172.31.255.6]) by director11.mail.ord1d.rsapps.net with LMTP id +JsTEnDWRmNHQQAAvGGmqA (envelope-from ) for ; Wed, 12 Oct 2022 11:00:00 -0400 Received: from smtp7.gate.iad3b ([172.31.255.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by proxy17.mail.iad3b.rsapps.net with LMTPS id wPHDDHDWRmMlcwAA5ccGVQ (envelope-from ) for ; Wed, 12 Oct 2022 11:00:00 -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: smtp7.gate.iad3b.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=greenie.muc.de X-Suspicious-Flag: YES X-Classification-ID: 8a3b318c-4a3e-11ed-8981-525400e292e5-1-1 Received: from [216.105.38.7] ([216.105.38.7:43198] helo=lists.sourceforge.net) by smtp7.gate.iad3b.rsapps.net (envelope-from ) (ecelerity 4.2.38.62370 r(:)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id CD/70-06026-F66D6436; Wed, 12 Oct 2022 10:59:59 -0400 Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1oidCr-0003Qf-2F; Wed, 12 Oct 2022 14:59:37 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oidCg-0003QT-3L for openvpn-devel@lists.sourceforge.net; Wed, 12 Oct 2022 14:59:26 +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:Message-Id: Date:Subject:To:From:Sender:Reply-To:Cc:Content-Type: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=H945cphmoXA6+oy+Q/Sk8n/RvzEns3N+s3OKZIsvUaA=; b=l5VPXIajMTKCnf13DmZWdEWFu6 h/TRMahbMDRFT160fcuHOiyLX/Vb+OMF+zOybIFbhqh6S8MiusOlN8mZ4G0xtME24FdkEn7VPFgEY ph69BKLjVGhm2f72JT7Eozlu487QUykRzj18wzIhiMJsaBWuMx/ecvKjsJMpuHIXYRLM=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:MIME-Version:Message-Id:Date:Subject:To:From: Sender:Reply-To:Cc:Content-Type: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=H945cphmoXA6+oy+Q/Sk8n/RvzEns3N+s3OKZIsvUaA=; b=m w3xnPf2V+dVvr/Uog135z/MsOb8h+VgfoKgVcmxIcO0nGUA5xOHQGqBZWbJi8dANd3lELquw149+3 r8SxFRQMq0GZKlNkEx9Efg7PiFRZgXLhmcNhtaap1pvBAQl/M4XUviKPdVjuu/rATyuFAOcRfYXfy gtn98yuPJhyoHdzQ=; Received: from vmail1.greenie.net ([195.30.8.66]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1oidCe-001EGt-E6 for openvpn-devel@lists.sourceforge.net; Wed, 12 Oct 2022 14:59:25 +0000 Received: from fbsd14.ov.greenie.net (fbsd14.ov.greenie.net [IPv6:2001:608:0:814:0:0:fb00:14]) by vmail1.greenie.net (8.17.1/8.16.1) with ESMTPS id 29CExF7r099941 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL) for ; Wed, 12 Oct 2022 16:59:15 +0200 (CEST) Received: from fbsd14.ov.greenie.net (localhost [127.0.0.1]) by fbsd14.ov.greenie.net (8.16.1/8.16.1) with ESMTPS id 29CExFJC025820 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 12 Oct 2022 16:59:15 +0200 (CEST) (envelope-from gert@fbsd14.ov.greenie.net) Received: (from gert@localhost) by fbsd14.ov.greenie.net (8.16.1/8.16.1/Submit) id 29CExFal025819 for openvpn-devel@lists.sourceforge.net; Wed, 12 Oct 2022 16:59:15 +0200 (CEST) (envelope-from gert) From: Gert Doering To: openvpn-devel@lists.sourceforge.net Date: Wed, 12 Oct 2022 16:59:14 +0200 Message-Id: <20221012145915.25810-1-gert@greenie.muc.de> X-Mailer: git-send-email 2.37.3 MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (vmail1.greenie.net [IPv6:2001:608:1:995a:20c:29ff:feb8:10eb]); Wed, 12 Oct 2022 16:59:15 +0200 (CEST) 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: For reasons unknown, OpenVPN has always put FreeBSD tun(4) interfaces into point-to-point mode (IFF_POINTOPOINT), which means "local and remote address, no on-link subnet". "--topology subnet" was emulated by adding a subnet-route to the "remote" (which was just picking a free address from the subnet). Content analysis details: (-2.0 points, 6.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [195.30.8.66 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 SPF_NONE SPF: sender does not publish an SPF Record X-Headers-End: 1oidCe-001EGt-E6 Subject: [Openvpn-devel] [PATCH 1/2] FreeBSD: for topology subnet, put tun interface into IFF_BROADCAST mode X-BeenThere: openvpn-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: openvpn-devel-bounces@lists.sourceforge.net X-getmail-retrieved-from-mailbox: Inbox For reasons unknown, OpenVPN has always put FreeBSD tun(4) interfaces into point-to-point mode (IFF_POINTOPOINT), which means "local and remote address, no on-link subnet". "--topology subnet" was emulated by adding a subnet-route to the "remote" (which was just picking a free address from the subnet). This works well enough for classic tun(4) interfaces that have no next-hop resolution, and routes pointing to "that fake remote" only (because all routing is done inside OpenVPN and it does not matter how packets get there) - but for ovpn(4) interfaces, it breaks iroute setup, where the route next-hop must be an on-link address. Thus, change interface to IFF_BROADCAST mode, and get rid of all the special code needed to "fake" subnet mode. Tested with tun(4) and ovpn(4) on FreeBSD 14, client and server, and with tun(4) on FreeBSD 12 and 7.4 To actually work with ovpn(4) / FreeBSD DCO, a followup patch for kernel ovpn(4) and OpenVPN dco_freebsd.c is needed. Signed-off-by: Gert Doering Signed-off-by: Kristof Provost --- Changes.rst | 5 +++++ src/openvpn/tun.c | 37 ++++++++++++------------------------- 2 files changed, 17 insertions(+), 25 deletions(-) diff --git a/Changes.rst b/Changes.rst index df56f76a..0397cb94 100644 --- a/Changes.rst +++ b/Changes.rst @@ -163,6 +163,11 @@ User-visible Changes - :code:`link_mtu` parameter is removed from environment or replaced with 0 when scripts are called with parameters. This parameter is unreliable and no longer internally calculated. +- FreeBSD tun interfaces with ``--topology subnet`` are now put into real + subnet mode (IFF_BROADCAST instead of IFF_POINTOPOINT) - this might upset + software that enumerates interfaces, looking for "broadcast capable?" and + expecting certain results. Normal uses should not see any difference. + Overview of changes in 2.5 ========================== diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index ddee49f9..a83ec9e6 100644 --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -1479,43 +1479,23 @@ do_ifconfig_ipv4(struct tuntap *tt, const char *ifname, int tun_mtu, #elif defined(TARGET_FREEBSD) || defined(TARGET_DRAGONFLY) - in_addr_t remote_end; /* for "virtual" subnet topology */ - /* example: ifconfig tun2 10.2.0.2 10.2.0.1 mtu 1450 netmask 255.255.255.255 up */ - if (tun) + if (tun) /* point-to-point tun */ { argv_printf(&argv, "%s %s %s %s mtu %d netmask 255.255.255.255 up", IFCONFIG_PATH, ifname, ifconfig_local, ifconfig_remote_netmask, tun_mtu); } - else if (tt->type == DEV_TYPE_TUN && tt->topology == TOP_SUBNET) - { - remote_end = create_arbitrary_remote( tt ); - argv_printf(&argv, "%s %s %s %s mtu %d netmask %s up", IFCONFIG_PATH, - ifname, ifconfig_local, print_in_addr_t(remote_end, 0, &gc), - tun_mtu, ifconfig_remote_netmask); - } - else + else /* tun with topology subnet and tap mode (always subnet) */ { - argv_printf(&argv, "%s %s %s netmask %s mtu %d up", IFCONFIG_PATH, - ifname, ifconfig_local, ifconfig_remote_netmask, tun_mtu); + int netbits = netmask_to_netbits2(tt->remote_netmask); + argv_printf(&argv, "%s %s %s/%d mtu %d up", IFCONFIG_PATH, + ifname, ifconfig_local, netbits, tun_mtu ); } argv_msg(M_INFO, &argv); openvpn_execve_check(&argv, es, S_FATAL, "FreeBSD ifconfig failed"); - /* Add a network route for the local tun interface */ - if (!tun && tt->type == DEV_TYPE_TUN && tt->topology == TOP_SUBNET) - { - struct route_ipv4 r; - CLEAR(r); - r.flags = RT_DEFINED; - r.network = tt->local & tt->remote_netmask; - r.netmask = tt->remote_netmask; - r.gateway = remote_end; - add_route(&r, tt, 0, NULL, es, NULL); - } - #elif defined(TARGET_AIX) { /* AIX ifconfig will complain if it can't find ODM path in env */ @@ -2949,12 +2929,19 @@ open_tun(const char *dev, const char *dev_type, const char *dev_node, struct tun if (tt->fd >= 0 && tt->type == DEV_TYPE_TUN) { + /* see "Interface Flags" in ifnet(9) */ int i = IFF_POINTOPOINT | IFF_MULTICAST; + if (tt->topology == TOP_SUBNET) + { + i = IFF_BROADCAST | IFF_MULTICAST; + } if (ioctl(tt->fd, TUNSIFMODE, &i) < 0) { msg(M_WARN | M_ERRNO, "ioctl(TUNSIFMODE)"); } + + /* multi_af mode for v4+v6, see "tun(4)" */ i = 1; if (ioctl(tt->fd, TUNSIFHEAD, &i) < 0) {