Log Dejargonizer

Cisco ASA / Firepower Threat Defense · Event 302014

Cisco ASA 302014: A TCP connection was torn down

A connection ended, and the firewall recorded how long it lasted, how many bytes moved, and why it closed. The byte count is the field that matters — it is the ASA's closest equivalent to flow data, and it is how you spot data leaving.

Also written as %ASA-6-302014ASA 302014Teardown TCP connectionASA connection teardown

What it means for you

For an analyst

The teardown reason distinguishes a normal close from a timeout from a policy-driven drop, which is genuinely useful when troubleshooting. The byte count makes this the message to aggregate when hunting for exfiltration, since the ASA does not produce NetFlow by default.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
Aug 28 2026 09:51:12 fw-edge-01 : %ASA-6-302014: Teardown TCP connection 8812345 for outside:198.51.100.203/443 to inside:192.0.2.44/51993 duration 0:09:42 bytes 184320119 TCP FINs

The fields that decide it

Everything else in the log line is context.

connection ID
Matches the 302013 that built the connection.
duration
How long the connection lasted, in hours, minutes, and seconds.
bytes
How much data moved. The field to aggregate when looking for large transfers.
reason
Why the connection ended.
  • TCP FINsA normal, orderly close by both sides.
  • TCP Reset-I or Reset-OOne side reset the connection. Common and usually unremarkable.
  • SYN TimeoutThe connection was never completed — the destination never answered.
  • Idle TimeoutThe firewall aged out an idle connection. A frequent cause of applications appearing to hang.
  • Deny TerminateDropped by policy after being built, typically by an inspection engine.
  • Flow closed by inspectionAn inspection engine ended it deliberately.

Ordinary reasons this happens

Most of the time it is one of these.

  • Every normal connection ending.
  • Idle timeouts on long-lived sessions, which is the usual explanation for applications that hang after a period of inactivity.
  • Applications resetting connections rather than closing them politely.
  • Health checks opening and closing connections continuously.

When it is not ordinary

Data being moved out of the network.

What gives it awayUnusually large byte counts on outbound connections from hosts that do not normally transfer data, particularly outside working hours.

ATT&CK T1041

Command and control beaconing.

What gives it awayMany short connections to the same destination with small, consistent byte counts at regular intervals.

ATT&CK T1071.001

Scanning that never completes.

What gives it awayLarge numbers of SYN Timeout teardowns from one source.

ATT&CK T1046

What to do next

  1. Read the byte count and the direction together. Large outbound is the combination that matters.
  2. Read the teardown reason — a timeout and a normal close mean very different things when troubleshooting.
  3. Match the connection ID to the 302013 for the full picture.
  4. For applications that hang, look for Idle Timeout teardowns and compare against the firewall's timeout settings.
  5. Aggregate bytes by source over a day to find hosts sending unusual volumes.

Queries to run

splunk Total bytes per source. The top of this list should be explainable. 
index=firewall "302014" | rex "duration (?<dur>\S+) bytes (?<bytes>\d+)" | rex "for \S+:(?<src_ip>[\d.]+)" | stats sum(bytes) as total by src_ip | sort -total | head 20
splunk Teardown reasons by frequency. A rise in Idle Timeout usually means an application problem, not a security one. 
index=firewall "302014" | rex "bytes (?<bytes>\d+) (?<reason>.+)$" | stats count by reason | sort -count
grep Largest transfers in a raw log file. 
grep '302014' asa.log | grep -oP 'bytes \K\d+' | sort -rn | head -20

Common questions

What does 'Idle Timeout' mean in an ASA teardown message?

The firewall removed the connection from its table because no traffic passed for longer than the configured idle timeout. The endpoints may still think the connection is open, which is why applications sometimes appear to hang and then fail after a period of inactivity. Adjusting the timeout for that traffic class, or enabling keepalives, is the usual fix.

How do I find large data transfers on a Cisco ASA?

Aggregate the bytes field from 302014 messages by source address over a period. The ASA does not produce NetFlow by default, so this is the practical way to get transfer volumes out of it. Sorting by total bytes per host over a day is usually enough to make anything unusual obvious.

What is the difference between 'TCP FINs' and 'TCP Reset-I' as a teardown reason?

TCP FINs means both sides closed the connection politely. Reset-I means the inside host sent a reset, and Reset-O means the outside host did. Resets are extremely common and usually just reflect how an application closes connections rather than indicating a problem.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026