Forum Discussion

DWiggins_116310's avatar
DWiggins_116310
Icon for Nimbostratus rankNimbostratus
Dec 19, 2013

IP Filter assistance

Hey guys,

I've never written an iRule for restricting access by IP address before so I hit the forums and see that this is a fairly common question so I reviewed what was available. That said I haven't yet found a scenario close enough to mine to be of much help and I've tested a few versions of some similar rules to no avail.

Here's the situation, I need to lockdown a URL by IP the catch is there is no URI when the site is accessed at least not initially when the login prompt is accessed. It's a SSRS portal that pops up a login prompt rather than a webpage. While there will be URI's after login I just want it to filter by IP everyone that comes in.

Here's the closest I think I have gotten to a working iRule. When its enabled all connections just get reset even if the external IP is in the data group.

when HTTP_REQUEST {
if { ([HTTP::uri] starts_with "/") and !([matchclass [IP::remote_addr] equals $::dataservices_allowed_client_IP ]) } {
    drop
        }
}

Thanks for any help you can provide.

application delivery
devops
iRules

1 Reply

  • VernonWells's avatar
    VernonWells
    Icon for Employee rankEmployee
    Dec 20, 2013

    Is it the case that you simply want to prevent a specific set of IPs from accessing a particular LTM virtual server? That is, in this case, do you want to prevent access to the login redirection and all other URIs thereafter? If so, the iRule below will accomplish that. The class match semantics vary somewhat between 10.x and 11.x, but here is an iRule that will work under 11:

     when CLIENT_ACCEPTED {
if { ! [class match [IP::client_addr] equals /Common/dataservices_allowed_client_IP] } {
log local0. "Rejecting client [IP::client_addr]"
reject
}
}

    using the following datagroup definition, for example:

    ltm data-group internal dataservices_allowed_client_IP {
    records {
        10.11.113.5/32 { }
    }
    type ip
}

    CLIENT_ACCEPTED fires after the completion of the TCP three-way handshake. HTTP_REQUEST doesn't fire until after the client has sent all HTTP request headers.

    If this is the desired behavior, you may find some value in the ACL chapter of the LTM manual: http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-datacenter-firewall-config-11-2-0/5.html?sr=34017242