From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 9E0C01FF15C for ; Fri, 11 Jul 2025 17:10:17 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 2401B13AA7; Fri, 11 Jul 2025 17:10:58 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 morty.keekles.org 4643D19E1DAC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bryanfields.net; s=909DCF92-EFE7-11EB-9235-648EB8AF1B81; t=1752246643; bh=XHT4+YEBTeIFITwAm2/pE9jE4dPrUtWmKOIlsgIlN+k=; h=Message-ID:Date:MIME-Version:To:From; b=auYlqnn6B8pNsd51YH4k8PGLm6ZnsJ+p8qSTVARrAUIpen6ENWKMC8DJiLdSbA5qg DUsxbOpk/86Hu1YmtyXNoQ4f0u0iG8En3zcB7fnH7/OaK5DgTo6aktHZ+0dJl6kcdX AfMVoviQn5SC0Hk+L7BfNfjP4GIxoWsQzhm9t/YIw3nKXnC0AOcOgGHmIcN+s++KQH 6dJauxoEGpcfsq40V30Bv7kmz0lNBeBmRTIXADF/HR8Sr9CkGtsp0nAywtcSSK9PpF nNeWF8mLb2jZ8v2JfUImTn8z/paIG5lLWo7ZBu4E1aJiLj1W0Ospl2p1U7tL8k8l08 lgJu2JonuhQRQ== X-Virus-Scanned: amavis at morty.keekles.org Message-ID: <5a2d1471-7fd4-42d0-8632-d26c7709df0b@bryanfields.net> Date: Fri, 11 Jul 2025 11:10:42 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: pve-user@lists.proxmox.com References: <1d20bc9d-b794-4124-bd47-f7586ab1ccd7@bryanfields.net> <8308d4c1-c352-4df2-bd34-9f004f7b3a21@bryanfields.net> Content-Language: en-US From: Bryan Fields In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL 0.002 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain DMARC_MISSING 0.1 Missing DMARC policy SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [bryanfields.net] Subject: Re: [PVE-User] PVE-firewall and multicast with linux bridging X-BeenThere: pve-user@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE user list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE user list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pve-user-bounces@lists.proxmox.com Sender: "pve-user" 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