From: Bryan Fields <bryan@bryanfields.net>
To: pve-user@lists.proxmox.com
Subject: Re: [PVE-User] PVE-firewall and multicast with linux bridging
Date: Fri, 11 Jul 2025 11:10:42 -0400 [thread overview]
Message-ID: <5a2d1471-7fd4-42d0-8632-d26c7709df0b@bryanfields.net> (raw)
In-Reply-To: <mailman.725.1751264740.395.pve-user@lists.proxmox.com>
On 6/30/25 2:16 AM, g.husson_proxmox-pve-user--- via pve-user wrote:
> "It is not a bug, it is a feature" :-)
> Look at the documentation :
> ===
> The following traffic is dropped, but not logged even with logging enabled:
> - Broadcast, multicast and anycast traffic not related to corosync,
> i.e., not coming through ports 5405-5412
> ===
>
> Again, from the documentation :
> ===
> proxmox-firewall will create two tables that are managed by the proxmox-
> firewall service: proxmox-firewall and proxmox-firewall-guests. If you
> want to create custom rules that live outside the Proxmox VE firewall
> configuration you can create your own tables to manage your custom
> firewall rules. proxmox-firewall will only touch the tables it
> generates, so you can easily extend and modify the behavior of the
> proxmox-firewall by adding your own tables.
> ===
None of this mentions that connection tracking is enabled globally, even
on interfaces that are not firewalled. It's an undocumented "feature".
This kills multicast traffic globally, and owing to connection tracking
being unable to match traffic.
> Chain PVEFW-FORWARD (1 references)
> num target prot opt source destination
> 1 DROP 0 -- 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
> Now you can use rc.local, or crontab @reboot or better a systemd file
> that chains after proxmox VE firewall start in order to apply the manual
> rules you found.
Given how iptables works, I can make a new table and insert it before
the PVEFW-FORWARD chain. However there is no way to negate a later rule
other than by allowing/forwarding it, which I may not want to do 'permit
any any' on an interface globally. The only option is to edit the
PVEFW-FORWARD chain directly, but this will get overwritten on reboots
and when the firewall settings are changed in pve.
If there's a way to kick off a script when pve-firewall updates, this
would be an option, but the better option would be to fix this so it can
be enabled on a per interface basis, rather than all or none.
--
Bryan Fields
727-409-1194 - Voice
http://bryanfields.net
_______________________________________________
pve-user mailing list
pve-user@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-user
prev parent reply other threads:[~2025-07-11 15:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-22 6:22 Bryan Fields
2025-06-23 3:53 ` Bryan Fields
2025-06-29 8:14 ` Bryan Fields
2025-06-30 6:16 ` g.husson_proxmox-pve-user--- via pve-user
2025-07-11 15:10 ` Bryan Fields [this message]
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=5a2d1471-7fd4-42d0-8632-d26c7709df0b@bryanfields.net \
--to=bryan@bryanfields.net \
--cc=pve-user@lists.proxmox.com \
/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