Nimbostratus
CirrusAs far as I know you can only use trusted IP addresses, when policy builder is in use. If not, there should be no effect on that. From my understanding trusted IP addresses are not meant to no block anything in general, but help policy builder to tighten/loosen the policy.
I'm not sure what you are trying to achieve. Do you need to create a new policy on an existing VS without having false positive issues? If so, I assume that the single address, for which blocking mode should be used, is a test client, correct?
What about 1. use the transparent mode in general and just use event logs or better traffic learning to see if your configuration is working as assumed? You can issue violations from your test client and check the traffic learning for matching entries. 2. working with IP address exceptions. You can set a single IP address or whole networks to "policy default", "never block" or "always block". I'm not sure if longest match is working at this point (network 0.0.0.0/0.0.0.0 -> never block, network 1.1.1.1/255.255.255.255 -> policy default). Just check this out. 3. using different hostnames for testing purposes. The ASM policy allows to use transparent mode for single host names (ASM -> Headers -> Host Names), while all others are using the policy default (which would be blocking mode in your case).
Does that help?
I fully agree with samstep, that iRules are not the correct or best way to to dynamic policy assignments. In fact you will need to have an ASM policy assigned to the virtual, to be able to use ASM:: functions in irules. So you would need to issue ASM::disable to disable ASM on your conditions.
LTM policies are much faster than iRules and most of my customers don't like to write iRules, event they are much more flexible that LTM policies. In fact there is always at least one LTM (auto)policy, when you assign a security policy to a virtual.