Proxmox claiming MAC address

openaspace

Member
Sep 16, 2019
347
6
23
Italy
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.
 
Jan 16, 2020
43
6
8
24
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?
 
Last edited:

openaspace

Member
Sep 16, 2019
347
6
23
Italy
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
 
Aug 19, 2019
40
7
13
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

Member
Sep 16, 2019
347
6
23
Italy
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
 
Last edited:

spirit

Famous Member
Apr 2, 2010
5,153
485
103
www.odiso.com
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"

Code:
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 ?
 

ReptoxX

New Member
Mar 8, 2020
5
1
1
23
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"

Code:
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.
 

spirit

Famous Member
Apr 2, 2010
5,153
485
103
www.odiso.com
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 ?
 
Last edited:

ReptoxX

New Member
Mar 8, 2020
5
1
1
23
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.
 

spirit

Famous Member
Apr 2, 2010
5,153
485
103
www.odiso.com
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:

Code:
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.
 
  • Like
Reactions: whitenexx

spirit

Famous Member
Apr 2, 2010
5,153
485
103
www.odiso.com
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.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.

Buy now!