iRule Geo Targeting

Some minor cosmetic changes:

when HTTP_REQUEST { 
    if { [string tolower [HTTP::uri]] starts_with "/geo" } { 
         Parse the client IP from X-Forwarded For as Client IP is proxied. 
        if { not ( [HTTP::header exists X-Forwarded-For] ) } {
            set state [class match -value [whereis [IP::client_addr] state] equals uk_regions]
            switch $state { 
                "Leeds" {
                    HTTP::redirect "http://62.190.1.1/ab/leeds"
                } 
                "York" {
                    HTTP::redirect "http://62.190.1.1/ab/york"
                } 
                "grlond" {
                    HTTP::redirect "http://www.google.com/news"
                } 
                default {
                    pool DEV-HTTP-POOL
                } 
            } 
        } else {
             what do we do if the X-Forwarded-For header is missing?
        }
    } else {
         what do we do if the URI doesn't start with /geo?
    }
} 

A couple of key points also:

1. In the previous rule you had the "state" switch outside the X-Forwarded-For header/class match conditional, which meant the $state variable could have not existed when the switch statement was performed - causing an error. I moved all of that into the X-Forwarded-For header conditional.

2. The default pool action will only be triggered if the URI starts with "/geo", the X-Forwarded-For header doesn't exist, and class match fails. You should probably have else conditions outside of these to account for:

   • What happens if the X-Forwarded-For exists
   • What happens if the URI deosn't start with "/geo"

There are three "else" conditions in the above iRule:

1. If the URI doesn't start with "/geo" - this is the last else condition in the iRule. As written, it should simply ignore all of the processing and pass the traffic (ie. "else do nothing").

    

2. If the URI starts with "/geo" but the request doesn't have an X-Forwarded-For header - this is the next else condition up from the bottom. As written it will simply pass the traffic through.

    

3. If the class match doesn't find anything - this is the "default" condition in the switch clause. As written it sends traffic to the DEV-HTTP-POOL pool.

    

Hi Kevin ,

We've finally got some production access time. We can get a rule working as expected when we do it without the x-forwarded for , ie the below :

when HTTP_REQUEST { if { [string tolower [HTTP::uri]] starts_with "/geo" } { set state [class match -value [whereis [IP::client_addr] state] equals uk_regions] if {($state ne "")}{ switch $state { Angus { pool $region } Poole {HTTP::redirect "http://www.hotmail.com"} Leeds {HTTP::redirect "http://www.yahoo.com"} else {pool CMS-TEST-POOL} } } } }

When we try with the X-Forward for element it doesn't seem to detect correctly though. Anyway you can think of to log out the x-forwarded for IP to the local0 to if the real IP / state is being detected ?

I think we've found the issue whereby multiple X-Forward For IP's are being reported when we output to Log file. ie : : X-Forward IP: {193.x.x.250, 80.239.x.x} 46.33.x.x

Any ideas as to have the rule just process the first IP in the list , IF the problem is that when the rule receives multiple IP's is doesn't fire.

Thanks

Neil

You could do this:

set xff [lindex [split [string map [list " " ""] [HTTP::header "X-Forwarded-For"]] ","] 0]

Ref: https://devcentral.f5.com/questions/using-x-forwarded-for-to-block-clients