DROP rule is ignored for multicast traffic, but only via Wireguard

DROP rule is ignored for multicast traffic, but only via Wireguard

[Adam Nielsen]

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.

Re: DROP rule is ignored for multicast traffic, but only via Wireguard

[Sunny73Cr]

- 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@shikadi.net> 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.