what's teardown meaning in "sh log"

Hi guys, when I run command "show log" in PIX firewall, I don't understand what "teardown TCP connection" mean. Does it mean that the connection was dropped? Thanks for help!

I've never worked with PIX, but I looked up the message for you, and essentially, yes, it means the TCP connection was dropped. TCP connections have a four way handshake termination, as you probably already know, with both hosts acknowledging each other's separate termination of their side of the connection. So that's where the message "Teardown TCP Connection" gets it's meaning.

I'll take jwj's explanation a step further for you.

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 realtime troubleshooting - and tossing the problem back in their laps!

tGc

For every Built Connection, there'll always be a teardown. Now there are not few but many reasons of a teardown when you 'specifically' talk about a Pix firewall log. Here are a few reasons:

Conn-timeout
Connection ended because it was idle longer than the configured idle timeout.

Deny Terminate
Flow was terminated by application inspection.

FIN Timeout
Force termination after 10 minutes awaiting the last ACK or after half-closed timeout.

Flow closed by inspection
Flow was terminated by inspection feature.

Flow terminated by IPS
Flow was terminated by IPS.

Flow reset by IPS
Flow was reset by IPS.

Invalid SYN
SYN packet not valid.

Idle Timeout
Connection timed out because it was idle longer than timeout value.

IPS fail-close
Flow was terminated due to IPS card down.

SYN Control
Back channel initiation from wrong side.

SYN Timeout
Force termination after two minutes awaiting three-way handshake completion.

TCP bad retransmission
Connection terminated because of bad TCP retransmission.

TCP FINs
Normal close down sequence.

TCP Invalid SYN
Invalid TCP SYN packet.

TCP Reset-I
Reset was from the inside (high security).

TCP Reset-O
Reset was from the outside (low security).

TCP segment partial overlap
Detected a partially overlapping segment.

TCP unexpected window size variation
Connection terminated due to variation in the TCP window size.

Tunnel has been torn down
Flow terminated because tunnel is down.

Unauth Deny
Denied by URL filter.

Unknown
Catch-all error.

Xlate Clear
Command-line removal


Hope that makes the reason crystal.


Rahul...!!!
Empowering The Internet Generation