TCP Half-Close Session -
TCP is a unicast connection-oriented protocol. Before either end can send data to the other, a connection must be established between them. During connection establishment, several options can be exchanged between the two endpoints regarding the parameters of the connection. Some options are allowed to be sent only when the connection is established, and others can be sent later.
A connection typically goes through three phases:
- Establishment
- Data transfer (called established)
- Teardown (closing).
Some of the difficulty in creating a TCP session is handling all of the transitions between and among these phases correctly.
A typical TCP connection establishment and close (without any data transfer) is shown below:
The figure above also shows how a TCP connection is closed (also called cleared or terminated). Either end can initiate a close operation, and simultaneous closes are also supported. Traditionally, it was most common for the client to initiate a close. However, other servers (e.g., Web servers) initiate a close after they have completed a request. Usually a close operation starts with an application indicating its desire to terminate its connection (e.g., using the close () system call). The closing TCP initiates the close operation by sending a FIN segment (a TCP segment with the FIN bit field set). The complete close operation occurs after both sides have completed the close:
- The client (Initiator) sends a FIN segment specifying the current sequence number. The FIN also includes an ACK for the last data sent.
- The server (responder) responds by ACKing value K + 1 to indicate its successful receipt of the client’s FIN. At this point, the application is notified that the other end of its connection has performed a close. Typically this results in the application initiating its own close operation.
- To complete the close, the final segment contains an ACK for the last FIN. Note that if a FIN is lost, it is retransmitted until an ACK for it is received.
The rule is that either end can send a FIN when it is done sending data. When a TCP receives a FIN, it must notify the application that the other end has terminated that direction of data flow. The sending of a FIN is normally the result of the application issuing a close operation, which typically causes both directions to close.
TCP Half Close –
TCP supports a half-close operation.
The half-close operation in TCP closes only a single direction of the data flow. Two half-close operations together close the entire connection.
TCP Half-Close connections are when a server or client sends a FIN when it is done sending data, but the other side is not finished sending data. Due to this condition, the other side continues to send data.
This is because TCP allows you to close each direction of the connection independently.
Below figure shows TCP Half Closed Stage.
HOW DOES A PALO ALTO FIREWALL HANDLE TCP HALF-CLOSE CONNECTIONS?
In this scenario, when the Palo Alto firewall sees the FIN from either side, the session goes to TCP-WAIT mode which resets the session time-to-live to 30 seconds. The session will remain in the ACTIVE state for 30 seconds and the session is closed afterwards. Thus, further data sent by the other side after these last 30 seconds will be discarded causing applications to fail.
If applications handled in this manner are causing the sessions to fail, the tcp-wait timer can be increased:
From Web UI -
Go to Device > Setup > Session
Edit the Session Timeouts section
Edit the value for "TCP wait"
From CLI -
# set deviceconfig setting session timeout-tcpwait <time-in-seconds>
It is recommended to be cautious with this setting as it may cause an increase in the use of the session table, as more sessions may remain open and consume session table entries.
Hope you find this helpful!
Mayur
