ASA TCP Connection Flags

When troubleshooting TCP connections through the ASA, the connection flags shown for each TCP connection provide a wealth of 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.

Here is the output of the show conn protocol tcp command, which shows the state of all TCP connections through the ASA. These connections can also be seen with the show conn command.

ASA# show conn protocol tcp

101 in use, 5589 most used

TCP outside 10.23.232.59:5223 inside 192.168.1.3:52419, idle 0:00:11, bytes 0, flags saA

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:443 inside 192.168.1.3:52427, idle 0:01:02, bytes 4504, flags

TCP outside 10.23.232.217:5223 inside 192.168.1.3:52425, idle 0:00:10, bytes 0, flags saAUIO

TCP outside 10.23.232.57:5223 inside 192.168.1.3:52412, idle 0:00:23, bytes 0, flags saA

TCPoutside 10.23.232.60:5223 inside 192.168.1.3:52413, idle 0:00:23, bytes 0, flags saATCP

TCP outside 10.23.232.116:5223 inside 192.168.1.3:52408, idle 0:00:23, bytes 0, flags saA

TCP outside 10.23.232.96:5223 inside 192.168.1.3:52421, idle 0:00:11, bytes 0, flags saAsaA

TCP outside 10.23.232.190:5223 inside 192.168.1.3:52424, idle 0:00:10, bytes 0, flags

The next picture shows the 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.

  

TCP Connection Flag Values

Additionally, in order to view all of the possible connection flags issue the show connection detail command on the command line:

ASA# show conn detail

84 in use, 1537 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,D - DNS, d - dump, E - outside back connection, F - outside FIN, f - inside FIN,G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,k - Skinny media, M - SMTP data, m - SIP media, n – GUP, i - incomplete, J - GTP, j - GTP data, K - GTP t3-response ,O - outbound data, P - inside back connection, p - Phone-proxy TFTP connection, inside acknowledged FIN, S - awaiting inside SYN,q - SQL*Net data, R - outside acknowledged FIN,R - UDP SUNRPC, r -s - awaiting outside SYN, T - SIP, t - SIP transient, U - up, V - VPN orphan, W - WAAS,X - inspected by service module

TCP has a 3-way connection establishment handshake, and a pair of 2-way close handshakes.

The PIX, like many other professional firewalls, is a stateful firewall. Essentially, this means that the PIX actively monitors all connection oriented traffic (mainly TCP), and builds a connection table (or database) that it uses to keep track of active sessions. Depending on where you set your buffer logging, you can see both the building and teardown of TCP connections that traverse the firewall. For example, you may have a user opening up an FTP session from the inside of your network out to the internet somewhere. In this case, you will see the PIX log a message like:

Built outbound tcp connection for IP address/sourceport to IP Address/21... (word order not exact, but you get the idea)

This log message indicates the start of the 3-way handshake process (it does not mean that it worked, however...)

You can now do a "show conn" on the PIX command line, and you should see a line in there for this particular TCP session. The destination port would be 21, since this is an FTP. Also, there are some flags at the end of the line. If the connection was successful, you will see a capital U (for Up, meaning the 3-way handshake was successful). If you have any a's or s's (small or upper case), then something didn't work, and you are most likely in a SYN-Sent state, waiting for the remote Ack-SYN. That's a whole other conversation though...

Back to the topic - let's say that this connection failed, perhaps the remote FTP server is down. The PIX has some Global connection timeout values. The default value for a half-open, (embryonic) connection is 2 minutes. If the remote server doesn't send the ACK-SYN back to the initial connection establishment, then the PIX will clear the connection from it's table, and log a connection teardown message.

There are about 3 or 4 types of teardown messages that can be logged (if memory serves me). At the very end of the log entry there is a reason. Some of them are:

FINs

TCP-Reset-O

TCP-Reset-I

Conn-Timeout

Deny

There may be others, but you'd have to check the PIX docs to see (if it's even in there...)

I know you're going to ask, so here is what each one means:

FINs - this represents a normal close - in other words the two systems talking to each other mutually agreed to close the session. This is normal behavior.

TCP-Reset-O (or I): Another way that a TCP session can be closed is for one of the parties to send a TCP-Reset. This is essentially a packet that tells the other side that "I'm hanging up on you". It's the TCP/IP equivalent to when you really piss off your girlfriend, and she slams down the phone in your ear. The difference between the I and the O has to do with the interface the reset was heard from. If it's an I, it means inside - but not necessarily the actual inside interface... it's the interface that has the higher security value of the two interfaces being used to build the connection in question. If it's an O, then it came from the lower security interface...

Conn-Timeout - just what you think - this refers back to the scenario I mentioned above with the FTP session and the remote server being down. After that 2 minute timer expires, the PIX will log the teardown with this as the reason. You will also see this if the PIX active connection idle timer expires too (default is 1 hour for that). And lastly, you can see this if the two systems fail to exchange the TCP-FIN process properly (normal close process). The normal close process, by the way, is simply a FIN packet from the system who is initiating the close request, and the other side is supposed to ACK the FIN (that's one pair). Now the session is 'half-closed'. Once the remote side is ready to close the connection too, it sends a FIN, and the other side should ACK it. Now it's fully closed. If part of this pair of 2-way handshake fail, then the connection according to the PIX is half closed (you'll see F flags in the show conn command output). The half-closed timer I believe is 5 minutes. If the connection doesn't close normally after that 5 minute counter expires, the PIX clears the connection from it's table and logs this conn-timeout reason in the teardown.

Lastly, there is 'Deny'. This one is seldomly observed. Generally, you would see it if a connection that was being application inspected (via the fixup's, like FTP or http, for example), violated the fixup rulebase. The PIX would clear the connection and log the deny as the reason in the teardown message. I've seen really old FTP servers do this.

Anyway - I hope this clears things up a bit for you. If you are using the PIX for your business and you have a lot of traffic going through it, I highly recommend you learn more about the connection table, especially the flags at the end. The PIX can be a very powerful troubleshooting tool when the application clowns are telling you there is a network problem (the story of my life!). Between the logs and the connection flags, you can pretty much see what's going on at any given moment in time - excellent for real time troubleshooting - and tossing the problem back in their laps!