On Fri, Jul 09, 2021 at 10:39:25AM +0200, Pierre Dupond wrote:
> Le Fri, 9 Jul 2021 07:39:26 -0000 (UTC),
> Stuart Henderson <[email protected]> a écrit :
>
> > On 2021-07-07, Pierre Dupond <[email protected]> wrote:
> > > HI All,
> > > I am setting up a firewall with PF. The strategy used is quite
> > > common: set block-policy return
> > > set loginterface none
> > > set skip on lo0
> > > match in all scrub (random-id reassemble tcp)
> > > block log
> > >
> > > Then some rules are used to pass the authorized packets.
> > >
> > > One of the rule is
> > > pass from <TV_nets> to <multicast>
> > > pass from <multicast> to <TV_nets>
> > >
> > > where the table "multicast" contains all the multicast address and
> > > the table "TV_nets" the networks used for IT TV.
> > >
> > > In the log regularly the following message is produced:
> > > Jul 07 10:44:40.049159 rule 26/(match) pass in on vlan120:
> > > 192.168.88.1 > 224.0.0.1: igmp query [tos 0xc0] [ttl 1]
> > >
> > > where vlan120 is part of an OpenBSD bridge used in egress part of
> > > the firewall.
> > >
> > > A lot of similar rules (many vlan are used) and some other
> > > pass rules are defined but only this one (26) produces a message.
> >
> > What is rule 26? (pfctl -sr -R 26)
> >
> > It may relate to IP options, you can try allow-opts.
> >
> > A more detailed packet dump might give clues, e.g. from
> > tcpdump -neipflog0 -vvXs1500
> >
> >
> Thanks for the answer and the clue about how to get exactly a rule with
> a specific number. I have looked for a long time how to do it without
> really finding a good solution (pfctl -s | head -26 is not as precise).
>
> I will be able now to give more precise information.
>
Apologies for intruding mid-thread.
TL,DR: adding allow-opts to the pf rule fixes things (explanation below)
I've been watching the same behaviour on my network for a long time:
some igmp queries are always logged, even if the matching rule has no
"log" in it, but never cared too much about it:
# tcpdump -neti pflog0 -vv
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
rule 229/(match) [uid 0, pid 66873] pass in on vlan20: 10.17.18.4 > 224.0.0.1:
igmp query [len 12] (DF) [tos 0x88] [ttl 1] (id 25795, len 36, optlen=4
IPOPT-148{4})
# pfctl -sr -R 229
pass in on vlan20 inet proto igmp from 10.17.18.4 to any
(just a bit of context: 10.17.18.4 is a ISP-provided wifi router for
"triple play service" (a Thomson/Technicolor TG784n v3), which has been
repurposed as a wifi AP on vlan 20)
By reading pf.conf(5)'s section about the "allow-opts" -- which I
hadn't, thanks for the pointer, Stuart -- it is very clear that packets
with options are blocked by default, and the logged packets do have the
"router alert" option set (IPOPT-148), as can be seen above, on
tcpdump's output. This means that the packet is in fact being blocked,
even though a pass rule is being matched and logged (I find this a bit
counterintuitive, TBH, but that's on me). Adding "allow-opts" to the
rule makes the packet pass and the logging stop.
--
