Re: False Reporting Deny's on PIX 6.1.2

rhanly · ‎07-22-2002

Why am I seeing this 3 "Deny"s considering that :

a) The pix should store the state

b) The src/dest should kill the session (1st and 3rd Deny) not the

firewall - unless the state has obviously timed out, which in this case

you

can see with the timestamp, is well within the state timeout

Have a look at this log. How do I cut this down or resolve this.

Jul 17 08:43:02 pix-fw Jul 17 2002 08:45:48: %PIX-6-302001: Built

inbound

TCP connection 1343142 for faddr 5.6.7.8/39570 gaddr 1.2.3.4/25 laddr

1.2.3.4/25

Jul 17 08:43:05 pix-fw Jul 17 2002 08:45:52: %PIX-6-302002: Teardown TCP

connection 1343142 faddr 5.6.7.8/39570 gaddr 1.2.3.4/25 laddr 1.2.3.4/25

duration 0:00:03 bytes 89970 (TCP Reset-O)

Jul 17 08:43:05 pix-fw Jul 17 2002 08:45:52: %PIX-6-106015: Deny TCP (no

connection) from 5.6.7.8/39570 to 1.2.3.4/25 flags RST on interface

outside

Jul 17 08:43:05 pix-fw Jul 17 2002 08:45:52: %PIX-6-106015: Deny TCP (no

connection) from 5.6.7.8/39570 to 1.2.3.4/25 flags RST on interface

outside

Jul 17 08:43:06 pix-fw Jul 17 2002 08:45:53: %PIX-6-106015: Deny TCP (no

connection) from 1.2.3.4/25 to 5.6.7.8/39570 flags FIN PSH ACK on

interface inside

Even though I get these denies, the session is still running.

gfullage · ‎07-22-2002

The first line here is telling you that the PIX has created a TCP connection.

4 seconds later (the second line), the PIX receives a TCP RST from 5.6.7.8 on the outside interface and so it tears down it's connection. It also passes this RST onto the internal host. You can see why the PIX has torn down the connection at the end of this line (TCP Reset-O), this means the PIX has seen an RST onthe outside interface.

Lines 3 and 4 show the outside host sending two more RST's, but because the PIX has already torn down the connection because of the first RST, the packets are dropped.

Line 5 shows the inside host sending a FIN, again this is dropped because the outside host has previously sent an RST and the connection has already ben dropped.

I seriously doubt this particular connection is still going since both hosts have closed it down. There is probably another TCP connection open between them that is still running. The deny's you're seeing are the outside host sending 3 RST's to tear the connection down, something that is not standard.