×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Possible xlate\conn problem with 6.3(3) ?

Unanswered Question
Sep 19th, 2003
User Badges:

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.

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.

mnlatif Sat, 09/20/2003 - 09:21
User Badges:

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.

mnlatif Mon, 09/22/2003 - 15:15
User Badges:

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


Actions

This Discussion