Hi all,
came across this explanation from Walter Roberson. I Also noticed this events in <7.x versions.
Regards,
Arne
(http://www.mcse.ms/message1301912.html):
When a new connection comes in, the PIX receives the SYN packet,
creates the appropriate translation entry, half-fills it, and
generates a SYN packet to go inward to the target host. If the target
host does not return a SYN ACK packet, then the PIX will remove the
entry from its tables after the "half-open" timeout period, leaving
it to the remote end to decide that the connection isn't going to
happen. When the PIX receives the SYN ACK packet from the target host,
it will finish populating it's internal tables, and generate
a SYN ACK to send to the originator. The originator is then to send
a SYN ACK back to complete the connection; at that point the PIX would
send a SYN ACK to the original target and mark the connection
as completely open. In all packets after that, the SYN flag would
not be present.
It is an error for a host to attempt to start a connection with
anything outer than a SYN flag: for example, it is an error for a
host to just suddenly send a PSH ACK towards a destination in hopes
that the destination will respond. If it were to do so, the message
the PIX would generate would be the one you indicate above. The
only thing the originating machine is allowed to send before it gets
the SYN ACK back from the PIX is to repeat the original SYN packet
[under the assumption that the packet was lost.]
In between the time that the PIX has sent back the SYN ACK and the time
the SYN ACK is sent back by the originator, it is legal for the
originator to send non SYN ACK packets [because it might have sent the
SYN ACK and the SYN ACK might have gotten lost on the way], but those
packets would be discarded.
[...]
What you are probably seeing is the result of something slightly
different than what I describe above. When a connection drops, because
of a FIN or a RST or because one end does not ACK repeated
retransmissions within a reasonable amount of time [e.g., because the
router was down so packets couldn't reach it], then the PIX will drop
the connection from its internal tables. Especially with newer PIX
versions, though, the PIX sometimes cleans up too quickly, not
"lingering" at all long in a state that indicates "this was a valid
connection but it is gone now." When the PIX cleans up like that, it
forgets all about having been in the middle of a conversation, and so
the natural retransissions of the other end, together with any packets
that were "in flight" at the time the connection dropped, are viewed
exactly as if the other end was trying to get packets through without
having gone through the proper SYN/SYN-ACK/SYN-ACK handshake.
With newer PIX versions, it is not uncommon to see log messages
similar to the one you indicate, complaining about FIN, FIN ACK,
or RST packets -- cases where the PIX was too aggressive in
getting rid of connections that it knew were finished. It happens
a fair bit with HTTP connections, in cases where both ends figure
out independantly that the conversation is at an end and so both
ends send FIN or RST packets. The device on the LAN side of the PIX is
usually much much closer than the remote device, so the PIX will
usually see the FIN or RST from LAN device first, cleans up its
tables, and then when the FIN or RST comes from the remote device,
the PIX doesn't realize that it was just talking to that device
and complains that the device is trying to send data without
having established a connection.
