Forum Discussion

mbayer_236661's avatar
mbayer_236661
Icon for Nimbostratus rankNimbostratus
Dec 07, 2015

HTTP going to Pool81 and everything else going to HTTPS on elsePool on Same VIP

I have an application that will need to resolve to the same DNS/VIP -- I would like to have HTTP on say /status route to an Apache listing on port81, and everything else coming in on that same VIP IP be HTTPS and route to a separate (elsePool) on the backend. This is BIGIP V 11.52 by the way, any ideas would be wonderful, I know this can be done other ways but am looking if this can be done so I don't need DEV cycles to put this app behind an F5.

 

3 Replies

  • Hi,

     

    I am not sure to get your question right.

     

    Is the traffic received on different TCP ports or do you expect it all encrypted on the same virtual IP and port 443?

     

    Will the clients use the same hostname or will it be different hostnames? In case of different hostnames (especially if you are using different 2nd and top level domains) you would use the so called server name indication (aka SNI).

     

    Multiple client-ssl profiles with hostname specific certificate/key pairs would be required and bound to the virtual server.

     

    Based on hostname you can decide by iRule to forward cleartext http to a specific pool (by disabling server-ssl) or to re-encrypt and to forward to another server pool.

     

    Thanks, Stephan

     

  • Thank you sounds good -- if I have to use multiple VIPs with all the public IP's it will make the F5 console unusable.

     

  • Hi,

    here is a modified excerpt from the iRule I used for a clients Exchange environment:
    when CLIENT_ACCEPTED {
        switch [TCP::local_port] {
            81  {
                 Cleartext HTTP traffic (redirect into https)
                SSL::disable clientside
                pool defaultPool
                return
            }
            443 {
                 Encrypted HTTP traffic (decrypt, forward to pool)
                pool elsePool
                return
            }
            default {
                 Reject everything else
                reject
                return
            }
        }
    }
    

    The associated virtual server has a client-ssl profile and optionally a server-ssl profile depending on your specific requirements.

    The virtual server works in mode of "Standard" and uses TCP and has a port of "0" to listen on all service ports.

    The pools will be configured with specific ports.

    In case of incoming traffic on TCP/81 the client-ssl profile will be disabled by the iRule.

    In case of incoming traffic on TCP/443 the virtual servers client-ssl profile will kick in and terminate SSL before forwarding traffic to the elsePool.

    Btw, the original iRule has more use cases and turns http profile on and off, modifies persistence methods and rewrites redirects.

    (In production since a couple of months instead of using the approach described in the deployment guide.)

    Thanks, Stephan