Date: Sat, 1 Apr 2006 09:29:44 +0100 From: "Greg Hennessy" <Greg.Hennessy@nviz.net> To: "'Christopher McGee'" <chris@xecu.net> Cc: freebsd-pf@freebsd.org Subject: RE: Traffic mysteriously dropping Message-ID: <000001c65566$6e3bb630$0a00a8c0@thebeast> In-Reply-To: <442DBD5E.3090905@xecu.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> There are only 3 or 4 rules in the ruleset that are > non-stateful. I can try to eliminate those also. That would be sensible. > All rules that are block are also using log. A lot of the > pass rules do not because it generates such enormous logs. I > can try enable logging on every rule temporarily in order to > troubleshoot this if necessary. I would, you need to see what exactly is matching a flow. > > > > > Yes, if I tcpdump on em0, pflog0, and em1 simultaneously > during a traffic test, the traffic hits em0, and never shows > up as blocked in pflog0 and never shows up at all on em1. As > I stated, it's only 1 out of a bunch of connections, so there > is no rule blocking all the traffic. Hmmm, are you using route-to or such like in the policy ? If its not going out the interface you expect, it may be going out through another. Time to tcpdump on everything including localhost to be sure. Silly question, is Jumbo frames enabled on one of the end points or are you running stock sized ethernet framing everywhere ? Has the firewall ever does transparent web caching ? Does the traffic route successfully if you disable pf with pfctl -d ? That should quickly determine if it's a routing or a firewall issue. > >Using interface groups without directionality, means that a > single rule > >will match the flow on both the ingress and egress interfaces. > > > >Combined with antispoof, it makes for simpler policy > > > > > > > I have coded the rule as explained above and even as the > first rule after the default block rule, it still drops > traffic. If I change it to non-stateful, it doesn't drop the > connections. I can't seem to get away from the thought of a > state mis-match, however, I don't know why it would > consistently do it on these http connections. Hmmm, possibly something strange with the stack on the endpoints. Are you using scrub in the policy ? > >What other blocks are in the policy ? > > > > > > > I don't believe I'm doing any specifc blocks. Just the > default block and then allow what we need after that. Time to do a quick grep to be completely sure, it's easy to miss one by just reading through a policy that large. > >It doesn't. Tagging works per stateful flow, not per packet. Using > >tagging will permit you to significantly reduce the size of > the rulebase. > > > > > > > The ruleset will be getting a significant rewrite, however, > time has not permitted it yet. > I know that feeling LOL. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000001c65566$6e3bb630$0a00a8c0>