Hi, Sorry for the late answer.
It seems to do what it's intended to do. I ran `bridge link set dev fwpr<id>p0 flood off` If it works ok I will deploy it on more VMs. Med vänliga hälsningar Josef Johansson On 9/14/21 09:21, Josef Per Johansson wrote: > Hi, > > I can check it out for sure, not touching ebtables would be nice. > > Sent from Nine > ________________________________ > From: alexandre derumier <[email protected]> > Sent: Tuesday, 14 September 2021 02:28 > To: Proxmox VE development discussion > Subject: Re: [pve-devel] hetzner bug with pve-firewall > > > Hi, I just send another patch, > > without ebtables, but with disabling unicast_flood on vm bridge ports. > > maybe can you try it ? > > > Le dimanche 12 septembre 2021 à 12:37 +0200, Josef Per Johansson a > écrit : >> Hi, >> >> Yeah sure! It seems a bit better than my hack! >> >> Yeah I meant the mac-address-table, my bad. >> >> Sent from Nine >> ________________________________ >> From: alexandre derumier <[email protected]> >> Sent: Friday, 10 September 2021 18:19 >> To: Proxmox VE development discussion >> Subject: Re: [pve-devel] hetzner bug with pve-firewall >> >> >> Hi, >> >> Le vendredi 10 septembre 2021 à 12:53 +0200, Josef Johansson a >> écrit : >>> >>> I have a patch for the source code regarding only allowing the VMs >>> MAC >>> in ebtables for incoming traffic also. >> I just send a patch too for incoming traffic, maybe could you try it >> ? >> >> >> >>>> Traffic is only broadcasted to MAC B if the ARP-table in the >>>> switch >>>> times out. >>>> >>>> Which makes this problem a hell to diagnose :-) >> to be exact, if the mac-address-table timeout in the switch. (switch >> don't have arp, until it's a router) >> That's why in general, switch need to be configured with mac-address- >> table aging-time (2h for exemple) > than arp timeout on servers. >> >> Like this, if no traffic occur on servers, and arp is timeout out, >> server is sending a new arp request, and the switch see the arp reply >> with the mac address, >> (and no expiration in mac-address-table). >> >> Looking at hetzner problem, the tcpdump send by users show really >> stranges mac address vendor. (sound like forged flood). >> Anyway, they should fix this, with static mac in their switch, as >> they >> known allowed mac by server anyway. >> (Until they have poor cheap switch without mac filtering ....) >> I wonder if they are not only filtering/detecting the wrong mac on >> their gateway. (as here, we send tcp reset to an external ip, going >> through the gateway) >> >> >> >> _______________________________________________ >> pve-devel mailing list >> [email protected] >> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel >> _______________________________________________ >> pve-devel mailing list >> [email protected] >> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel > _______________________________________________ > pve-devel mailing list > [email protected] > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel > > _______________________________________________ > pve-devel mailing list > [email protected] > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel _______________________________________________ pve-devel mailing list [email protected] https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
