Re: Still no answer on my bridge question -- resolved
Russell Fulton [EMAIL PROTECTED] writes: Yet another illustration of the rule that one should post config files when asking questions. simply exposing your rule set to a fresh set of eyes sometimes has wonderful problem solving capability. seriously, the real risk of embarrasment along the lines of now what on g*d's green earth are you doing that for? is a lot less than you think. Posting your config along with your problem description is always good. Obfuscate if you have to. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ First, we kill all the spammers The Usenet Bard, Twice-forwarded tales
Re: Still no answer on my bridge question
[In a message on Thu, 07 Apr 2005 12:58:22 +1200, Russell Fulton wrote:] Hi, Earlier I posted a note here asking about the order of processing incoming packets on a bridge with pf. I would really like to know if there is something wrong with our set up or if this is expected behaviour. I am seeing packets being dropped by pf that should not traverse the bridge at all (i.e. packets between hosts that are on the same side of the bridge). After a little thought I came to the conclusion that this is quite plausible since the filtering is taking place on the interface closest to the affected hosts and the packets are hitting pf before they get to the bridging logic. What do you mean packets being dropped by pf that should not traverse the bridge at all? Some clarity would help here. Are you saying: (host 1, host 2) (int_1 OBSD Box int_2) - (other hosts) And that packes from host 1 to host 2 (and vice versa) are showing as being dropped on int_2? If so, outbound? By a block rule? Topology and a pf.conf file will get you more help. . . I want to know if this conclusion is correct or do I have a problem that should be investigated. BTW I have also spent some time looking for docs that describe exact order of processing of packets but could not find anything useful. Try the list archives. This came over the list on March 17: http://mniam.net/pf/pf.png Sean
Re: Still no answer on my bridge question
On Thu, 7 Apr 2005, Russell Fulton wrote: I am seeing packets being dropped by pf that should not traverse the bridge at all (i.e. packets between hosts that are on the same side of the bridge). After a little thought I came to the conclusion that this is quite plausible since the filtering is taking place on the interface closest to the affected hosts and the packets are hitting pf before they get to the bridging logic. No, bridging comes first. And yes, the packet _should_ be dropped when the destination interface (according to the bridgecache) is the same as the source interface of the packet.
RE: Still no answer on my bridge question
Hi Russell, When I was looking for more information regarding pf + altq I also ask for documents describing packets processing and I got the following links: http://www.redshift.com/~ray/network/packet.gif http://mniam.net/pf/pf.png Hope this helps, Benjamin Constant TI Automotive -Original Message- From: Russell Fulton [mailto:[EMAIL PROTECTED] Sent: jeudi 7 avril 2005 2:58 To: pf@benzedrine.cx Subject: Still no answer on my bridge question Hi, Earlier I posted a note here asking about the order of processing incoming packets on a bridge with pf. I would really like to know if there is something wrong with our set up or if this is expected behaviour. I am seeing packets being dropped by pf that should not traverse the bridge at all (i.e. packets between hosts that are on the same side of the bridge). After a little thought I came to the conclusion that this is quite plausible since the filtering is taking place on the interface closest to the affected hosts and the packets are hitting pf before they get to the bridging logic. I want to know if this conclusion is correct or do I have a problem that should be investigated. BTW I have also spent some time looking for docs that describe exact order of processing of packets but could not find anything useful. Russell. The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. This communication is from TI Automotive.
Re: Still no answer on my bridge question
Thanks Sean! On Wed, 2005-04-06 at 19:36 -0700, Sean Kamath wrote: [In a message on Thu, 07 Apr 2005 12:58:22 +1200, Russell Fulton wrote:] Hi, Earlier I posted a note here asking about the order of processing incoming packets on a bridge with pf. I would really like to know if there is something wrong with our set up or if this is expected behaviour. I am seeing packets being dropped by pf that should not traverse the bridge at all (i.e. packets between hosts that are on the same side of the bridge). After a little thought I came to the conclusion that this is quite plausible since the filtering is taking place on the interface closest to the affected hosts and the packets are hitting pf before they get to the bridging logic. What do you mean packets being dropped by pf that should not traverse the bridge at all? Some clarity would help here. the addresses of the packets being dropped are both on the same side of the bridge and therefore the packets should not traverse the bridge. host 1 host2 | | | | +-+-+ | | bridge | | + rest of network I am seeing packets between host1 and host2 being dropped on the bridge, filtering is taking place on the interface closest to host1 and host2. Russell smime.p7s Description: S/MIME cryptographic signature
Re: Still no answer on my bridge question -- resolved
On Thu, 2005-04-07 at 12:58 +1200, Russell Fulton wrote: I am seeing packets being dropped by pf that should not traverse the bridge at all (i.e. packets between hosts that are on the same side of the bridge). After a little thought I came to the conclusion that this is quite plausible since the filtering is taking place on the interface closest to the affected hosts and the packets are hitting pf before they get to the bridging logic. Thanks to those who clarified the way bridge and pf interact and to Camiel Dobbelaar who suggested some useful diagnostics in private email. I now know what is going on. A while ago we were having some issues with our two pf/bridges interacting with our cisco switches, the network folk got these partly resolved by turning learning off on the bridges, so now they are simply flooding everything back and forth -- which is exactly what I had observed. Sigh... Thanks again and apologies for bothering the list with something that should have been sorted out locally. Yet another illustration of the rule that one should post config files when asking questions. If I had done that I would have noticed that learning had been turned off and solved the problem then and there. Russell -- Russell Fulton, Information Security Officer, The University of Auckland New Zealand smime.p7s Description: S/MIME cryptographic signature
