Proxmox claiming MAC address

it could be great to have more trace to known what's going out.
I'm not sure that the problem is only the tcp reset packets sent by pve-firewall reject rules.
As for some user, it seem to happen only when reboot the proxmox node.

could you try to add

Code:
ebtables -I OUTPUT -o <phyiscal intertace> --among-src ! <mac1,mac2,mac3....> --log-level info --log-prefix "MAC-FLOOD-O" --log-ip -j CONTINUE
ebtables -I FORWARD -o <physical interface> --among-src ! <mac1,mac2,mac3....> --log-level info --log-prefix "MAC-FLOOD-F" --log-ip -j CONTINUE
?

where <physical interface> is your eth0, eno1,enp2s0 .., and mac1,mac2,mac3 is the list of all your allowed mac address (vms mac + host mac)..

it should be logged in /var/log/messages.
 
i currently did not receive any abuse message after one week of having this installed.
Have you rebooted the server?
If not, please reboot it...I was receiving messages only at the reboot.

I have migrated all to aws, no time to test the solution with jobs in progress
 
Now, the problem is back after i upgraded a LXC with Debian 10.5 to 10.10 (and reboot the lxc, reboots on 10.5 makes no problems), I can find the problematic MAC with "ip add" on the fwln100i0@fwpr100p0 bridge. But it's strange with enabled Hetzner Robot Firewall there is no traffic to find with tcpdump.

@spirit I will try your ebtables.
 
Now, the problem is back after i upgraded a LXC with Debian 10.5 to 10.10 (and reboot the lxc, reboots on 10.5 makes no problems), I can find the problematic MAC with "ip add" on the fwln100i0@fwpr100p0 bridge. But it's strange with enabled Hetzner Robot Firewall there is no traffic to find with tcpdump.

@spirit I will try your ebtables.
thanks for the report, I'll to check if lxc + debian 10.10 could send some strange packet at reboot.
(what is the /etc/network/interfaces inside this debian ct ? do you use ipv4 only ? ipv4 + ipv6 ? )

so the wrong mac see by hetzner is mac address of "fwln100i0@fwpr100p0" ?

indeed, the ebtables log rule could be fine to have more info.
 
I have found something with CT,

it seem than the fwbr bridge is sending an multicast igmp report when CT start.

I don't think it's related to CT os, as I can produce with only creating the fwbr without plugging the veth of the CT

Code:
ebtable log:

Oct  6 09:46:24 kvmformation3 kernel: [437256.753355] MAC-FLOOD-F IN=fwpr109p0 OUT=eno1 MAC source = 22:5f:0b:cb:ac:42 MAC dest = 01:00:5e:00:00:16 proto = 0x0800 IP SRC=0.0.0.0 IP DST=224.0.0.22, IP tos=0xC0, IP proto=2


# tcpdump -e -i eno1 igmp

09:53:23.914825 22:5f:0b:cb:ac:42 (oui Unknown) > 01:00:5e:00:00:16 (oui Unknown), ethertype IPv4 (0x0800), length 54: 0.0.0.0 > igmp.mcast.net: igmp v3 report, 1 group record(s)
^C

( 22:5f:0b:cb:ac:42 is the mac of the fwbr bridge or fwpr)


I don't know yet why this igmp report v3 is send. (linux bridge have report v3 by default, also tested with enable/disable snooping, and I don't see any igmp query coming...)
 
can you try:

echo 0 > /proc/sys/net/ipv4/igmp_link_local_mcast_reports

?

it's fixing the igmp packets send on ct stop/start for me
Thanks, I will try it soon.

At the moment:
Code:
# cat /proc/sys/net/ipv4/igmp_link_local_mcast_reports
1

I also have IPv6 enabled, here the /etc/network/interfaces (xxx.xxx -> Public IPs) (yyy.yyy -> Internal (local) IPv4)
Code:
# interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address xxx.xxx.xxx.xxy/32
# --- BEGIN PVE ---
    post-up ip route add xxx.xxx.xxx.xxx dev eth0
    post-up ip route add default via xxx.xxx.xxx.xxx dev eth0
    pre-down ip route del default via xxx.xxx.xxx.xxx dev eth0
    pre-down ip route del xxx.xxx.xxx.xxx dev eth0
# --- END PVE ---

iface eth0 inet6 static
    address xxxx:xxxx:xxxx:xxxx::y/64
    gateway xxxx:xxxx:xxxx:xxxx::x

auto net1
iface net1 inet static
    address yyy.yyy.yyy.yy/24
 
ebtables -I OUTPUT -o <phyiscal intertace> --among-src ! <mac1,mac2,mac3....> --log-level info --log-prefix "MAC-FLOOD-O" --log-ip -j CONTINUE ebtables -I FORWARD -o <physical interface> --among-src ! <mac1,mac2,mac3....> --log-level info --log-prefix "MAC-FLOOD-F" --log-ip -j CONTINUE
I have rebooted the server two times and at the moment, no abuse messages..
 
ebtables -I OUTPUT -o <phyiscal intertace> --among-src ! <mac1,mac2,mac3....> --log-level info --log-prefix "MAC-FLOOD-O" --log-ip -j CONTINUE ebtables -I FORWARD -o <physical interface> --among-src ! <mac1,mac2,mac3....> --log-level info --log-prefix "MAC-FLOOD-F" --log-ip -j CONTINUE
Problem unsolved.
The support report me that is still answering to unallowed mac address.

Bye bye server.
good lucks ;)
 
Last edited:
Problem unsolved.
The support report me that is still answering to unallowed mac address.

Bye bye server.
good lucks ;)
I have rebooted the server two times and at the moment, no abuse messages..
the ebtables don't block nothing, it's only log to /var/log/messages, it could be great if you can look if you have some of them and send it.


also, do you have tried "echo 0 > /proc/sys/net/ipv4/igmp_link_local_mcast_reports " ? Because If 100% sure that it send packets with bridge mac address on vm/ct start.

to get it persistent at reboot, you can also set it in /etc/sysctl.d/pve.conf with
"net.ipv4.igmp_link_local_mcast_reports = 0"
 
Last edited:
the ebtables don't block nothing, it's only log to /var/log/messages, it could be great if you can look if you have some of them and send it.
i mean

ebtables -I FORWARD -o enp2s0 -p IPv4 --among-src ! 00:50:56:15:14:e5,d4:3d:7e:da:f0:03 --log-level info --log-prefix "MAC-FLOOD-F" --log-ip -j DROP
 
i mean

ebtables -I FORWARD -o enp2s0 -p IPv4 --among-src ! 00:50:56:15:14:e5,d4:3d:7e:da:f0:03 --log-level info --log-prefix "MAC-FLOOD-F" --log-ip -j DROP
you need to remove "-p IPv4", or it's not blocking ipv6 or other layer2 protocol like arp,...

Then, please send log from /var/log/messages
 
Last edited:
Do you use the 7 or the 6?
I'm testing with 7 curently (but ebtables rules are the same)

it doesn't work anyway.
without the ""-p IPv4" ?

Code:
ebtables -I FORWARD -o enp2s0 --among-src ! 00:50:56:15:14:e5,d4:3d:7e:da:f0:03 --log-level info --log-prefix "MAC-FLOOD-F" --log-ip -j DROP


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

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!