Limit http Requests from a Specific IP.

I'm not sure this is possible on the older 4.x platform, though I know it is in 9.x. What version of BIG-IP are you running?

 

 

I'll have to look and see what I can dig up regarding 4.x and IP based limiting.

 

 

Thanks,

 

-Colin

We are currently running 4.5.13. We have been looking at the filter functionality, but I don't believe it will have the flexability we need.

 

 

Any help would be much appreciated.

 

 

-Thanks.

Liam,

here is a possible solution:

service 80 88 tcp enable
service 88 timeout tcp 30
pool servers {
   
   ...
}
rule myweb {
  if(client_addr == 176.123.123.23) {
     redirect to "http://limited.mywebapp.com:88/" + http_uri
  } else {
     use pool servers
  }
}
rule limited_myweb {
  if(client_addr != 176.123.123.23) {
     redirect to "http://www.mywebapp.com/" + http_uri
  } else {
     use pool servers
  }
}
virtual :80 {
   use rule myweb
}
virtual :88 {
   limit 10
   use rule limited_myweb
}

It works like this:

* everytime 176.123.123.23 connects to www.mywebapp.com it is redirected to the alternative.mywebapp.com virtual which has connection limit of 10 connections,

* anybody else that connects to alternative.mywebapp.com is redirected to www.mywebapp.com

Caveats:

* the solution does not scale well. You can create an address class in order to match larger number of addresses that are supposed to be granted only limited number of connections, but you'd have to create another alternative virtual server for each limited client, in order to get per client address connection limits. The normal virtual connection limit is shared by all clients, so a rogue client can take all available connections. You may improve the situation by using different port on limited.mywebapp.com virtual (e.g. 88 as show above) and setting short idle timeout for this port (also shown above),

* limited clients still make connections to www.mywebapp.com ... but those connections are only brief and they cannot keep them open for too long (the BIG-IP closes the connection as soon as it spits back the HTTP redirect),

Disclaimer: I've not tested the solution (but it should work) 😉