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
interfaces. What puzzles me here is that my ruleset is actually working.
With peer0 = 1.2.3.4 and peer1 = 5.6.7.8, the following ruleset works as
expected:
-----
peers = "{1.2.3.4, 5.6.7.8}"
set skip on lo
block all
# Allow IKE
pass in proto {tcp, udp} from $peers to self port isakmp
pass out proto {tcp, udp} from self 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 écrit:
> On 20 Mar 2017, at 23:08, Marin Bernard wrote:
> > Yet, it appears that pf is able to handle references to enc(4) in its
> > ruleset
> > even if the kernel does not support it. Is it expected behaviour? Is
> > it
> > safe to use such a configuration on a production machine ?
> >
> pf accepts rules for interfaces that don’t exist (yet), so this is
> expected,
> but it won’t do what you want it to do.
>
> Regards,
> Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1490085811-bc1aa9c7b83aeddb9dee198bc4071b35>