Forum Discussion
MW1
Cirrus
CirrusHTTPS monitor (and curl on a LTM/GTM) fails to connect full
All,
apologies as I realise this may not be 100% F5 but I'm only getting the issue on F5 devices so was hoping someone would be friendly enough to point me in the right direction for troubleshooting. I'm trying to setup a simple HTTPS health monitor on a LTM which matches 'SEND' on a page. (quick background this is not a actual webserver but an app built on the openSSL packages and displays in a web browser without issue). As the monitor fails I tried using curl, from my curl on my windows box it works without issue (using curl -vk https://208.16.209.148 and its curl/7.19.4). However when trying curl from several LTM's at different location I just get:
* About to connect() to 208.16.209.148:443
* Connected to 208.16.209.148 (208.16.209.148) port 443
and then no more, it doesn't show a handshake on the SSL etc. If this was plain HTTP I'd run a packet sniffer but a its HTTPS I presume there is no point as I can't see inside the communication. Can anyone suggest a way to trouble shoot this further?
thanks in advance
Matt
6 Replies
MW1Just as an update I've tested curl from a fedora 10 box against the IP and that works without issue as well.- MW1Further update I was dropping out of the curl session too early on the LTM/GTM's and it appears to be a SSL handshake issue as I get the following if I leave it at the connected msg (see below) for about 3-4 mins):
curl -vk https://208.16.209.148:443 * About to connect() to 208.16.209.148:443
* Connected to 208.16.209.148 (208.16.209.148) port 443
* SSL: error:00000000:lib(0):func(0):reason(0)
* Closing connection 0
curl: (35) SSL: error:00000000:lib(0):func(0):reason(0)
As previously stated this works with versions of curls I've tested on both fedora and windows (and now redhat) so I presumed to go the heart fo the issue I needed to use openSSL's s_client which gives similar:
Loading 'screen' into random state - done
CONNECTED(00000774)
3560:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:.\ssl\s23_lib.c:188:
So from testing it may well an issue with the openSSL packages which I presume F5 calls to use for their HTTPS health monitor. - MW1Just as an update it appears there was a slight difference between curl on windows/fedora and the one on the F5 and I had to force SSLv3 and it works. The same goes for the the openssl s_client. However forcing SSLv3 on the F5 monitor still fails.
Does anyone know how to debug a health monitor further? - dennypayne
Employee
LTM does have ssldump, so that might help in digging into the payload to see what's going on. Nothing else is jumping out at me so far though..
Denny 
hoolioCirrostratus
You might be able to get more detailed info by enabling debug on the monitoring daemon, bigd:
b db bigd.debug enable
The output is written to /var/log/bigdlog
Make sure to disable debug (b db bigd.debug disable) when you're done as the log file can get out of hand quickly.
Aaron- MW1All - thanks for the replies. Heres how my ticket ended with F5 tech support regarding getting the HTTPS inbuilt monitor to work:
feedback from the (f5) Dev team which confirm that the code does indeed always send SSLv2+ client hello messages in an attempt to be maximally compatible.
They have filled a RFE (request for enhancement) to add a way to force bigd to send TLSv1/SSLv3 Client Hello instead of SSLv2. This is CR120244.
As the app I was trying to run in against was a inhouse written one it was dropping the SSL handshake when it received the SSLv2 Hello (basically wasn't seeming to follow the rfc's quite). After forcing sslv3 on curl I was able to use a shell script monitor.
thanks
Matt
