Log Dejargonizer

Cisco ASA / Firepower Threat Defense · Event 106100

Cisco ASA 106100: An access-list rule matched

A rule with logging enabled matched a packet, and the firewall recorded whether it permitted or denied it. Unlike the deny-only messages, this one shows permits too, which makes it the message to use when confirming a rule actually works.

Also written as %ASA-6-106100ASA 106100access-list permittedASA-6-106100

What it means for you

On a personal computer

Enterprise firewall logging. You will not see this on a home router.

For an analyst

Only generated for access-list entries with the log keyword, and it aggregates by default over a five-minute interval rather than logging every packet. That aggregation makes it far cheaper than per-packet logging but means the count matters more than the individual message. Excellent for finding rules with zero hits during a rule-base cleanup.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
Aug 28 2026 09:41:22 fw-edge-01 : %ASA-6-106100: access-list outside_access_in permitted tcp outside/198.51.100.77(49820) -> dmz/192.0.2.15(443) hit-cnt 1 first hit [0x8ed2f1c1, 0x0]

The fields that decide it

Everything else in the log line is context.

action
Whether the rule permitted or denied the traffic. This is what distinguishes it from the deny-only messages.
  • permittedThe rule allowed the traffic. Useful for confirming a change worked.
  • deniedThe rule blocked it, recorded here because the rule has logging enabled.
access-list name
Which access-list matched. Go straight to this one rather than reading the whole configuration.
protocol
tcp, udp, icmp, or a protocol number.
source interface/address
Where the traffic came from and on which interface.
destination interface/address/port
Where it was going. The destination port is what you match against the rule base.
hit-cnt
How many packets matched during the interval. This is the aggregated count, not a per-packet record.

Ordinary reasons this happens

Most of the time it is one of these.

  • Ordinary traffic matching rules that happen to have logging enabled.
  • Deliberate logging on a rule while troubleshooting a specific flow.
  • Rules left with logging on after a troubleshooting session, which is a common source of unnecessary volume.
  • Compliance requirements to log specific permitted flows.

When it is not ordinary

Permitted traffic that should not have been allowed.

What gives it awayPermits on administrative ports from sources outside your management ranges. The firewall is doing what it was told; the rule is the problem.

ATT&CK T1133

An overly broad rule being exploited.

What gives it awayHigh hit counts on a permissive rule from sources with no business using it.

ATT&CK T1190

What to do next

  1. Read the action first — permitted and denied need different responses.
  2. Note the access-list name and inspect that rule directly.
  3. Read the hit count rather than counting messages; the message is already aggregated.
  4. For permits, confirm the source range is one that should be allowed.
  5. During a rule-base cleanup, look for rules with no 106100 messages at all — those are candidates for removal.
  6. Turn logging off on rules where it was only enabled for troubleshooting.

Queries to run

splunk Which rules are actually being used, and for what. 
index=firewall "106100" | rex "access-list (?<acl>\S+) (?<action>permitted|denied) (?<proto>\S+) (?<src_if>\S+)/(?<src_ip>\S+)\((?<src_port>\d+)\) -> (?<dst_if>\S+)/(?<dst_ip>\S+)\((?<dst_port>\d+)\)" | stats sum(hit_cnt) as hits by acl action dst_port | sort -hits
grep Hit counts per access-list, straight off a raw log file. 
grep '106100' asa.log | grep -oP 'access-list \K\S+' | sort | uniq -c | sort -rn

Common questions

What is the difference between ASA 106023 and 106100?

106023 records traffic denied because no rule allowed it, and it appears whether or not logging is configured on the rule. 106100 appears only for access-list entries that have the log keyword, and it records both permits and denies with an aggregated hit count. Use 106023 for denies and 106100 when you need to see what a specific rule is doing.

Why does ASA 106100 show a hit count instead of one message per packet?

Because the ASA aggregates these over an interval — five minutes by default — rather than logging every packet. That keeps the volume manageable on a busy firewall. The trade-off is that the count in the message matters more than the number of messages, which trips up queries that count log lines.

How do I find unused firewall rules on a Cisco ASA?

Enable logging on the rules you are evaluating and look for access-lists that generate no 106100 messages over a representative period. `show access-list` also displays per-rule hit counters directly, which is usually the faster route for a one-off cleanup.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026