iRule command to allow IP range to access specific URL

Hi,

We are having a project that require us to allow only set of IP ranges to access specific URL. May I know if this is possible via iRule?

hello ,

yes it is possible.. here is the example..

when HTTP_REQUEST {
    set srcip [IP::client_addr]
    if { [HTTP::header exists “X-Forwarded-For”] } {
        set srcip [HTTP::header “X-Forwarded-For”]
        log local0. “USER-SOURCE $srcip”
    }
 
    if  { [HTTP::path] starts_with “/xzy” } {
        switch $srcip {
            “13.174.130.182” -
            “31.121.101.157” -
            “35.77.107.183” {
          ACCESS::disable
            }
        }
    }
}

you can use this if you want to block any specific ip to a vip - Restricting access to a virtual server by IP subnet (f5.com)

or please let me know if its only specific to urls?

Hi Aswin,

Yes we will allow only specific IPs to access specific URL

Hi,

Can you tell me if below is correct?

if  { [HTTP::path] starts_with “/xzy” } {        <<<<<<<<< URL
        switch $srcip {
            “13.174.130.182” -             <<<<<<<<<<<<<<<<< IPs Allowed?
            “31.121.101.157” -
            “35.77.107.183” {
          ACCESS::disable                <<<<<<<<<<<<<<<<< Action?

hello Jayson27,

it is just an example …

instead of ACCESS::disable .. you can user “reject” or

HTTP::respond 403 content {
            <html>
            <head><title>403 Forbidden</title></head>
            <body>
            <h1>403 Forbidden</h1>
            <p>Access denied: Your IP address does not have permission to access this resource.</p>
            </body>
            </html>
        } Content-Type “text/html”
        
        # ends the connection
        reject
    }

Hi,

the iRule config will be like this? Where can i include the allowed IP?

when HTTP_REQUEST {
    set srcip [IP::client_addr]
    if { [HTTP::header exists “X-Forwarded-For”] } {
        set srcip [HTTP::header “X-Forwarded-For”]
        log local0. “USER-SOURCE $srcip”
    }
 
    if  { [HTTP::path] starts_with “/bo/login/” } {
        switch $srcip {
            “13.174.130.182”
            “31.121.101.157”
            “35.77.107.183”

{ HTTP::respond 403 content {
            <html>
            <head><title>403 Forbidden</title></head>
            <body>
            <h1>403 Forbidden</h1>
            <p>Access denied: Your IP address does not have permission to access this resource.</p>
            </body>
            </html>
        } Content-Type “text/html”
        
        # ends the connection
        reject
    }
            }
        }
    }
}

I don’t understand exactly what you want, but I think it would be easier to allow only certain IPs and block the rest… you can update it this way..  I am giving very general examples here, which you can modify and apply as you wish.

when CLIENT_ACCEPTED {
    # allowed IPS
    set allowed_ips {192.168.1.100 10.0.0.50 172.16.0.20}

client IP
    set client_ip [IP::client_addr]

# check the client IP is in the allowed-IPs
    if { [lsearch -exact $allowed_ips $client_ip] < 0 } {
        # if not , logged, blocked and message 
        log local0. “Blocked IP: $client_ip tried to access without permission.”

HTTP::respond 403 content {
            <html>
            <head><title>403 Forbidden</title></head>
            <body>
            <h1>403 Forbidden</h1>
            <p>Access denied: Your IP address does not have permission to access this resource.</p>
            </body>
            </html>
        } Content-Type “text/html”

reject
    }
    # If the client IP is among the allowed ones, continue as normal workflow
}

I am now getting the iRule but can I add also the URI to filter.

What we are trying to achieve is when client with IP 10.1.1.1 (sample only) access the http uri path “/example/login” it will be allowed then others will be deny.

In the long run it would be easier to use irule data groups so you can adding urls and IPs without touching the irule

Hi @jayson27

Did you get expected answer. ? I can see so many irule attached in this conversation now

I resolved the issue by using the LTM Policy instead of the iRule.