Forum Discussion
Cirrusproblem with irule and policy rule @ 11.4
Hi,
I still test the firmware 11.4 and have a problem with the new policy rules, you have to create at ltm.
-
I did create a irule, which insert a header:
when HTTP_REQUEST { set bea header HTTP::header insert "WL-Proxy-SSL" "true" } -
I did create a policy with the settings: Strategy first-match, Requires http, Controls forwarding
-
I did create a Rule with the settings: Action
target http-reply event request action redirect parameters location http://www.google.de
So every incoming traffic should be redirect to www.google.de (example)
With this settings, I get a TCP reset and a log entry:
TCL error: /Common/SetWLSHeaderIrule-Proxy-SSL - Operation not supported (line 1) invoked from within "HTTP::header insert "WL-Proxy-SSL" "true""
I know, the irule is correct. If I remove the policy from the virtual server, everything is ok. If I add the policy, I get the resets again.
It looks like the rule is wrong. But I don't see the error 😮
Anybody with an idea?
thx
13 Replies
TortiAt the old 11.2, I only created a HTTP class with the action: redirect to...
If your plan is to create a redirect that also inserts a header, you should be able to do it completely by using this policy as a starting point, and then adding a second action that inserts the header you desire: https://devcentral.f5.com/questions/creating-a-redirect-with-local-traffic-policies-v114
- Note that your location header will differ from what is documented in the discussion linked above.
- Sorry, this appears not to work. Will add another comment if I figure out a way.
- Torti
my plan is to create a virtual server with multiple apps (ASM) and a default redirect, if there was no match. All without an irule.
At 11.2:
vitual server class1 -> uri starts-with - /app1 class2 -> uri starts-with - /app2 class3 -> redirect to ... IN this case, it follows the same way. Your policy matching strategy should be "first-match", and then you have a rule for each class;
rule_class1: conditions: URI starts with "/app1" Actions: whatever you desire.
rule_class2: conditions: URI starts with "/app2" Actions: whatever you desire
rule_default: Conditions: (empty) Actions: redirect to...
ON the main policy page, you can then reorder the rules and make sure they appear in the order specified, and then click "update".
I haven't tested this because I don't have time right now though.
- Torti1. it doesn't work, because i use ASM for the rules, too. So it want an asm action in the rule_default, too. But why I have to use asm, if I want to redirect? Strange... 2. I still cannot insert a header via an irule.
- Torti3. i allways will be redirected, so rule_class1 doesn't work.
- Torti
what I found out:
the reset and the error message about wrong irule will be generated, I I get the traffic from another virtual server in front.
what is still mysterious:
If I place a default rule with a redirect at the end, every traffic will be redirected :-(
I am not familiar with ASM, but I think you need to describe your setup a bit better. Why do you have an irule if you want to do everything with policies?
I understand the potential problem if a redirect appears to take precedence over all other actions and if true, this is something that merits further investigation. I believe that the rules are evaluated in order when the matching strategy is first-match, so the only reason why the redirect rule will match is if the first 2 don't match.
- Also, in the worst case, assuming there are not too many branches, you can specify the conditions for the redirect rule to be a "NOT (rule_class1 or rule_class2)" since the conditions allow negation.
By the way, can you post the HTTP class which you have previously created to accomplish this task?
- Torti
I use the iurle to set some http header or for rewrite some urls or to repond with a special response page, if the pool is down, i.e.
ok, I found a first mistake in my config. I did setup "all-match" instead of "first-match". :-o Now, the redirect is working fine, thx.
The next step is to find out, why forwarding to another virtual server ends in tcp reset and tcl error messages from above.
