Log Dejargonizer

Cisco ASA / Firepower Threat Defense · Event 302013

Cisco ASA 302013: A TCP connection was built

The firewall allowed a TCP connection and started tracking it. This is what a successful, permitted flow looks like, and it is the message you check to confirm that a rule change actually worked.

Also written as %ASA-6-302013ASA 302013Built inbound TCP connectionBuilt outbound TCP connection

What it means for you

On a personal computer

Enterprise firewall logging. It records a connection being allowed.

For an analyst

Together with 302014 it gives you full connection records including byte counts, which is the closest thing to flow data the ASA produces natively. The connection ID links the two. Direction is stated explicitly in the message, and reading it wrong is the most common mistake when triaging these.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
Aug 28 2026 09:41:30 fw-edge-01 : %ASA-6-302013: Built outbound TCP connection 8812345 for outside:198.51.100.203/443 (198.51.100.203/443) to inside:192.0.2.44/51993 (192.0.2.44/51993)

The fields that decide it

Everything else in the log line is context.

connection ID
A number identifying this connection. Match it against the 302014 teardown for duration and byte counts.
direction
Whether the connection was inbound or outbound, stated in the message text. Outbound connections to unexpected destinations are the more interesting direction.
source interface:address/port
Where the connection came from.
destination interface:address/port
Where it went.
user
The identity associated with the connection, when identity-based policy is configured.

Ordinary reasons this happens

Most of the time it is one of these.

  • All normal permitted traffic through the firewall.
  • Users browsing, sending mail, and using applications.
  • Server-to-server communication between segments.
  • Monitoring and management traffic.
  • Backup and replication flows.

When it is not ordinary

A compromised internal host reaching command and control.

What gives it awayOutbound connections from a server that has no business initiating outbound traffic, particularly at regular intervals.

ATT&CK T1071

Data being moved out of the network.

What gives it awayLarge outbound transfers, visible in the byte counts on the matching 302014, from hosts that do not normally send data out.

ATT&CK T1041

Lateral movement between segments.

What gives it awayInternal connections on administrative ports crossing segmentation boundaries that should not carry that traffic.

ATT&CK T1021

What to do next

  1. Read the direction from the message text before anything else.
  2. For outbound connections, ask whether that source should be initiating outbound traffic at all.
  3. Match the connection ID against the 302014 teardown for duration and byte counts.
  4. Look at the timing pattern for repeated connections to the same destination.
  5. For internal connections, check whether they cross a segmentation boundary they should not.

Queries to run

splunk Outbound connections grouped by destination — the direction that matters most. 
index=firewall "302013" | rex "Built (?<direction>\w+) TCP connection (?<connid>\d+) for (?<src_if>\S+):(?<src_ip>[\d.]+)/(?<src_port>\d+) .* to (?<dst_if>\S+):(?<dst_ip>[\d.]+)/(?<dst_port>\d+)" | search direction=outbound | stats count by src_ip dst_ip dst_port | sort -count
splunk Internal hosts reaching an unusual number of destinations. 
index=firewall "302013" | rex "for \S+:(?<src_ip>[\d.]+)" | stats dc(dst_ip) as destinations by src_ip | where destinations > 100

Common questions

How do I confirm a firewall rule change worked on a Cisco ASA?

Look for a 302013 for the flow you expected to work. If you see 106023 or 106001 instead, the traffic is still being denied. Matching the connection ID to the 302014 teardown additionally tells you whether data actually flowed or the connection was built and immediately dropped.

What is the connection ID in ASA 302013 for?

It links the connection to its teardown message. The 302014 for the same ID carries the duration and the number of bytes transferred, which together turn two log lines into something close to a flow record.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026