HTTPS SNI Monitoring How-to

Hi,

You may or may not already have encountered a webserver that requires the SNI (Server Name Indication) extension in order to know which website it needs to serve you. It comes down to "if you don't tell me what you want, I'll give you a default website or even simply reset the connection". A typical IIS8.5 will do this, even with the 'Require SNI' checkbox unchecked.

So you have your F5, with its HTTPS monitors. Those monitors do not yet support SNI, as they have no means of specifying the hostname you want to use for SNI.

In comes a litle script, that will do exactly that.

Here's a few quick steps to get you started:

  1. Download the script from this article (it's posted on pastebin: http://pastebin.com/hQWnkbMg).
  2. Import it under 'System' > 'File Management' > 'External Monitor Program File List'.
  3. Create a monitor of type 'External' and select the script from the picklist under 'External Program'.
  4. Add your specific variables (explanation below).
  5. Add the monitor to a pool and you are good to go.

A quick explanation of the variables:

  • METHOD (GET, POST, HEAD, OPTIONS, etc. - defaults to 'GET')
  • URI ("the part after the hostname" - defaults to '/')
  • HTTPSTATUS (the status code you want to receive from the server - defaults to '200')
  • HOSTNAME (the hostname to be used for SNI and the Host Header - defaults to the IP of the node being targetted)
  • TARGETIP and TARGETPORT (same functionality as the 'alias' fields in the original monitors - defaults to the IP of the node being targetted and port 443)
  • DEBUG (set to 0 for nothing, set to 1 for logs in /var/log/ltm - defaults to '0')
  • RECEIVESTRING (the string that needs to be present in the server response - default is empty, so not checked)
  • HEADERX (replace the X by a number between 1 and 50, the value for this is a valid HTTP header line, i.e. "User-Agent: Mozilla" - no defaults)
  • EXITSTATUS (set to 0 to make the monitor always mark te pool members as up; it's fairly useless, but hey... - defaults to 1)

There is a small thing you need to know though: due to the nature of the openssl binary (more specifically the s_client), we are presented with a "stdin redirection problem". The bottom line is that your F5 cannot be "slow" and by slow I mean that if it requires more than 3 seconds to pipe a string into openssl s_client, the script will always fail. This limit is defined in the variable "monitor_stdin_sleeptime" and defaults to '3'. You can set it to something else by adding a variable named 'STDIN_SLEEPTIME' and giving it a value. From my experience, anything above 3 stalls the "F5 script executer", anything below 2 is too fast for openssl to read the request from stdin, effectively sending nothing and thus yielding 'down'. When you enable debugging (DEBUG=1), you can see what I mean for yourself: no more log entries for the script when STDIN_SLEEPTIME is set too high; always down when you set it too low.

 

I hope this script is useful for you,

Kind regards,

Thomas Schockaert

Published Mar 23, 2014
Version 1.0
availability
deployment
https
management
monitor
monitoring
openssl
security
sni
ssl
  • Nikoolayy1's avatar
    Nikoolayy1
    Icon for MVP rankMVP
    Oct 17, 2019

    I just noticed that it is "$sleep" , shouldn't it be just "sleep" as this is a command ? Also this is a linked article to this one:

     

    https://devcentral.f5.com/s/articles/https-sni-monitor

  • Peter_Baumann's avatar
    Peter_Baumann
    Icon for Cirrostratus rankCirrostratus
    Aug 14, 2019

    Just for information:

    I just opened a support case asked to be added to the already existing RfE ID 453494.

     

    --> Support can't handle RfE, they informed me to contact Sales Representative or Account Manager what I'm doing now...

  • Peter_Baumann's avatar
    Peter_Baumann
    Icon for Cirrostratus rankCirrostratus
    Aug 14, 2019

    Hi ,

    Today I had the time to test the In-TMM Monitoring on a test instance and it was working quite well.

    Since we have only generic ICMP/HTTP/HTTPS monitors, all of them are still running.

    You will see the following in the log:

    # modify sys db bigd.tmm value enable
 
Aug 14 13:52:29 slot1/f5-test-mng notice tmm[12672]: 01ad0000:5: Monitor Agent TMM 0: channel connection opened
Aug 14 13:52:29 slot1/f5-test-mng notice tmm[12672]: 01ad0002:5: Monitor Agent TMM 0: channel authenticated
Aug 14 13:52:29 slot1/f5-test-mng notice tmm[12672]: 01ad0014:5: Monitor Agent TMM 0: created activity: proto TMA_PROTO_HTTP, endpoint 1.4.2.9:80, monitor /Common/http_test
Aug 14 13:52:29 slot1/f5-test-mng notice tmm[12672]: 01ad0014:5: Monitor Agent TMM 0: created activity: proto TMA_PROTO_GATEWAY_ICMP, endpoint 1.4.7.5:0, monitor /Common/icmp_Routing-Pool
Aug 14 13:52:29 slot1/f5-test-mng notice tmm[12672]: 01ad0014:5: Monitor Agent TMM 0: created activity: proto TMA_PROTO_GATEWAY_ICMP, endpoint 1.4.2.1:0, monitor /Common/icmp_Routing_via_NewDCA
Aug 14 13:52:29 slot1/f5-test-mng notice tmm[12672]: 01ad0014:5: Monitor Agent TMM 0: created activity: proto TMA_PROTO_GATEWAY_ICMP, endpoint 1.4.4.1:0, monitor /Common/icmp_Routing_via_NewDCB
Aug 14 13:52:34 slot1/f5-test-mng notice tmm[12672]: 01ad0014:5: Monitor Agent TMM 0: created activity: proto TMA_PROTO_GATEWAY_ICMP, endpoint 1.4.6.1:0, monitor /Common/icmp_Routing-Pool

    So In-TMM Health Monitoring has started processing.

    I planned to start tests with a SNI monitor but then I found the following "show-stopper":

    Bug ID 778517: Large number of in-TMM monitors results in delayed processing

    https://cdn.f5.com/product/bugtracker/ID778517.html

    We did tests with External scripts as SNI health monitors but this was leading to a too high loadad big-ip then.

    With the "show-stopper" above it makes no sense to use this kind of health-monitoring on our about 1500 virtual-servers and manymany health monitors loaded machine.

    The question is now again:

    When is F5 implement a native SNI health monitor to the big-ips??

  • ErikM's avatar
    ErikM
    Icon for Cirrus rankCirrus
    Aug 12, 2019

    Hi anyone,

     

    So, enabling In-TMM monitoring requires changing monitor functions to TMM kernel instead of the bigd process. This is a global setting. Do you have any idea what the impact will be on existing monitors? For instance, are there any types of monitors that will not run in the TMM mode? And what else will be different, if anything? KB article is not too clear about this.

     

    And if this type of monitoring requires less system resources then why on earth is it disabled by default?? 😀

     

    Erik

     

     

  • John_Beckmann's avatar
    John_Beckmann
    Icon for Employee rankEmployee
    Jul 01, 2019

    This has actually been implemented in 13.1.0

     

    K11323537: Configuring In-TMM monitoring

    https://support.f5.com/csp/article/K11323537

     

    This allows you to add a ServerSSL Profile to a Monitor, and in the ServerSSL Profile, you can specify a SNI.

     

    # list ltm monitor https https_in_tmm

    ltm monitor https https_in_tmm {

       adaptive disabled

       defaults-from https

       destination *:*

       interval 5

       ip-dscp 0

       recv none

       recv-disable none

       send "GET /\r\n"

       ssl-profile /Common/in-tmm-monitor

       time-until-up 0

       timeout 16

    }

    ltm profile server-ssl in-tmm-monitor {

       app-service none

       defaults-from serverssl

       server-name email.apmjb2.local

    }

     

    Now the monitor sends an SNI of email.apmjb2.local

     

    # tshark -r /shared/tmp/tmm_sni.pcap -T fields -e ssl.handshake.extensions_server_name -R "ssl.handshake.extensions_server_name" -2

    email.apmjb2.local

     

     

  • Peter_Baumann's avatar
    Peter_Baumann
    Icon for Cirrostratus rankCirrostratus
    Jun 26, 2019

    The script is nice but there's a problem in general with the BIG-IP:

    When this monitor is used on a BIG-IP with a large configuration, the load goes very high so that error will show up with monitoring etc.

    But this is more a general problem using external scripts for health monitoring.

     

    I'm wondering when F5 will start to add SNI health monitoring features to the native monitors??

  • Peter_Baumann's avatar
    Peter_Baumann
    Icon for Cirrostratus rankCirrostratus
    Jun 26, 2019

    @daboochmeister SNI is another method than HTTP Host Header, see here:

    https://www.researchgate.net/figure/SNI-extension-of-the-TLS-handshake-protocol_fig6_321580115

     

  • John_Beckmann's avatar
    John_Beckmann
    Icon for Employee rankEmployee
    Jun 19, 2019

    HEADER1="User-Agent: Mozilla"

    HEADER2="MyHeader: MyValue"

    etc

    If the script find these, then is sets the Headers as indicated

     

  • ErikM's avatar
    ErikM
    Icon for Cirrus rankCirrus
    Jun 17, 2019

    Hi Thomas,

     

    You write:

     

    A quick explanation of the variables:

    <snip>

    • HEADERX (replace the X by a number between 1 and 50, the value for this is a valid HTTP header line, i.e. "User-Agent: Mozilla" - no defaults)

    <snip>

     

    Could you please tell me where i can find which number references which header?

     

    Thanks,

     

    Erik

     

  • Richard_Tocci's avatar
    Richard_Tocci
    Icon for Employee rankEmployee
    May 17, 2019

    Log a support case and ask to be added to BZID453494. This is the RFE for HTTPS SNI monitors.