HTTP HTTPS Proxy redirect question

The short answer is yes, but the solutions for HTTP and HTTPS can be slightly different.

Assuming you're going to use standard ports (80 for HTTP and 443 for HTTPS), for HTTP traffic you can do what's commonly called "host-based load balancing", where the load balancer sends traffic to a pool based on the HTTP request URI. Here's an example:

when HTTP_REQUEST {
    switch [string tolower [HTTP::host]] {
        "app1.example.com" {
            pool app1_pool
        }
        "app2.example.com" {
            pool app2_pool
        }
    }
}

This is probably the easiest method. You could also use an app-based URI if the host name was the same for both applications (ex. www.example.com/app1 or www.example.com/app2). The real beauty of this approach is that you're putting each application (based on IP and/or port) into its own pool. To add additional resources you can simply add new nodes to the pools and actively load balance and monitor the applications.

The above takes care of port 80 HTTP applications using a single IP address. Doing this for HTTPS is little more complicated in that the SSL negotiation is 1) based on the host name, and 2) happens before the HTTP host name can be evaluated. You can use the same exact iRule above, but you also need to configure the SSL properties of the VIP to accommodate multiple host names. Your options are:

1. A "Wildcard" certificate applied to the single client SSL profile applied to the VIP - this is a single certificate with a wildcard host name (ex. (.example.com) that would cover any host name that matches this domain pattern. These certificates tend to be expensive.

2. A "Subject Alternative Name (SAN)" certificate applied to the single client SSL profile applied to the VIP - this is a single certificate with a single subject name, but multiple subject alternative names. Like a wildcard it can support multiple host names, but unlike a wilcard it only supports a specified subset of host names.

3. Server Name Indicator (SNI) - an extension to TLS 1.0 and above that allows the F5 VIP to switch between multiple single cert client SSL profiles based on the server_name attribute sent by the client in the CLIENTHELLO message of the SSL handshake. This requires TLS so some legacy clients can't use this (ie. WinXP and earlier).

All of these options have the effect of allowing you to negotiate SSL with a single VIP, without error, and then use the host-based iRule above to send traffic to the correct application pool.

Thanks Kevin & Richard. With all those info I should be able to make it but first I need a coffee and a bit of fresh air ;)

Cheers

Seb

Feel a bit stupid to ask this but would anyone be so kind to detail me the steps I have to follow on how to achieve this has of course there is no template for dummy and I have tried all I could but doesn t succeed. Thanks a lot

seb

The admin guides on the support site can go into much greater detail, but essentially you'd do this:

1. Create a pool of web servers for each application
2. Create the above iRule and modify as required (change host and pool names accordingly)
3. Create a virtual server and apply the iRule (and potentially one default pool)
4. Apply an HTTP profile to the VIP config
5. Apply any other profiles as required (persistence, SNAT, etc.)

That's really about it. For HTTPS traffic you'll create a separate VIP listening on the same IP address and port 443. All other settings can be the same (HTTP profile, default pool, iRule, etc.). You also need a client SSL profile for this VIP to be able to negotiate SSL with the client. If you choose options 1 or 2 above (wildcard or SAN), you'll need to first acquire one of those types of certificates and private keys, apply them to a single client SSL profile, and then apply that profile to the VIP. If you choose option 3 (SNI) - and remember its SSL TLS and F5 v11 requirement - you would create a separate client SSL profile for each single subject certificate, specify a host name in the "server name" block in the profile that matches the subject name in the certificate, and designate one profile as the "default" (a check box in the profile). Apply all of these client SSL profiles to the VIP.

Thanks a lot Kevin. that s basically what I have done but maybe I missed something here or there. Will give it another shot and thanks for helping out the newbie :) I ll have a look also in the admin guide.

Cheers

Seb