Firewall Wizards mailing list archives

Re: TCP buffers in firewalls


From: Travis Low <tlow () mindq com>
Date: Fri, 12 Dec 1997 14:24:27 -0500

At 12:49 PM 12/10/97 -0500, Stout, William wrote:
[Checkpoint FW-1 on UltraSparc, Ultrasparc locks up on heavy traffic]

...new TCP connection requests
backed up in the firewall queue, and caused the firewall to hang...

...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.

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.

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?

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?

I could be wrong in any number of places, so go ahead and shoot me.  Or
better yet, correct me.

Travis



Current thread: