Hi, We have server listening on port 443 behind F5, The pool members is unable to monitor the server on port 443. Kindly advice Regards, Midhun p.K

There's SOL12531 that talks about monitors a little bit, and then this article that adds a little extra information. Whenever I'm having monitor issues, I try a couple different things. 1: I try to do a curl from the F5 CLI to verify that the url I'm trying to monitor is working properly and the response is coming back as expected. 2: Turn on monitor debugging for the member and check the log that gets created. Those steps are as follows: Open the pool that is having the problem (let's call it MY_POOL)Make sure the monitor is active on the pool (let's call it MY_MONITOR)On the Members tab in the pool settings, click on one of the members (let's call it 10.0.0.1:3389) Enable the checkbox for Monitor Logging Open an SSH session (I use Putty to connect) to the device and log in to the shell.Run the command cd /var/log/monitorsRun the command ls -lLook for the file referencing your pool and member (most likely in our example it'd be something like _Common_MY_MONITOR__Common_10.0.0.1_3389.log)Run the command tail -f FILENAME (where FILENAME is the log filename)It may be visible immediately, but you should see where the monitor sends the request to the server (and you'll see the send string), and you're looking for the recv string that comes back.Take that recv string and update the monitor and see if the pool member(s) show up green again. Go back in and disable the monitor logging for that member so you don't have excessive logging filling up space. Hopefully, this will help figure it out. If your log file ever looks like it's not updating, delete the lo file and remove the monitor from the pool and re-add it. I've found that will kick it back off again. Hope this helps.

Hi midhun, in addition to Michael´s detailed answer I would also consider the server expects a request via TLS with SNI (server name indication). There is an article with description of an external monitor using openssl s_client here on DevCentral. You can validate it from CLI by using the following syntax: openssl s_client -connect : -servername -quiet Now openssl establishes a connection using TLS with SNI attribute and you can paste in a valid request followed by two Carriage Return / New Lines (aka Enter): GET / HTTP/1.1 Host: Connection: close I had to use the described solution in a customer´s SharePoint environment and just added the ability to work in route domains. It works great on v11.5.1 since a couple of months. Thanks, Stephan

One small note : I believe there is no monitor logging checkbox on http/https monitors. You may rely on your back-end web server logs to get logging...

On your Windows 2012 server, I assume you are using IIS web server. By default, authentication is set to anonymous, so monitors should work out of the box. Check the authentication setting on your web server, if it is set to something else than anonymous, you may have to adjust your monitors.

Montoring https port in windows server 2012 is not working with F5

26 Replies

midhun_108442
Nimbostratus
Feb 01, 2015
Hi,

Sorry for asking more question and making it not clear ,below is the actual issue.

When the server is using trusted CA certificate F5 unable to monitor the server on port 443. When it using self signed certificate F5 can able to monitor the server.

regards, Midhun P.K
midhun_108442
Nimbostratus
Feb 01, 2015
Hi,

Sorry for asking more question and making it not clear ,below is the actual issue.

When the server is using trusted CA certificate F5 unable to monitor the server on port 443. When it using self signed certificate F5 can able to monitor the server.

regards, Midhun P.K
StephanManthey
Nacreous
Feb 01, 2015
Hi midhun,

would you please provide the output of the following commands to us:

openssl version curl --version tmsh show sys version | head -n 8 curl -k -v https:/// openssl s_client -connect : (now enter "GET / HTTP/1.0" & press Enter twice)

You just indicated using TMOS v11.2. (There is a couple of maintenance releases and hotfixes available for this minor release.)

Thanks, Stephan
PS: I wasn´t able to modify my previous post and replaced it.
midhun_108442
Nimbostratus
Feb 02, 2015
Hi Stephan,

Find the below output.

openssl version
OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

curl --version
curl 7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 Protocols: tftp ftp telnet dict ldap http file https ftps Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

curl -k -v https://192.168.249.21
About to connect() to 192.168.249.21 port 443
Trying 192.168.249.21... connected
Connected to 192.168.249.21 (192.168.249.21) port 443
successfully set certificate verify locations:
CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none
SSLv2, Client hello (1): Unknown SSL protocol error in connection to 192.168.249.21:443
Closing connection 0 curl: (35) Unknown SSL protocol error in connection to 192.168.249.21:443
openssl s_client -connect 192.168.249.21:443
CONNECTED(00000003) write:errno=104
- StephanManthey
  Nacreous
  Feb 02, 2015
  Hi midhun, so obviously even the provided command line tools of your TMOS version are not able to establish an SSL connection. What is the output of "tmsh show sys version | head -n 8" or alternatively "bigpipe version", please? Are you able to establish a connection to your poolmember on SSL level (i.e. via web browser) from another system in your infrastructure? Thanks, Stephan
- Edgar_Pajuelo_1
  Nimbostratus
  Aug 19, 2015
  Hello Stephan Do you know if they fixed the problem? We have the same issue. Big-IP 11.5.1 HF3 and SSL from Thawte with SHA-256. And the HTTPS monitors fails down, then, we can not go through F5 and see the the Web pages. But directly to the Web server (without F5) works well.
Edgar_Pajuelo_1
Nimbostratus
Aug 19, 2015
Did you found the problem? We have the same issue. Big-IP 11.5.1 HF3 and SSL from Thawte with SHA-256. And the HTTPS monitors fails down, then, we can not go through F5 and see the the Web pages. But directly to the Web server (without F5) works well.
- StephanManthey
  Nacreous
  Aug 20, 2015
  Hi Edgar, if you read this thread, you will notice multiple potential reasons for a https monitor to fail: - layer 3/4: wrong IP or port - SSL/TLS layer: TLS downgrade, handshake failure, missing or untrusted client certificate - layer 5: missing http-headers, wrong request or not matching receive string To troubleshoot the issue I would first check a plain TCP monitor to the pool members IP and port. If this works I would continue using both curl and openssl s_client (as described above) to validate the SSL handshake and the proper request/receive string definitions. The results would allow you to limit protocol versions and ciphers in your https monitor cipher string settings, i.e. by using a fixed cipher of 'ECDHE-RSA-AES128-GCM-SHA256' (supported on TLS1.2 only; for other ciphers you may want to exclude protocols i.e. by appending ":!TLS1:!TLS1_1"). In case your server supports TLS 1.0 only, a downgrade may fail during the handshake. A cipher as follows may help to fix the issue (to permit TLS 1.0 only): 'DEFAULT:!DTLSv1:!SSLv3:!TLSv1_1:!TLSv1_2' The remaining ciphers can be tested by using the command "tmm --clientcipher 'your_cipher_here'". With one of my clients it was required to use SNI (TLS extension (currently supported only by an external monitor based on openssl s_client). Thanks, Stephan PS: Updated the comment regarding downgrade TLS issues.
weblead_151334
Nimbostratus
Aug 21, 2015
Stephan-Can you please assist over https://devcentral.f5.com/questions/i-rule-help-route-incoming-traffic-based-on-source-subnet-amp-url-contains-string-admin-or-intra ...