Date: Fri, 31 Mar 2006 16:56:17 +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: <000001c654db$a5203440$0a00a8c0@thebeast> In-Reply-To: <442D48F3.2020307@xecu.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 2 of the nics are onboard, however the quad-port intel card > is PCI-X. In a PCI-X/100 or 133 slot ? > This is a 3.0Ghz pentium 4. Should be adequate. > > > > > The first rule is block log all. I put the http rules right > after that rule, or I lose connections. I would suggest minimising the amount of non stateful rules in the policy. They have a habit of biting one in the rear. > The packets are not being logged as > blocked. A block further down the policy without a 'log' may cause this. One of the joys of debugging a last match policy. > The just never show up on the internal nic. I take it you've simultaneously tcpdumped both ingress and egress interfaces to confirm this ? Packets disappearing during traversal implies a routing issue. > I can make this a bi-direction rule instead of keep state That's inefficient as each packet forces a rule base traversal. Try coding a tcp flow as pass log quick on em inet proto tcp from source to dest port something keep state flags S/SA I said 'em' above, not em[0-9]. 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 > and it still drops traffic if I > move it down in the list. If I leave it where it is, and > make it a keep state rule, it drops the connections also. What other blocks are in the policy ? > > > Is there a link to this information, or has it recently been added to > the documentation? I would like to read the reasoning behind this. It's worth reading the openbsd-pf mailing list on benzedrine.cx and openbsd newsgroups. > At peak times, the state table grows as large as 17000 states > or so. If that's the case, the default table size is inadequate, I would set it to at least 25000. > Generic egress rules are a little difficult because I'm trying to do > traffic shaping of certain traffic. Get the policy working without drops 1st, then shape. > A side note, the machine is not doing any NAT. Tagging seems like it would require more > overhead than what the firewall is doing already. It doesn't. Tagging works per stateful flow, not per packet. Using tagging will permit you to significantly reduce the size of the rulebase. > I'm no developer, so I don't know the code involved, so I could definitely > be wrong about this. Since more manageable rulesets were brought up, does the optimizer > really do anything, or is that just asking for trouble? I don't use it, any pf policies I create are coded in a first match style using 'quick'. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000001c654db$a5203440$0a00a8c0>