Forum Discussion

Piotr_Lewandows's avatar
Piotr_Lewandows
Icon for Altostratus rankAltostratus
Nov 22, 2017

Local 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

 

allowed uri
devops
iRules
local traffic policy
LTM
match strategy
order of execution
trailing slash

1 Reply

Sort By
  • Stanislas_Piro2's avatar
    Stanislas_Piro2
    Icon for Cumulonimbus rankCumulonimbus
    Nov 23, 2017

    Piotr, In manual look at this :

     

    An all-match strategy starts the actions for all rules in the Rules list that match.

     

    Note: In an all-match strategy, when multiple rules match, but specify conflicting actions, only the action of the best-match rule is implemented. A best-match rule can be the lowest ordinal, the highest priority, or the first rule that matches in the Rules list.

     

    In default strategy Best match, http-host is preferred, so the first rule may match.

     

    I didn't know you can assign multiple policies sharing same actions to the same virtual server

     

    the default configuration (first match) disallow to assign multiple policies with same actions type to one VS. maybe the all match strategy may allow it.

     

    I never use another strategy than First Match and I recommend to use only one policy with multiple rules.