Traffic mysteriously dropping

[Greg Hennessy]

> 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