Proxmox claiming MAC address
- Thread starter tmsg
- Start date
-
- Tags
- networking openvswitch ovs
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
?
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'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 CONTINUEwhere <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.
@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
( 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...)
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
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
1I 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/24Problem 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
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:
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:
I'm testing with 7 curently (but ebtables rules are the same)
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 DROPso you have tried "net.ipv4.igmp_link_local_mcast_reports = 0" as I have asked before ?
@spirit for me ) on different hosts. No new Abuse Message.
net.ipv4.igmp_link_local_mcast_reports = 0 in combination of the Hetzner Robot Firewall it looks good, I tried to restart CTs (and also update from 10.5 to 10.10 ) on different hosts. No new Abuse Message.you need to ask to the support for manual verification, otherwise it can happen randomly ...