PF, bridge, states and window scaling problem

[Erik Osterholm]

On Tue, Nov 13, 2007 at 03:53:38PM +0200, Alupului Costin wrote:
> On Nov 13, 2007 4:20 AM, Girish Venkatachalam
> <girishvenkatachalam at gmail.com> wrote:
> > On 22:08:03 Nov 12, Alupului Costin wrote:
> > >
> > > pass in quick on vlan0 from any to anIP/32
> > > pass out quick on vlan0 from anIP/32 to any keep state queue ul_client
> > > pass in quick on vlan1 from anIP/32 to any
> > > pass out quick on vlan1 from any to anIP/32 keep state queue dl_client
> > >
> > > The above rules generate state-mismatches.
> >
> > Didn't get you. What sort of mismatch?
> 
> When that client tries logging in to Yahoo Messenger I can see an
> increase in the number of state-mismatch reported by pfctl -si. There
> are states established, but after a while the packets simply do not
> match the states created. Also they will not create new states and nor
> will they match a catch-all rule which follows.

I wonder why it's not creating new states.  Could you be running out
of kernel memory?  Are they actual syn packets?  


> I will answer here to Erik Osterholm also:
> 
> Performance really is an issue here when I give up statefull
> inspection. The firewall contains roughly 2000 filter rules and the
> traffic passing through is 20kpps at peak hours. So it is a huge
> difference between statefull and stateless filtering. If I drop the
> stafefull filtering the machine simply cannot handle all the traffic,
> or in the best case scenario it develops quite some latency.

I didn't mean to imply that performance wasn't an issue on your part,
just mentioning it on ours.  I know that keeping state is probably
ideal in general, but depending upon your ruleset, it may be possible
to optimize it so that keeping state isn't required for performance.
For example, if you have many rules which are identical except for the
host, you can use a table to keep track of the hosts and then only a
few rules.  This can speed things up dramatically.  (Sorry if I'm
telling you things that you already know--I'm not familiar with your
level of expertise.)

Erik