Proxmox claiming MAC address

so you have tried "net.ipv4.igmp_link_local_mcast_reports = 0" as I have asked before ?

I have deleted my server... too much time to solve this problem.

Switched to AWS.... and written to some companies about the automatic layer2 traffic isolation ...
Good luck.
 
Last edited:
you need to ask to the support for manual verification, otherwise it can happen randomly ...
No, I have reproduced it on 2 hosts, other 2 (after setting echo 0 > /proc/sys/net/ipv4/igmp_link_local_mcast_reports) hosts looks good, no abuse message.

We use hetzner (over 10 Years) and proxmox (since pve 5) lots of years, and we hand never a big trouble.
 
No, I have reproduced it on 2 hosts, other 2 (after setting echo 0 > /proc/sys/net/ipv4/igmp_link_local_mcast_reports) hosts looks good, no abuse message.

We use hetzner (over 10 Years) and proxmox (since pve 5) lots of years, and we hand never a big trouble.
Thanks for the report !

I think this behaviour already existed before, this is a feature from the kernel since years.
Maybe something at hetzner have change ? Maybe they were filtering igmp/multicast before ?

I have send a patch to pve-devel mailing to set the sysfs to 0 by default.
 
No, I have reproduced it on 2 hosts, other 2 (after setting echo 0 > /proc/sys/net/ipv4/igmp_link_local_mcast_reports) hosts looks good, no abuse message.
I'm sorry but without human confirmation with dedicated scan it's not a really proof. One of my server was on for one week and after started to receive notifications. Please ask to execute a human verification.
 
Hey guys, we experience the same problems at Hetzner with Proxmox machines that already exists many years! It happens exactly since the 04th of september 2021. After doing a tcpdump I could also see incoming traffic for these wrong MAC addresses. And I also have the same setup using a vmbr0 bridge linked to the physical interface. We also use Proxmox firewall. These guys here at reddit also have the same problems since exactly the 04.09.2021. https://www.reddit.com/r/hetzner/co.../?utm_source=share&utm_medium=web2x&context=3

I have already written many times with the Hetzner Support but they can't help. I'm glad that I found this thread here. I think Hetzner has changed something in their configuration but since we don't get any information we have to deal with it.

I've read about many solutions here in this thread. What's the most/best one at this time? Currently we're running Proxmox 6 but it should be no problem to upgrade to 7 now. Will this issue be fixed then or do I need to install the patch (deb packages) manually? Do I need further changes? The temporary solution with the Hetzner firewall sounds good and logical to me since this traffic won't get to the machine anymore but it would be also nice to fix this issue directly in Proxmox in the long run.

Best regards from germany

/UPDATE/
I configured the Hetzner Firewall to only allow traffic where our public/external IPv4 addresses are in the package destination. I also configured to allow traffic from private networks to have vSwitch networking furthermore working.

I can now see no more package noise and bad traffic on the physical network interfaces on the nodes.
I think this will help mostly for the main time but as I've seen there might be other sources for using a wrong MAC address on the bridge until I can use the "disable mac learning" patch for the bridge from @spirit . So my next todo will be upgrading my Proxmox 6 cluster to the newest 7.x version, hopefully with the patch already included or with manual patch installation afterwards. I still have to think about what to do with one older Proxmox single node we have. Maybe I have to do some planned upgrades sooner as planned.
 
Last edited:
Hey guys, we experience the same problems at Hetzner with Proxmox machines that already exists many years! It happens exactly since the 04th of september 2021. After doing a tcpdump I could also see incoming traffic for these wrong MAC addresses. And I also have the same setup using a vmbr0 bridge linked to the physical interface. We also use Proxmox firewall. These guys here at reddit also have the same problems since exactly the 04.09.2021. https://www.reddit.com/r/hetzner/co.../?utm_source=share&utm_medium=web2x&context=3

I have already written many times with the Hetzner Support but they can't help. I'm glad that I found this thread here. I think Hetzner has changed something in their configuration but since we don't get any information we have to deal with it.

I've read about many solutions here in this thread. What's the most/best one at this time? Currently we're running Proxmox 6 but it should be no problem to upgrade to 7 now. Will this issue be fixed then or do I need to install the patch (deb packages) manually? Do I need further changes? The temporary solution with the Hetzner firewall sounds good and logical to me since this traffic won't get to the machine anymore but it would be also nice to fix this issue directly in Proxmox in the long run.

Best regards from germany
the my provided patches (disable bridge learning) are not yet released, they basically allowing to use REJECT rules in firewall.
but it should work without them if you use DROP rules.

if you are in proxmox6, for the 2 bugs:

1) rst packet bug
- don't use REJECT as default inbound rule, use DROP.
- they are a bug in default DROP, where REJECT is used for port 43, so you can block it with a DROP rule at the end of your rules.
(this is fixed in proxmox7).

2) multicast igmp report on local link plug

- echo 0 > /proc/sys/net/ipv4/igmp_link_local_mcast_reports (+ /etc/sysctl.d/pve.conf with et.ipv4.igmp_link_local_mcast_reports=0 for persistant value at reboot)
 
