Forum Discussion

William_Them_99's avatar
William_Them_99
Icon for Nimbostratus rankNimbostratus
Aug 02, 2005

HTTP_RESPONSE problems with multiple requests

If there are any other posts that would answer this - just let me know and I will do more digging, but I didn't see any.

We have an iRule that handles client certificate authentication. I've posted other things about it before. It handles users either providing a valid cert that is in our LDAP tree, providing a valid cert that is not in our LDAP tree, and not providing a cert at all. The client SSL profile is set to "Request" for client certificates.

The rule was working perfectly...until we needed to add another CA to the bundle of advertised client certificates. After doing this, we ran the "b load" command from the Linux command line to reload all settings to make it take effect. Now our rule breaks when the user provides a valid cert that is not in LDAP. Specifically, in the HTTP_RESPONSE, we check a variable to see if AUTH_FAILURE has occurred, and if so, redirect to another page. Ever since we ran "b load", it seems as though two simultaneous requests come through the whole rule, and these two requests result in this error:

Aug 2 22:22:37 tmm tmm[16587]: 01220001:3: TCL error: Rule auth_responses - Operation not supported. Multiple redirect/respond invocations not allowed (line 1) invoked from within "HTTP::redirect https://idelb/BIGIPClientCert/Cli

entCert.aspx"

In fact, even using a valid cert that is in the LDAP tree results in multiple requests.

I know that Internet Explorer has this behavior of sending multiple requests, but before, the behavior was that the requests seemed to occur consecutively (this was proven by us using variables to do certain behavior based on whether an authentication attempt already occurred). Now these requests seem to happen simultaneously, as can be seen below, so variable tracking has become useless...

Aug 2 22:22:34 tmm tmm[16587]: Rule auth_responses : initing auth_tried

Aug 2 22:22:34 tmm tmm[16587]: Rule auth_responses : initing auth_tried

Aug 2 22:22:36 tmm tmm[16587]: Rule auth_responses : initing auth_tried

Aug 2 22:22:36 tmm tmm[16587]: Rule auth_responses : initing auth_tried

Aug 2 22:22:37 tmm tmm[16587]: Rule auth_responses : in the client ssl handshake

Aug 2 22:22:37 tmm tmm[16587]: Rule auth_responses : initing auth_tried

Aug 2 22:22:37 tmm tmm[16587]: Rule auth_responses : initing auth_tried

Aug 2 22:22:37 tmm tmm[16587]: Rule auth_responses : in the client ssl handshake

Aug 2 22:22:37 tmm tmm[16587]: Rule auth_responses : Setting to profile type_cert_ldap

Aug 2 22:22:37 bigiptst tamd: 010b0232:4: pam_authenticate: 6

Aug 2 22:22:37 bigiptst tamd: 010b0235:4: AUTH: Permission denied

Aug 2 22:22:37 tmm tmm[16587]: Rule auth_responses : auth_failure

Aug 2 22:22:37 tmm tmm[16587]: Rule auth_responses : auth_failure - reject, auth_code is 1

Aug 2 22:22:37 tmm tmm[16587]: Rule auth_responses : auth_failure

Aug 2 22:22:37 tmm tmm[16587]: Rule auth_responses : auth_failure - reject, auth_code is 1

Aug 2 22:22:37 tmm tmm[16587]: Rule auth_responses : in http response, auth_code is 1

Aug 2 22:22:37 tmm tmm[16587]: Rule auth_responses : in http response, auth_code is 1

Aug 2 22:22:37 tmm tmm[16587]: 01220001:3: TCL error: Rule auth_responses - Operation not supported. Multipl

e redirect/respond invocations not allowed (line 1) invoked from within "HTTP::redirect https://idelb/BIGIPClientCert/Cli

entCert.aspx"

Any advice? Because it just seems to have happened out of the blue. We had not changed any other configurations before running the "b load" command. If you'd like any other supporting info, please let me know. Our entire iRule can be seen below. Thanks.


when CLIENT_ACCEPTED {
  log local0. "initing auth_tried"
  set auth_tried 0
  set auth_code 0
}
when CLIENTSSL_HANDSHAKE {
  log local0. "in the client ssl handshake"
}
when HTTP_REQUEST
{
 set id [SSL::sessionid]
 set the_cert [session lookup ssl $id]
 if {[HTTP::uri] contains "/BIGIPClientCert/ClientCert.aspx"}
 {    
    set auth_code 0
    HTTP::header replace SSLClientCert [b64encode $the_cert]
    log local0. "Sending to new pool"
    log local0. [HTTP::header SSLClientCert]
    pool owgwtis3_pool
 } else {
  
  if {$the_cert != "" && $auth_tried == 0}
  {
   set auth_tried 1
   set issuer [X509::issuer $the_cert]   
     
   if {$issuer contains "Lockheed Martin"}
   { 
     log local0. "Setting to profile type_cert_ldap"
     set myprofilename "type_cert_ldap"
   } elseif {$issuer contains "VeriSign"} {
      log local0. "Setting to profile type_cert_ldap_392"
      set myprofilename "type_cert_ldap_392"
      
    }
    set tmm_auth_ssl_cc_ldap_sid [AUTH::start pam $myprofilename] 
    AUTH::cert_credential $tmm_auth_ssl_cc_ldap_sid $the_cert 
    AUTH::authenticate $tmm_auth_ssl_cc_ldap_sid 
    HTTP::collect
  }
  elseif {$the_cert == "" && $auth_tried == 0} {
    if {[matchclass [HTTP::uri] starts_with $::no_cert_required]} {
     log local0. "no cert needed for this URI"
     HTTP::release
    }
    else {
      log local0. "cert required but not provided"
      HTTP::uri "/Errors/NoCert.html"
    }
  }
 }
}
when AUTH_SUCCESS
{
  log local0. "auth_success" 
  set auth_code 0
  if {$tmm_auth_ssl_cc_ldap_sid eq [AUTH::last_event_session_id]}
  { 
    HTTP::release 
  } 
}
when AUTH_FAILURE
{
  log local0. "auth_failure" 
  set auth_code 1
  if {$tmm_auth_ssl_cc_ldap_sid eq [AUTH::last_event_session_id]}
  { 
    log local0. "auth_failure - reject, auth_code is $auth_code"
    HTTP::release   
  }
}
when AUTH_WANTCREDENTIAL
{
  log local0. "auth_wantcredential" 
   if {$tmm_auth_ssl_cc_ldap_sid eq [AUTH::last_event_session_id]}
  { 
    reject    
  }
}
when AUTH_ERROR
{  
  log local0. "auth_error" 
  if {$tmm_auth_ssl_cc_ldap_sid eq [AUTH::last_event_session_id]}
  { 
    reject   
  } 
}
when HTTP_RESPONSE {
  log local0. "in http response, auth_code is $auth_code"  
  if {$auth_code eq 1}  { 
   this page only exists onowgwipo1 
   set auth_code 0
   HTTP::redirect https://idelb/BIGIPClientCert/ClientCert.aspx
  }
}

2 Replies

  • Ok - I think you can almost disregard my post...

     

     

    We rebooted the device and the behavior has gone back to normal. Before the reboot, we did notice that many of the caches were at the maximum allocation. Could this be the cause of the strange behaviors I described? Is there a way to purge caches without a device reboot? It doesn't bode well for a production environment.

     

     

    Thanks.
  • unRuleY_95363's avatar
    unRuleY_95363
    Historic F5 Account
    One thing that might be helpful is to log the AUTH::last_event_session_id and possibly the client IP and source port in your log messages as it will help correlate which logs are with which connections.