This section covers the specific configuration for HTTPS health monitor type.

The HTTPS monitor type can be used to validate the health of HTTPS encrypted web servers. Use this monitor when NSX Advanced Load Balancer is either passing SSL encrypted traffic directly from clients to servers, or NSX Advanced Load Balancer is providing SSL encryption between itself and the servers.

Configuring HTTPS Health Monitor

A health monitor can be configured for HTTPS settings if the Type of the health monitor is selected as HTTPS.

For configuring the general health monitor settings, see Creating a New Health Monitor.



Under the HTTPS tab, configure the following:

  1. Specify aHealth Monitor Port that must be used for the health check. When this field is configured, the clients are directed to a different port than the default port than the one that is monitored. When this field is left blank, the default port configured for the server is used.

  2. Select the Authentication Type.

  3. Enter the User name and Password for server authentication. For further details on authenticating health monitors see Authenticating HTTP and HTTPs Health Monitor.

  4. Use the section Client Request Header and Client Request Body to send an HTTP request to the web server. NSX Advanced Load Balancer does not validate the request, as different servers may support unique request syntax:

    1. Method: Any method may be used, though GET, POST and HEAD are the most common for monitoring. If no method is defined, NSX Advanced Load Balancer will use GET.

    2. GET /index.htm

    3. POST /upload.asp HTTP/1.0\r\nHost: www.site.com\r\nContent-Length: 10\r\nABCDE12345

  5. Path: The path may include the URI and query, such as /index.htm?user=test. If no path is specified, / will be used.

    Note:

    The maximum size of the HTTP request body for health monitors is increased from 1024 bytes to 5120 bytes.

  6. Select Use Exact Request to use the exact http_request string as specified by the user. This will avoid automatic insertion of headers like host header.

  7. Under Server Response Data, enter the match for a keyword in the first 2kb of the server header and body response. See Example health check for more information.

  8. In the Response Code field, enter HTTPS response codes for a successful match. A successful HTTPS monitor requires either the response code, the server response data, or both fields to be populated. The response code expects the server to return a response code within the specified range. For a GET request, a server must usually return a 200, 301 or 302. For a HEAD request, the server will typically return a 304. A response code by itself does not validate the server’s response content, just the status.

  9. Click Enable SSL Attributes to allow SSL encrypted traffic to pass to servers without decrypting in the load balancer (the SE). Configure the following:

    1. In the TLS SNI Server Name field, enter a fully qualified DNS hostname to include SSL host header extension during TLS handshakes. If no value is specified, the value from the pool will be inherited from the pool.

    2. Select an existing SSL Profile or create a new one, as required. This defines the ciphers and SSL versions to be used for the health monitor traffic to the backend servers.

    3. Select an existing PKI Profile or create a new one, as required. This will be used as to validate the SSL certificate presented by the server.

    4. Select an existing SSL Key and Certificate or create a new one, as required.

      The SSL settings on a health monitor are always considered if provided. If SSL settings for the health monitor are not provided, the health monitor falls back to using pool SSL settings. An HTTPS health monitor needs SSL settings on either the health monitor configuration itself or in the pool configuration. If is absent in both, NSX Advanced Load Balancer reports an error.