I manage a really old BIG-IP environment. Most of the configuration were not made by myself so I'll try to give you a brief overview what I have here. There is a BIG-IP cluster, some partitions configured, some route domains configured. In common partition I have to specifiy IP addresses in ASM address exceptions with %1 to get matches for example.
Here is my challenge:
I have a VS VirtualServer-443 that is offloading SSL traffic for several SNIs. ThisVS VirtualServer-443 works fine. We want to implement WAF features but we have no testing capabilities. The idea is to deploy another VS (TargetVirtualServer) beside the prod VS VirtualServer-443. Traffic from specific friendly users should be intercepted by an iRule bound to the VirtualServer-443 and forwarded to the new TargetVirtualServer. The TargetVirtualServer holds the same configuration like VirtualServer-443:
Same client SSL profiles (including default for SNI)
Same serverssl profile
AutoMap
Same Destination pool
Same HTTP profile
Same Request Adapt profile (for ICAP)
Imagine the TargetVirtualServer as a clone of the VirtualServer-443.
I have a super simple iRule that should solve my problem attached to VirtualServer-443.
# Check the HTTP request and set client IP in variable
when HTTP_REQUEST {
set source_ip [IP::client_addr]
# Check if the source IP is one of the allowed IPs
if { $source_ip eq "x.x.x.x%1" || $source_ip eq "y.y.y.y%1" } {
log local0. "client: $source_ip"
virtual TargetVirtualServer
log local0. "[virtual]"
}
}
Unfortunately it doesn't work at all. Here is the log output
I even attached a traffic policy to VirtualServer-443 to solve this but it did not work out (removed the iRule before). I have other BIG-IPs where I use the good old VIP-targeting-VIP concept in conjunction with traffic policies and it works out like a charm. But there is only the default route domain configured.
I have no clue why the BIG-IP tries to forward the traffic to the same VS (VirtualServer-443) instead to TargetVirtualServer. I suspect the route domains for my trouble but I am not sure about that. Any ideas?
@seamlessfirework The syntax in the iRule seems to be correct, supported on this code version, and I don't see any bugs relating to this specific action. You might consider running the following tcpdump and opening it up in wireshark to see what the F5 is doing with it.
This should show you exactly where the traffic is going if you look at the F5 field that will be added into the capture. It might be worth uploading a QKVIEW to iHealth and see if it can find anything as well.
@Paulius Thanks for your quick hint. An upload to iHealth is not possible. Sorry. But I did a capture and found something strange to me. The BIG-IP sends a TCP reset because of an iRule execution error. Have a look at the F5 trailer
@seamlessfirework At this point I think that would be best because that's definitely odd behavior. The nice part here is you probably already have the captures they want but you will most likely have to provide them a QKVIEW as well. Another note is to make sure you are on the newest recommended code version because that will be one of the first things they have you do if the issue is not easily found.
So i think http profile inspect layer 7, when traffic hit on this profile and inspect http header, maybe we cannot forward traffic to another virtual server
Got some news for you. I had conversation with the support. What I didn't know was that
log local0. "[virtual]"
only displays the current Virtual Server not the one the traffic is forwarded to. So my logging was not clear enough and I went down the wrong track the whole time. They gave me the hint to configure an iRule just for logging purposes on the backside VS. When I tried a request in my production environment no packets hit the backside VS, no logging visible, too.
I tried this setup on another BIG-IP cluster with no route domains and it worked out like a charm. I think my problem are the whole bunch of route domains configured on my legacy BIG-IPs. I asked the support whether there are options in iRules to say that the new VS is located in route domain xyz. When I have some news I'll write them down right here.
