What is the reason for the log %ASA-6-106015?

When the ASA receives a packet it checks the conn table and whether a connection entry is found for that packet, it is handled by the Fast Path and bypass the ACLs. It is true for any packet that doesn't require application inspection, otherwise it is handled by session management path or control plane path.


So what if you see the following logs:

Feb 20 2012 08:15:08: %ASA-6-302013: Built outbound TCP connection 7985447 for outside:192.168.0.35/80 (192.168.0.35/80) to inside:10.0.0.20/45494 (192.0.2.20/45494)
Feb 20 2012 08:15:38: %ASA-6-302014: Teardown TCP connection 7985447 for outside:192.168.0.35/80 to inside:10.0.0.20/45494 duration 0:00:30 bytes 0 SYN Timeout
Feb 20 2012 08:15:54: %ASA-6-106015: Deny TCP (no connection) from 192.168.0.35/80 to 192.0.2.20/45494 flags SYN ACK  on interface outside


The 3-way handshake has been started and after 30 seconds it was dropped due to a SYN timeout. The destination server tried to complete the handshake, but the firewall dropped the packet because there was no associated connection for that packet. Note that it is a SYN+ACK packet and for any packet with flags set for anything other than SYN only, the firewall always check the conn table.

Now we understand what was the problem, but we don't know what is causing this issue. Actually there are many possible causes for that, but we can list some of them:
- Idle timeout, embryonic timeout and half-closed timeout;
- Asymmetric routing

IDLE TIMEOUT

An idle timeout occurs for established connections. The ASA enforces a timeout control for idle connections. If no packets are received within the timeout value, the connection is dropped and any packet received after that will be denied. If the application requires a long idle time frame or if a low bandwidth path is used, you can disable the idle control or increase the default value. See the article "Disabling idle timeout for specific traffic".


EMBRYONIC TIMEOUT


Embryonic connections are those that have not yet completed the 3-way handshake. The default value for embryonic timeout is 30 seconds. You can also disable or change the timeout parameters following the instructions presented in "Disabling idle timeout for specific traffic".

An embryonic timeout can also be caused by communication problems between the firewall and the source or destination. I recommend you to use a bottom-up approach to troubleshoot a connectivity issue. We use to check things like routing, access rules, and NAT rules, but we also have to check basic things like ARP and addresses conflicts. Make sure ARP resolution is working (debug arp), and ping both source and destination addresses and whether possible confirm if the MAC addresses are correct.


HALF-CLOSED TIMEOUT


Client and server must complete a handshake to close a connection. It's very common to see half-closed connections and it is actually not a big problem, since the firewall removes the session entry from the conn table after the timeout value and any packet received after that will be dropped. Thus you can see those logs but they are not always an indication of a connectivity issue.


ASYMMETRIC ROUTING


If the firewall has multiple paths between source and destination, you can have an asymmetric routing problem. Let's say that a company have redundant paths between HQ and a remote site, for example, MPLS and IPsec VPN tunnel. If both paths are active at the same time, we might have packets from client to server going through the IPsec tunnel (inside to outside) and replies from the server are forwarded through the MPLS link. If the packets from server reach the firewall on any interface other than the inside (for example, MPLS interface), it drops the packet because there is no connection between client and server on the MPLS interface.