Stephan Mending on Wed, May 27 2020:
>> [bridge0 with members athn0 em0 vether0, all in group lan]
>>
>> # ifconfig athn0 -group lan
> Did you flush states between your tests (pfctl -F states) ? -> After
> you removed athn0 from lan group ?
Yes, I did.
>> [sys/net/if_bridge.c: bridge_process()]
>>
>> a packet that comes in on a member of a bridge and is addressed to _any_
>> bridge member interface, is processed as input to (only) the destination
>> interface. if that destination interface differs from the one that the
>> packet actually came in on, pf rules for the actual input interface are
>> not evaluated.
Note that the responsible code at the end of the function will set "ifp"
to the interface that the packet arrived on and branch to
reenqueue:
bridge_ifinput(ifp, m);
So if I'm reading this right, the idea is to reevaluate a packet that
arrives on one interface for the address of another as having come in on
the latter, and I'm guessing pf processing happens only after that.
Correct me if I'm wrong: My expectation was that a packet that comes
in on bridge member athn0 has to pass the "in" rules for athn0,
regardless of destination. What I'm unsure about is how/if any rules for
the destination member should apply. Should a packet coming in on athn0
but destined for the address of vether0 have to pass "in" rules for both
athn0 and vether0?
Regards,
pesco
