RE: TCP buffers in firewalls

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

> ----- Original Message -----
> From: Travis Low [SMTP:tlow () mindq com]
<snip>
> > ...In the end, Checkpoint's technical support
> > said the firewall and webserver application were not compatible.
>
> Did they give a more specific reason?  What is the exact FW-1 feature that
> breaks?  What line of code causes the crash?  "not compatible" isn't a
> reason, it's an excuse.

I worked with this company AFA the hardware design of the webserver
(SMP/RAM/RAID/Physical database layout) but they chose to handle all
firewall issues with a direct relationship with Checkpoint.  ;)
 
Fortunately for me, the database is fast enough, however the application
written in-house is the actual bottleneck.

> Could you replace the database with something faster that just pumps out
> garbage data?  Then you could see if the database slowness is really the
> problem.

I pointed them to Hobbit's Netcat and Cinco (Network General) NetXray to
pump data, they're now testing their application, again they've removed
the firewall and now use extended packet filtering.

> > 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?  
>
> I dunno, but let me expand on your question.  What are the most likely
> performance bottlenecks in each architecture?  How does each react to (1)
> lots of TCP connection requests? (2) lots of TCP traffic? (3) normal TCP
> traffic with lots of other IP (say UDP) traffic?  (4) anything else you
> could think of?

Good questions.  ;)

I'm sure someone tested this stuff before.  Right?

> > 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.
>
> Since I'm not a firewall wizard, I went to Checkpoint's site to read about
> state-based packet filtering.  From what I read, FW-1 either drops packets
> or forwards them.  It may queue them before forwarding them.  There are
> therefore no TCP connections to the firewall itself, and I would conclude
> that the firewall is choking because of some boundary condition related to
> maintaining state information for each queued TCP request.  Out of memory,
> maybe?  Stuck in a loop waiting for memory?

That's what I'm beginning to think.  Tracking session state may reduce
capacity in 'the stack' to less than a service behind it.  A proxy acts
more like the webserver itself, and should have the same capabilities.
The amount of memory allocated to track state could be huge for a high
number of sessions, which leads me to believe that other state-based
routers (PIX, hardcoded FW-1) are even more vulnerable to session
overloads simply because of memory restrictions and no swap disk.

I used to have a lab where I could test this stuff, wish I still had the
resources.  My contribution to this thread is limited to questions and
theory.

Bill Stout