Log Dejargonizer

Cisco ASA / Firepower Threat Defense · Event 106001

Cisco ASA 106001: Inbound TCP connection denied

The firewall dropped an inbound TCP packet, either because no rule allowed it or because the packet did not belong to any established connection. Its severity 2 rating makes it look urgent in a log viewer; on an internet-facing interface it is routine.

Also written as %ASA-2-106001ASA 106001Inbound TCP connection deniedASA-2-106001

What it means for you

On a personal computer

Enterprise firewall logging. The equivalent on a home router is silently dropping unsolicited inbound traffic — the firewall just writes a line about each one.

For an analyst

The severity 2 rating causes real problems: it lights up alerting systems that key on severity, and teams often suppress it entirely as a result. Suppress by message ID rather than by severity, or you will lose genuinely critical messages alongside it. The flags field distinguishes a fresh connection attempt from an out-of-state packet, which is the more interesting variant.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
Aug 28 2026 09:42:03 fw-edge-01 : %ASA-2-106001: Inbound TCP connection denied from 198.51.100.77/49820 to 192.0.2.15/3389 flags SYN on interface outside

The fields that decide it

Everything else in the log line is context.

interface
Which interface the packet arrived on. Inbound on the outside interface is expected noise; inbound on an internal interface is not.
source address/port
Where the packet came from.
destination address/port
Where it was headed. The port tells you what was being probed.
flags
The TCP flags on the denied packet.
  • SYNA fresh connection attempt. Ordinary scanning and misconfigured clients.
  • ACKA packet claiming to belong to a connection the firewall has no record of. Out-of-state, and more interesting than a plain SYN.
  • RSTA reset for an unknown connection, often the tail of an asymmetric routing problem.
  • FIN ACKA teardown for a connection that already timed out on the firewall.

Ordinary reasons this happens

Most of the time it is one of these.

  • Background internet scanning against a public interface, which is continuous and expected.
  • Packets arriving after the firewall's connection timeout expired, particularly on long-idle sessions.
  • Asymmetric routing, where return traffic arrives on an interface the firewall did not see the connection start on.
  • Clients still trying to reach a decommissioned service.
  • Health checks aimed at services that were moved.

When it is not ordinary

Port scanning.

What gives it awayOne source denied against a sequence of destination ports in a short window.

ATT&CK T1046

A sweep for one exposed service.

What gives it awayOne destination port across many destination addresses.

ATT&CK T1018

Crafted out-of-state packets probing firewall behaviour.

What gives it awayDenies with ACK or unusual flag combinations rather than plain SYN, from a source that never established a connection.

ATT&CK T1595

What to do next

  1. Ignore the severity rating and judge by direction and pattern instead.
  2. Check the interface — inbound on a public interface is expected; inbound on an internal one is not.
  3. Read the flags. A plain SYN is a connection attempt; an ACK is a packet claiming a connection that does not exist.
  4. Aggregate before judging: distinct ports per source, and distinct destinations per port.
  5. For persistent out-of-state denies on a working service, investigate asymmetric routing or connection timeouts rather than security.
  6. Suppress by message ID rather than by severity if the volume is a problem.

Queries to run

splunk Port scanning, as distinct ports per source. 
index=firewall "106001" | rex "from (?<src_ip>[\d.]+)/(?<src_port>\d+) to (?<dst_ip>[\d.]+)/(?<dst_port>\d+)" | stats dc(dst_port) as ports by src_ip | where ports > 20 | sort -ports
grep Most-probed destinations, straight off a raw log file. 
grep '106001' asa.log | grep -oP 'to \K[\d.]+/\d+' | sort | uniq -c | sort -rn | head -20

Common questions

Why is ASA 106001 rated severity 2 if it is not serious?

Because Cisco assigned the severity when the message was designed, and it reflects the protocol-level event rather than its operational significance. On an internet-facing firewall these arrive continuously as background scanning. Judge by pattern and direction rather than by the severity number.

How do I stop ASA 106001 messages flooding my syslog?

Suppress the specific message with `no logging message 106001`, or set a lower logging level for it. Do not suppress by severity — 106001 shares severity 2 with messages you genuinely want to see, and filtering at that level is how real alerts get lost.

What does 'flags ACK' mean on a denied inbound connection?

The packet claimed to belong to an established connection that the firewall has no record of. That happens legitimately when a connection timed out on the firewall but not on the endpoints, and when routing is asymmetric. It also happens when someone is crafting packets to probe how the firewall responds.

Read next

Vendor documentation

Last reviewed 28 August 2026