From nobody Tue Aug 23 15:59:18 2022 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with UTF8SMTP id 4MBv6B37TQz4ZyJY for ; Tue, 23 Aug 2022 15:58:42 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from cm0.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with UTF8SMTPS id 4MBv686dBpz4P6T; Tue, 23 Aug 2022 15:58:40 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from zeta.dino.sk ([84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384) by cm0.netlabit.sk with ESMTPSA id 0000000000E63BF9.000000006304F929.00002CEC; Tue, 23 Aug 2022 17:58:33 +0200 Date: Tue, 23 Aug 2022 17:59:18 +0200 From: Milan Obuch To: freebsd-net@freebsd.org Cc: tt78347@protonmail.com, grembo@freebsd.org Subject: Re: Tunnel interfaces and vnet boundary crossing Message-ID: <20220823175918.4696603f@zeta.dino.sk> In-Reply-To: <3N4WPlYG_OY2JAm4Rg5nWFjqo650j0ccOEOUWSwvWEp9cOudWPfFQ3C54QddWJcqyKd450QB7eczvghXmHbgImkn0tk2pAg7zbn49dJlPtM=@protonmail.com> References: <3N4WPlYG_OY2JAm4Rg5nWFjqo650j0ccOEOUWSwvWEp9cOudWPfFQ3C54QddWJcqyKd450QB7eczvghXmHbgImkn0tk2pAg7zbn49dJlPtM=@protonmail.com> X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.1) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MBv686dBpz4P6T X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-net@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-net@dino.sk X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; FREEMAIL_CC(0.00)[protonmail.com,freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[dino.sk]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Tue, 23 Aug 2022 15:06:00 +0000 tt78347 wrote: > Hello. This is my first email to this mailing list, so I hope it has > been sent and formatted correctly. Well, top posting is being frowned upon a bit on mailing list, which has its racio, otherwise I think everything is fine :) > Regarding tun interfaces, I do something similar to M. Gmelin, > however, I create the tunnel (tun, for openvpn) within the vnet jail. > I think your question is not about tun interfaces but about gre, > which I discuss near the end of this email. You are right, terminology is sometimes somewhat ambiguous. I have no issues with software tunnel interface (man tun). I did not find the right configuration for my needs for network tunnels (man gif, man gre, man if_ipsec, the last one could be the most desired one). > Regarding devfs: > My /etc/devfs.rules contains the following ruleset, applicable to all > such jails: > > [devfsrules_jail=5] > add include $devfsrules_hide_all > add include $devfsrules_unhide_basic > add include $devfsrules_unhide_login > add path bpf unhide > add path tun* unhide > add path bpf0 unhide > > This ruleset ID is specified during jail creation. If you are > modifying this on a running system, I think you will need to use the > devfs utility. This is how I get tun interfaces into a jail, for use > with openvpn or otherwise. I use something similar in my setup, basically with expanded includes. > General background: > All the vnet jails are to be connected to a bridge with epairs, and > NAT is to be performed for jail traffic exchanged with the > exterior. In general, epair is optional, in some use cases vnet jail could be decisively insulated from the rest of jails. But I know this one and use it if in accordance with my design goals. > There is an additional vnet jail which handles ipsec; the ipsec jail > connects the host's jail network (usually a /24) to other local > networks. Each external local network's route is specified in the > host's routing table, with a next-hop being the ipsec jail. I > personally don't use ipsec interfaces, so in the ipsec jail the > traffic is extracted by the kernel (per TSs that are configured with > StrongSwan), encapsulated and sent out the host's external interface. > I have no knowledge of whether this is better or worse than using an > ipsec interface. This one is interested for me. Could you elaborate more on its design? Output of 'ifconfig', 'netstat -rn', 'pkg info', 'cat /etc/rc.conf' commands would be really usefull. If you do concern about privacy, maybe edit it a bit (I am not interested in exact IPs and such info). > Specific steps inside an openvpn jail: > > After an openvpn jail is started, the tunnel (tun interface) is > created in the jail by running the openvpn daemon. I think tunnel > numbers (appearing on the interface name) need to be globally > distinct. I'm not sure if you needed any assistance with this. In my scenario, I use tun devices pre-created before running OpenVPN process. This allows for better control and easier to understand setup. > Regarding gre interfaces, I also create these within the jail. I have > not ever had any problems with this. I don't know that a specific > device is needed, so I don't know if devfs is involved here. This setup just requires connection to outer network, which I would like specifically to be avoided as it makes setup a bit more complicated. Just a reminder, I have almost twenty of running OpenVPN instances in one jail, with almost twenty vnet jails handling the routing for each VPN. [ snip ] I hope this time I made it a bit clearer what I am looking for. Regards, Milan