Proxmox claiming MAC address

[openaspace]

It's very simple, I created a screenshot replace <Your IP 1 - 5> with your public IP that you can find at the first tab "IPs". The name filed is irrelevant choose everything that describe your rule.

at the server reboot .. new abuse message
this not solve the problem.

 

[MarvinE]

at the server reboot .. new abuse message
this not solve the problem.

For us it is working for 8 days, the abuse messages before without the rules cams every 2 days.

- Do you now that no of your VM has a wrong MAC ?
- Yes, only a in comming rule, because its redirected traffic for other hosts... Read the posts of this thread to understand it.
Edit:
- Have you checked all wrong MACs with "tcpdump ether host <MAC>" if the traffic is droped, after the rule creation?

 

[openaspace]

For us it is working for 8 days, the abuse messages before without the rules cams every 2 days.

- Do you now that no of your VM has a wrong MAC ?
- Yes, only a in comming rule, because its redirected traffic for other hosts... Read the posts of this thread to understand it.
Edit:
- Have you checked all wrong MACs with "tcpdump ether host <MAC>" if the traffic is droped, after the rule creation?

What I understand it's that last possibilities to try is to switch to routed mode instead of bridged

 

[thommie]

The issue is not solved yet, even not with

root@tokoeka ~ # pveversion pve-manager/7.0-11/63d82f4e (running kernel: 5.11.22-4-pve)

Today I received a new abuse complaint from Hetzner again for Proxmox using "diced MACs" which are unknown to the Hetzner robot.

@proxmox staff: any comment from your side? This affects a growing number of customers, minimum those hosted at Hetzner

 

[openaspace]

The issue is not solved yet, even not with

root@tokoeka ~ # pveversion pve-manager/7.0-11/63d82f4e (running kernel: 5.11.22-4-pve)

Today I received a new abuse complaint from Hetzner again for Proxmox using "diced MACs" which are unknown to the Hetzner robot.

@proxmox staff: any comment from your side? This affects a growing number of customers, minimum those hosted at Hetzner

You have installed and configured the beta patch?

https://forum.proxmox.com/threads/p...-allowed-by-the-data-center.95946/post-419866

 

[openaspace]

Today I received a new abuse complaint from Hetzner again for Proxmox using "diced MACs" which are unknown to the Hetzner robot.

Please let me know.
https://forum.proxmox.com/threads/p...-allowed-by-the-data-center.95946/post-419866

I scheduled to install proxmox 7 today.
If doesn't work I will choose another strategy.

 

[spirit]

I repost test patch here:

if you want test on proxmox7, download this deb:

https://mutulin1.odiso.net/libpve-common-perl_7.0-6_all.deb
https://mutulin1.odiso.net/libpve-network-perl_0.6.1_all.deb (optionnal, only if you use the sdn beta feature)
https://mutulin1.odiso.net/pve-container_4.0-9_all.deb (only if you use containers)
https://mutulin1.odiso.net/qemu-server_7.0-13_amd64.deb (only if you use vms)

and install them with "dpkg -i *.deb".

then, edit /etc/network/interfaces,

and under the vmbrX bridge, add "bridge-disable-mac-learning 1"

auto vmbr0
iface vmbr0 inet manual
        bridge ports ...
       ...
        bridge-disable-mac-learning 1

Then, reboot.


can somebody test it on hetzner to see if it's fixing it ?

 

[thommie]

I will test this on Hetzner, but would like to see a reply from proxmox staff on this ...

 

[openaspace]

any news

I will test this on Hetzner, but would like to see a reply from proxmox staff on this ...

Hi Mr. Thommie.
do you have good news?

 

[openaspace]

Idea....?
could be that creating a vswitch and assigning (in some way) the proxmox bridges to the vlan , can limit the layer 2 traffic within the datacenter vswitch?

https://docs.hetzner.com/robot/dedicated-server/network/vswitch/

https://engineerworkshop.com/blog/configuring-vlans-on-proxmox-an-introductory-guide/

 

[ReptoxX]

I repost test patch here:

if you want test on proxmox7, download this deb:

https://mutulin1.odiso.net/libpve-common-perl_7.0-6_all.deb
https://mutulin1.odiso.net/libpve-network-perl_0.6.1_all.deb (optionnal, only if you use the sdn beta feature)
https://mutulin1.odiso.net/pve-container_4.0-9_all.deb (only if you use containers)
https://mutulin1.odiso.net/qemu-server_7.0-13_amd64.deb (only if you use vms)

and install them with "dpkg -i *.deb".

then, edit /etc/network/interfaces,

and under the vmbrX bridge, add "bridge-disable-mac-learning 1"

auto vmbr0
iface vmbr0 inet manual
        bridge ports ...
       ...
        bridge-disable-mac-learning 1

Then, reboot.


can somebody test it on hetzner to see if it's fixing it ?

Bad news, just implemented it and got the abuse message again.

 

[openaspace]

Bad news, just implemented it and got the abuse message again.

Oooh
Thank you for the update

 

[spirit]

Bad news, just implemented it and got the abuse message again.

do you have reboot after the patch ? (or stop/start all vms)

just to verify that patch is correctly apply, can you check that

cat /sys/class/net/veth<ctid>i0/brport/learning

or

cat /sys/class/net/tap<vmid>i0/brport/learning

(when vm or ct are started)

is correctly set to 0 ?

 

[ReptoxX]

I now just checked the files and all were filled with a "0".
Then i let Hetzner re-evaluate my issue and got the message that my issue is not resolved.

Yes i did restart the node.

 

[openaspace]

anyone know if this happen also with OVH?

 

[spirit]

I now just checked the files and all were filled with a "0".
Then i let Hetzner re-evaluate my issue and got the message that my issue is not resolved.

Yes i did restart the node.

About the patch, it's still possible that wrong packet is coming up to the host vmbr0, (but not to the vm or vm firewall bridge)
because the physical interface is still is promiscous mode.

It's possible to disable promisc mode, if my patch is apply (with bridge-disable-mac-learning 1),
but also, bridge need to be in vlan-aware mode. (even if vm don't have any vm).

if somebody could try:

auto vmbr0
iface vmbr0 inet manual
        bridge ports ...
       ...
        bridge-disable-mac-learning 1
        bridge-vlan-aware yes
        bridge-vids 2      #just to avoid to generate too much vlans

I think that untagged traffic should still works.


With this, if you do a dmesg, you shouldn't see this message "device ethX entered promiscuous mode" anymore.
Then we are 100% sure than wrong dest ip/mac is not entering the server.

 

[openaspace]

It's possible to disable promisc mode

There are bad effects disabling promisc mode?

 

[spirit]

There are bad effects disabling promisc mode?

there is bad effect to enabling it. promisc mode accept any packet, for any destination (with bad mac address sent by hetzner for example in our case).

It's enabled by default on any interfaces in a bridge. (so, it's not enabled on routed moded)

The only way to remove promisc on physical interfaces, is to disable bridge learning on all vms/tap interfaces. (so mac address need to be setup statically in the bridge fdb). (this is what my patches are doing).
But also the bridge need to be vlan-aware too.

 

[openaspace]

Anyone can confirm that is working on hetzner?

 

[alebeta]

@spirit the patch works with OpenVSwitch?