From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 1A5AC68B30 for ; Fri, 10 Sep 2021 13:36:56 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 082EA139AD for ; Fri, 10 Sep 2021 13:36:26 +0200 (CEST) Received: from office.oderland.com (office.oderland.com [91.201.60.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 387D61398F for ; Fri, 10 Sep 2021 13:36:24 +0200 (CEST) Received: from [193.180.18.161] (port=38738 helo=[10.137.0.14]) by office.oderland.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1mOeA5-007Wzz-C0 for pve-devel@lists.proxmox.com; Fri, 10 Sep 2021 12:53:37 +0200 Message-ID: <7686571e-ebf0-8ad5-8bc3-af484fd2ac88@oderland.se> Date: Fri, 10 Sep 2021 12:53:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:92.0) Gecko/20100101 Thunderbird/92.0 Content-Language: en-US To: pve-devel@lists.proxmox.com References: From: Josef Johansson In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - office.oderland.com X-AntiAbuse: Original Domain - lists.proxmox.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - oderland.se X-Get-Message-Sender-Via: office.oderland.com: authenticated_id: josjoh@oderland.se X-Authenticated-Sender: office.oderland.com: josjoh@oderland.se X-SPAM-LEVEL: Spam detection results: 0 AWL 0.170 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% CTE_8BIT_MISMATCH 0.837 Header says 7bits but body disagrees KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -1.975 Looks like a legit reply (A) 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. [proxmox.com] Subject: Re: [pve-devel] hetzner bug with pve-firewall X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2021 11:36:56 -0000 Hi, I've stumpled upon this problem a couple of times and it resulted in me add ebtables rules. It is a very annoying problem to be fair. In our case what happen is * traffic is sent to MAC A because traffic flows towards IP A * traffic is broadcasted to MAC B and MAC A * MAC B responds with RST * upstream switch learns that IP A is at MAC B We are doing some benchmark testing with it to ensure that performance will not regress also, not done with that. Another more lean solution would be do to DROP instead of REJECT, which would solve it. I have a patch for the source code regarding only allowing the VMs MAC in ebtables for incoming traffic also. On 9/10/21 12:31, alexandre derumier wrote: > Hi, > > multiple users have reported problems with hetzner in bridged mode this > week and pve-firewall > https://forum.proxmox.com/threads/proxmox-claiming-mac-address.52601/ > https://forum.proxmox.com/threads/mac-address-abuse-report.95656/ > > Seem that hetzner have bugs or are under attack, but they are flooding > traffic to proxmox nodes with wrong mac/ip destination. > > The problem is that if users use pve-firewall with reject rules, the > RST packet is send with the wrong mac/ip as source, > > and then hertzner is blocking the server of the users .... > > > I'm looking to see if we could add filtering at ebtables level, to drop > wrong mac destination. > > But they are also another problem, if user use DROP as default action, >  we have a default REJECT for whois port 53. > > 'PVEFW-Drop' => [ >    # same as shorewall 'Drop', which is equal to DROP, >    # but REJECT/DROP some packages to reduce logging, >    # and ACCEPT critical ICMP types >    { action => 'PVEFW-reject', proto => 'tcp', dport => '43' }, # > REJECT 'auth' > > Does somebody known why we do a reject here ?  could it be change to > drop ? > > > > > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel -- Med vänliga hälsningar Josef Johansson