From nobody Wed Aug 17 21:08:32 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 4M7LFk21rSz4ZGj3 for ; Wed, 17 Aug 2022 21:07:54 +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 4M7LFj2ZFbz3HXV for ; Wed, 17 Aug 2022 21:07:52 +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 0000000000E3C981.0000000062FD58A6.00016266; Wed, 17 Aug 2022 23:07:50 +0200 Date: Wed, 17 Aug 2022 23:08:32 +0200 From: Milan Obuch To: John-Mark Gurney Cc: freebsd-net@freebsd.org Subject: Re: Tunnel interfaces and vnet boundary crossing Message-ID: <20220817230832.5d688ee5@zeta.dino.sk> In-Reply-To: <20220817201214.GZ88842@funkthat.com> References: <20220815085303.2c5cdb02@zeta.dino.sk> <20220817201214.GZ88842@funkthat.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: 4M7LFj2ZFbz3HXV 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_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[dino.sk]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 17 Aug 2022 13:12:14 -0700 John-Mark Gurney wrote: > Milan Obuch wrote this message on Mon, Aug 15, 2022 at 08:53 +0200: > > I tried to mimic this in FreeBSD with following commands: > > > > ifconfig gre1 create tunnel 172.16.1.1 172.16.0.1 vnet ov1 > > jexec ov1 ifconfig gre1 10.1.0.2/30 10.1.0.1 > > > > This does not work. I found some older post which made me believing > > this is caused by clearing whole tunnel configuration after moving > > interface into different vnet. My (failed) tests indicate this is > > most probably the cause. > > > > So, my question is, does anybody use tunnel interface similar way? > > Is it possible to achieve what I am trying with netgraph? I am able > > to create some inter-vnet link using epair interface, but this is > > something different. Or ideally, is somebody using IPSEC with VNET > > jails, processing encapsulating packets in base and raw content in > > some child vnet? > > This doesn't work since the tunnel interface needs to see the > interface with the IP to route it to, and since it's in another > jail/vnet, it can't get there. > > The closes thing I can think of is putting an epair in w/ the tunnel > interface, and routing the tunnel out of the vnet via the epair > interface... > > Does this make sense? > Partially, but does not help. Problem is there could be two networks somewhere run by two different entities, different admins, both using, say, 192.168.1.0/24 for LAN segment. With your approach, I would need two routes for the same destination address block via two tunnels. Obviously, not good. Regards, Milan