Hi, I deployed on all interfaces, both fwnl and fwpr.
It seems to have solve a bunch of troubles on our side. Med vänliga hälsningar Josef Johansson On 10/1/21 17:19, Josef Johansson wrote: > 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 _______________________________________________ pve-devel mailing list [email protected] https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
