Which runs first iRULE or PolicyLTM(With ASM being applied)

Hello, I'm not really getting what's the purpose of this iRule.

I see that you have a VIP in place that receives several connections for several websites.

If users connect to "mysiteexample.com.br" they get a specific ASM policy, if they conect to a set of "misc" services they get a different "general" policy, and they get no policy for any other hostname. 

So far, so good. 

But.. In the Virtual Server configuration, how do you differentiate connections to "mysiteexample.com.br" web server from the "misc" ones? And how do you differentiate those to the hosts that don't match anything else? Do you have different pools, or is it all on the same web server? Do you have different ports as well? And is this the reason that you have the iRule in place? 

I think it's important to sort this out, because it will help you understand what instructions to put in the Policy and the iRule. 

A few issues I see with your setup: 

• The iRule doesn't check HTTP Host. This means that it will fire if you point to "mysiteexample.com.br", it will fire if you point at misc services, and it will also fire if you point at anything else.
• After the iRule fires and there's a match with the URI, client will receive a HTTP redirect. I see another issue here: users will still resolve [HTTP::host] with the F5 IP, and point to it on HTTPS standard port 443. If you don't have a Virtual Server configured to receive this connection, users will crash.
• If you just need to change the HTTPs port in backend connection only, there's no need to set up redirects, F5 supports this out-of-the-box!  You'll just need to configure a new pool on port 443 and use the "pool X" iRule statement instead of a redirect. Muuuch cleaner. 
• ASM policy will still be processed ! 

If I got anything wrong, please correct me -- I'm expecially curious about the redirects. 

I'll be happy to help you tune this scenario, if you could share with me the requirements.  

In your specific setup:

1. The LTM policy LTM_POLICY_ASM_MYSITE is evaluated first.
   • If the http-host matches www.mysiteexample.com.br or mysiteexample.com.br, the ASM policy /Common/ASM_MYSITEWAFPOLICY is enabled.
   • If the http-uri contains miscelaneous, the ASM policy /Common/ASM_MYSITEWAFPOLICY_MISC is enabled.
   • If neither of these conditions are met, the no_asm rule disables ASM processing.
2. After the LTM policy conditions are evaluated and any ASM policies are enabled or disabled, the HTTP_REQUEST iRule is processed.
3. The traffic is then inspected by the ASM policy if it has been enabled by the LTM policy.

If the ASM policy is interfering with the iRule, you might need to structure your LTM policy and iRule to ensure the iRule logic executes as expected. One approach could be to temporarily disable the ASM policy within the iRule for specific conditions and then re-enable it after the redirect, though this can be complex and might not always be feasible.

when HTTP_REQUEST {
    if {[HTTP::uri] starts_with "/region1/abc"} {
        # Temporarily disable ASM for this specific redirect
        ASM::disable
        HTTP::redirect https://[getfield [HTTP::host] ":" 1][HTTP::uri]
        ASM::enable
    } elseif {[HTTP::uri] starts_with "/region2/abc"} {
        ASM::disable
        HTTP::redirect https://[getfield [HTTP::host] ":" 1][HTTP::uri]
        ASM::enable
    } elseif {[HTTP::uri] starts_with "/region3/abc"} {
        ASM::disable
        HTTP::redirect https://[getfield [HTTP::host] ":" 1][HTTP::uri]
        ASM::enable
    } elseif {[HTTP::uri] starts_with "/region4/abc"} {
        ASM::disable
        HTTP::redirect https://[getfield [HTTP::host] ":" 1][HTTP::uri]
        ASM::enable
    } else {
        # do nothing
    }
}