You should protect vCloud Director public endpoints with a Web Application Firewall (WAF). When used in conjunction with a load balancer, configure the WAF to allow inspection and blocking of malicious traffic by terminating the HTTPS connection at the WAF, allowing the WAF to complete the handshake using its own certificate and forward acceptable requests to the cell with an X-Forwarded-For header.

Client requests to vCloud Director must be made to an HTTPS endpoint. (An HTTP connection to the cell is supported but is not secure.) Even when communications between the remote client and the WAF are secured with HTTPS, it is required that WAF-to-cell communication also be done over HTTPS.

The following simple diagram, leaving out the load balancer, illustrates the two TLS or SSL connections that exist when using TLS or SSL termination, one between the user's computer and the WAF, and one between the firewall and the vCloud Director cell.

Figure 1. TLS/SSL Configuration with WAF
Figure showing an SSL-terminating load balancer between the Internet and the Web Application Firewall, and another SSL-terminating load balancer between the Web Application Firewall and the cell. Both load balancers are configured with signed certificates.

TLS/SSL Termination and Certificates

When configuring TLS or SSL termination, it is important not only to install a CA-signed certificate at the WAF so that client applications such as the vCloud API and the Web Console can be assured of the identity of the server, but also to use a CA-signed certificate on the cells even though they are only seen by the WAF. Self-signed certificates, even if the WAF accepts them, are only appropriate if each certificate is manually accepted at deployment time; however, this limits the flexibility of the vCloud Director server group, as each cell must be manually configured (and reconfigured when certificates are renewed).

Finally, if the load balancer is independent of the WAF, it too should use a CA-signed certificate. Procedures for adding certificate chain paths for load-balancer endpoints are documented in Customize Public Endpoints in the vCloud Director Administrator's Guide.

X-Forwarded-For Header

X-Forwarded-For is a widely used header, supported by many proxies and firewalls. It is recommended that you enable generation of this header at the firewall if possible.

When a firewall is present in front the cell, the cell may query for the client's IP address in order to log it; but it will generally get the address of the firewall instead. However, if the X-Forwarded-For header is present in the request the cell receives, it will log this address as the client address and it will log the firewall address as a separate proxyAddress field in the log.