The Cisco ASA tracks two layered tables that explain almost every "is this traffic flowing" question: the connection table (one entry per active flow, 5-tuple plus state) and the xlate table (one entry per active NAT translation, source-side and destination-side). When something is wrong with traffic that should be passing the firewall, show conn and show xlate tell you whether the flow exists at all and whether it is being NATed correctly. This article walks the table layout, the most useful filters, and the operational clear commands you reach for during real troubleshooting, all using live output from the PingLabz ASA reference lab on ASAv 9.23(1).
If you do not yet have a flow in show conn when you expect one, start with packet-tracer to find the dropping phase, then an interface capture to confirm the packet arrived. If the flow is in the table but the application is not working, the problem is usually NAT - and that is where show xlate earns its keep.
Connection Table vs Xlate Table
| show conn | show xlate | |
|---|---|---|
| What it tracks | Active flows: 5-tuple, interfaces, state flags, idle timer | NAT bindings: pre-NAT to post-NAT, type (static/dynamic/PAT/identity/twice), refcount |
| Per-flow lifetime | Born when first packet creates flow, dies when timeout or RST/FIN | For dynamic NAT, born and dies with the flow (refcount == 0). For static, lives as long as the rule exists. |
| Default capacity | 250,000 - several million depending on platform memory | Same scale; tied to memory, not interface speed |
| Filterable by | Address, protocol, port, interface, state | Address (local/global), interface |
| Cleared with | clear conn | clear xlate (also clears tied conns) |
The relationship: every dynamic NAT entry has a corresponding conn (or several, if PAT is multiplexing). Static and identity entries can exist without conns. The xlate id field on a conn is a pointer back to the xlate that produced it.
Counting What's There
ASA-PERIM# show conn count
14 in use, 15 most used
ASA-PERIM# show xlate count
14 in use, 16 most used
"In use" is current; "most used" is the high-water mark since the last reload. If "most used" is approaching the platform license cap, you have a sizing problem coming. For the lab's small ASAv that is no issue, but on a real perimeter the most-used number is the trend you watch with show resource usage.
show conn detail: The Full Flow Picture
Without detail, show conn gives you the 5-tuple and a flag string. With detail, you also get internal flow IDs, NAT pointers, idle timers, and uptime - the data you need to correlate a flow with an xlate, and to diagnose a stuck flow.
ASA-PERIM# show conn detail address 10.10.10.1
14 in use, 15 most used
Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,
B - initial SYN from outside, b - TCP state-bypass or nailed,
... [legend continues] ...
U - up, ...
UDP outside: 8.8.8.8/1967 inside: 10.10.10.1/52151,
flags - , idle 34s, uptime 44s, timeout 2m0s, bytes 156, xlate id 0x7f0a9813eb00, flow id 195
UDP outside: 8.8.8.8/1967 inside: 10.10.10.1/64852,
flags - , idle 1m54s, uptime 2m4s, timeout 2m0s, bytes 156, xlate id 0x7f0a9813e600, flow id 186
UDP dmz: 192.168.50.10/1967 inside: 10.10.10.1/58256,
flags - , idle 1m55s, uptime 2m5s, timeout 2m0s, bytes 156, flow id 185
UDP dmz: 192.168.50.10/1967 inside: 10.10.10.1/57775,
flags - , idle 35s, uptime 45s, timeout 2m0s, bytes 156, flow id 194
UDP outside: 8.8.8.8/1967 inside: 10.10.10.1/57936,
flags - , idle 14s, uptime 24s, timeout 2m0s, bytes 156, xlate id 0x7f0a9813e880, flow id 197
Read this:
UDP outside: 8.8.8.8/1967 inside: 10.10.10.1/52151- a UDP flow whose outside-leg is 8.8.8.8:1967 and inside-leg is 10.10.10.1:52151. Source is 10.10.10.1, destination is 8.8.8.8. The "inside:" and "outside:" tell you which interface terminates each leg.flags -- no special flags. UDP has fewer flags than TCP because there is no state machine. A typical TCP flow shows something likeUIO= Up, Inbound data, Outbound data.idle 34s, uptime 44s, timeout 2m0s- the flow has been idle 34 seconds and has lived 44 seconds; it will be culled if it stays idle past 2 minutes.xlate id 0x7f0a9813eb00- this is the pointer to the xlate entry. Useful when you want to see exactly which NAT rule produced this flow.flow id 195- internal sequence number. Higher = newer.
The two flow types in this output show the lab's NAT architecture clearly: flows whose outside-leg is 8.8.8.8 transited the outside interface (and have an xlate id, because they are PATted), while flows whose outside-leg is 192.168.50.10 transited the dmz interface (and have no xlate id, because inside-to-dmz traffic is not NATed).
Filtering by Protocol or Port
For triage on a busy ASA, narrow the view:
ASA-PERIM# show conn protocol udp
14 in use, 15 most used
UDP outside 8.8.8.8:1967 inside 10.10.10.1:52151, idle 0:00:33, bytes 156, flags -
UDP outside 8.8.8.8:1967 inside 10.10.10.1:64852, idle 0:01:53, bytes 156, flags -
UDP dmz 192.168.50.10:1967 inside 10.10.10.1:58256, idle 0:01:53, bytes 156, flags -
... [continued] ...
Other useful filters:
show conn protocol tcp port www- all TCP flows on port 80.show conn address 192.168.50.10- every flow involving DMZ-WEB.show conn state up- only TCP flows in fully-established UP state. The complement (state half-closed,state finin,state finout) shows you flows that are tearing down.show conn long- show flows older than the long timer (typically used for DC-style long-running connections).
Reading the Flag String
The flag string is dense but reveals exactly what state a TCP flow is in:
| Flag | Means |
|---|---|
U | Up: full handshake completed both directions. |
I | Inbound data has flowed. |
O | Outbound data has flowed. |
A | Awaiting inside ACK to SYN. Three-way handshake in progress. |
a | Awaiting outside ACK to SYN. |
F | Outside FIN seen. |
f | Inside FIN seen. Both F and f = teardown in progress. |
R | Outside acknowledged FIN. Half-closed. |
r | Inside acknowledged FIN. |
i | Incomplete: TCP flow lacking either side's full handshake. |
b | TCP state-bypass or nailed. ASA is not enforcing TCP state on this flow. |
N | Inspected by Snort/IPS. |
D | DNS or Umbrella inspection. |
V | VPN orphan: flow exists for traffic that hit a tunnel but the tunnel is gone. |
A flow stuck at UI (Up, Inbound only) for a long time is one-way traffic. i alone means the handshake never completed - usually a downstream firewall dropping the SYN-ACK. V orphans accumulate when a VPN flaps; clear them with clear conn vpn-flow.
show xlate detail: The NAT Side
The xlate table has its own flag legend and shows pre/post-NAT mappings:
ASA-PERIM# show xlate detail
14 in use, 16 most used
Flags: D - DNS, e - extended, I - identity, i - dynamic, r - portmap,
s - static, T - twice, N - net-to-net
NAT from dmz:192.168.50.10 to outside:198.51.100.10
flags s idle 0:00:14 timeout 0:00:00 xlate id 0x7f0a98140b80
NAT from inside:10.10.0.0/16 to outside:10.10.0.0/16
flags sIT idle 1:53:57 timeout 0:00:00 xlate id 0x7f0a98140180
NAT from outside:10.99.99.0/24 to inside:10.99.99.0/24
flags sIT idle 1:53:57 timeout 0:00:00 xlate id 0x7f0a98140400
NAT from outside:172.20.0.0/24 to inside:172.20.0.0/24
flags sIT idle 1:53:56 timeout 0:00:00 xlate id 0x7f0a9813ff00
UDP PAT from inside:10.10.10.1/58380 to outside:203.0.113.2/58380 flags ri idle 0:00:37 timeout 0:00:00
UDP PAT from inside:10.10.10.1/52513 to outside:203.0.113.2/52513 flags ri idle 0:00:57 timeout 0:00:00
UDP PAT from inside:10.10.10.1/64356 to outside:203.0.113.2/64356 flags ri idle 0:01:17 timeout 0:00:00
UDP PAT from inside:10.10.10.1/51684 to outside:203.0.113.2/51684 flags ri idle 0:00:17 timeout 0:00:00
Read the flags:
s- static. The mapping was created by an explicit static rule and persists regardless of traffic.I- identity. The pre-NAT and post-NAT addresses are the same (used for VPN exemptions and routing-only translations).T- twice NAT. Both source and destination are translated by the same rule.i- dynamic. Created on demand by traffic.r- portmap (PAT). Source port translated as well as IP.D- DNS rewrite applied.N- net-to-net (whole subnet mapping).
The first entry (flags s) is the DMZ-WEB static (one-to-one between the inside-facing and outside-facing IPs). The next three (flags sIT) are static-identity-twice rules used for VPN exemption and partner-network exemption. The last four (flags ri) are dynamic PAT mappings: each one is a single source-port-to-source-port mapping built on demand for an outbound flow.
Get the Cisco ASA Field Reference - 9 pages, free
Everything you'd want to remember about Cisco ASA on nine printable pages. Per-packet pipeline diagram, NAT 8.3+ section ordering, six-branch troubleshooting decision tree, real lab show-output annotated, paste-ready three-zone config. Free for PingLabz members - just sign up with your email.
Filtering xlate by Source Address
ASA-PERIM# show xlate local 10.10.10.1
14 in use, 16 most used
UDP PAT from inside:10.10.10.1/50199 to outside:203.0.113.2/50199 flags ri idle 0:00:05 timeout 0:00:00
UDP PAT from inside:10.10.10.1/60087 to outside:203.0.113.2/60087 flags ri idle 0:01:05 timeout 0:00:00
UDP PAT from inside:10.10.10.1/62133 to outside:203.0.113.2/62133 flags ri idle 0:00:15 timeout 0:00:00
UDP PAT from inside:10.10.10.1/64852 to outside:203.0.113.2/64852 flags ri idle 0:02:05 timeout 0:00:00
UDP PAT from inside:10.10.10.1/52151 to outside:203.0.113.2/52151 flags ri idle 0:00:45 timeout 0:00:00
UDP PAT from inside:10.10.10.1/57936 to outside:203.0.113.2/57936 flags ri idle 0:00:25 timeout 0:00:00
UDP PAT from inside:10.10.10.1/58379 to outside:203.0.113.2/58379 flags ri idle 0:01:45 timeout 0:00:00
UDP PAT from inside:10.10.10.1/52529 to outside:203.0.113.2/52529 flags ri idle 0:01:25 timeout 0:00:00
Eight active PAT mappings for one source. show xlate local filters by pre-NAT (inside) IP; show xlate global filters by post-NAT (outside) IP. On a busy perimeter the global filter is what you reach for first when an inbound flow is failing because you suspect the wrong outbound source IP.
show xlate count: The PAT Pool Health Check
The single most useful operational check on an ASA's NAT subsystem is show xlate count - watch the trend, not the absolute number. PAT (portmap) entries consume one source-port slot per flow. With one outside interface IP and 65535 - 1024 = 64511 ephemeral ports, the platform can support at most ~64K simultaneous PAT mappings before running out. If show xlate count rises faster than connections are leaving and the PAT pool is one IP, you are heading for nat-no-xlate-to-pat-pool drops. Add a backup PAT IP, expand to a pool, or split the source.
Clearing Conns and Xlates
When you change a NAT rule or an ACL, the ASA does not retroactively rebuild flows that were created under the old rules. They will continue to forward through the firewall using the old translation until they idle out or you clear them. If you want immediate effect:
ASA-PERIM# clear conn address 10.10.10.1
ASA-PERIM# clear xlate local 10.10.10.1
clear conn kills the flow; on the next packet, the ASA re-runs the new rules. clear xlate kills the NAT binding and any conns tied to it. In production you almost never use clear conn all or clear xlate all - that resets every flow on the firewall and is service-affecting.
Other surgical variants:
clear conn protocol tcp port www- drop only HTTP connections.clear conn state finin- drop only flows in TCP FIN-WAIT.clear xlate global 198.51.100.99- drop the partner-PAT mapping when its tunnel changes.clear conn vpn-flow- clear orphaned VPN flows after a tunnel flap.
Key Takeaways
Two tables, two questions: show conn tells you whether a flow exists and what state it is in; show xlate tells you whether NAT is producing the right pre/post mapping. When traffic is failing, walk the chain: confirm the flow exists in show conn detail, find its xlate id, follow that to show xlate, and verify the mapping is what you expected. The flags - i for incomplete, V for VPN orphan, sIT for static-identity-twice - are most of the diagnostic content. For surgical fixes, clear conn and clear xlate with tight filters reset just the affected flows. The full Cisco ASA reference cluster covers the rest of the operational toolkit, including CLI packet capture, asp-drop counters, and common outage scenarios that this table walk is the fastest path through.
