public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Josef Johansson <josef@oderland.se>
To: pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] hetzner bug with pve-firewall
Date: Fri, 10 Sep 2021 12:53:35 +0200	[thread overview]
Message-ID: <7686571e-ebf0-8ad5-8bc3-af484fd2ac88@oderland.se> (raw)
In-Reply-To: <a8964d56b11abd57afcab5b304ff484216cb9d21.camel@odiso.com>

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




  parent reply	other threads:[~2021-09-10 11:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-10 10:31 alexandre derumier
2021-09-10 10:43 ` Fabian Grünbichler
2021-09-13 17:43   ` alexandre derumier
2021-09-10 10:53 ` Josef Johansson [this message]
2021-09-10 12:34   ` Josef Johansson
2021-09-10 16:18   ` alexandre derumier
2021-09-12 10:37     ` Josef Per Johansson
2021-09-14  0:27       ` alexandre derumier
2021-09-14  7:21         ` Josef Per Johansson
2021-10-01 15:19           ` Josef Johansson
2021-10-12 12:41             ` Josef Johansson

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=7686571e-ebf0-8ad5-8bc3-af484fd2ac88@oderland.se \
    --to=josef@oderland.se \
    --cc=pve-devel@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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal