From owner-freebsd-net@freebsd.org Mon Jun 8 11:47:15 2020 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2059632D097 for ; Mon, 8 Jun 2020 11:47:15 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [IPv6:2a01:4f8:171:f902::5]) (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 ESMTPS id 49gWh210Kbz4K6M for ; Mon, 8 Jun 2020 11:47:13 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest-mbp.local (200116b8647baa00ed0faa6ad69d2e0d.dip.versatel-1u1.de [IPv6:2001:16b8:647b:aa00:ed0f:aa6a:d69d:2e0d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id 1C1053D6DC for ; Mon, 8 Jun 2020 11:47:06 +0000 (UTC) Subject: Re: On Netgraph To: freebsd-net@freebsd.org References: From: Jan Bramkamp Message-ID: <00686a7c-1035-f214-bb93-4ea69bb97d5e@rlwinm.de> Date: Mon, 8 Jun 2020 13:47:05 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Rspamd-Queue-Id: 49gWh210Kbz4K6M X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of crest@rlwinm.de designates 2a01:4f8:171:f902::5 as permitted sender) smtp.mailfrom=crest@rlwinm.de X-Spamd-Result: default: False [-1.05 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.91)[-0.909]; DMARC_NA(0.00)[rlwinm.de]; NEURAL_SPAM_SHORT(0.36)[0.360]; NEURAL_HAM_MEDIUM(-0.20)[-0.198]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[2001:16b8:647b:aa00:ed0f:aa6a:d69d:2e0d:received] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 11:47:15 -0000 On 27.05.20 10:06, Tom Marcoen wrote: > Hey all, > > I'm new to this mailing list and also quite new to FreeBSD (huray, welcome > to me!) so bare with me, please. > > I'm reading up on Netgraph on how I can integrate it with FreeBSD jails and > I was looking at some of the examples provided in > /usr/share/examples/netgraph and now have the following question. > The udp.tunnel example shows an iface point-to-point connection but it is > unencrypted. Of course I could encrypt it with an IPsec tunnel on the host > or tunnel it through SSH, but I was wondering whether there exists a nice > Netgraph solution, e.g. a node with two hooks, receiving unencrypted > traffic on the inside hook and sending out encrypted traffic on the outside > hook. Netgraph is a very flexible tool, but not needed for this. First of all if_bridge(4) just got a massive throughput gain by at least a factor of 5 in 13-current and 12-stable. Next you would be reinventing the wheel with ng_bridge and ng_ksocket to tunnel ethernet in UDP. As soon as you have more than two jail hosts you'll run into new problems. The canonical solution to your problem is VXLAN. This allows you to learn traffic to the unicast tunnel endpoint address for unicast cast traffic and multicast the rest. These encapsulations have been invented to allow emulate a shared layer 2 Ethernet networks per tennant. Unless your jails are VNET enabled and your jail admins require a shared layer 2 network you can avoid most of this overhead with dynamic routing. I know this sounds a lot like "your're holding it wrong". Your approach would work, but it would cripple performance unless you can wait for FreeBSD 12.2 and switch from netgraph to if_bridge(4). Routing is fast (enough) in the existing FreeBSD releases and in my opinion the cleaner solution, but it complicates hosting services expecting a shared layer 2 e.g. mDNS and DLNA require either multicast routing or proxies.