Log Dejargonizer

Cisco ASA / Firepower Threat Defense · Event 106023

Cisco ASA 106023: Traffic denied by an access-list

The firewall dropped a packet because no rule allowed it. This is the firewall doing its job, and on an internet-facing device it fires constantly. It only matters when the traffic was supposed to work, or when the pattern looks like scanning.

Also written as %ASA-4-106023ASA 106023ASA-4-106023

What it means for you

On a personal computer

You will not see this on a home router — it is enterprise firewall logging. The idea is the same as your router silently dropping unsolicited inbound traffic, except the firewall writes a line about every one.

For an analyst

Two distinct uses. As a troubleshooting signal it tells you exactly which access-group refused a flow you expected to pass. As a detection signal, denies are only interesting once aggregated: one source touching many destination ports, or one port across many hosts.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
Aug 28 2026 09:41:17 fw-edge-01 : %ASA-4-106023: Deny tcp src outside:198.51.100.77/49820 dst dmz:192.0.2.15/3389 by access-group "outside_access_in" [0x8ed2f1c1, 0x0]

The fields that decide it

Everything else in the log line is context.

protocol
The IP protocol of the dropped packet — tcp, udp, icmp, or a protocol number.
src interface:address/port
Where the packet arrived from, and on which firewall interface. The interface name tells you which direction the traffic was travelling.
dst interface:address/port
Where it was headed. The destination port is what you match against your rule base when troubleshooting.
access_group acl_ID
The access-list that refused it. Go straight to this ACL rather than reading the whole configuration.
type / code
Present for ICMP only. Type 8 is an echo request — a ping being blocked, and by far the most common ICMP entry.

Ordinary reasons this happens

Most of the time it is one of these.

  • Background internet noise hitting a public interface. Any address reachable from the internet is scanned continuously; the denies are the expected outcome.
  • A new application deployed without a corresponding firewall rule — the classic change-management gap.
  • Misconfigured clients still pointing at a decommissioned server.
  • Broadcast and discovery protocols leaking across interfaces.
  • Health checks and monitoring probes aimed at services that were moved.

When it is not ordinary

Port scanning from a single source.

What gives it awayOne source address denied against a long sequence of destination ports on one host, usually within a short window.

ATT&CK T1046

Network sweep for one exposed service.

What gives it awayOne destination port across a large range of destination addresses. Look for the ports attackers currently favour rather than maintaining a fixed list.

ATT&CK T1018

Compromised internal host attempting to reach out.

What gives it awayDenies where the source is inside your network and the destination is external. Outbound denies deserve far more attention than inbound ones and are routinely ignored.

ATT&CK T1071

Lateral movement probing between segments.

What gives it awayInternal-to-internal denies on administrative ports, particularly crossing segmentation boundaries that should never carry that traffic.

ATT&CK T1021

What to do next

  1. Decide the direction first — outbound and internal-to-internal denies are worth real attention; inbound denies from the internet usually are not.
  2. If you are troubleshooting, note the access_group name and inspect that ACL directly for the missing or shadowed rule.
  3. Aggregate before you judge. Count distinct destination ports per source, and distinct destinations per port.
  4. For inbound floods, confirm the traffic is being denied at the edge rather than reaching anything, then move on.
  5. For internal sources, identify the host and work out what process is generating the traffic before adjusting any rule.
  6. Resist the reflex to permit the traffic just to silence the log. Confirm the flow is legitimate first.

Queries to run

splunk Horizontal port scanning, expressed as distinct ports per source. 
index=firewall "106023" | rex "src (?<src_if>\S+):(?<src_ip>\d+\.\d+\.\d+\.\d+)" | rex "dst (?<dst_if>\S+):(?<dst_ip>\d+\.\d+\.\d+\.\d+)/(?<dst_port>\d+)" | stats dc(dst_port) as ports by src_ip | where ports > 20
grep Quick triage on a raw log file when you have no platform in front of you. 
grep '106023' asa.log | grep -oP 'dst \w+:\K[\d.]+/\d+' | sort | uniq -c | sort -rn | head -20

Common questions

Should I be worried about lots of ASA 106023 messages?

Not by themselves. On any internet-facing firewall these arrive continuously as background scanning, and each one means the firewall blocked something. Look closer when the source is inside your own network, when one source touches many different ports, or when traffic you expected to work is being refused.

How do I find which rule is blocking my traffic?

The message names the access-group at the end of the line. Inspect that access-list for the source, destination, and port in the message. Most often there is no matching permit at all; occasionally a broader deny earlier in the list is shadowing a permit further down.

Why does 106023 show a port for ICMP traffic?

It does not. For ICMP the message carries type and code values instead. Type 8 code 0 is an echo request, meaning a ping was blocked — usually expected on an external interface.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026