Date: Tue, 21 Mar 2017 10:18:36 +0100 From: "Kristof Provost" <kristof@sigsegv.be> To: "Marin Bernard" <lists@olivarim.com> Cc: freebsd-pf@freebsd.org Subject: Re: Support for the enc(4) pseudo-interface Message-ID: <44FBCEF5-6151-46FF-A166-81E7306914CC@sigsegv.be> In-Reply-To: <1490085811-bc1aa9c7b83aeddb9dee198bc4071b35@olivarim.com> References: <1490085811-bc1aa9c7b83aeddb9dee198bc4071b35@olivarim.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 Mar 2017, at 9:43, Marin Bernard wrote:
> 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.
>
Can you try without the enc0 rule? I suspect that what’s happening
here is that
the IPSec traffic is bypassing the firewall altogether. If that's the
case the
your traffic will still flow, even without the pass on enc0 rule.
If you want to filter on it it should work if you add ‘device enc’
to your
kernel config. The man page suggests that should then allow you to
filter IPSec
traffic on enc0.
Regards,
Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44FBCEF5-6151-46FF-A166-81E7306914CC>