topic Re: PIX 7.0 blocking traffic without connection in Network Security

PIX 7.0 blocking traffic without connection

GW6 — Fri, 21 Feb 2020 08:31:21 GMT

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?

Re: PIX 7.0 blocking traffic without connection

r-lai — Tue, 15 Nov 2005 21:43:13 GMT

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.

Re: PIX 7.0 blocking traffic without connection

GW6 — Wed, 16 Nov 2005 04:16:01 GMT

I've got a TAC case going. If I find anything I'll post it here.

Re: PIX 7.0 blocking traffic without connection

brianwangrpm — Wed, 08 Feb 2006 15:09:27 GMT

Hi,

I got the same problem with you.Would you post the reply of TAC? Thanks !

Re: PIX 7.0 blocking traffic without connection

bahoosh — Wed, 08 Feb 2006 15:35:29 GMT

I do too .... I am going to keep an eye on this thread.

Re: PIX 7.0 blocking traffic without connection

igzhuhair — Wed, 08 Feb 2006 19:31:17 GMT

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

Re: PIX 7.0 blocking traffic without connection

bakerat2000 — Wed, 08 Feb 2006 20:40:11 GMT

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!

Re: PIX 7.0 blocking traffic without connection

bahoosh — Thu, 09 Feb 2006 02:26:49 GMT

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.

Re: PIX 7.0 blocking traffic without connection

thamdani — Thu, 09 Feb 2006 07:26:36 GMT

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

Re: PIX 7.0 blocking traffic without connection

aduerr — Fri, 10 Feb 2006 14:47:12 GMT

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.

Re: PIX 7.0 blocking traffic without connection

syip — Thu, 16 Feb 2006 17:28:04 GMT

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).