Bug 250394

Summary: After creating an ethernet bridge the host responds to incoming packets not addressed to itself
Product: Base System Reporter: be
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed Works As Intended    
Severity: Affects Some People    
Priority: ---    
Version: 12.1-RELEASE   
Hardware: amd64   
OS: Any   

Description be 2020-10-16 11:55:47 UTC
Preface: the host where this issue was detected is connected to a buggy switch.
The switch sends unicast packets addressed to foreign MACs to this host.

As soon as a bridge is created with the host's uplink interface as a member, the host responds to packets addressed to foreign MAC/IP address combinations.

In this example 0c:c4:7a:9a:9a:ac is a foreign MAC address and is a foreign IP address while 70:85:c2:39:08:19 and are local to the host. tcpdump output:

12:07:49.256533 00:24:dc:41:9f:c0 > 0c:c4:7a:9a:9a:ac, ethertype IPv4 (0x0800), length 74: > UDP, length 32

12:07:49.256612 70:85:c2:39:08:19 > 00:24:dc:41:9f:c0, ethertype IPv4 (0x0800), length 102: > ICMP udp port 33452 unreachable, length 68

On the other hand as soon as the bridge is detroyed, the host stops responding to foreign packets. It also does not respond to foreign packets without the bridge but with enabled promisc. mode on the uplink interface.

This is the interface configuration while showing the weird behaviour:

# ifconfig
        ether 70:85:c2:39:08:19
        inet netmask 0xffffff00 broadcast
        inet netmask 0xffffffff broadcast
        inet netmask 0xffffffff broadcast
        inet netmask 0xffffff00 broadcast
        inet netmask 0xffffffff broadcast
        inet netmask 0xffffffff broadcast
        inet netmask 0xffffffff broadcast
        inet6 fe80::7285:c2ff:fe39:819%re0 prefixlen 64 scopeid 0x1
        inet6 2a0a:51c0:0:2c::e prefixlen 64
        inet6 2a0a:51c0:0:2c::80 prefixlen 128
        inet6 2a0a:51c0:0:2c::53 prefixlen 128
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet netmask 0xff000000
        inet netmask 0xffffffff
        groups: lo
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33160
        groups: pflog
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: vmnet-discourse.nomadbsd.org-0-public
        ether 00:bd:c7:24:20:00
        groups: tap vm-port
        media: Ethernet autoselect
        status: active
        Opened by PID 39345
vm-public: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether d2:f1:1a:d8:37:b0
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: re0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 1 priority 128 path cost 20000
        groups: bridge vm-switch viid-4c918@
        nd6 options=1<PERFORMNUD>
Comment 1 be 2020-10-16 12:21:22 UTC
Update: I found that pf logged the incoming packet as blocked. With block-policy return this would explain the port unreachable ICMP message.