Deny TCP (no connection) - PSH ACK

[bluesea2010]

Hi,

I am getting the following on my asa firewall

1 ) Jan 15 2017 10:17:19 106015 10.0.1.34 63547 1.1.1.1 80 Deny TCP (no connection) from 10.0.10.34/63547 to 1.1.1.1/80 flags PSH ACK on interface Inside

2 )

6 Jan 15 2017 10:17:19 106015 10.0.1.34 63547 1.1.1.1 80 Deny TCP (no connection) from 10.0.10.34/63547 to 1.1.1.1/80 flags PSH ACK on interface Inside

ACK on interface Outside

Why this happens

Thanks

[saif musa]

Hi,

You are logging access attempts that are being denied per your configuration on the ASA. denying unauthorized access attempts. 

Regards

[bluesea2010]

Hi,

you mean denied by acl 

[saif musa]

Hi,

Now I made a mistake, I'm sorry. As Mohammed said above, The ASA discarded a TCP packet that has no associated connection in connection table. your device looks for a SYN flag in the packet, which indicates a request to establish a new connection. If the SYN flag is not set, and there is not an existing connection, the device discards the packet.

Now we need mohammed to tell us if there is a recommended action for this, for me, I would check if the device receives a large volume of these invalid TCP packets. In this case, I will trace the packets to the source and determine the reason these packets were sent.

My first answer was wrong so just discard it please.

Thanks

[Mohammed al Baqari]

You picked it right. You need to traceback to the source and find the reason for sending these packets.

Most of the time I have seen this happening because of the way applications coded to response to RST flags. But definitely worth at looking full TCP session.

If you are sending logs from ASA to SIEM device then you can traceback the entire session. Else, you can configure ASA to capture packets between two hosts and look at the capture later using CLI or wireshark

[Mohammed al Baqari]

Hi,

Since ASA is statefull firewall, it will allow TCP connections which were correctly established. Now, TCP establish connections using 3-way TCP handshake (SYN , SYN-ACK , ACK).

This log is poping because ASA didn't have TCP connection between these hosts on mentioned ports (SYN/SYN-ACK/ACK) and you can't send PSH-ACK without completing the original TCP handshake.

Now some applications send RST message. ASA will read this message and accordingly terminate the connection. Now the other side of the application will read the RST message and instead of sending ACK, it will send PSH-ACK. ASA will  drop this packet because it terminated the connection based on previous RST. This is very common reason for this message

Hope its clear now.