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  	81.83.76.1  	224.0.0.1  	IGMP
> 23:46:19.929921 WAN 	81.83.92.1 	224.0.0.1 	IGMP
> 23:46:19.929646 WAN 	81.83.32.1 	224.0.0.1 	IGMP
> 23:46:19.929361 WAN 	81.82.222.1 	224.0.0.1 	IGMP
> 23:46:19.929041 WAN 	81.165.144.1 	224.0.0.1 	IGMP
> 23:46:19.928769 WAN 	81.165.156.1 	224.0.0.1 	IGMP
> 23:46:19.928496 WAN 	10.74.0.1 	224.0.0.1 	IGMP
> 23:46:19.928239 WAN 	172.22.208.1 	224.0.0.1 	IGMP
> 
> This is what I get with an explicit non-logging rule for IGMP :
> 
> 23:50:29.966303 WAN  	10.74.0.1  	224.0.0.1  	IGMP
> 23:50:29.966047 WAN 	172.22.208.1 	224.0.0.1 	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
forwarded.

The "block private networks" setting can always be accomplished with
explicit rules, in which case you can control the order.

					Fred Wright