Technical Articles
F5 SMEs share good practice.
cancel
Showing results for 
Search instead for 
Did you mean: 
Thomas_Schocka1
Altocumulus
Altocumulus

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

Comments
hooleylist
Cirrostratus
Cirrostratus
Hi Thomas,

 

 

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
Thomas_Schocka1
Altocumulus
Altocumulus
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
Skye_85590
Nimbostratus
Nimbostratus
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
Max_Q_factor
Cirrocumulus
Cirrocumulus
The Microsoft Active Directory Federation Services (BIG-IP v11: LTM, APM) deployment guide has a nice working SNI script referenced in it.

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?

 

Opher_Shachar_6
Nimbostratus
Nimbostratus

@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.

 

Richard_Tocci
F5 Employee
F5 Employee

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.

 

Parker_Barthlom
Nimbostratus
Nimbostratus

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.

 

Abed_AL-R
Cirrostratus
Cirrostratus

Hi

 

Has someone tried to implement this on version 12.1.3.5 and worked for him ?

 

Abed_AL-R
Cirrostratus
Cirrostratus
John_Beckmann
F5 Employee
F5 Employee

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

Jesse_Flint
Nimbostratus
Nimbostratus

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

Richard_Tocci
F5 Employee
F5 Employee

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

ErikM
Altocumulus
Altocumulus

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

 

John_Beckmann
F5 Employee
F5 Employee

HEADER1="User-Agent: Mozilla"

HEADER2="MyHeader: MyValue"

etc

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

 

Peter_Baumann
Cirrostratus
Cirrostratus

@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

 

Peter_Baumann
Cirrostratus
Cirrostratus

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??

John_Beckmann
F5 Employee
F5 Employee

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

 

 

ErikM
Altocumulus
Altocumulus

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

 

 

Peter_Baumann
Cirrostratus
Cirrostratus

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??

Peter_Baumann
Cirrostratus
Cirrostratus

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

Version history
Last update:
‎23-Mar-2014 15:57
Updated by:
Contributors