Port Confusion

There was a recent post on the lb-l mailing list which discussed a problem relating to combining SSL and non-SSL virtual services pointing to the same web server(s).

The issue comes up when you have two virtual services, typically for the same website, one for HTTPS (port 443) and one for HTTP (port 80), and everything points to the same set of servers.

Consider the following configuration:

• Virtual Service: 192.168.0.200 port 443 (SSL termination)
  • Server: 192.168.1.100 port 80
    Server: 192.168.1.101 port 80
• Virtual Service: 192.168.0.200 port 80 (non-SSL)
  • Server: 192.168.1.100 port 80
  • Server: 192.168.1.101 port 80

Both 443 and 80 point to the same web servers, and to the same web server instance. In this situation, the web server can’t discern what traffic came in at HTTPS port 443 versus HTTP port 80. As a result, the dynamic content generated by the servers will give an “http://” URL instead of a “https://” URL

The easiest solution is to force all traffic to be HTTPS, by setting up the HTTP virtual service as a relative redirector. If you put in http://lbdigest.com/directory, a 403 would be generated redirecting the browser to https://lbdigest.com/directory. No matter what URL you try to get on port 80, you’ll always be redirected to the equivalent HTTPS URL.

You can do this one of two ways:

1. Through the load balancer, if it’s supported. Most do.
2. By setting up a separate web server instance, with a URL re-write capability with ASP, PHP, mod_rewrite, or some other mechanism.

For instance, here is a relative URL re-write I wrote for PHP:

<?php
ob_start();
$url = $_SERVER["REQUEST_URI"];
$host = $_SERVER["HTTP_HOST"];
header("Location: https://$host$url");
ob_flush();
?>