- Note: I am re-replying, as I responded incorrectly. My reply should now show on the mailing list. > is there just something going on here that I'm unaware of? I am uncertain, but consider that it is possible that the kernel is routing based on Ethernet destination address. You could try blocking destinations that match IP6 multicast MAC addresses. To quote 'IANA Ethernet Numbers' (I forget the proper name for the document): "As described in <xref type="draft" data="RFC-ietf-intarea-rfc7042bis-11"/>, 48-bit MAC addresses in the range 33-33-00-00-00-00 to 33-33-FF-FF-FF-FF are used for IPv6 multicast." There may be some specific sub-sets you are interested in. Please consult RFC7042 and related for further information. Another thing to consider is the route that the packet follows. Carefully read your static routing rules and ensure you are filtering on the correct interface. sunny On Sunday, January 26th, 2025 at 4:20 AM, Adam Nielsen <a.nielsen@xxxxxxxxxxx> wrote: > Hi all, > > I'm having some problems getting iptables to match some packets going > through my machine. > > To debug, I created these rules: > > ip6tables -I INPUT 1 -i wg0 -j DROP > ip6tables -I FORWARD 1 -i wg0 -j DROP > > This correctly blocked all unicast traffic coming in on the interface, > but it did not stop any multicast traffic from coming in. > > I can use `tcpdump -i wg0` to confirm the multicast traffic is > definitely hitting this interface, yet somehow it seems to be skipping > any rules I have configured. I have "smcroute" running to configure > some static multicast routing rules in the kernel, and the kernel is > picking up and rebroadcasting the multicast traffic to other machines > on the LAN, despite the DROP rules. > > Does anyone know why this might be? > > The setup is a Wireguard VPN, with multicast enabled (this is off by > default). The remote end is sending multicast traffic, which is > forwarded over the VPN where it arrives on the machine in question. > > This all works fine, but I am trying to set up some rules to match the > multicast traffic so that I can use the packet counter stats to see how > much multicast traffic is traversing the VPN. These rules work fine > for unicast traffic across the VPN, but they are reporting zero bytes > transmitted for multicast traffic. > > To debug this I switched to the above DROP rules instead as I figured > they should have a more obvious impact, but even these are ignored. > Those rules are inserted first, so they should match before any other > rule is examined, so no other rules should be affecting their behaviour. > > I added these rules to another machine and they worked fine, blocking > all incoming IPv6 multicast traffic immediately. The only differences > with that machine was that the packets were coming in on a physical > interface instead of a Wireguard one, and the kernel is not doing > multicast routing. > > This makes me wonder whether it's a bug in the Wireguard > implementation, or is there just something going on here that I'm > unaware of? > > Many thanks, > Adam.
