On Fri, 9 Jul 2021 11:09:07 +0100
Zé Loff <zel...@zeloff.org> wrote:
> 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 <s...@spacehopper.org> a écrit :
> >
> > > On 2021-07-07, Pierre Dupond <76nem...@gmx.ch> 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.
>
>
> --
>
Thank you for these clear explanations. By following them I have fully
solved the problem.
