HTTPS SNI Monitoring How-to

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>

• 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

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