1. Home
  2. Networking Firewalls
  3. Deny TCP (no connection) flags RST on inside intf ? PIX 6.3.5

Deny TCP (no connection) flags RST on inside intf ? PIX 6.3.5

Hi,

I have recently moved from a "managed" firewall to a pix running 6.3.5; 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)

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

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.

There are usually several series of these log enties in a row - sometimes a up to 15, but often only 4 or 5. I have compared both the originating hosts and the destination hosts over several days and they're apparently random hosts browsing random internet servers - I can find no pattern except a large number of the above log entries.

The durations are always short for these session - and over a "series" of these entries the source port number (client browser) generally increments by one - but even this isn't constant.

This is the only route to the Internet for these hosts.

Can someone please help me understand these entries?

Many thanks, Nick

Reply to
nick
Loading thread data ...

PIX questions are better addressed to comp.dcom.sys.cisco -- there are more PIX people there.

Normal message.

Normal message.

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.

Reply to
Walter Roberson

Thank you Walter - and I appreciate your advice to use the comp.dcom.sys.cisco in the future.

Nick

Reply to
nick

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.