You can create an HTTPS application profile for three HTTPS traffic types: SSL passthrough, HTTPS offloading, and HTTPS end-to-end. The workflow for creating the application profile varies for each HTTPS traffic type.

Note:
  • Starting in NSX 6.4.5, the Application Profile Type drop-down menu contains separate options to create a profile for each of the three HTTPS traffic types.
  • In NSX 6.4.4 and earlier, the Type drop-down menu contains only a single HTTPS option. To create a profile for each of the three HTTPS traffic types, you must specify appropriate profile parameters.
  • NSX load balancer does not support proxy SSL passthrough.
Starting in NSX 6.4.5, the UI terminologies for a couple of HTTPS profile parameters have changed. The following table lists the changes.
NSX 6.4.4 and Earlier NSX 6.4.5 and Later
Virtual Server Certificates Client SSL
Pool Certificates Server SSL
The following table describes the three HTTPS traffic types.
Table 1. HTTPS Traffic Types
HTTPS Traffic Type Description
SSL Passthrough

Application rules related to SSL attributes are allowed without requiring an SSL termination on the load balancer.

The traffic pattern is: Client -> HTTPS-> LB (SSL passthrough) -> HTTPS -> Server.

HTTPS Offloading

HTTP-based load balancing occurs. SSL ends on the load balancer and HTTP is used between the load balancer and the server pool.

The traffic pattern is: Client -> HTTPS -> LB (end SSL) -> HTTP -> Server.

HTTPS End-to-End

HTTP-based load balancing occurs. SSL ends on the load balancer and HTTPS is used between the load balancer and the server pool.

The traffic pattern is: Client -> HTTPS -> LB (end SSL) -> HTTPS -> Server.

The following table describes the persistence supported in HTTPS traffic types.
Table 2. Supported Persistence Types
Persistence Description
Source IP

This persistence type tracks sessions based on the source IP address.

When a client requests a connection to a virtual server that supports a source IP address persistence, the load balancer checks whether that client was previously connected. If yes, the load balancer returns the client to the same pool member.

SSL Session ID

This persistence type is available when you create a profile for the SSL passthrough traffic type.

SSL Session ID persistence ensures that repeat connections from the same client are sent to the same server. Session ID persistence allows the use of SSL session resumption, which saves processing time for both the client and the server.

Cookie

This persistence type inserts a unique cookie to identify a session the first time a client accesses the site.

The cookie is referred in subsequent requests to persist the connection to the appropriate server.

For the Source IP and SSL Session ID persistence types, you can enter the persistence expiration time in seconds. The default value of persistence is 300 seconds (five minutes).
Remember: The persistence table is of a limited size. If the traffic is heavy, a large timeout value might lead to the persistence table filling up quickly. When the persistence table fills up, the oldest entry is deleted to accept the newest entry.
The load balancer persistence table maintains entries to record that client requests are directed to the same pool member.
  • If no new connection requests are received from the same client within the timeout period, the persistence entry expires and is deleted.
  • If a new connection request from the same client is received within the timeout period, the timer is reset, and the client request is sent to a sticky pool member.
  • After the timeout period has expired, new connection requests will be sent to a pool member allocated by the load balancing algorithm.

For the L7 load balancing TCP source IP persistence scenario, the persistence entry times out if no new TCP connections are made for a period, even if the existing connections are still alive.

The following table lists the approved cipher suites that can be used to negotiate security settings during an SSL or TLS handshake.

Table 3. Approved Cipher Suites
Cipher Value Cipher Name
DEFAULT DEFAULT
ECDHE-RSA-AES128-GCM-SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ECDHE-RSA-AES256-GCM-SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
ECDHE-RSA-AES256-SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
ECDHE-ECDSA-AES256-SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
ECDH-ECDSA-AES256-SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
ECDH-RSA-AES256-SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
AES256-SHA TLS_RSA_WITH_AES_256_CBC_SHA
AES128-SHA TLS_RSA_WITH_AES_128_CBC_SHA
DES-CBC3-SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA
ECDHE-RSA-AES128-SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
ECDHE-RSA-AES128-SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
ECDHE-RSA-AES256-SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
AES128-SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256
AES128-GCM-SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256
AES256-SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256
AES256-GCM-SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384

The following procedure explains the steps to create an application profile for each of the three HTTPS traffic types.

