Proxmox generate 2 mac address visibile on the switch not allowed by the data center
- Thread starter openaspace
- Start date
nothing...also blocking the 43 port.
New MAC address abuse message.
how you have applied the rule? as global or replicated the rule for each device in the firewall?
> Unallowed MACs:
> 26:03:a1:a1:00:6c
> 76:9f:bd:f1:bc:de
> 9e:f7:09:95:e1:ab
> d2:b2:a0:1d:1e:4a
Crap
I was waiting for your conclusion ...
Probably need to be applied global, in Proxmox.
I am not sure
It seem.that will be fixed globally
https://forum.proxmox.com/threads/proxmox-claiming-mac-address.52601/post-416219
https://forum.proxmox.com/threads/proxmox-claiming-mac-address.52601/post-416219
yes, the problem is that in default "drop" action, they are a "reject" rules on port 43.
This has been fixed some days ago on proxmox7, but not on proxmox6.
so you can add a specific "drop" for tcp/43 to be sure.
@openaspace I still don't known why this is the mac address of the bridges that hetzner see, as I my tests and others users, the src mac = the bad wrong mac flooded by hetzner previously). I have only tested with proxmox7, maybe it's different with proxmox6 kernel, not sure about that.
Could be great to see if blocking the port 43 is working, to be sure it's the same problem.
Also, can you try: (without the drop 43 rules)
echo 0 > /sys/class/net/tapXi0/brport/unicast_flood, for each tap interface (when the vm are running)
I would like to see if it's working fine, it should avoid to send bad traffic to the firewall, so it should works with reject rules too.
echo 0 > /sys/class/net/tapXi0/brport/unicast_flood, for each tap interface (when the vm are running)
I would like to see if it's working fine, it should avoid to send bad traffic to the firewall, so it should works with reject rules too.
doesn't work.
Restarted the server two times and at the second reboot , new abuse mail received.
hi thank you.
why when are running?
What I see is that the mac's are visibile on the switch only when the server is starting , after the complete boot there no mac visibile on the switch.
Hi, when you say "server is starting", are you talking about the vm or the proxmox server ?
When I said "
", I mean, just after the vm have started, because the tap interface is created at vm start.
There is no end to this problem.
Allowed MACs:
> 00:50:56:01:02:62
> d4:3d:7e:d8:bd:c5
> 00:50:56:00:eb:57
> 00:50:56:00:b1:05
> 00:50:56:00:84:12
> 00:50:56:00:b8:95
> 00:50:56:00:b8:8c
> Unallowed MACs:
> 00:50:56:00:05:2e
> 00:50:56:00:14:67
> 00:50:56:00:4e:cf
> 00:50:56:00:cc:58
> 00:50:56:00:d4:86
> 3c:94:d5:4b:0c:0c
> 74:d0:2b:9a:85:00
> d4:3d:7e:d8:be:44
> d4:3d:7e:d8:c0:dc
Allowed MACs:
> 00:50:56:01:02:62
> d4:3d:7e:d8:bd:c5
> 00:50:56:00:eb:57
> 00:50:56:00:b1:05
> 00:50:56:00:84:12
> 00:50:56:00:b8:95
> 00:50:56:00:b8:8c
> Unallowed MACs:
> 00:50:56:00:05:2e
> 00:50:56:00:14:67
> 00:50:56:00:4e:cf
> 00:50:56:00:cc:58
> 00:50:56:00:d4:86
> 3c:94:d5:4b:0c:0c
> 74:d0:2b:9a:85:00
> d4:3d:7e:d8:be:44
> d4:3d:7e:d8:c0:dc
So, just to be sure, you have blocked port 43 with a drop rule in all yours vms where firewall is enabled and you use DROP as default inbound action ?
Last edited:
Hi "spirit" ,
I have a global rules added in every VPS and main host and the proxmox firewall is enabled on all VPS.
Today after a serve restart:
Allowed MACs:
> 00:50:56:01:02:62
> d4:3d:7e:d8:bd:c5
> 00:50:56:00:eb:57
> 00:50:56:00:b1:05
> 00:50:56:00:84:12
> 00:50:56:00:b8:95
> 00:50:56:00:b8:8c
> Unallowed MACs:
> 06:0b:54:05:72:c2
> 76:1f:fa:14:95:a7
> ae:71:1b:d1:ab:82
> f6:d7:0e:d6:67:47
>
can you send a example of /etc/pve/firewall/<vmid>.fw
Hi, when you say "server restart", are you talking about the vm or the proxmox server ?
thank you for the support.
I mean proxmox Server reboot.
[OPTIONS]
log_level_in: info
enable: 1
[RULES]
GROUP mac_address_deny
IN ACCEPT -source xxx.xxx.xxx.xxx -p tcp -dport 10000:30000 -log nolog
IN SSH(ACCEPT) -source xxx.xxx.xxx.xxx -log info
IN FTP(ACCEPT) -source xxx.xxx.xxx.xxx -log info
IN ACCEPT -source xxx.xxx.xxx.xxx -p tcp -dport 8080 -log info # ip mariangela
IN FTP(ACCEPT) -source +ip_admin -log nolog
IN SSH(ACCEPT) -source +ip_admin -log nolog
IN ACCEPT -source +ip_admin -p tcp -dport 8080 -log info
IN HTTP(ACCEPT) -log info
IN HTTPS(ACCEPT) -log info
GROUP mac_address_deny (paranoic)
ok, the rules seem to be fine.
When you restart the proxmox node, do you first stop the vm manually ? or is it the auto shutdown of vms done by proxmox ?
(I'll try to reproduce on my side to see what could happen exactly)
also, do you also use firewall to protect the host itself ? (in proxmox node rules, or datacenter rules). if yes, do you also block the port 43 ?
When you restart the proxmox node, do you first stop the vm manually ? or is it the auto shutdown of vms done by proxmox ?
(I'll try to reproduce on my side to see what could happen exactly)
also, do you also use firewall to protect the host itself ? (in proxmox node rules, or datacenter rules). if yes, do you also block the port 43 ?
automatic vps shutdown and start.
I apply the same
GROUP mac_address_deny
After the GROUP mac_address_deny rules, after one week uptime I have received new abuse messages... (without any changes on the server and vps).
But every time I restart the node after 5 minutes ..new abuse email arrive.
Thank you.
I have moved critical vps to amazon aws.
you confirm me that all this problems are solved on proxmox 7?
thank you.-
Currently, on the default port43 reject has been fixed to drop.
I'm currently working to fix this hetzner bug with fixing static mac in bridge, to avoid wrong mac traffic going through the firewall and vms.
BTW, another proxmox user have found a way to block bad traffic at hetzner level, in hetzner robot firewall.
https://forum.proxmox.com/threads/proxmox-claiming-mac-address.52601/page-4
Doesn't works.
After the main server reboot... There is the usual abuse notification email.
This problem is fixed on proxmox 7? No LAN traffic is sent on the main Ethernet interface to the switch?
I have migrated all to Amazon aws, my options are, try proxmox7 or change data center
Last edited: