TCP buffers in firewalls

["Stout, William" <StoutW () pios com>]

I had a situation where a firewall locked up repeatedly during high
traffic periods and required hard reboots.  The firewall was a
Checkpoint FW-1 on an UltraSparc where the Internet feed was a 10Mb
Ethernet link.  The machine behind that was an Alphaserver serving
banner ads.  This was a operational failure, not an attack.

Apparently there were periods where requests overwhelmed the .gif
database, the Db was not fast enough to serve and release the TCP
sessions.  Since current connections were not being released by the
webserver because of the database delay, new TCP connection requests
backed up in the firewall queue, and caused the firewall to hang.  A
simple fix would've been to break the session connection somewhere by
making it UDP, but the HTTP portion is TCP only.  A caching proxy might
have helped to some (unknown) degree also, vs. packet filtering which
cannot cache.

I don't have detailed information about the firewall config since the
user controlled the firewall configuration closely, and Checkpoint
performed the installation.  In the end, Checkpoint's technical support
said the firewall and webserver application were not compatible.

Question:
Would a high volume of current TCP sessions and a high volume of
unserved TCP requests affect state-based packet filters and proxy
services differently?  If a webserver behind a firewall was able to hold
a greater number of sessions than the firewall, I would think this is a
TCP stack issue, not an issue with the way a proxy handles sessions vs.
a filter.  I'm still not sure if a finger should be pointed at a slow
database for locking up the firewall, or at the firewall for locking up
because of unreleased/unserved TCP sessions.

Bill Stout