How to allow both HTTP and HTTPS traffic from a single VIP?

I'd recommend two Virtual Servers instead - one for port TCP 80, another for port TCP 443. It's a straight-forward setup which is a much preferred configuration over a wildcard Virtual Server. It's not a bad idea to go for a wildcard VS if the number of ports is significant (i.e. a few hundred), but I see no good reason for a single VS setup if you're just working with two ports (80 and 443).

If you insist on using a single VS for whatever reason, just configure it as L4 Performance (or Standard) Type Virtual Server with port number set to *. Do not apply HTTP profile. Now the main question is, if you accept clientside TCP port 80 connections, do you want the serverside connections to be routed to Pool-Member:443, or Pool-Member:80? Depending on your requirements, you may need to use an iRule (CLIENT_ACCEPTED event) or LTM Local Trafic Policy to select the appropriate destination.

As you set VS port number to * (any), you also want to make sure you do not allow incoming requests to other ports besides TCP 80 and 443. For that, you must fine-tune the pool-selection Policy/iRule to drop packets to irrelevant ports. Luckily, that's not very hard to do either. Just let us know if you need help with anything.

Regards,

I'd recommend two Virtual Servers instead - one for port TCP 80, another for port TCP 443. It's a straight-forward setup which is a much preferred configuration over a wildcard Virtual Server. It's not a bad idea to go for a wildcard VS if the number of ports is significant (i.e. a few hundred), but I see no good reason for a single VS setup if you're just working with two ports (80 and 443).

If you insist on using a single VS for whatever reason, just configure it as L4 Performance (or Standard) Type Virtual Server with port number set to *. Do not apply HTTP profile. Now the main question is, if you accept clientside TCP port 80 connections, do you want the serverside connections to be routed to Pool-Member:443, or Pool-Member:80? Depending on your requirements, you may need to use an iRule (CLIENT_ACCEPTED event) or LTM Local Trafic Policy to select the appropriate destination.

As you set VS port number to * (any), you also want to make sure you do not allow incoming requests to other ports besides TCP 80 and 443. For that, you must fine-tune the pool-selection Policy/iRule to drop packets to irrelevant ports. Luckily, that's not very hard to do either. Just let us know if you need help with anything.

Regards,

Here is an example iRule that will disable your SSL profile for traffic received on port 80 and allow HTTP all the way through on that port. Since you are using SSL bridging you will leave your clientSSL, serverSSL, and http profiles attached to the VIP and set you VIP to use * for the port. AND, please don't just throw this into production without testing it :-).

when RULE_INIT {
     Requests to ports not defined in either the https or http ports list will be reset
     Define virtual server ports that should have SSL enabled
    set static::vip_https_port 443
     Define virtual server ports that should be answered with HTTP
    set static::vip_http_port 80
}
when CLIENT_ACCEPTED {
    if { [TCP::local_port] == $static::vip_https_port] }{
         Request was to an HTTPS port, so do nothing for the clientside connection.
         The defined client and/or server SSL profiles will be applied as normal
        if {[PROFILE::exists clientssl] == 0}{
            reject
        }
    }
    elseif { [TCP::local_port] == $static::vip_http_port }{
         Request was to an HTTP port, not an HTTPS port, so disable client SSL profile if one is enabled on the VIP
         Check to see if there is a client SSL profile and if so, disable it
        if { [PROFILE::exists clientssl] == 1} {
            SSL::disable clientside
        }
         Check to see if there is a server SSL profile and if so, disable it
        if { [PROFILE::exists serverssl] ==1} {
            SSL::disable serverside
        }
    }
    else {
         Request wasn't to a defined port, so reset the TCP connection.
        reject
   }
}