I now had my third abuse issue at Hetzner, this issue is still un-solved
proxmox version ?
do you have set the 2 fixes I have send in the previous post ?

Why dont we get any response from Proxmox staff?
as you are proxmox subscriber, do you have send a ticket to the proxmox support ?
 
proxmox version ?
do you have set the 2 fixes I have send in the previous post ?


as you are proxmox subscriber, do you have send a ticket to the proxmox support ?
I also have same problem. Proxmox VE 6.3-3

Firewall INPUT policy was on DROP as per default:

1634059306224.png

I also altered the sys value:

Code:
cat /proc/sys/net/ipv4/igmp_link_local_mcast_reports
0

Just received another abuse message :(
 
I also have same problem. Proxmox VE 6.3-3

Firewall INPUT policy was on DROP as per default:

View attachment 30299

I also altered the sys value:

Code:
cat /proc/sys/net/ipv4/igmp_link_local_mcast_reports
0

Just received another abuse message :(
What about this:
- they are a bug in default DROP, where REJECT is used for port 43, so you can block it with a DROP rule at the end of your rules.
(this is fixed in proxmox7).
from https://forum.proxmox.com/threads/proxmox-claiming-mac-address.52601/page-7#post-422371
 
  • Like
Reactions: spirit
POSSIBLE HINT: same problem here. but only with two proxmox hosts out of three which makes it even stranger. All hosts have basically the same config and version. BUT: the host that did not receive a MAC ABUSE message, yet, has the updated kernel 5.11.22-2-pve #1 SMP PVE 5.11.22-4~bpo10 (Wed, 21 Jul 2021 17:53:37 +0200) x86_64 GNU/Linux - all others have the 5.4.140-1-pve #1 SMP PVE 5.4.140-1 (Wed, 08 Sep 2021 16:21:59 +0200) x86_64 GNU/Linux-
 
Any news?
I have do tcpdump for 2 weeks, and I don't have seen packets coming from ip of the bridge with:

1) don't use reject for iptables (with last promox7 pve-firewall or explictit dropping port 43 for proxmox6
2) disabling igmp_link_local_mcast_reports (occuring at vm/ct stop/start)

I'm don't have any hetzner server to confirm it's totally fixing it. so, maybe can you give it a try.
 
Do you mean I have to add a firewall rule to drop any outgoing (?) packets on port 43 for PVE6?
no, for ingoing.

to resume: you can't use REJECT rules for incoming rules with hetzner, because it's sending a RST packet with the mac of the bridge.
but, they are a bug in in the default DROP action, where a REJECT is done for port tcp/43.
This a been fixed (removed) in last proxmox 7.
but for proxmox6, you need to add a DROP rule for "direction:in port:tcp/43" at the end of ALL yours vm/ct rules.
 
no, for ingoing.

to resume: you can't use REJECT rules for incoming rules with hetzner, because it's sending a RST packet with the mac of the bridge.
but, they are a bug in in the default DROP action, where a REJECT is done for port tcp/43.
This a been fixed (removed) in last proxmox 7.
but for proxmox6, you need to add a DROP rule for "direction:in port:tcp/43" at the end of ALL yours vm/ct rules.
Not enough to add it on the datacenter level?
 
I moved to aws for now,
if anyone have a hetzner server, please apply the modifications and ask to the support for manual mac scan.
 
I am getting abuse messages from Hetzner since I moved to Proxmox from ESXi (September 2021). I followed the first few pages of this thread but got lost after a while. I am running Kernel 5.11.22-5-pve. Could someone help me with the latest thinking here, regarding the firewall config? i.e. what steps should I be taking now (October 2021) to hopefully stop the abuse emails?

I have disabled all the rpcbind stuff already

The abuse email listed two unallowed MACs
> Unallowed MACs:
> 56:5b:60:9a:58:4a
> a6:43:63:c9:90:26

Many thanks
Jon
 
Last edited:
I am getting abuse messages from Hetzner since I moved to Proxmox from ESXi (September 2021). I followed the first few pages of this thread but got lost after a while. I am running Kernel 5.11.22-5-pve. Could someone help me with the latest thinking here, regarding the firewall config? i.e. what steps should I be taking now (October 2021) to hopefully stop the abuse emails?

I have disabled all the rpcbind stuff already

The abuse email listed two unallowed MACs
> Unallowed MACs:
> 56:5b:60:9a:58:4a
> a6:43:63:c9:90:26

Many thanks
Jon
1) never use REJECT rules for inbound rules, and use DROP as default action.
2) if you are still on proxmox6, add an extra DROP for tcp/43 for inbound rule. (this is fixed in proxmox7 pve-firewall_4.2-3 )
3) echo 0 >/proc/sys/net/ipv4/igmp_link_local_mcast_reports + add in /etc/sysctl.d/pve.conf
"net.ipv4.igmp_link_local_mcast_reports = 0"
 
  • Like
Reactions: apkoval

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 yours easily in our online shop.

Buy now!