comp.security.firewalls archive
Re: Deny TCP (no connection) flags RST on inside intf ? PIX 6.3.5
Date: Fri Apr 14 2006 - 19:08:19 CEST
In article <1145033606.604157.220140@t31g2000cwb.googlegroups.com>,
nick <nleachman@gmail.com> wrote:
>I have recently moved from a "managed" firewall to a pix running 6.3.5;
PIX questions are better addressed to comp.dcom.sys.cisco -- there
are more PIX people there.
>and in the syslogs I'm seeing enough of the following messages that I'm
>concerned that I have a timeout, etc. misconfigured on the pix.
>08:01:53 Local4.Info 10.0.0.5 Apr 14 2006 12:01:36: %PIX-6-302013:
>Built outbound TCP connection 17848999 for outside:204.54.192.17/80
>(204.54.192.17/80) to inside:192.168.11.8/2732 (68.43.34.22/17302)
Normal message.
>08:01:53 Local4.Info 10.0.0.5 Apr 14 2006 12:01:36: %PIX-6-302014:
>Teardown TCP connection 17848999 for outside:204.54.192.17/80 to
>inside:192.168.11.8/2732 duration 0:00:01 bytes 294 TCP FINs
Normal message.
>
>08:01:53 Local4.Info 10.0.0.5 Apr 14 2006 12:01:36: %PIX-6-106015:
>Deny TCP (no connection) from 192.168.11.8/2732 to 204.54.192.17/80
>flags RST ACK on interface inside
>08:01:53 Local4.Info 10.0.0.5 Apr 14 2006 12:01:36: %PIX-6-106015:
>Deny TCP (no connection) from 192.168.11.8/2732 to 204.54.192.17/80
>flags RST on interface inside
>I would expect these more on the outside intf where the pix shuts down
>a connection more quickly than the web server can react; but I don't
>understand them on the inside.
The same thing can happen: the outside host can shut down the connection
faster than the inside reacts.
The problem started in PIX 6.2(2) or so: the PIX no longer holds on
to connection information for a few seconds to check for trailing packets
from a connection winding down.
Notice that the first of the messages was RST ACK: that implies that
the other end sent a RST. The PIX closed the connection then, and
the RST ACK sent by the inside host is being logged. Then the inside
host closes the connection from its end, generating a RST of its own.
You might be able to play with the "timeout" parameters, but I don't
think it will help.
Received on Mon May 1 01:07:07 2006