Forum Discussion
cmcnicholas
Cirrus
CirrusHealth Monitor query - https
Apologies if this isn't explained well, or if the answer is very obvious for more experienced posters.... I have a virtual server with 4 different pools associated with it. All four pools are config...
CA_Valli
MVP
MVPLet me get this straight.. you have 2 different F5 instances, and there's one that's configured to forward traffic to VIPs exposed by the second one, correct?
There's 4 different HTTPS pools on different ports, all pointing to a VS on the second unit, which runs them on a single IP with different ports.
You're using the same HTTPS (standard? custom?) monitor on all pools, but two fail and two don't.
First thing that comes to my mind: on the "back end" F5, do all VS/pools forward traffic to the same nodes?
If you're using a custom string, you should also make sure that your monitor points to a resource that exists on all 4 services, ex. if you run "GET /health" then /health page should exists on all 4 services.
Also, if back end server are not the same, you should tune the "Host:" header in your monitor, in order for traffic to match.
The easiest way to test your monitor is running a curl command or something similar, via F5 cli :
(echo -e "GET /health HTTP/1.1\r\nHost: www.f5.com\r\nConnection: Close\r\n\r\n";sleep 1) | openssl s_client -connect 10.0.0.10:443
Hope this helps
CA
cmcnicholasCirrus
CirrusAnother observation:
The proxy server we hit requires SNI for inbound traffic coming from our side. We have input the ServerName in the serversslprofile to ensure that the SNI extension is in thr Client Hello. This works.
When we run about 20 tests, about half will work fine because we see the SNI extension in the Client Hello and we hit the API. The other half fail however because there is no SNI extension in the Client Hello and we can't access the API because the server has no idea which certificate to server to us.
When the connection doesn't work we get an error in the logs:
[ssl:error][pid25730:tid 140171399874304]AH02033: No hostname was provided via SNI for a name based virtual host.
Observation:
Every time we don't see the SNI extension in the Client Hello, it has come from the Self IP. Every time we do see the SNI extension, it has come from the Float IP.