cancel
Showing results for 
Search instead for 
Did you mean: 

iRule to deny not working as expected (http 403 response not working)

Sabir_Alvi
Altocumulus
Altocumulus

So, we have been using iRules for many years to manage whitelisting of application access based on incoming source IP and strings in URL. When the request doesn't match, an HTTP 403 response is sent to the user. However, after we upgrade our BiG IP from v11.2.1 to v15.0.1, the 403 response is not working. The iRule itself works correctly to allow/deny access to the application, but the response when the request doesn't match is no longer 403 in the browser, it says "Can’t reach this page", which doesn't look clean as a user. Any ideas why the behavior change in the new version?

(Please don't suggest using Network policy etc, it is just too much of a workload to move hundreds of clients to a new configuration) Let me know how the iRule can be fixed to display the 403 response.

 

Here's the syntax I use -

 

when HTTP_REQUEST {     if { ([matchclass [string tolower [HTTP::uri]] contains "XYZ_Strings"]) and !([matchclass [IP::remote_addr] equals "ABC_IPs"]) } {              HTTP::respond 403 } }
7 REPLIES 7

SanjayP
MVP
MVP

This should work and give standard browser error for 403. But if it's not working in your case, you can try sending a content to the client in the iRule. Also, please replace matchclass with class match syntax as matchlass has been deprecated

 

when HTTP_REQUEST { if { ([class match [string tolower [HTTP::uri]] contains "XYZ_Strings"]) and !([class match [IP::remote_addr] equals "ABC_IPs"]) } { HTTP::respond 403 content "You don't have authorization to view this page. Access Denied" noserver Content-Type text/html Connection Close Cache-Control no-cache } }

You can also send custom html page from ifile stored on BIGIP

Hi Sanjay, thanks for the reply. I tried it, did not work, same response as before even with using content in the syntax.

Did you change syntax to class match? Please change it to class match.

​Also, would suggest to enable logging in iRule and check for ​the http trace in developer tools in browser or using fiddler/http watch. Which response code and content do you see there?

Yes, I have changed syntax to use class match. Please see the trace captured in the browser developer tool below.

 

0691T00000CngcIQAR.png

Can you modify iRule to below and test again?

when HTTP_REQUEST { if { ([class match [string tolower [HTTP::uri]] contains "XYZ_Strings"]) and !([class match [IP::remote_addr] equals "ABC_IPs"]) } { HTTP::respond 403 content "You don't have authorization to view this page. Access Denied" noserver Content-Type text/html Connection Close Cache-Control no-cache return } }

also, do you have any other iRule on the VIP that's conflicting here?

If ​this still doesn't work for you, you might want to log a case with F5 support. Meanwhile, you can enable some logging in iRule, capture the tcpdump and ssldump to analyse it.

I modified the iRule (I think I just had to add "return" at the end, still same issue.

Yes, there are other iRules but this whitelisting iRule is first in order so I don't think it is even getting to the next one to cause issues.

I will see if I can open a case with F5 support.

Appreciate your efforts to check this, thank you!

does the the /var/log/ltm show something with any of the irules on the virtual server?