Date: Fri, 8 Oct 2021 12:54:31 +0200 From: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> To: Kristof Provost <kp@FreeBSD.org> Cc: freebsd-pf@freebsd.org Subject: Re: "set skip on lo" on 12.x and 13.0 Message-ID: <33519ad1-cd22-6c50-a3af-8db6398445d5@plan-b.pwste.edu.pl> In-Reply-To: <eaf96b2c-29a2-6d8a-8f89-f08c626e4b20@plan-b.pwste.edu.pl> References: <76015004-7980-fb5c-1cf8-60d7d745bdb9@plan-b.pwste.edu.pl> <F0076C8D-340F-448B-BC41-2960F38FA779@FreeBSD.org> <eaf96b2c-29a2-6d8a-8f89-f08c626e4b20@plan-b.pwste.edu.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--s4cui987dOg2xDeoxv74jG0Z3tOJn4be9
Content-Type: multipart/mixed; boundary="FNKmuMJH9Btsh3aDTkoO8h0IBEeUXzj62";
protected-headers="v1"
From: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl>
To: Kristof Provost <kp@FreeBSD.org>
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>
<F0076C8D-340F-448B-BC41-2960F38FA779@FreeBSD.org>
<eaf96b2c-29a2-6d8a-8f89-f08c626e4b20@plan-b.pwste.edu.pl>
In-Reply-To: <eaf96b2c-29a2-6d8a-8f89-f08c626e4b20@plan-b.pwste.edu.pl>
--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 <ifgroup>
>> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33519ad1-cd22-6c50-a3af-8db6398445d5>