on 23-Mar-2014 15:57
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:
A quick explanation of the variables:
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
Thanks for posting this great solution. Could you add the code to the Devcentral codeshare too so it's preserved for future reference?
https://devcentral.f5.com/wiki/AdvDesignConfig.codeshare.ashx
Thanks, Aaron
Done.
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.
Kind regards,
Thomas
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.
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
 
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
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
Log a support case and ask to be added to BZID453494. This is the RFE for HTTPS SNI monitors.
Hi Thomas,
You write:
A quick explanation of the variables:
<snip>
<snip>
Could you please tell me where i can find which number references which header?
Thanks,
Erik
HEADER1="User-Agent: Mozilla"
HEADER2="MyHeader: MyValue"
etc
If the script find these, then is sets the Headers as indicated
@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
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??
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
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
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??
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...
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