cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
273
Views
0
Helpful
4
Replies

Possible xlate\conn problem with 6.3(3) ?

mnlatif
Level 3
Level 3

Hi,

We upgraded our PIX 515E from 6.2(2) to 6.3(3) and have started seeing this problem, where legitimate TCP flow packets are being denied by the Access-List.

e.g. consider the following conversation.

A host on inside interface initiated a connection to a machine in dmz interface but the return traffic from the DMZ machine was denied, however the ACL shouldn't even be considered in this case as an entry should already have been added to the xlate\conn table.

"Inside" host initiated connection to "DMZ"

+++++++++++

Sep 19 17:07:14 firewall %PIX-6-302013: Built outbound TCP connection 488010 for ftp:172.29.1.19/3000 (172.29.

1.19/3000) to inside:172.16.100.199/3276 (172.16.100.199/3276)

++++++++++++++

PIX denied the return traffic

++++++++++

Sep 19 17:07:14 firewall %PIX-4-106023: Deny tcp src ftp:172.29.1.19/3000 dst inside:

172.16.100.199/3276 by access-group "104"

Sep 19 17:07:14 firewall %PIX-4-106023: Deny tcp src ftp:172.29.1.19/3000 dst inside:

172.16.100.199/3276 by access-group "104"

Sep 19 17:07:14 firewall %PIX-4-106023: Deny tcp src ftp:172.29.1.19/3000 dst inside:

172.16.100.199/3276 by access-group "104

+++++++++++++++++++++++

I had attempted this connection from my PC. After this failed attempt, the next attempt was successful.

This problem has been intermittent since we have upgraded.

Our PIX Deny logs are usually around 8-9MB (atleast for the past month), but after the Upgrade, todays logs were around 13 MB and they were filled with all these "deny statements", which probably were legitimate connections.

I think that either PIX fails to add the first established connection in the xlate\conn table and doesn't find it when comparing for the return traffic ? OR sometimes intermittently it doesn't consider the xlate\conn table ?

The timeouts were unchanged from 6.2(2) and are

timeout xlate 1:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00

Has anyone else seen this problem ?

You probably won't notice it in the performance significantly but you can definitely tell from the logs.

4 Replies 4

jmia
Level 7
Level 7

Hi Naman,

I presume that you tried command 'clear xlate' and check if the problem comes back. Please check that the access-list and access-group are correct.

For your info, the pix error ID : %PIX-4-106023 is the following:

%PIX-4-106023: Deny protocol src [inbound-interface]:[src_address / src_port] dst outbound-interface:dst_address / dst_port [type {type}, code {code}] by access_group access-list-name

Explanation An IP packet was denied by the access-list.

Action Change permission of access-list if a permit policy is desired. If messages persist from the same source address, messages could indicate a foot printing or port scanning attempt. Contact the remote host administrator.

Thanks - Jay.

Hi Jay,

It has nothing to do with the Access-List. Traffic is going from Interface "inside" to Interface "ftp" and the Access List message that you are seeing is from access-list applied to interface "ftp".

Since the connection was initiated from INterface "inside" so the Access-List for interface "ftp" shouldn't be checked as that is "Return TCP Traffic".

And the Deny message comes up intermittently, all other times it works Ok.

I guess i will downgrade to 6.2(3), where exactly the same config was working Ok.

scoclayton
Level 7
Level 7

Very interesting...I have seen some other complaints similar to this over the past few days. Can you send me (sclayton@cisco.com) the output from a 'sh tech' as well as several minutes worth of *complete* syslog (debug level) showing one of the denied connections?

Scott

Ok.

I have done more testing today. After using "capture" in the PIX firewall later "ethereal" on both intefaces, it turns out that TCP connection are working fine. The "deny" statements in the log files are actually the ACK packets denied, which are in response to RST Packets.

So the packet sequence is

Host A(interface inside)<--->Host B(interface dmz)

SYN from A to B

SYN,ACK from B to A

ACK from A to B

<-->Data Exhangce

FIN,ACK from A to B

Data from B to A

Data from B to A

ACK from B to A

RST from A to B

ACK from B to A (Blocked, syslog deny message)

RST from A to B

ACK from B to A (Blocked, syslog deny message)

Actually the Host A in this question is a monitoring host that checks the HTTP service on Host B. As soon as it gets the first response back, it tries to FIN the connection. But Host B keeps on sending some data as you can see in the above sequence, so Host A tries to RST the connection but the ACKs (to RST) are blocked and it keeps on sending RST.

This behaviour was not present on 6.2(2), as we never had these entries in our log files.

I am not sure, if this is some security enhancement (how ?)? OR some bug ?

UDP Packets:

There are some problems with UDP packets also. I have done some testing on DNS packets, in which some legitimate DNS replies are blocked by PIX. Resulting in our Internal DNS Server having to resend these requests again to our DMZ-DNS server.

Since our DNS Server only uses one source port for making all these queries, so it was really difficult to figure out that which replies were blocked (as we noticed from the log entries). I did the sniffer test again at both ends to compare the packet flow art both interfaces.

I am sending you the Traces as you requested.

\\ Naman

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: