understanding pf(4) 'in' interface with bridge(4)

Hi all,

I have a bridge(4) here in a small router, it has a couple of em(4) interfaces:

bridge0: flags=41<UP,RUNNING> mtu 1500
index 7 llprio 3
groups: bridge
priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
designated: id 00:00:00:00:00:00 priority 0
em2 flags=3<LEARNING,DISCOVER>
port 3 ifpriority 0 ifcost 0
em1 flags=3<LEARNING,DISCOVER>
port 2 ifpriority 0 ifcost 0
em0 flags=3<LEARNING,DISCOVER>
port 1 ifpriority 0 ifcost 0


em0 has a single IPv4 address, 192.168.0.1/16, this is the default gateway on this network:
em0: flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0d:xx:xx:xx:xx
description: Internal LAN
index 1 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet 192.168.0.1 netmask 0xffff0000 broadcast 192.168.255.255
inet6 fe80:
inet6 fc00: prefixlen 7
inet6 2a01: prefixlen 64 pltime 552833 vltime 552833

em2 has no IP address on the router, it's just a link to little rpi.
em2: flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0d:b9:51:ab:96
description: nvr.localdomain
index 3 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex,master,rxpause,txpause)
status: active
The rpi itself on this em2 link has an IPv4 address of 192.168.0.3/16, it's part of the internal LAN.

The other day I wanted to filter what the rpi (192.168.0.3, linked up on em2) wants to send to my wireguard link (configured on this router) so I cooked up a pf(4) line to match packets coming *in* on em2:
pass in on em2 proto tcp from 192.168.0.3 to (wg0:network) port $nvr_wg0_allow_ports
||| ||||||||||| |||||||||||
||| ||||||||||| ^^^^^^^^^^^ dst where the rpi is sending packets
||| ^^^^^^^^^^^ rpi's IPv4 address
^^^ interface where rpi is linked

To my surprise, it didn't work, because I had to use em0 as the "in" device:

pass in on em0 proto tcp from 192.168.0.3 to (wg0:network) port $nvr_wg0_allow_ports

Now I understand that ultimately the rpi at 192.168.0.3 uses its default gateway (192.168.0.1 and its MAC address after an arp lookup) as a destination for these packets, and that destination is in fact em0 on the router - and em0 and em2 is bridged together -, but isn't the first interface where this packet comes *in* actually em2?
Is this because of how bridge(4) works internally?


Thanks for any insight,
Daniel