I think an interesting example that people are fishing for below is any ethernet broadcast packet going through an openbsd bridge, one packet goes out many (all) interfaces.
Of course, which do you allow the reply from? Even worse is when you have: client->(bridge0)->router->(bridge1)->server Now a packet can not only get replies from any interface in bridge0, but can generate state *twice*, once per bridge. ATM this doesn't work - bridge1 packets are dropped as dups. So if PF needs to understand what i/f a reply can come from, it that needs to also tag the state with the right bridge info. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexey E. Suslikov Sent: Tuesday, August 05, 2003 8:27 AM To: Daniel Hartmeier Cc: [EMAIL PROTECTED] Subject: Re[2]: pf and altq couple: before and after merge Tuesday, August 5, 2003, 12:36:02 AM, Daniel Hartmeier wrote: > On Mon, Aug 04, 2003 at 11:35:13PM +0300, Alexey E. Suslikov wrote: >> keepstated connection's packets silently pass all interfaces and all >> directions, so we just can't REASSEMBLE the queue to take control >> over them. the only controllable option is the connection's state. >> but there are TOO MANY packets matching this STATE and they are >> DIFFERENT. > Given that there is no working multipath routing in OpenBSD, all > packets of one forwarded connection usually enter through one > interface and leave through one other interface. At least in my simple > corner of the world :) hmmm... you can dup-to them to multiple destinations. > If you want, you can create state on both interfaces, there's nothing > wrong or obscure about that. A forwarded packet will match one of the > states on the incoming interface and the other on the outgoing. You > can queue to two different queues (one for each interface) with those > two states. yes, i already heard previously: "it is possible to have multiple states for the same connection". but this mechanics needed to be explained. this is your "Prioritizing empty TCP ACKs with pf and ALTQ" example: ext_if="kue0" altq on $ext_if priq bandwidth 100Kb queue { q_pri, q_def } queue q_pri priority 7 queue q_def priority 1 priq(default) pass out on $ext_if proto tcp from $ext_if to any flags S/SA \ keep state queue (q_def, q_pri) # 01 pass in on $ext_if proto tcp from any to $ext_if flags S/SA \ keep state queue (q_def, q_pri) # 02 "Both incoming and outgoing TCP connections will pass by those two rules, create state, and all packets related to the connections will be assigned to either the q_def or q_pri queues. Packets assigned to the q_pri queue will have priority and will get sent before any pending packets in the q_def queue". this is your statement. assume we have incoming packet matching rule 02. after this we will have "keepstated by the rule 02" connection which will not match any rules lately, because it will silenty pass as of keepstated nature. this is my statement. but this is wrong statement as i know what "it is possible to have multiple states for the same connection". i just want to remove this contradiction. please, explain. > ALTQ doesn't queue incoming packets (they are processed immediately, > as they arrive), so you can only queue outgoing packets on those two > interfaces (that was true before the pf/altq merge, too). just for example: incoming packet on some ext0 and outgoing on some int0 - the same packet. you can't queue it on the ext0, but can on the int0. > You could split your packet filter and ALTQ setup into two separate > machines, the first one doing the packet filtering statefully, the > second one using pf completely statelessly just to do the ALTQ > classification. It would be forced to create states and assign all see PREFACE in my original post: there are no questions about stateless. > Maybe (very likely, even) I'm just doing simple and naive > classifications, can you give an example of setup that you wanted to > do but would require splitting the stateful filtering and > classification? Something with a real and common use, not some > far-fetched theoretical example?
