[pve-devel] hetzner bug with pve-firewall

[Josef Johansson]

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 <aderumier at odiso.com>
> 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 <aderumier at odiso.com>
>> 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
>> pve-devel at lists.proxmox.com
>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>> _______________________________________________
>> pve-devel mailing list
>> pve-devel at lists.proxmox.com
>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> _______________________________________________
> pve-devel mailing list
> pve-devel at lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
> _______________________________________________
> pve-devel mailing list
> pve-devel at lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel