Proxmox claiming MAC address
- Thread starter tmsg
- Start date
-
- Tags
- networking openvswitch ovs
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:
What I understand it's that last possibilities to try is to switch to routed mode instead of bridged
The issue is not solved yet, even not with
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
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:
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.
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"
Then, reboot.
can somebody test it on hetzner to see if it's fixing it ?
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 1Then, reboot.
can somebody test it on hetzner to see if it's fixing it ?
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/
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/
Last edited:
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:
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 vlansI 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.
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.