Forum Discussion
f5mkuDefault
Cirrus
CirrusF5 health-monitor suddenly use tlsv1
Hi experts, Did anyone encounter such issue using https health monitor where suddenly it communicates with real server using TLSv1 instead of TLSv2? I have a pair of F5 active-standby. Al...
Lidev
MVP
MVPHello,
Have you read this thread : https://devcentral.f5.com/s/question/0D51T00007EM6ML/f5-server-ssl-profile-using-tls-10-instead-of-tls-12
Are you in the same configuration .NET app using SNI ?
Regards
f5mkuDefaulthi Lidev, actually we found out it is a bug. Bug ID 739963. The only problem is we need to find out why the sslhandshake failed that trigger this bug.
F5 has no answer as per the KB
https://cdn.f5.com/product/bugtracker/ID739963.html
Symptoms
HTTPS monitors mark a TLS v1.2-configured pool member down and never mark it back up again, even if the pool member is up. The monitor works normally until the SSL handshake fails for any reason. After the handshake fails, the monitor falls back to TLS v1.1, which the pool members reject, and the node remains marked down.
Impact
Once the handshake fails, the monitor remains in fallback mode and sends TLS v1.0 or TLS v1.1 requests to the pool member. The pool member remains marked down.
Conditions
This might occur when the following conditions are met:
-- Using HTTPS monitors.
-- Pool members are configured to use TLS v1.2 only.
Workaround
To restore the state of the member, remove it and add it back to the pool.
Fix Information
None
- Lidev
The SSL Handshake failed because your Pool members are configured to use TLS v1.2 only.
Maybe try to add another TLS version like TLS1.1 to see if the bug disappears.
- f5mkuDefault
Like I said its bug. See above I posted.
the health monitor was working fine for the last several months. It communicate to server via tls1.2 and something happen we dont know what causes the sslhandshake to break and then F5 fallback to tlsv1...and since server dont support it becomes inactive on F5 end. F5 got stuck on tls1v.