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:
- Download the script from this article (it's posted on pastebin: http://pastebin.com/hQWnkbMg).
- Import it under 'System' > 'File Management' > 'External Monitor Program File List'.
- Create a monitor of type 'External' and select the script from the picklist under 'External Program'.
- Add your specific variables (explanation below).
- 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
- Jesse_FlintNimbostratus
Not to Necro a thread... (this is 2 years old)... but is there ANY future support planned for HTTPS health monitors to support SNI? This problem is just going to get worse and worse and I really dont want to have dozens of custom scripts "running" on each of my devices like this... Not to mention, they are difficult to adjust/manage.. I do appreciate this response though.. Kudos to the OP
- John_BeckmannEmployee
There seems to be a bug in the script if you try to set a HEADER
http_content=
(echo -e "$monitor_method $monitor_uri HTTP/1.1\r\nHost: $monitor_hostname\r\n${monitor_header}\r"; $sleep $monitor_stdin_sleeptime) | $openssl s_client -connect $monitor_targetip:$monitor_targetport -servername $monitor_hostname
After the ${monitor_header} there is only a \r but it should be \r\n
- Abed_AL-RCirrostratus
we configured this and it is working https://devcentral.f5.com/s/articles/big-ip-and-adfs-part-5-working-with-adfs-30-and-sni
 
- Abed_AL-RCirrostratus
Hi
Has someone tried to implement this on version 12.1.3.5 and worked for him ?
- Parker_BarthlomNimbostratus
Has anyone gotten this monitor to work? I've tried everything I can think of, including hardcoding values into the script, but still cannot get it to mark a node "UP". I am using 12.1.2.
- Richard_TocciEmployee
Correct. Do a packet capture of the monitor traffic, and the server_name TLS extension is NOT sent by the monitor daemon to the server. When the server requires it and it's not sent by the client, the server resets the connection.
- Opher_Shachar_6Nimbostratus
@daboochmeister It is about the TLS extension of Server Name. This happens at the SSL negotiation level that takes place before the HTTP request is sent. ADFS for example will reset the connection if no SNI extension is given in the SSL's ClientHello.
I'm confused on why this script would be needed. If you know the hostname which you want to be included in the HTTPS probe (which seems to be a req't for this script), why don't you simply create an HTTPS monitor, then adjust the Send string to be HTTP/1.1 and include the correct hostname, e.g.:
GET / HTTP/1.1\r\nHost: sni-name.whateverdomain.com\r\nConnection: Close\r\n\r\n
That always works for me in such situations. What advantage does this script have over doing that?
- Max_Q_factorCirrocumulusThe Microsoft Active Directory Federation Services (BIG-IP v11: LTM, APM) deployment guide has a nice working SNI script referenced in it.
- Skye_85590NimbostratusTo anyone out there that would like to help provide visibility to getting built-in SNI support for BIGIP monitors, please drop a case and ask to have it tied to the request for enhancement for this: ID 453494