From owner-freebsd-virtualization@freebsd.org Sat Aug 1 14:52:04 2020 Return-Path: Delivered-To: freebsd-virtualization@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 5B72337DE28 for ; Sat, 1 Aug 2020 14:52:04 +0000 (UTC) (envelope-from list+org.freebsd.virtualization@io7m.com) Received: from mail.io7m.com (mail.io7m.com [45.77.76.92]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.io7m.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BJnDM4Hrfz4PD0 for ; Sat, 1 Aug 2020 14:52:03 +0000 (UTC) (envelope-from list+org.freebsd.virtualization@io7m.com) Received: from sunflower.int.arc7.info (cust187-dsl61.idnet.net [212.69.61.187]) by mail.io7m.com (Postfix) with ESMTPSA id DAD4A32735 for ; Sat, 1 Aug 2020 14:51:55 +0000 (UTC) Date: Sat, 1 Aug 2020 14:51:44 +0000 From: Mark Raynsford To: freebsd-virtualization@freebsd.org Subject: Restricting IP ranges for guests over tap devices Message-ID: <20200801145144.7bf342d9@sunflower.int.arc7.info> Organization: io7m.com OpenPGP: id=E36981ED130DB4F68D420248BBFFDB755BAED95D; url=http://www.io7m.com/pgp/E369_81ED_130D_B4F6_8D42_0248_BBFF_DB75_5BAE_D95D.key MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/EmyCu6p8G8MCXNxzrkk+4yY"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-Queue-Id: 4BJnDM4Hrfz4PD0 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.23 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[io7m.com:s=mail]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-virtualization@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.023]; DKIM_TRACE(0.00)[io7m.com:+]; DMARC_POLICY_ALLOW(-0.50)[io7m.com,quarantine]; NEURAL_HAM_SHORT(-0.11)[-0.106]; NEURAL_HAM_LONG(-1.00)[-1.003]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:20473, ipnet:45.77.76.0/22, country:US]; TAGGED_FROM(0.00)[org.freebsd.virtualization] X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2020 14:52:04 -0000 --Sig_/EmyCu6p8G8MCXNxzrkk+4yY Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello! Let's say I have a machine running a few dozen bhyve guests. Each bhyve guest gets its own tap device, and all of the tap devices are connected to a bridge. Everything works fine. I can write pf rules that control access between each guest, and between each guest and the world. I can't directly observe the IP addresses that the guests have assigned to the tap devices I gave them, but if I know the addresses beforehand, I can for example write pf rules that say things like: block log all pass in on tap23 proto tcp \ from any to $guest_23_ip port ssh modulate state That then means that even if the guest is compromised and tries to bind a server to another address, the pf rules won't allow anyone else to actually connect to it. The good thing about this is also the bad thing about this; I have to write specific rules that say "only allow access to this specific IP via this specific tap device". Over dozens of guests, that can multiply to hundreds of laboriously maintained rules. Is there some more general way I can supply a mapping between tap devices and allowed addresses? Remember that pf can't see the guest addresses on the host sides of the tap devices, so I can't use the (device) syntax to expand to "the address of a NIC called 'device'". I can generate rule sets, but perhaps there's something "better"[0]? The documentation isn't suggesting much. [0] Better in the sense that, for example, a table is usually better than a massive list of macros. :) -- Mark Raynsford | https://www.io7m.com --Sig_/EmyCu6p8G8MCXNxzrkk+4yY Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTjaYHtEw209o1CAki7/9t1W67ZXQUCXyWBgAAKCRC7/9t1W67Z XS5bAPsGUhS+D8eewNrpesIPgQEwFPDtyZeB361ZxRupWwsiLgEAtTb8pj0H8zrx eKyRN0cNpV4VrfZfU70YfS81fpIX2Qw= =GHWQ -----END PGP SIGNATURE----- --Sig_/EmyCu6p8G8MCXNxzrkk+4yY--