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)
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 ?
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.
Very interesting...I have seen some other complaints similar to this over the past few days. Can you send me (email@example.com) the output from a 'sh tech' as well as several minutes worth of *complete* syslog (debug level) showing one of the denied connections?
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.
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 ?
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.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in HA
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationCo...
I am currently unable to specify "crypto keyring" command when configuring VPN connection on my cisco 2901 router.
The following licenses have been activated on my router :