https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283380
Bug ID: 283380
Summary: accepts and processes IPv4 packets destined to
non-local MAC addresses instead of dropping them
Product: Base System
Version: 14.1-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: j...@osn.de
FreeBSD 14.1-RELEASE-p5 running on Proxmox VE 8.2 with Open vSwitch using vtnet
devices
the system accepts and forwards IP packets to non-local MAC addresses which can
be
seen on a tcpdump eg tcpdump -netttti vtnet2 host 146.185.xx.yy
the MAC address on our vtnet interface is bc:24:11:xx:yy:zz
fc:0a:81:xx:yy:zz and 48:f8:db:xx:yy:zz are both non-local/unknown MAC
addresses
2024-12-17 13:00:49.618676 fc:0a:81:xx:yy:zz > 48:f8:db:xx:yy:zz, ethertype
IPv4 (0x0800), length 79: 146.185.xx.yy.443 > 217.76.xx.yy.60299: Flags [P.],
seq 600:625, ack 636, win 126, length 25
2024-12-17 13:00:49.618687 bc:24:11:xx:yy:zz > 20:50:0f:xx:yy:zz, ethertype
IPv4 (0x0800), length 79: 146.185.xx.yy.443 > 217.76.xx.yy.60299: Flags [P.],
seq 600:625, ack 636, win 126, length 25
2024-12-17 13:00:49.618910 bc:24:11:xx:yy:zz > 20:50:0f:xx:yy:zz, ethertype
IPv4 (0x0800), length 79: 146.185.xx.yy.443 > 217.76.xx.yy.60299: Flags [P.],
seq 600:625, ack 636, win 126, length 25
2024-12-17 13:00:54.619698 fc:0a:81:xx:yy:zz > 48:f8:db:xx:yy:zz, ethertype
IPv4 (0x0800), length 79: 146.185.xx.yy.443 > 217.76.xx.yy.60299: Flags [P.],
seq 650:675, ack 687, win 126, length 25
2024-12-17 13:00:54.619715 bc:24:11:xx:yy:zz > 20:50:0f:xx:yy:zz, ethertype
IPv4 (0x0800), length 79: 146.185.xx.yy.443 > 217.76.xx.yy.60299: Flags [P.],
seq 650:675, ack 687, win 126, length 25
2024-12-17 13:00:54.619762 bc:24:11:xx:yy:zz > 20:50:0f:xx:yy:zz, ethertype
IPv4 (0x0800), length 79: 146.185.xx.yy.443 > 217.76.xx.yy.60299: Flags [P.],
seq 650:675, ack 687, win 126, length 25
The FreeBSD system "sees" a packet which is flooded on the network because of
the
unknown destination MAC address. The problem is that this packet is processed
and
forwarded by the kernel.
The MAC 20:50:0f:xx:yy:zz is the correct MAC address of the next hop. Which
means the
kernel does a route table lookup and forwards the packet to the "correct" next
hop which
causes duplicates on the receiving end.
Furthermore it looks like the kernel itself generates a duplicate of this
packet
and sent it twice.
I would expect that those packets are simple dropped by the kernel.
--
You are receiving this mail because:
You are the assignee for the bug.
