[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PF, Bridge, and IP on bridged interface [more]



On Wed, Feb 16, 2005 at 10:51:48PM -0500, Jim Fron wrote:
> Okay, I can get my bridge and pf rules working if I need to, but
> I'd still like to understand WHY they work they way they do.  So
> I ran some test cases.
> 1b. bridge (4), and all of the literature I can find online says
> 	that frames on the bridge will pass through pf twice.
> 	"Bridged frames pass through pf(4) twice.  They can be filtered
> 	on any interface, in both directions."
> 
> -> They do not appear to do so.  They appear to pass through pf only 
> once.
> 	That is, they pass in once and out once, exactly as they do when
> 	routing between two Subnets in an unbridged configuration.  Why?
> 	Is the documentation wrong?  Are there frames that are not showing
> 	up in my pflog, despite all rules being log-all?  For this
> 	"dual pass" through pf, does it only make a second pass if it
> 	has not found a destination?  When running these tests, I first
> 	did a `brconfig bridge0 flushall` in the hopes of eliminating such
> 	a scenario.
That sentence is meant to explain exactly that there's no difference
between bridging and IP forwarding regarding pf, that pf sees the same
packet twice, once incoming on an interface, once outgoing on another
interface, that's twice.
The reason why it's mentioned is that some OS / packet filter
combinations don't work this way. For instance, on older OpenBSD releases
IPFilter (in bridged setups) would only see packets coming in on the
first interface (but not again outgoing on the other), so people learned
to write their rulesets with this in mind, and only filtered incoming. If
you assumed pf wouldn't filter packets outgoing (again), and used a
default block policy, the pf bridge possibly wouldn't work. That's what this
sentence in the documentation is supposed to make clear.
> 2b. traffic from the LAN to the router appears to come from the
> 	wrong interface
I don't know why you're seeing this. You might have some cabling problem
that explains why packets pass in on the wrong interface.
I have a similar setup for my wireless access point running pf, one
sis(4) interface to the LAN with an IP address assigned, and one wi(4)
interface without an address. I can ping through the bridge from either
side, or ping from and to the bridge itself to/from either side, and
only see packets on the expected interfaces. It doesn't matter at all
which interface I assign the address to.
You might want to run tcpdump -nvvvei <if> on the two interfaces
directly and check the MAC addresses printed. pf will see the same
frames on the same interfaces as you see with tcpdump on the interfaces.
If a frame really comes in on the wrong interfaces, and tcpdump shows
that, you can be pretty sure that, for whatever reason, the frame really
did arrive on that interface. The explanation must be found somewhere in
your network or cabling.
As for outgoing packets from the bridge itself, they should pass out
through the appropriate interface in both cases, assuming the bridge has
learned that the destination MAC address is reachable through a
particular interface. When you first ping an unknown destination, the
stack will do an ARP lookup to find the destination MAC address for the
IP address. When the peer replies ARP, the bridge learns which interface
that MAC address is reachable through, so the first ICMP echo request
will already pass out through the appropriate interface only.
In short, things should be pretty similiar to IP forwarding. Note that
'log-all' is only meaningful when you create state (otherwise 'log' is
sufficient, as each packet causes evaluation of the ruleset). If you do
create state, all packets related to one state get logged with the rule
number that created the state. Subsequent packets might not be passing
through the same interface as the first packet (if not using if-bound
states). Running tcpdump on the real interface might clear things up.
Daniel