SSL handshake failure

Hello,

we're seeing a weird behaviour during SSL handshake where the client (on an Android mobile device) sends the ClientHello to the LB but the LB does not send back the ServerHello. We see the clientHello come in and then 60 seconds later a "TCP RST" sent by the LB. We considered that it might be related to session resume but we found out that most of the sessions are resumed successfully.

I read online (http://ask.wireshark.org/questions/14419/ssl-record-layer-vs-sslv3-record-layer) that "In the transition from SSLv2 to SSLv3 backward compatibility was ensured by using a SSLv2 record layer header. But today most servers won't allow (the insecure) SSLv2 protocol, so if the client tries a SSLv2 compatible handshake, the server just denies the connection". I tried disabling SSLv2 by adding the following lines to my clientssl profile:

ciphers "!SSLv2:ALL:!DH:!ADH:!EDH:@SPEED"

renegotiate enable

This did not have any impact as we kept encountering the same behaviour of no ServerHello sent by the LB. I also checked whether we are hitting our SSL TPS limits but found that we are nowhere near.

I have attached the tcpdump of the failing ClientHello. Has anybody come across this type of behaviour? what could be the cause? Is that possibly a bug in F5?

Our F5 is running with:

Kernel:

Linux 2.6.18-164.11.1.el5.1.0.f5app

Package:

BIG-IP Version 10.2.1 297.0

Final Edition