We are seeing large number of logged Deny messages for what seem to be the reverse outbound leg of incoming SSL connections.
In the logs we see continual Denys with source IP of an internal server and source port tcp/443.
The destination in each case is a legitimate client IP address and high port.
4 Apr 10 2014 15:04:57 126.96.36.199 443 188.8.131.52 64213 access-list DMZ_access_in_1 denied tcp DMZ/184.108.40.206(443) -> outside/220.127.116.11(64213)
So the server inside the DMZ is replying to a client, but is being blocked by the ASA for some reason.
As the traffic analysis should be stateful I don't really understand why we are seeing this.
Despite this we have not experienced any obvious problems so far.
Has anyone experienced similar issue or logging instance?
I've seen similar log messages for the final packet in a flow. I had found a reference that I can't put my finger on right now that explained that once the TCP connection record was removed from the ASA, the normal logic that bypasses the interface ACL no longer applies and thus you get this syslog artifact.
It may or may not be what you're seeing, a capture of the traffic correlated to the log entry time would confirm or deny this possibility.
That's interesting as an idea and hopefully thats all it is the final packet as the alternative is that genuine packets are being dropped!
Although as I say so far we haven't noticed any obvious problems because of it.
Hopefully someone else has also experienced the problem and has an understanding of it.
Does anyone have idea on this as we're still seeing outbound connections sourced with TCP/443.
We host an SSL page and the traffic seems linked, but why would the return traffic be blocked by the ASA?
We have not observed any actualy problems other than these messages but it is very strange.
If anyone has any ideas or has seen similar please let me know!
|4||Aug 21 2014||14:15:23||18.104.22.168||443||22.214.171.124||50452||access-list DMZ_access_in_1 denied tcp DMZ/126.96.36.199(443) -> outside/188.8.131.52(50452) hit-cnt 1 first hit [0x8c22f0ef, 0x0]|
Can you try to capture the traffic between those selected hosts?.... Once we get the traffic initiated and flow through, we should be able to find why the packets is getting initiated....
do you have any special configurations such as tcp-bypass or something configured?
Same time if you check on the connection for that specific host... does that result that as a new connection?
do you have any specific configuration in the application server @ dmz zone?