allowed uri
2 TopicsIrule to allow specific IPs
I have a site which is abc.com Trying to achieve below requirements- 1) If uri is / it should redirect to abc.com/xyz - open for all 2) If uri is /rdp_xyz_tshoot should accessible to internal network - (here we can use the datagroup list) As this site is migrated to akamai where they have requirement to use below irule- when HTTP_REQUEST { if { [HTTP::header exists True-Client-IP] } { set trueclientip [HTTP::header True-Client-IP] HTTP::header replace X-Forwarded-For $trueclientip } } Cause for above akamai irule= Normally the True-Client-IP header includes the real IP of the clients when requests are coming from Akamai. It will be unaffected and be sent as part of the request to the pool member. So, your backend servers could look for that header and do something with its value. However, if you want the F5 to translate it to the X-Forwarded-For header, you can use an iRule to convert the Akamai True-Client-IP header to the X-Forwarded-For header. we are trying with below irule which is not working- when HTTP_REQUEST { if { ([HTTP::uri] starts_with "/rdp_xyz_tshoot") && (not[class match [IP::client_addr] equals allowed_IPs])} { reject } if { [HTTP::uri] == "/" } { HTTP::redirect "https://[HTTP::host]/abc_login.jsp" } } Please help37Views0likes2CommentsLocal Traffic Policy and selective URI access - missing trailing / issue
Hi, Trying to figure out how in the simplest and most effective way (avoiding iRule) achieve result like below: VS receiving traffic for multiple FQDNs Each FQDN should be directed to separate Pool Only specified FQDNs should be allowed to be passed to backend For selected FQDNs only specified URIs should be allowed 403 response instead of TCP reset should be send back to client when traffic blocked More or less I did achieve above but it is quite complicated considering number of LTPs or rules inside LTPs. Especially painful is handling URIs without trailing / So I have two setups: One LTP with all matching strategy and four rules (just handling one FQDN for a start): Host header rewrite when there is match on Host header in request Block all request when Host header is not (list of allowed FQDNs). This rule sets variable used in iRule sending 403 responses and closing connection Block all request when URI is not (list of allowed URIs). This his rule sets variable used in iRule sending 403 responses and closing connection Redirect when allowed URI (listed in previous rule) has not trailing slash. This rule sets variable used in iRule in a way that is not triggering HTTP::respond 403 Four separate policies with one rule each and first matching This is quite a lot of work, plenty of places to make mistake or typo so I wonder if there is any better way to configure LTPs? Or I should gave up and use iRule? I am quite puzzled as well what is difference between having one LTP with multiple rules vs multiple LTPs with one rule. From my test I can't see difference in performed actions but... What is strange for me is what is order of executing actions on matched rules. Three rules are setting same variable with different values. But what dictates order - in other words which rule will set final value? In all matching scenario and multiple rules for some reason rule responsible for Redirect (missing slash) sets this value last, even if during one LTP execution there is match on three rules: Host header blocking - var set to 403 Allowed URI hit - (here only full URIs are listed, like /test/) so /test triggers this, variable set to 403-1 Redirect hit (here URIs like /test are listed), var is set to 200 (so not HTTP::response 403 triggers in iRule) Every time var final value is 200 (so as set by Redirect rule) - I can see sequence of var value changes in log. Even if all match mode is used I tried to change order of rules in LTP - no change in behavior. Same happens when I have separate LTPs with single rule attached to VS. Again last rule setting var is Redirect. I wonder if this is king of coincidence or there is some reason for such behavior? Piotr291Views0likes1Comment