Fallback URL for SSL pass through

Not sure if this going to help but have you tried using the following

when CLIENTSSL_HANDSHAKE {
    if { [active_members https_pool] > 1 } { HTTP::redirect "https://abc.123.com" }
}

or

when SERVERSSL_HANDSHAKE {
    if { [active_members https_pool] > 1 } { HTTP::redirect "https://abc.123.com" }
}

CB

Thanks, but it doesn't work either. I just got the "command is not valid in current event context" message when trying to enter via the GUI.

In a passthrough SSL virt will there be any handshake that the BigIP knows about?

No it won't determine that for a ssl passthrough, atleast not from the tests that I have done. The problem is that in order for this to work, ssl has to be decripted before the irules can process it for the HTTP::redirect command

 

 

The only clear solution is to terminate the SSL cert on the F5.

 

 

Perhaps the pro's in this forum have a better idea or approach.

 

 

/CB

 

 

 

 

Hi,

 

 

No choice but to make the BIGIP be a SSL termination otherwise it won't be possible i'm afraid.

 

 

Sorry ^^

Maybe there will be a way to present some more options in future releases.

 

 

/CB

 

Not for such a thing.

 

 

Since it's SSL we won't be able to send a redirect to the user since it's encrypted

in 4.x you can tell the configs for the pool to do a fallback host, and it doesn't care anything about http/https/etc. So this is somewhat of a regression as it pertains to how we did things in 4.x compared to 9.x, we lost that flexibility.

you can configure a fallback host within an HTTP profile in v9.X

 

 

But it's impossible to send a redirect to the client since first it will try to exchange SSL certificate, if no server is avaiable it will fail.

 

 

I don't see how it may work in v4 0o maybe it was allowed to implement such a configuration but i would be surprised if it would work because it would mean the BIGIP will by itself send its own certificate to the browser, establish a SSL communication and then send the redirect ...

If you're able to import the SSL cert and key to the BIG-IP, you could use a rule to check whether there are any members available in the pool. If there are members available, the requests would be passed through the BIG-IP without trying to decrypt the HTTPS. If no members are available, you could use the cert/key to decrypt the traffic and send an HTTP redirect. The VIP configuration would need a client SSL profile and an HTTP profile.

The rule would look something like this:

when CLIENT_ACCEPTED {
   log local0. "[IP::client_addr]:[TCP::client_port]: Received connection with active members: [active_members [LB::server pool]]"
    Check if there are members available in the VIP's default pool
   if {[active_members [LB::server pool]]}{
       Disable the client SSL profile so the HTTPS traffic is passed through encrypted to the node
      SSL::disable
       Disable the HTTP profile as we're not going to redirect this request
      HTTP::disable
      log local0. "[IP::client_addr]:[TCP::client_port]: Members available"
   }
}
when HTTP_REQUEST {
    The HTTP_REQUEST event is only triggered if the pool members are down and the client SSL and HTTP profiles are left enabled
    Redirect the client
   HTTP::redirect https://maintenance.example.com
   log local0. "[IP::client_addr]:[TCP::client_port]: Redirecting request"
}

Note that this rule won't redirect the client if the pool is up when the connection is established and then it goes down. I tried addressing this by adding some logic to the LB_FAILED event to enable the client SSL and HTTP profiles and send a redirect. This resulted in a TMM restart. I'm guessing none of these commands are allowed in the LB_FAILED event.

Also, once you're done testing, comment out the log statements.

Aaron