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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux