11-11-2005 09:32 AM - edited 02-21-2020 12:31 AM
I just upgraded to PIX 7.04 and am getting a ton of these errors:
%PIX-6-106015: Deny TCP (no connection) from 172.22.x.x/58478 to 172.22.x.x/44443 flags RST ACK on interface outside
Here is a session:
2005-11-11 08:58:01 Local1.Info 172.22.x.x Nov 11 2005 08:58:02: %PIX-6-609001: Built local-host outside:172.22.x.x
2005-11-11 08:58:01 Local1.Info 172.22.x.x Nov 11 2005 08:58:02: %PIX-6-106015: Deny TCP (no connection) from 172.22.x.x/58578 to 172.22.x.x/44443 flags RST ACK on interface outside
2005-11-11 08:58:01 Local1.Info 172.22.x.x Nov 11 2005 08:58:02: %PIX-6-609002: Teardown local-host outside:172.22.x.x duration 0:00:00
Basically a host from a DMZ is trying to come in to the LAN or a more secure DMZ and make a request from a server. the traffic is being blocked because of no session being established.
I should add that this same config works just fine on PIX 6.3. Anyone know what is causing this?
11-15-2005 01:43 PM
I have same problem with Pix ver 7.0.4. I am looking cisco TAC website for resolution. I see that interim release 70.4.1 is out.
11-15-2005 08:16 PM
I've got a TAC case going. If I find anything I'll post it here.
02-08-2006 07:09 AM
Hi,
I got the same problem with you.Would you post the reply of TAC? Thanks !
02-08-2006 07:35 AM
I do too .... I am going to keep an eye on this thread.
02-08-2006 11:31 AM
Picked the below note from one of the Cisco docs. Pls see if it helps.
"With PIX Version 6.3, only inside hosts with last octet addresses of 0 and 255 could initiate a connection to an outside interface. If a host connected to the outside interface tried to initiated a connection to an inside host with .0 or .255 in the last octet of their IP address, PIX Version 6.3 denied it.
With PIX Security appliance Version 7.0,connections from the outside hosts are not denied, if an access-list permits it."
-zhuhair
02-08-2006 12:40 PM
I am having the same problem with PIX 7.0(4). All of a sudden the configuration stopped working. It has been working fine since early Fall 2005.
I have a TAC case open.
Please let me know if you find anything.
Thanks!
02-08-2006 06:26 PM
OK ... just got an email from the TAC guy. he said
"timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02 timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00 timeout uauth 0:05:00 absolute
So the timeout for idle connections is 1 hour, the timeout for AAA connections is 5 minutes, that may be the issue, if you set them to be 0:00:00 then you won't have them to time out and this should solve your issue. The thing for this is that if there are lots of connections (idle) they're taking NAT translations and that could also be an issue. Please try setting them to 0 for testing purposes and let's see what happens. Please let me know your thoughts.
Kind regards.
"
to his credit on the pix that we dont have this issue timeout is set to 3 hours ... so i did this to see if it fixes it. Will let you know if it did anything.
02-08-2006 11:26 PM
Hi All,
%PIX-6-106015: Deny TCP (no connection) from 172.22.x.x/58478 to 172.22.x.x/44443 flags RST ACK on interface outside
The above syslog message means that a TCP packet that has no associated connection in the pix connection table was discarded.
Now if we look at the message we are getting the RST ACK for SYN.And connection is cleared/teardown from the connection table if
1)Proper closing of session [FIN]
2)Idle timeout elapses.
3)reset is received.
The reason for the no connection can be if both the host are trying to comunicate on different ports,as pix keeps the connection entry beased on IP/port no. used in initial SYN and if they differ then pix think that it is a different connetion and has no entry for that hence deny it.
Why is server/host sending the RST ?
Check if the port on which session was initiated is getting the reply back on same port.
Check whts the timeout vlaue ,I do not agree with what TAC has replied as i dont think it will take more than few mili sec to reply back and i dont think we can set timeout value in mili sec hence it should not timeout at least not for the initial TCP handshake.
Regards,
Tanveer
02-10-2006 06:47 AM
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.
02-16-2006 09:28 AM
I agree with the explanation of PIX closing the tcp connection too quickly. For that, I use the following sysopt command in PIX:
sysopt connection timewait
This will give another 15 sec or so before PIX really close the connection (for a really busy firewall with lots of connections and tight resource, don't use it).
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide