[pve-devel] hetzner bug with pve-firewall

[pve-devel] hetzner bug with pve-firewall

[alexandre derumier]

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 ?

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

[Fabian Grünbichler]

On September 10, 2021 12:31 pm, 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 ?

 https://git.proxmox.com/?p=pve-firewall.git;a=commit;h=d9e7522b561ceb323e93affb29c9fced89fed967

would just require a bump + upload

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

[Josef Johansson]

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

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

[Josef Johansson]

Traffic is only broadcasted to MAC B if the ARP-table in the switch
times out.

Which makes this problem a hell to diagnose :-)

On 9/10/21 12:53, Josef Johansson wrote:
> 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

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

[alexandre derumier]

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)

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

[Josef Per Johansson]

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

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

[alexandre derumier]

Hi,


>  
> https://git.proxmox.com/?p=pve-firewall.git;a=commit;h=d9e7522b561ceb323e93affb29c9fced89fed967
> 
> would just require a bump + upload

is it possible to backport it to pve 6 ?
(I have seen 2 users on the forum requesting it )


Le vendredi 10 septembre 2021 à 12:43 +0200, Fabian Grünbichler a
écrit :
> On September 10, 2021 12:31 pm, 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 ?
> 
>  
> https://git.proxmox.com/?p=pve-firewall.git;a=commit;h=d9e7522b561ceb323e93affb29c9fced89fed967
> 
> would just require a bump + upload
> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

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

[alexandre derumier]

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

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

[Josef Per Johansson]

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

Re: [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@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
From d.whyte@proxmox.com  Fri Oct  1 17:31:03 2021
Return-Path: <d.whyte@proxmox.com>
X-Original-To: pve-devel@lists.proxmox.com
Delivered-To: pve-devel@lists.proxmox.com
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with ESMTPS id 2214D711BB
 for <pve-devel@lists.proxmox.com>; Fri,  1 Oct 2021 17:31:03 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id 170B82D8C7
 for <pve-devel@lists.proxmox.com>; Fri,  1 Oct 2021 17:31:03 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
 [94.136.29.106])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by firstgate.proxmox.com (Proxmox) with ESMTPS id 11E7B2D8BE
 for <pve-devel@lists.proxmox.com>; Fri,  1 Oct 2021 17:31:02 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
 by proxmox-new.maurer-it.com (Proxmox) with ESMTP id DC565453EB
 for <pve-devel@lists.proxmox.com>; Fri,  1 Oct 2021 17:31:01 +0200 (CEST)
From: Dylan Whyte <d.whyte@proxmox.com>
To: pve-devel@lists.proxmox.com
Date: Fri,  1 Oct 2021 17:30:50 +0200
Message-Id: <20211001153051.175856-2-d.whyte@proxmox.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20211001153051.175856-1-d.whyte@proxmox.com>
References: <20211001153051.175856-1-d.whyte@proxmox.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL 0.444 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
Subject: [pve-devel] [PATCH pve-docs 2/3] pveum: add intro to 'limited API
 Token' section
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Fri, 01 Oct 2021 15:31:03 -0000

Add a short introduction to the section "Limited API Token for
Monitoring", to provide some context

Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
---
 pveum.adoc | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/pveum.adoc b/pveum.adoc
index a0fabfb..97e0005 100644
--- a/pveum.adoc
+++ b/pveum.adoc
@@ -793,7 +793,13 @@ members of the group `customers` and within the realm `pve`.
 Limited API Token for Monitoring
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Given a user `joe@pve`, with the PVEVMAdmin role on all VMs:
+Permissions on API tokens are always a subset of those of their corresponding
+user, meaning that an API token can't be used to carry out a task that the
+backing user has no permission to do. This section will demonstrate how you can
+use an API token with separate privileges, to limit the token owner's
+permissions further.
+
+Give the user `joe@pve` the role PVEVMAdmin on all VMs:
 
 [source,bash]
  pveum acl modify /vms -user joe@pve -role PVEVMAdmin
-- 
2.30.2

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

[Josef Johansson]

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