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.
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.
There happens to be a question (which is actually a response) from somebody who encountered the same issue, but with ADFS. He also created an external script, and I find his method of calling openssl a lot 'prettier' than my (echo $something; sleep 5) | openssl ..... . I think I should maybe change my script to match his method - will test that.
To 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
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?
@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.
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.
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.
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
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?? 😀
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??
