From: Adam Nielsen <a.nielsen@shikadi.net>
To: netfilter@vger.kernel.org
Subject: DROP rule is ignored for multicast traffic, but only via Wireguard
Date: Sun, 26 Jan 2025 01:20:28 +1000 [thread overview]
Message-ID: <20250126012028.2a3f1428@gnosticus> (raw)
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.
next reply other threads:[~2025-01-25 15:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-25 15:20 Adam Nielsen [this message]
2025-01-26 6:16 ` DROP rule is ignored for multicast traffic, but only via Wireguard Sunny73Cr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250126012028.2a3f1428@gnosticus \
--to=a.nielsen@shikadi.net \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox