F5 maintains a SSL session opened until 16 seconds after it receives a FIN request

Hi,

 

 

Can you open a case with F5 Support on this and report back on what they find?

 

 

Thanks, Aaron

Wow, that's a good one. There could be a few things going on here. I'm betting that this is a typical half-close, TIME_WAIT thing but we can't confirm that until we track down the source of that 16 seconds. If I am right, I'd expect to see a MSL of 8 seconds somewhere on the host side of the BigIP, but that seems odd to me somehow. Just to make sure I understand: I would expect the client (BigIP) to send the first FIN here, so are you seeing something like this?

 

 

(C) (S)

 

FIN---> close_wait

 

fin_wait <--- ACK

 

time_wait <---- FIN

 

...16 seconds pass, you go get a beer, etc.

 

ACK---> closed

 

 

Is that diagram correct?

 

 

Also, have you by chance tried this with a typical HTTP monitor? Is that monitor HEAD request correct? I'd expect \r\n\r\n at the end to complete it. If you're seeing the FIN come from the server first, I wonder if it's responding to a request that's incomplete (missing the two CRLF), then sending its FIN, at which point there's some timeout on the request side...but I suppose I'd expect a RST in that picture...hmm you got me churning on this one!

 

 

One other note: there's been some debate on RFC 2616 and HTTP connection management regarding how much consideration was given to how TCP does its thing. If you're interested you may want to read through this - not that it's got a solution to this issue but it may be a factor:

 

 

http://lists.w3.org/Archives/Public/ietf-http-wg-old/2001JanApr/0036.html

 

 

-- and and old but really interesting draft discussing connection management.

 

http://ftp.ics.uci.edu/pub/ietf/http/draft-ietf-http-connection-00.txt

 

 

Keep us posted, and more data would be appreciated :)

 

-Matt

Thanks for the interest Matt.

 

 

First of all I have to say that unfortunately I don´t have the server private key, so I just can see at tcp level in the packet capture, I can´t go deeper into HTML because it´s encrypted. Once cleared this point, I continue:

 

 

Your diagram isn´t ok. The communication is going on some weird, I show you how is the flow:

 

 

 

(C) (S)

 

<------ FIN

 

Encrypted Alert------>

 

<------ ACK to Encrypted alert

 

 

After 16 seconds

 

 

------> FIN

 

Closed<------ ACK

 

 

 

As you can see, the first FIN comes from the server side, and I´d expect it because I send a close session instruction into the head request to the server. About the CRLF, I don´t think those are necessary because my BIG IP is on the 10.1.0 version, however I did do some tests adding those character at the end of the request and the issue persists.

 

 

Regarding to the HTTP typical monitor the answer is yes. I´ve tried doing the same request on other different servers and it works perfectly, the F5 closes the session once it receives the FIN request (it doesn´t wait). I can´t do this type of monitor (typical http) in the server that is presenting the issue because it only listens on the port 443.

 

 

Please let me know what kind of information would help you to try to understand/clarify what´s happening.

 

 

Also I´ve tried to do the request manually helped by the command: "openssl s_client -host X.X.X.X -port 443"; when I do this test the communication seems to flow ok. The server closes the connection and the same happens with the F5 without waiting 16 seconds.