On Mon, 13 Sep 2004, Timothy Jans wrote:
> Ok, I think I discovered a bug and solved my problem :)
Depends on what you mean by "bug". :-)
> This is what I get with no explicit rule :
> 23:46:19.930192 WAN 18.104.22.168 22.214.171.124 IGMP
> 23:46:19.929921 WAN 126.96.36.199 188.8.131.52 IGMP
> 23:46:19.929646 WAN 184.108.40.206 220.127.116.11 IGMP
> 23:46:19.929361 WAN 18.104.22.168 22.214.171.124 IGMP
> 23:46:19.929041 WAN 126.96.36.199 188.8.131.52 IGMP
> 23:46:19.928769 WAN 184.108.40.206 220.127.116.11 IGMP
> 23:46:19.928496 WAN 10.74.0.1 18.104.22.168 IGMP
> 23:46:19.928239 WAN 172.22.208.1 22.214.171.124 IGMP
> This is what I get with an explicit non-logging rule for IGMP :
> 23:50:29.966303 WAN 10.74.0.1 126.96.36.199 IGMP
> 23:50:29.966047 WAN 172.22.208.1 188.8.131.52 IGMP
> You can clearly see that the 81.x.x.x are not logged anymore.
> The others are probably logged because they are private IP ranges.
> When I now uncheck "block private networks" (Interfaces -> WAN) the
> firewall won't log any IGMP packet :)
That explains why I never had the problem - my only IGMP packets come
from my ISP's router.
If your "WAN" is in a context where private addresses are meaningful, then
the "block private networks" setting is clearly inappropriate.
If the private addresses are really in somebody else's private network,
then that seems like a bug in multicast routing, in which case the logging
is probably a "feature". :-) Note that IGMP packets are not supposed to be
The "block private networks" setting can always be accomplished with
explicit rules, in which case you can control the order.