Usage Guidelines
When you use the detail option, the system displays information about the translation type and interface information using
the connection flags defined in Table 4-34. Also, VPN stub may be shown at the end of the output of this command indicating that the connection is playing the role
of a VPN encryption stub flow in addition to its cluster role. A VPN stub is used to encrypt clear text packets in an asymmetric
VPN traffic scenario or hub-n-spoke scenario.
Note
|
In Firepower 3100 and Cisco Secure Firewall 1200 model devices, though the priority queue is disabled and no connection is
established, the output of the show conn details displays a note that mentions an invalid connection due to an invalid internal-data/Rx-ring number.
|
Table 35. Connection Flags
|
Flag
|
Description
|
|
a
|
awaiting outside ACK to SYN
|
|
A
|
awaiting inside ACK to SYN
|
|
b
|
TCP state bypass
|
|
B
|
initial SYN from outside
|
|
C
|
Computer Telephony Interface Quick Buffer Encoding (CTIQBE) media
connection
|
|
d
|
dump
|
|
D
|
DNS
|
|
E
|
outside back connection. This is a secondary data connection that must
be initiated from the inside host. For example, using FTP, after the
inside client issues the PASV command and the outside server accepts, the
ASA preallocates an outside back connection with this flag set. If the
inside client attempts to connect back to the server, then the ASA denies
this connection attempt. Only the outside server can use the preallocated
secondary connection.
|
|
f
|
inside FIN
|
|
F
|
outside FIN
|
|
g
|
Media Gateway Control Protocol (MGCP) connection
|
|
G
|
connection is part of a group2
|
|
h
|
H.225
|
|
H
|
H.323
|
|
i
|
incomplete TCP or UDP connection
|
|
I
|
inbound data
|
|
k
|
Skinny Client Control Protocol (SCCP) media connection
|
|
K
|
GTP t3-response
|
|
l
|
local director/backup stub flow
|
|
L
|
traffic subject to LISP flow-mobility
|
|
m
|
SIP media connection
|
|
M
|
SMTP data
|
|
N
|
Inspected by Snort.
If the system is configured to preserve connections if Snort goes down (this is enabled by default), the N flag includes a
number.
-
1—This connection will be preserved if Snort goes down.
-
2—Snort did go down, and this connection was preserved. The connection will no longer be inspected by Snort.
|
|
o
|
Off-loaded flow.
|
|
O
|
outbound data
|
|
p
|
replicated (unused)
|
|
P
|
inside back connection. This is a secondary data connection that must be
initiated from the inside host. For example, using FTP, after the inside
client issues the PORT command and the outside server accepts, the ASA
preallocates an inside back connection with this flag set. If the outside
server attempts to connect back to the client, then the ASA denies this
connection attempt. Only the inside client can use the preallocated
secondary connection.
|
|
q
|
SQL*Net data
|
|
Q
|
Diameter connection
|
|
r
|
inside acknowledged FIN
|
|
R
|
outside acknowledged FIN for TCP connection
|
|
R
|
UDP RPC3
|
|
s
|
awaiting outside SYN
|
|
S
|
awaiting inside SYN
|
|
t
|
SIP transient connection4
|
|
T
|
SIP connection5
|
|
u
|
STUN connection
|
|
U
|
up
|
|
v
|
M3UA connection
|
|
V
|
VPN orphan
|
|
w
|
For inter-chassis clustering on the Firepower 9300, identifies a flow on
a backup owner on a separate chassis.
|
|
W
|
WAAS
|
|
X
|
Inspected by the service module, such as a CSC SSM.
|
|
y
|
For clustering, identifies a backup owner flow.
|
|
yo
|
For clustering, indicates that packets are (forwarded and) offloaded by
director backup of the conn. For this case, owner is also director of the
conn.
|
|
Y
|
For clustering, identifies a director flow.
|
|
Yo
|
For clustering, indicates that packets are (forwarded and) offloaded by
director of the connection.
|
|
z
|
For clustering, identifies a forwarder flow.
|
|
zo
|
For clustering, indicates that packets are offloaded by a forwarder of
the connection.
|
|
Z
|
Cloud Web Security
|
Note
|
For connections using a DNS server, the source port of the connection may be replaced by the
IP
address
of
DNS
server
in the
show
conn
command output.
|
A single connection is created for multiple DNS sessions, as long as they are between the same two hosts, and the sessions
have the same 5-tuple (source/destination IP address, source/destination port, and protocol). DNS identification is tracked
by app_id, and the idle timer for each app_id runs independently.
Because the app_id expires independently, a legitimate DNS response can only pass through the ASA within a limited period
of time and there is no resource build-up. However, when you enter the
show
conn
command, you will see the idle timer of a DNS connection being reset by a new DNS session. This is due to the nature of the
shared DNS connection and is by design.
Note
|
When there is no TCP traffic for the period of inactivity defined by the
timeout
conn
command (by default, 1:00:00), the connection is closed and the corresponding conn flag entries are no longer displayed.
|
If a LAN-to-LAN/Network-Extension Mode tunnel drops and does not come back, there might be a number of orphaned tunnel flows.
These flows are not torn down as a result of the tunnel going down, but all the data attempting to flow through them is dropped.
The
show
conn
command output shows these orphaned flows with the
V
flag.
When the following TCP connection directionality flags are applied to connections between same-security interfaces (see the
same-security
permit
command), the direction in the flag is not relevant because for same-security interfaces, there is no “inside” or “outside.”
Because the ASA has to use these flags for same-security connections, the ASA may choose one flag over another (for example,
f vs. F) based on other connection characteristics, but you should ignore the directionality chosen.
-
B—Initial SYN from outside
-
a—Awaiting outside ACK to SYN
-
A—Awaiting inside ACK to SYN
-
f—Inside FIN
-
F—Outside FIN
-
s—Awaiting outside SYN
-
S—Awaiting inside SYN
To display information for a specific connection, include the
security-group
keyword and specify a security group table value or security group name for both the source and destination of the connection.
The ASA displays the connection matching the specific security group table values or security group names.
When you specify the
security-group
keyword without specifying a source and destination security group table value or a source and destination security group
name, the ASA displays data for all SXP connections.
The ASA displays the connection data in the format
security_group_name
(
SGT_value
) or just as the
SGT_value
when the security group name is unknown.
Note
|
Security group data is not available for stub connections because stub connection do not go through the slow path. Stub connections
maintain only the information necessary to forward packets to the owner of the connection.
|
You can specify a single security group name to display all connections in a cluster; for example, the following example
displays connections matching security-group mktg in all units of the cluster:
ciscoasa# show cluster conn security-group name mktg
Use the
data-rate
keyword to view the current state of the connection data rate tracking feature—enabled or disabled. Use the
data-rate
filte
r keyword to filter the connections based on the data-rate value in bytes per second. Use the relational operators (lesser
than, equal to, or greater than) to filter the connections data. The output displays the active connections along with two
data rate values—instantaneous one-second and maximum data rate, for both forward and reverse flows.
Examples
When specifying multiple connection types, use commas without spaces to separate the keywords. The following example displays
information about RPC, H.323, and SIP connections in the Up state:
ciscoasa# show conn state up,rpc,h323,sip
The following is sample output from the
show
conn
count
command:
ciscoasa# show conn count
54 in use, 123 most used
The following is sample output from theshow conn command. This example shows a TCP session connection from inside host 10.1.1.15 to the outside Telnet server at 10.10.49.10.
Because there is no B flag, the connection is initiated from the inside. The “U”, “I”, and “O” flags denote that the connection
is active and has received inbound and outbound data.
ciscoasa# show conn
54 in use, 123 most used
TCP out 10.10.49.10:23 in 10.1.1.15:1026 idle 0:00:22, bytes 1774, flags UIO
UDP out 10.10.49.10:31649 in 10.1.1.15:1028 idle 0:00:14, bytes 0, flags D-
TCP dmz 10.10.10.50:50026 inside 192.168.1.22:5060, idle 0:00:24, bytes 1940435, flags UTIOB
TCP dmz 10.10.10.50:49764 inside 192.168.1.21:5060, idle 0:00:42, bytes 2328346, flags UTIOB
TCP dmz 10.10.10.51:50196 inside 192.168.1.22:2000, idle 0:00:04, bytes 31464, flags UIB
TCP dmz 10.10.10.51:52738 inside 192.168.1.21:2000, idle 0:00:09, bytes 129156, flags UIOB
TCP dmz 10.10.10.50:49764 inside 192.168.1.21:0, idle 0:00:42, bytes 0, flags Ti
TCP outside 192.168.1.10(20.20.20.24):49736 inside 192.168.1.21:0, idle 0:01:32, bytes 0, flags Ti
TCP dmz 10.10.10.50:50026 inside 192.168.1.22:0, idle 0:00:24, bytes 0, flags Ti
TCP outside 192.168.1.10(20.20.20.24):50663 inside 192.168.1.22:0, idle 0:01:34, bytes 0, flags Ti
TCP dmz 10.10.10.50:50026 inside 192.168.1.22:0, idle 0:02:24, bytes 0, flags Ti
TCP outside 192.168.1.10(20.20.20.24):50663 inside 192.168.1.22:0, idle 0:03:34, bytes 0, flags Ti
TCP dmz 10.10.10.50:50026 inside 192.168.1.22:0, idle 0:04:24, bytes 0, flags Ti
TCP outside 192.168.1.10(20.20.20.24):50663 inside 192.168.1.22:0, idle 0:05:34, bytes 0, flags Ti
TCP dmz 10.10.10.50:50026 inside 192.168.1.22:0, idle 0:06:24, bytes 0, flags Ti
TCP outside 192.168.1.10(20.20.20.24):50663 inside 192.168.1.22:0, idle 0:07:34, bytes 0, flags Ti
The following is sample output from the show conn command, whcih includes the “X” flag to indicate that the connection is being scanned by the SSM.
ciscoasa# show conn address 10.0.0.122 state service_module
TCP out 10.1.0.121:22 in 10.0.0.122:34446 idle 0:00:03, bytes 2733, flags UIOX
The following is sample output from the show conn detail command. This example shows a UDP connection from outside host 10.10.49.10 to inside host 10.1.1.15. The D flag denotes that
this is a DNS connection. The number 1028 is the DNS ID over the connection.
Uptime represents the total time the SCTP association has been active on the device. The counter begins at the initial handshake
(INIT/INIT-ACK) of the association. Idle indicates the duration since the last packet (including heartbeats) was processed for a specific multi-homing connection.
Examples
ciscoasa# show conn detail
54 in use, 123 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,
C - CTIQBE media, c - cluster centralized,
D - DNS, d - dump, E - outside back connection, e - semi-distributed,
F - outside FIN, f - inside FIN,
G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
k - Skinny media, L - LISP triggered flow owner mobility
l - local director/backup stub flow
M - SMTP data, m - SIP media, n - GUP
N - inspected by Snort
O - outbound data, o - offloaded,
P - inside back connection,
Q - Diameter, q - SQL*Net data,
R - outside acknowledged FIN,
R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,
s - awaiting outside SYN, T - SIP, t - SIP transient, U - up, u - STUN,
V - VPN orphan, v - M3UA W - WAAS,
w - secondary domain backup,
X - inspected by service module,
x - per session, Y - director stub flow, y - backup stub flow,
Z - Scansafe redirection, z - forwarding stub flow
Cluster units to ID mappings:
ID 0: asa1
ID 255: The default cluster member ID which indicates no ownership or affiliation
with an existing cluster member
TCP outside:10.10.49.10/23 inside:10.1.1.15/1026,
flags UIO, idle 39s, uptime 1D19h, timeout 1h0m, bytes 1940435
UDP outside:10.10.49.10/31649 inside:10.1.1.15/1028,
flags dD, idle 39s, uptime 1D19h, timeout 1h0m, bytes 1940435
TCP dmz:10.10.10.50/50026 inside:192.168.1.22/5060,
flags UTIOB, idle 39s, uptime 1D19h, timeout 1h0m, bytes 1940435
TCP dmz:10.10.10.50/49764 inside:192.168.1.21/5060,
flags UTIOB, idle 56s, uptime 1D19h, timeout 1h0m, bytes 2328346
TCP dmz:10.10.10.51/50196 inside:192.168.1.22/2000,
flags UIB, idle 18s, uptime 1D19h, timeout 1h0m, bytes 31464
TCP dmz:10.10.10.51/52738 inside:192.168.1.21/2000,
flags UIOB, idle 23s, uptime 1D19h, timeout 1h0m, bytes 129156
TCP outside:10.132.64.166/52510 inside:192.168.1.35/2000,
flags UIOB, idle 3s, uptime 1D21h, timeout 1h0m, bytes 357405
TCP outside:10.132.64.81/5321 inside:192.168.1.22/5060,
flags UTIOB, idle 1m48s, uptime 1D21h, timeout 1h0m, bytes 2083129
TCP outside:10.132.64.81/5320 inside:192.168.1.21/5060,
flags UTIOB, idle 1m46s, uptime 1D21h, timeout 1h0m, bytes 2500529
TCP outside:10.132.64.81/5319 inside:192.168.1.22/2000,
flags UIOB, idle 31s, uptime 1D21h, timeout 1h0m, bytes 32718
TCP outside:10.132.64.81/5315 inside:192.168.1.21/2000,
flags UIOB, idle 14s, uptime 1D21h, timeout 1h0m, bytes 358694
TCP outside:10.132.64.80/52596 inside:192.168.1.22/2000,
flags UIOB, idle 8s, uptime 1D21h, timeout 1h0m, bytes 32742
TCP outside:10.132.64.80/52834 inside:192.168.1.21/2000,
flags UIOB, idle 6s, uptime 1D21h, timeout 1h0m, bytes 358582
TCP outside:10.132.64.167/50250 inside:192.168.1.35/2000,
flags UIOB, idle 26s, uptime 1D21h, timeout 1h0m, bytes 375617
The following is sample output from the
show
conn
command when an orphan flow exists, as indicated by the
V
flag:
ciscoasa# show conn
16 in use, 19 most used
TCP out 192.168.110.251:7393 in 192.168.150.252:21 idle 0:00:00, bytes 1048, flags UOVB
TCP out 192.168.110.251:21137 in 192.168.150.252:21 idle 0:00:00, bytes 1048, flags UIOB
To limit the report to those connections that have orphan flows, add the
vpn_orphan
option to the
show
conn
state
command, as in the following example:
ciscoasa# show conn state vpn_orphan
14 in use, 19 most used
TCP out 192.168.110.251:7393 in 192.168.150.252:5013, idle 0:00:00, bytes 2841019, flags UOVB
For clustering, to troubleshoot the connection flow, first see connections on all units by entering the
cluster
exec
show
conn
command on the master unit. Look for flows that have the following flags: director (Y), backup (y), and forwarder (z). The
following example shows an SSH connection from 172.18.124.187:22 to 192.168.103.131:44727 on all three ASAs; ASA 1 has the
z flag showing it is a forwarder for the connection, ASA3 has the Y flag showing it is the director for the connection, and
ASA2 has no special flags showing it is the owner. In the outbound direction, the packets for this connection enter the inside
interface on ASA2 and exit the outside interface. In the inbound direction, the packets for this connection enter the outside
interface on ASA 1 and ASA3, are forwarded over the cluster control link to ASA2, and then exit the inside interface on ASA2.
ciscoasa/ASA1/master# cluster exec show conn
ASA1(LOCAL):**********************************************************
18 in use, 22 most used
Cluster stub connections: 0 in use, 5 most used
TCP outside 172.18.124.187:22 inside 192.168.103.131:44727, idle 0:00:00, bytes 37240828, flags z
ASA2:*****************************************************************
12 in use, 13 most used
Cluster stub connections: 0 in use, 46 most used
TCP outside 172.18.124.187:22 inside 192.168.103.131:44727, idle 0:00:00, bytes 37240828, flags UIO
ASA3:*****************************************************************
10 in use, 12 most used
Cluster stub connections: 2 in use, 29 most used
TCP outside 172.18.124.187:22 inside 192.168.103.131:44727, idle 0:00:03, bytes 0, flags Y
The output of
show
conn
detail
on ASA2 shows that the most recent forwarder was ASA1:
ciscoasa/ASA2/slave# show conn detail
12 in use, 13 most used
Cluster:
fwd connections: 0 in use, 0 most used
dir connections: 0 in use, 0 most used
centralized connections: 1 in use, 61 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,
C - CTIQBE media, c - cluster centralized,
D - DNS, d - dump, E - outside back connection, e - semi-distributed,
F - outside FIN, f - inside FIN,
G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
k - Skinny media, L - LISP triggered flow owner mobility
l - local director/backup stub flow
M - SMTP data, m - SIP media, n - GUP
N - inspected by Snort
O - outbound data, o - offloaded,
P - inside back connection,
Q - Diameter, q - SQL*Net data,
R - outside acknowledged FIN,
R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,
s - awaiting outside SYN, T - SIP, t - SIP transient, U - up, u - STUN,
V - VPN orphan, v - M3UA W - WAAS,
w - secondary domain backup,
X - inspected by service module,
x - per session, Y - director stub flow, y - backup stub flow,
Z - Scansafe redirection, z - forwarding stub flow
Cluster units to ID mappings:
ID 0: asa1
ID 1: asa2
ID 255: The default cluster member ID which indicates no ownership or affiliation
with an existing cluster member
TCP outside: 172.18.124.187/22 inside: 192.168.103.131/44727,
flags UIO , idle 0s, uptime 25s, timeout 1h0m, bytes 1036044, cluster sent/rcvd bytes 0/1032983, cluster sent/rcvd total bytes 0/1080779, owners (1,255)
Traffic received at interface outside
Locally received: 0 (0 byte/s)
From most recent forwarder ASA1: 1032983 (41319 byte/s)
Traffic received at interface inside
Locally received: 3061 (122 byte/s)
The following examples show how to display connections for the Identity Firewall feature:
ciscoasa# show conn user-identity
1219 in use, 1904 most used
UDP inside (www.yahoo.com))10.0.0.2:1587 outside (user1)192.0.0.2:30000, idle 0:00:00, bytes 10, flags -
UDP inside (www.yahoo.com)10.0.0.2:1586 outside (user2)192.0.0.1:30000, idle 0:00:00, bytes 10, flags –
UDP inside 10.0.0.34:1586 outside 192.0.0.25:30000, idle 0:00:00, bytes 10, flags –
...
ciscoasa# show conn user user1
2 in use
UDP inside (www.yahoo.com))10.0.0.2:1587 outside (user1)192.0.0.2:30000, idle 0:00:00, bytes 10, flags –
See the following output for the
show
conn
long
zone
command:
ciscoasa# show conn long zone zone-inside zone zone-outside
TCP outside-zone:outside1(outside2): 10.122.122.1:1080 inside-zone:inside1(inside2): 10.121.121.1:34254, idle 0:00:02, bytes 10, flags UO
When you use the
detail
keyword, you can see information about Dead Connection Detection (DCD) probing, which shows how often the connection was
probed by the initiator and responder. For example, the connection details for a DCD-enabled connection would look like the
following:
TCP dmz: 10.5.4.11/5555 inside: 10.5.4.10/40299,
flags UO , idle 1s, uptime 32m10s, timeout 1m0s, bytes 11828, cluster sent/rcvd bytes 0/0, owners (0,255)
Traffic received at interface dmz
Locally received: 0 (0 byte/s)
Traffic received at interface inside
Locally received: 11828 (6 byte/s)
Initiator: 10.5.4.10, Responder: 10.5.4.11
DCD probes sent: Initiator 5, Responder 5
The following is sample output from the show conn detail command, which includes the Initiator and Responder field values for a UDP traffic flow.
ciscoasa# UDP BulkInlineSetNo1:interface2(interface2): 172.16.2.255/138 BulkInlineSetNo1:interface1(interface1): 172.16.2.1/138,
flags - N(egress-optimization FR), idle 11s, uptime 11s, timeout 2m0s, bytes 437, flow id 12123, Snort id 12, rule id 268434436, Rx-RingNum 23, Internal-Data0/1
Initiator: 172.16.2.1, Responder: 172.16.2.255
Connection lookup keyid: 7021890
The following example shows how to view the status of connection data-rate tracking feature:
ciscoasa# show conn data-rate
Connection data rate tracking is currently enabled.
The following example shows how to filter the connection based on a specified data-rate:
ciscoasa# show conn detail data-rate-filter ?
eq Enter this keyword to show conns with data-rate equal to specified value
gt Enter this keyword to show conns with data-rate greater than specified
value
lt Enter this keyword to show conns with data-rate less than specified value
ciscoasa# show conn detail data-rate-filter gt ?
<0-4294967295> Specify the data rate value in bytes per second
ciscoasa# show conn detail data-rate-filter gt 123 | grep max rate
max rate: 3223223/399628 bytes/sec
max rate: 3500123/403260 bytes/sec
Feedback