From nobody Fri Oct 08 10:54:31 2021 X-Original-To: freebsd-pf@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 ESMTP id CB65317EF89D for ; Fri, 8 Oct 2021 10:54:42 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (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 "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HQlSd4x6Lz3h3Q; Fri, 8 Oct 2021 10:54:41 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from fomalhaut.potoki.eu (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 198AsWYX033969 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 8 Oct 2021 12:54:32 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1633690472; bh=fu8+ZAAwZ9a/yU/UWmzLgjKrc6TnDrB9Nb+BL18NLWQ=; h=From:To:Cc:References:Subject:Date:In-Reply-To; b=RBMU7Qc+Y5nlf+JmGoeJ2y6Nzh9jNKaobezuED9cL9o8pwe25t7M+RyU/iMdst44Y hMFGtQ0l1YwyLwuH5zR15u1b6sRf1nnuoCPcOOyxHt/dsIM+HAqHDu9yey8mbUaMLO mJThCqEasUhYdm+sszA/jpXHAx3tHsGdJvsioS0mV/Y+GPyq6gqtMo0A9/3qqh1WIA 81sz1ngQNiGHc0CcFE/aA1jdNCQzDkEQUw/SJaG8WpPnXxUydpkkWOdzhwMCj23KNZ x7TL5291nuK5rg9D4wGV+6c2VEoIELWcci4Dk11CEIvbF+Xds3AiqsQufoK0ZvUCmi V8mUOrgQo+cCA== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be fomalhaut.potoki.eu From: Marek Zarychta To: Kristof Provost Cc: freebsd-pf@freebsd.org References: <76015004-7980-fb5c-1cf8-60d7d745bdb9@plan-b.pwste.edu.pl> Subject: Re: "set skip on lo" on 12.x and 13.0 Message-ID: <33519ad1-cd22-6c50-a3af-8db6398445d5@plan-b.pwste.edu.pl> Date: Fri, 8 Oct 2021 12:54:31 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Technical discussion and general questions about packet filter (pf) List-Archive: https://lists.freebsd.org/archives/freebsd-pf List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="s4cui987dOg2xDeoxv74jG0Z3tOJn4be9" X-Rspamd-Queue-Id: 4HQlSd4x6Lz3h3Q X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=RBMU7Qc+; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-5.87 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; HAS_ATTACHMENT(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; NEURAL_HAM_SHORT(-0.97)[-0.971]; SIGNED_PGP(-2.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --s4cui987dOg2xDeoxv74jG0Z3tOJn4be9 Content-Type: multipart/mixed; boundary="FNKmuMJH9Btsh3aDTkoO8h0IBEeUXzj62"; protected-headers="v1" From: Marek Zarychta To: Kristof Provost Cc: freebsd-pf@freebsd.org Message-ID: <33519ad1-cd22-6c50-a3af-8db6398445d5@plan-b.pwste.edu.pl> Subject: Re: "set skip on lo" on 12.x and 13.0 References: <76015004-7980-fb5c-1cf8-60d7d745bdb9@plan-b.pwste.edu.pl> In-Reply-To: --FNKmuMJH9Btsh3aDTkoO8h0IBEeUXzj62 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable W dniu 09.02.2021 o=C2=A016:44, Marek Zarychta pisze: > W dniu 09.02.2021 o=C2=A015:55, Kristof Provost pisze: >> On 9 Feb 2021, at 15:50, Marek Zarychta wrote: >>> Dear list, >>> >>> I am observing changed behaviour of the rule "set skip on lo". This >>> rule previously allowed for communication between the host and the >>> jail no only on loopback interfaces, but also on shared network >>> interfaces, for example, if a host had address x.x.x.x/24 and jail >>> had address x.x.x.y/32 on the same NIC, the rule above allowed for >>> communication between the host and jail using x.x.x.x and x.x.x.y >>> addresses. I am considering jails without VNET enabled and using the >>> same fib number. Now to allow this kind of communication I had to add= >>> "pass quick on lo", but I went out of free states rather quickly, so >>> instead of increasing the state limit, I have changed the method of >>> communication between the host and the jails to utilize only loopback= >>> addresses. >>> >>> It's rather not a regression but a change, some people might consider= >>> it POLA violation, but probably won't if it gets widely announced. >>> >> I=E2=80=99m not aware of the behaviour change you describe. >> >> However, there have been subtle issues around set skip on >> that may be confusing you. >> See #250994 / 0c156a3c32cd0d9168570da5686ddc96abcbbc5a for some of the= >> details. >> >=20 > I have seen this fix, but probably never used on affected machine > 12.2-STABLE after the MFC of this fix, I have transitioned to > 13.0-STABLE instead. Anyway, both: 12.x-STABLE and 11.x-STABLE with "se= t > skip on lo" were allowing for such communication between jail and host > not only on 127.0.0.0/8 addresses but also on shared NIC addresses. >=20 > The behaviour described above was happening with 13.0-STABLE regardless= > of using set skip on the group or individual interfaces, I mean=C2=A0 "= set > skip on lo" and "set skip on {lo0,lo1,lo2,lo3,....}". Now, to work > around this I have transitioned to using 127.0.0.0/8 only, but some > other people might get confused. >=20 The original problem has been solved a long time ago in different way, but the right solution was to remove the rule: "antispoof quick for lo" which followed "set skip on lo". In FreeBSD 13.0 and later this ruleset adds among others: "block drop in quick on ! lo inet from 127.0.0.0/8 to any" that prevented communication between the host and jails. I have neither 12 nor earlier versions to test this, but certainly, it worked different way there. So concluding this 8 months old thread: either "set skip on lo" worked a different way preventing "antispoof quick for lo" load or this erroneous contradiction was worked around a different way. Thank you for help in solving this. Kind regards, --=20 Marek Zarychta --FNKmuMJH9Btsh3aDTkoO8h0IBEeUXzj62-- --s4cui987dOg2xDeoxv74jG0Z3tOJn4be9 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEnjwyTmqn2oNX6C8qHZW8vIFppoIFAmFgI2cFAwAAAAAACgkQHZW8vIFppoIP Xgf/U/eAphKpcbyPPf4F9JjLXBms3vCBbTxTLN9e6v6F93JPHTme1CsYmVcfgUCmYgFx8x1e0VTb vdlqvAQaTHyp9b82PqNV2B2L+M4fu8PwIldVLQbaW4qstJoddkxRjhJJoWt2Mc07O6f6IFUk/CCr qQ7l4YH27ffSZoLxglpVdWm1wk/4+fjbNdxMrdf+AmvAhNi/gKAgp3GZvTWXxPwP+IweXabwHops 62cDO/2Ig56F1cyBlgalIHmcRSPlEV+2Ev4tsMwcmIQzceVIM0JLPQ4LM/JSRx0LdLUy914hryMF etu/2Vq9HJC184Uat2X2KBEE0fUU0/PM8oFBkCHXuQ== =jD2I -----END PGP SIGNATURE----- --s4cui987dOg2xDeoxv74jG0Z3tOJn4be9--