HTTP and HTTPS in one VS

Hi,

why do you want to do this with one VS ?

Regards, Sören

Yes one listening VS on port 8080 and expect that ltm can distinguish if traffic is 80 or 443 and forward 80 to pool_80 and 443 to pool_443

Hi,

I would rather have more than one VS for this. Both VIPs can listen with the same IP so you end up with the same result just a lot less overhead from an iRule to filter and make the load balancing decisions. Unless you have a spesific reason why it has to be one VIP?

Just a thought, can the proxy add a custom header to say whether it was port 80 or 443? If so an Irule on the VS could then interrogate the header and forward accordingly.

Hope this helps, N

@Derekv, would be good, but nope customer requirement is one VS @Nathan, no proxy before LTM only listen on 8080 and forward on 8080 as well

look at this:

oneVS

If a customer's requirements don't make sense, you should point this out. What you ask is possible, but it is not worth the trouble both to create and to maintain and support it. YOu can have multiple VS with the same IP address as long as they are listening on different ports.

That is the easy way to do this. Otherwise, you can write irules that check the port, or any custom headers you specify and then call the pool command to send to whatever pool you want.

You can really just boils this down to the following:

when CLIENT_ACCEPTED {
    if { [TCP::local_port] == 80 } {
        SSL::disable
        pool myPool
    } elseif { [TCP::local_port] == 443 } {
        pool myPool
    } else { 
        discard 
    }
}

Make sure to apply an SSL profile to the VIP and set the port to * (any).

I agree with everyone else that it's better to use a separate virtual server per protocol. That said, if the customer wants one VS, you can use an iRule like this to support it:

https://devcentral.f5.com/wiki/iRules.HttpHttpsSingleVirtualServer.ashx

Aaron

Multiple VIPs is certainly the better option, but sometimes a requirement is just a requirement. I'd also add that while the above iRule should work, the discard statement inside the CLIENT_ACCEPTED event still allows a client to perform a full three-way handshake with the VIP (before being rejected). If you don't want this, then the better option is perhaps a carefully written packet filter rule - although separate VIPs with specific listening ports will give you the same thing.