Procedure

  1. Log in to the vSphere Web Client.
  2. Click Networking & Security > NSX Edges.
  3. Double-click an NSX Edge.
  4. Click Manage > Load Balancer > Application Profiles.
  5. Click Add.
    The New Application Profile window opens.
  6. Specify the application profile parameters.

    Steps for SSL Passthrough traffic type.

    NSX Version Procedure
    6.4.5 and later
    1. In the Application Profile Type drop-down menu, select SSL Passthrough.
    2. Enter the name of the profile.
    3. Select the type of persistence.
    4. Enter the persistence expiration time.
    5. Click Add.
    6.4.4 and earlier
    1. Enter the name of the profile.
    2. In the Type drop-down menu, select HTTPS.
    3. Select the Enable SSL Passthrough check box.
    4. Select the type of persistence.
    5. Enter the persistence expiration time.
    6. Click OK.

    Steps for HTTPS Offloading traffic type.

    NSX Version Procedure
    6.4.5 and later
    1. In the Application Profile Type drop-down menu, select HTTPS Offloading.
    2. Enter the name of the profile.
    3. Enter the URL to which you want to redirect the HTTP traffic.
    4. Select the type of persistence.
      • For Cookie persistence, enter the cookie name and select the mode of inserting the cookie. For a description about each cookie mode, see Create an HTTP Application Profile.
      • For Source IP persistence, enter the persistence expiration time.
    5. Optional: To identify the originating IP address of a client connecting to a Web server through the load balancer, enable the Insert X-Forwarded-For HTTP header option.
    6. Click the Client SSL tab.
    7. Select one or more cipher algorithms or cipher suite to be used during the SSL handshake. Make sure that the approved cipher suite contains DH key length more than or equal to 1024 bits.
    8. Specify whether client authentication is to be ignored or required. If necessary, then the client must provide a certificate after the request or the handshake is canceled.
    9. Select the required service certificate, CA certificate, and CRL that the profile must use to end the HTTPS traffic from the client on the load balancer.
    10. Click Add.
    6.4.4 and earlier
    1. Enter the name of the profile.
    2. In the Type drop-down menu, select HTTPS.
    3. Follow the steps given in this table for NSX 6.4.5 and later to define the following application profile parameters:
      • HTTP Redirect URL
      • Persistence
      • Insert X-Forwarded-For HTTP header
    4. Click the Virtual Server Certificates tab.
    5. Follow the steps given in this table for NSX 6.4.5 and later to define cipher algorithms and client authentication.
    6. Click Configure Service Certificates, and select the required service certificate, CA certificate, and CRL that the profile must use to end the HTTPS traffic from the client on the load balancer.
    7. Click OK.

    Steps for HTTPS End-to-End traffic type.

    In this application profile type, you specify both the Client SSL (Virtual Server Certificates) parameters and the Server SSL (Pool Side SSL) parameters.

    The Server SSL parameters are used to authenticate the load balancer from the server side. If the Edge load balancer has a CA certificate and a CRL already configured and the load balancer needs to verify a service certificate from the back-end servers, select the service certificate. You can also provide the load balancer certificate to the back-end server if the back-end server needs to verify the load balancer service certificate.

    NSX Version Procedure
    6.4.5 and later
    1. In the Application Profile Type drop-down menu, select HTTPS End-to-End.
    2. Enter the name of the profile.
    3. Follow the steps given in the table for creating an HTTPS offloading profile to define the following application profile parameters:
      • HTTP Redirect URL
      • Persistence
      • Insert X-Forwarded-For HTTP header
      • Client SSL: cipher algorithms, client authentication, service certificate, CA certificate, and CRL
    4. Click the Server SSL tab, and select the cipher algorithms, the required service certificate, CA certificate, and CRL to authenticate the load balancer from the server side.
    5. Click Add.
    6.4.4 and earlier
    1. Enter the name of the profile.
    2. In the Type drop-down menu, select HTTPS.
    3. Follow the steps given in the table for creating an HTTPS offloading profile to define the following application profile parameters:
      • HTTP Redirect URL
      • Persistence
      • Insert X-Forwarded-For HTTP header
      • Virtual Server Certificates: cipher algorithms, client authentication, service certificate, CA certificate, and CRL
    4. Select the Enable Pool Side SSL check box to enable the HTTPS communication between the load balancer and the back-end servers.
    5. Select the cipher algorithms and the required service certificate, CA certificate, and CRL to authenticate the load balancer from the server side.
    6. Click OK.