Forum Discussion

Nathan_McKay_67's avatar
Nathan_McKay_67
Icon for Nimbostratus rankNimbostratus
Jan 03, 2007

Possible to selectively enable/disable SSL and HTTP profiles?

Hi,

 

 

I am attempting to selectively enable client-side SSL processing based on a condition - pool member availability in this case.

 

 

Normally the virtual server in question will perform no SSL processing, so no client-SSL profile is assigned by default (nor is an HTTP profile obviously). However, in the event that there are no pool members available, I need the VS to apply a client-SSL profile, complete an SSL handshake with the client, and return an HTTP redirect.

 

 

The problem is, that the LTM will not let me assign an iRule that employs the SSL::profile command unless an exising SSL profile is applied to the virtual server (same goes for HTTP:: commands). The error message is as follows:

 

 

BIGpipe: rule modification error:

 

01070394:3: SSL::profile in rule (pool_unavail_redirect_ssl) requires an associated SERVERSSL or CLIENTSSL profile on the virtual server (vs-test).

 

 

 

My iRule is as follows:

 

 

when CLIENT_ACCEPTED {

 

 

set mypool "some_pool"

 

set myredir "http://example.com/error.html"

 

 

if { [ active_members $mypool ] < 1 } {

 

 

SSL::profile clientssl

 

SSL::enable

 

HTTP::enable

 

 

}

 

 

}

 

 

when HTTP_REQUEST {

 

 

HTTP::redirect $myredir

 

 

}

 

 

 

Note that I have also tried assigning both a client-ssl profile and http profile, and then using an else statement in which I run SSL::disable and HTTP::disable. While I can successfully load this configuration, I cannot seem to get it to work.

 

 

Is this even possible, and if so, what am I missing? Is there a better way to do this?

 

 

Thanks in advance,

 

Nathan
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    I don't believe you can dynamically add a profile to a virtual server. You can only disable/enable a profile that is already associated. I don't think there are any plans of changing this.

    Are you trying to decrypt the HTTPS traffic and send a redirect if the pool is down, but otherwise leave the HTTPS traffic encrypted and load balance it to the pool?

    If so, I think the logic would be something like this:

    
    when RULE_INIT {
       set mypool "some_pool"
       set myredir "http://example.com/error.html"
    }
    when CLIENT_ACCEPTED {
       if { [active_members $mypool] > 1 } {
          SSL::disable
          HTTP::disable
          pool $mypool
       }
    }
    when HTTP_REQUEST {
       HTTP::redirect $myredir
    }

    This assumes that you have client SSL and HTTP profiles associated with the virtual server.

    I haven't tested this but it seems like the logic is okay. If it doesn't work, can you add logging to each event to see what is being triggered when there are nodes available in the pool compared with what happens when the nodes are down?

    Aaron

  • Thanks for the reply. Yes I am trying to decrypt the HTTPS traffic and send a redirect if the pool is down but otherwise leave it alone and LB the connection as is. I was able to get your suggested rule to work with a little tweaking:

    
    when RULE_INIT {
       set mypool "some_pool"
       set myredir "http://example.com/error.html"
    }
    when CLIENT_ACCEPTED {
       global mypool
       if { [active_members $mypool] > 0 } {
          SSL::disable
          HTTP::disable
          pool $mypool
       }
    }
    when HTTP_REQUEST {
       global myredir
       HTTP::redirect $myredir
    }

    So while that works, I am concerned that it will cause what would otherwise be unnecessary load on the LTM units. In practice, the pool should almost never be unavailable, but I would like to employ this redirect as a failsafe (and customer-service) mechanism.

    Ideally I would not have to instruct the LTM to disable the profiles since that is going to be executed for every connection. Whereas if I could instruct the LTM to enable a profile dynamically, I could avoid this extra processing to accommodate a scenario which is (hopefully) unlikely to occur on any kind of regular basis.

    It may turn out that the overhead is negligible, but I would like to keep it to a minimum wherever possible.

    Thanks again for your feedback.

    - Nathan
  • Hi again.

     

     

    After some testing it would appear that there is really no noticeable performance or latency impact using this iRule in this fashion. However, it would appear that it is incompatible with SSL persistence. Despite my best efforts, I cannot coax the LTM to keep connection persistence when using an SSL persistence profile (no persistence records are displayed either via the LTMUI, or a 'b persist show'). I have even tried adding a 'persist ssl' statement to the rule itself. As soon as I disable the rule, I do start seeing persistence records being created though. Please note also that source address affinity works as expected, but will not meet my needs in this scenario.

     

     

    Anyway I didn't see anything relevant looking though tech.f5.com, so if this isn't a known issue I will open a case with Support.

     

     

    Thanks and best regards,

     

    Nathan