Date: Tue, 21 Mar 2017 09:43:31 +0100 From: "Marin Bernard" <lists@olivarim.com> To: "Kristof Provost" <kristof@sigsegv.be> Cc: freebsd-pf@freebsd.org Subject: Re: Support for the enc(4) pseudo-interface Message-ID: <1490085811-bc1aa9c7b83aeddb9dee198bc4071b35@olivarim.com>
next in thread | raw e-mail | index | archive | help
Hi,
Thanks for answering. Yes, I know that pf accepts rules mentioning inexistent=
=20
interfaces. What puzzles me here is that my ruleset is actually working.=20
With peer0 =3D 1.2.3.4 and peer1 =3D 5.6.7.8, the following ruleset works as=
=20
expected:
-----
peers =3D "{1.2.3.4, 5.6.7.8}"
set skip on lo
block all
# Allow IKE
pass=C2=A0 in proto {tcp, udp} from $peers to self=C2=A0=C2=A0 port isakmp
pass out proto {tcp, udp} from self=C2=A0=C2=A0 to $peers port isakmp
# Allow ICMPv4 echo requests only through IPsec
pass in on enc0 proto icmp from $peers to self icmp-type echoreq
-----
If there is no SA, it is impossible for a peer to ping another. As soon
as IKE creates a SA, however, ping starts working. As you can see,
the last rule is explicitely bound to the inexistent enc0 interface, and
yet is working fine.
Thanks,
Marin.
21 mars 2017 03:30 "Kristof Provost" a =C3=A9crit:
> On 20 Mar 2017, at 23:08, Marin Bernard wrote:=20
> > Yet, it appears that pf is able to handle references to enc(4) in its=
=20
> > ruleset=20
> > even if the kernel does not support it. Is it expected behaviour? Is=20
> > it=20
> > safe to use such a configuration on a production machine ?=20
> >=20
> pf accepts rules for interfaces that don=E2=80=99t exist (yet), so this is=
=20
> expected,=20
> but it won=E2=80=99t do what you want it to do.=20
>=20
> Regards,=20
> Kristof=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1490085811-bc1aa9c7b83aeddb9dee198bc4071b35>