Re: [pve-devel] hetzner bug with pve-firewall

[Josef Johansson <josef@oderland.se>]

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