Local Traffic Policy and iRule events
Hi, I was reading some post about order of execution, in other words if Local Traffic Policy (LTP) executes before or after iRule. Seems that answer is both 🙂 Scenario: VS with all ports allowed LTP with TCP port is not equal to any of 80; 443 and action Reset traffic iRule with CLIENT_ACCEPTED, HTTP_REQUEST, ACCESS_SESSION_STARTED events (actually few more are in iRule) Without any mods to iRule effect is like that: All commands in CLIENT_ACCEPTED are executed LTP is triggered to reset traffic (log action is performed, so I can see it triggers) All commands in HTTP_REQUEST are performed No command in ACCESS_SESSION_STARTED is executed RST-ACK is send to client CLIENT_CLOSED event is triggered So LTP is not preventing CLIENT_ACCEPTED and HTTP_REQUEST events to be triggered but disables other events and resets connection. I can understand why CLIENT_ACCEPTED is triggered but why HTTP_REQUEST? And why using only matching at TCP connection in LTP causes LTP parameter $1 have http included? I am as well setting variable via LTP. From logging it is obvious that this variable is not yet created when CLIENT_CONNECTED event is executed but it is when HTTP_REQUEST triggers. So for some events iRule is executed first for other LTP. Main question is why LTP allows HTTP_REQUEST to be triggered at all? Matching and actions in LTP are only for TCP protocol not HTTP. Reason I am asking is that I planned to use LTP to limit traffic to specified ports but seems it is not a good solution. Seems that it has to be performed in iRule at least when there is some code to be executed in CLIENT_ACCEPTED as there is no way to disable this event anyhow - or maybe there is? Implementation of Reset traffic is a bit weird. It is using TCP RST for that even if it is still allowing HTTP request to be processed. I understand that LTP is targeting HTTP traffic handling but then instead of TCP RST we should be able to use HTTP respond to more gracefully end client connection. I am able to disable HTTP_REQUEST by setting variable in LTP and checking it in HTTP_REQUEST but not in CLIENT_ACCEPTED. That could be avoided if LTP would not allow HTTP_REQUEST to be triggered. I guess that limiting traffic for all port VS is then possible in two ways: AFM policy iRule Or there is some other way? PiotrLocal 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? Piotr