For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

IainThomson85_1's avatar
IainThomson85_1
Icon for Cumulonimbus rankCumulonimbus
Feb 24, 2014

True-Client-IP error generated. /var/log/ltm

Hi All,

 

I've recently inherited an F5 BIP System to look after.

 

Currently there is a rule that appears to be causing a lot of spam in the logs, and I believe its due to the rule being written "poorly". However, i'm not a TCL expert. Can anyone spot anything obvious in whats happening?

 

I do not know the far end server dependency on the Rule, however I can't see it offering much value if erroring frequently.

 

Regards

 

Log Example

 

Feb 24 10:24:09 local/tmm2 err tmm2[6235]: 01220001:3: TCL error: trueclient_ip_rule - Operation not supported (line 1) invoked from within "HTTP::header insert "True-Client-IP" [getfield [IP::client_addr] "%" 1]"

 

Rule "rule trueclient_ip_rule when HTTP_REQUEST { HTTP::header insert "True-Client-IP" [getfield [IP::client_addr] "%" 1] } }"

 

9 Replies

  • Either ditch the iRule and use the HTTP profile to insert an X-Forwarded-For header (so that this can be captured in server access logs), or if you really need the True-Client-IP header then try;-

    rule trueclient_ip_rule {
        when HTTP_REQUEST { 
            HTTP::header insert True-Client-IP "[getfield [IP::client_addr] % 1]"
        }
    }
    
  • Forgive my ignorance, but the suggest amendments to the rule are the same ?

     

    Regards,

     

    • IheartF5_45022's avatar
      IheartF5_45022
      Icon for Nacreous rankNacreous
      But has no effect whatsoever. I was thinking that getfield only works on a single character split not a string, but I was wrong. I've tried your original rule and it works fine for me. So sorry I have not added any value at all!
  • I have a theory about what is happening. However, can't prove it due to sheer volume of traffic that is hitting the VIP that this is associated with.

     

    Would it be possible to include a statement - Only to insert the [IP::client_addr] - IF the connection is still open?

     

    I could be experiencing something where the connection is being torn down before the iRule has chance to be processed - Therefore generates an error for a few number of sessions.

     

    Regards

     

  • Hmmm....not so sure on that theory - have you found anything? Maybe some of the requests are not properly formed HTTP requests and that is why it is failing. Why don't you try;

     

    rule trueclient_ip_rule { when HTTP_REQUEST { if {[catch {HTTP::header insert True-Client-IP "[getfield [IP::client_addr] % 1]"}]} { log local0. "Caught [HTTP::request]" } } }

     

    Of course it will probably still barf when you try to do the logging but may tell you something.

     

  • Ok - Just to give a final close to this one.

     

    There was a fault that was being caused by another VIP on the F5 issueing a re-direct (This has been suggested before, however I didn't spot the priority statement), so regardless of the ordering of the rules physically, it wouldn't have fixed.

     

    We have since added a priorty statement so it'll be processed the first rule on the VIP - issue solved.

     

    Thank you for your help.

     

  • Thanks for the update. Do you mean the same VIP issuing a redirect from another iRule?

     

    Since the last post we have had a nearly identical issue, which F5 agreed was probably related to malformed HTTP request, however I will double check that we don't have a 2nd iRule attached too..