CISCO ASA

TCP CONNECTION FLAGS

  
ASA TCP Connection Flags

When troubleshooting TCP connections through the ASA, the connection flags shown for each TCP
connection provide the information about the state of TCP connections to the ASA. This information
can be used to troubleshoot problems with the ASA, as well as problems elsewhere in the network.

The show conn detail command reveals the available connection flags.

 TCP outside 192.168.3.5:80 dmz 172.16.103.221:57646, idle 0:00:29, bytes 2176, flags UIO
 TCP outside 10.23.232.217:5223 inside 192.168.1.3:52425, idle 0:00:10, bytes 0, flags saA
 TCP outside 10.23.232.217:443 inside 192.168.1.3:52427, idle 0:01:02, bytes 4504, flags UIO

TCP Connection Flag Values

ASA TCP Connection flags at different stages of the TCP state machine. The connection flags can be
seen with the show conn command on the ASA.
 Refer below image, showing the step by step OUTBOUND and INBOUND connection formation
with respect to ASA flags.

T h e f o l l o w i n g s t e p

outbound flow represented in Figure.

Step 1
After the SYN sent by the inside client has crossed the firewall (first step of the three-way
handshake), ASA waits for the SYN/ACK from the outside server (second step) and expecting ACK
from client (third step). ASA represents this first phase with the combination of flags saA.

Step 2
Having received the SYN/ACK back from the outside server, ASA clears the sa indication and keeps
only the A flag. (Because the inside ACK is still missing.)

Step 3
 ASA registers the receipt of the inside ACK with the U flag, a way to state that the setup phase is over
and that the connection is considered up.

Step 4
The addition of the I flag in the fourth step means that the data was received from the outside
(inbound data).

Step 5
The insertion of the O flag means that outbound data (data from the inside) has been seen by ASA.
The combination UIO of the last step tells that the connection is up and that data was already
received from both the outside server and the inside client.

Case Study

TCP VPN 10.99.55.44(18.17.16.15):11515 inside 10.88.77.66:30854, idle 0:02:48, bytes 178, flags
UIO

This traffic flow has completed the 3 way TCP handshake (U), has had both inbound (I) packet and
outbound (O) packets.

TCP outside 77.66.55.44:49368 VPN 15.15.15.15:443, idle 0:00:21, bytes 100531, flags UfrIOB

This traffic flow originated from the outside (B), has completed the 3 way TCP handshake (U), has had
both inbound (I) packet and outbound (O) packets. This flow also saw a fin packet sent to the inside
(f) and the inside also acknowledged the fin.

UDP VPN 10.17.17.17:8500 inside 10.20.20.20:4167, idle 0:01:38, bytes 616, flags -

This flow has no flags because it’s a UDP packet and therefore is stateless.

TCP VPN 77.66.55.44:30031 inside 10.20.20.20:51716, idle 0:00:11, bytes 0, flags U

This flow is just completing the 3 way handshake (U).

TCP inside 10.20.20.20:10101 outside 10.30.30.30:4450, idle 0:00:14, bytes 0, flags SaAB

A SYN was sent from 10.20.20.20 on the inside to 10.30.30.30 on the outside.