Forum Discussion

ant77's avatar
ant77
Icon for Cirrostratus rankCirrostratus
Jun 30, 2020

iRule parsing errors after upgrading BigIP to 13.1.3 version

Hi All,

 

Does anyone know why we are getting this iRule parsing or formatting error after upgrading our BigIP from 12.x to version 13.1.3.3? After upgrading, the irule that was working is no longer working and causing the website not to load. Not sure why the newer version of this code is disregarding the syntax for the "Check_IP" field. Can only one help in changing the irule so that it will work?

 

It looks like it has to do with the "CHECK_IP" get field. What we are doing is checking the XFF header first to see the client IP and make decision based on that to allow or deny the URIs the go to.

 

Error:

err tmm3[16683]: 01220001:3: TCL error: /Common/Web-iRule <HTTP_REQUEST> - bad IP network address format (line 5)invalid IP match item for IP class /Common/Data-Group-Allowed-IPs (line 5)   invoked from within "class match $CHECK_IP eq Data-Group-Allowed-IPs"

 

when HTTP_REQUEST {
if { [active_members POOL-EXT-WEB-SERVERS] < 1 } {
HTTP::redirect " http://maintenance.domain.com" 
    } else { 
set CHECK_IP [getfield [HTTP::header values X-Forwarded-For] " " 1]
  if { !([class match $CHECK_IP eq Data-Group-Allowed-IPs]) } {
      if { [class match [HTTP::uri] eq Data-Group-URI-List] } {
          reject }
       }
        
       switch -glob [HTTP::uri] {
         "*/level1/level2/portal/login*" -
         "*/level3/testlogin1*" -
         "*/aa/bb/portal/testlogin2*" {
          if { ([class match $CHECK_IP eq Data-Group-Allowed-IPs]) } {
			if { [HTTP::uri] contains "/home/admin1" } {
				HTTP::redirect "https://[HTTP::host]/home/admin2"
				} else {
          HTTP::redirect "https://[HTTP::host]/aa/bb/login/" 
          }
	 }
       }
    }
  }
}

 

3 Replies

  • Please refer the following article:

     

    https://support.f5.com/csp/article/K15450552

     

     

    =====

    F5 Product Development has assigned ID 704587 to this issue. F5 has confirmed that this issue exists in the products listed in the Applies to (see versions) box, located in the upper-right corner of this article. For information about releases, point releases, or hotfixes that resolve this issue, refer to the following table.

    Type of fixFixes introduced inRelated articlesRelease14.1.0K2200: Most recent versions of F5 softwarePoint release/hotfix13.1.1.5K9502: BIG-IP hotfix and point release matrix

     

    +++++++++++

     

    You can work around this issue by converting the string to an IP address with IP::addr before inserting it as a header.

    For example, the following iRule produces the previous error message:

    when HTTP_REQUEST {

       set exampleIP "192.0.0.2"   

       

       HTTP::header insert X-Forwarded-For $exampleIP

     

       log local0. "Where is myip1: [whereis $exampleIP country]"

    }

    To work around the issue, you can replace the previous iRule with the following iRule:

    when HTTP_REQUEST {

        set exampleIP "192.0.0.2"   

       

       HTTP::header insert X-Forwarded-For [IP::addr $exampleIP mask "255.255.255.255"]

     

      log local0. "Where is exampleIP: [whereis $exampleIP country]"

    }

  • ant77's avatar
    ant77
    Icon for Cirrostratus rankCirrostratus

    Thanks Sachin.

     

    So if I want to use two IP address to be looked at and match in the XFF client field, do you separate with a comma like below?

     

     

    when HTTP_REQUEST {

    set exampleIP "192.0.0.2, 192.0.0.3"  

       

       HTTP::header insert X-Forwarded-For [IP::addr $exampleIP mask "255.255.255.255"]

     

      log local0. "Where is exampleIP: [whereis $exampleIP country]"

    }

     

     

     

     

     

     

  • ant77's avatar
    ant77
    Icon for Cirrostratus rankCirrostratus

    Note that we are not trying to insert an IP address into the XFF header, but instead read the client-IP already inserted, and from there allow or deny/redirect based on a match or not. I used the IP called from within the data group for the match. If it does not, we know it is not coming from a location we allow and it should allow or deny based on that. This was working before the upgrade to 13.1.3.

     

    Thanks!