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

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



Trevor Talbot wrote:
> Apologies for not reading everything you've posted, but this thread may 
> provide the clue you're looking for:
> http://www.benzedrine.cx/pf/msg03238.html
That thread is, without the extensive quoting of rules and dump logs, approximately word-for-word what I've been doing.  :-)
No, it wasn't headers out of synch for me.  This happened in stock 3.5, stock 3.6, and -current as of last week.  Many people have been of great help, including one Camiel Dobbelaar, whose patch to if_bridge.c (for a VLAN-related, but similar, issue) I found on the web, and modified.  I solved about half of the problem, and found that it was good enough for me.
That bridge tagging doesn't work, I figured out the hard way.  :-)
Essentially, as I understand it: when bridge_input() receives a unicast frame, it searches the list of bridge interfaces for the interface with matching ethernet address from the frame.  In my case, I'm running a SS20 with le* interfaces, which means that all interfaces use the same ethernet address.  Since le2 was added to the bridge last, ALL inbound traffic showed up in PF rules as coming in on le2.  The patch I made checks first to see if the destination address is the same as the interface passed to bridge_input(), it disables rewriting m_pkthdr.rcvif.  Viola!  All traffic across the bridge still functions properly, but frames destined FOR the bridgewill now match the appropriate "in on le*" rule.
Still, all of my outbound traffic originating from the OBSD box shows up as out on le0 (the interface with the IP).  I figure that since le2 has no IP address, it CAN'T be a route.
(Also, I didn't patch the broadcast/multicast frame section in bridge_input, so those still might show up in PF as being in on the wrong interface.  ARP being broadcast, and arriving first, this might have something to do with the weird outbound route, though, according to the problems I was having with INbound unicast, it should see those all on le2, which wouldn't explan an outbound route of le0.)
However, I'm not too concerned about this.  (1) The reason I'm using a bridge in the first place, and not separate subnets, is to PASS broad/multicast packets.  (2) If I can block IN on all interfaces separately, the only reason I'd have to block OUT on all interfaces separately is if I did not trust traffic from the OBSD box.  The only reason I can think for not trusting that would be a compromised server, and at that point, PF rules are useless.
For the patch, see: http://www.sigmasoft.com/~openbsd/archive/openbsd-misc/200502/msg01916.html
Use at your own risk.  I have no idea if this will break countless other things.  FWIW, it doesn't seem to have broken anything else that I happen to be using.
> Assuming I understand everything correctly, you won't have this problem 
> in a pure bridging scenario -- where the IP destination or gateway is 
> not this machine.
The problem would still be there, you'd just never see it, because you wouldn't be looking for it, as there would be no way to send frames TO the bridge machine.  :-)  The only reason I  (and Torsten) have this problem is because we want the bridge machine to be directly addressable.
Also, FWIW, I've been informed by certain parties that "it's a bridge;" this is "100% normal."  I don't care.  I don't like it; I changed it; and I'm happy.  Hooray for open source.  I, too, think it's brain-dead that the [stock] bridge interface makes it impossible to tell where an inbound frame came in on.  As both Torsten and I have said, the physical interface of incidence is the only property of a frame that is 100% unspoofable.  If that inability qualifies the BSD bridge as an "ugly hack," then I agree with you.
JMF