Forum Discussion

MW1's avatar
MW1
Icon for Cirrus rankCirrus
Mar 27, 2009

HTTPS 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
management
monitoring
  • MW1's avatar
    MW1
    Icon for Cirrus rankCirrus
    Mar 27, 2009
    Just as an update I've tested curl from a fedora 10 box against the IP and that works without issue as well.
  • MW1's avatar
    MW1
    Icon for Cirrus rankCirrus
    Mar 30, 2009
    Further 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.

     

     

     

  • MW1's avatar
    MW1
    Icon for Cirrus rankCirrus
    Apr 02, 2009
    Just 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's avatar
    dennypayne
    Icon for Employee rankEmployee
    Apr 02, 2009
    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
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Apr 02, 2009
    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
  • MW1's avatar
    MW1
    Icon for Cirrus rankCirrus
    Apr 27, 2009
    All - 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