Forum Discussion

seamlessfirework's avatar
Sep 29, 2023

iRule forwarding to Virtual Server not working

Hey guys,

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

<HTTP_REQUEST>: client: SrcIP%1
<HTTP_REQUEST>: /Common/VirtualServer-443

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?

  • Hey guys

    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.

      • Paulius's avatar
        Paulius
        Icon for MVP rankMVP

        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.

        tcpdump -nni 0.0:nnp host <first_virtual_server_IP> -w /shared/tmp/VS_Tshoot.pcap

        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.

  • Hi,

    I'm not sure do you have HTTP profile on this VS: VirtualServer-443 or not? it maybe relate the issue

    Could you please try IRULE redirect IP or Domain to new virtual server instead ?

     

    • T-Trust Thanks for your reply. The "http" parent profile is bount to the VS. Could you explain what you mean exactly regarding your iRule suggestion?

      • T-Trust's avatar
        T-Trust
        Icon for Cirrostratus rankCirrostratus

        Hi Seamlssfirework

        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