Technical Forum
Ask questions. Discover Answers.
Showing results for 
Search instead for 
Did you mean: 
Custom Alert Banner

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
    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?



@seamlessfirework What code version are you running on these F5 devices?

You mean what BIG-IP version I am running? If yes

@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.

@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

F5 Ethernet Trailer Protocol
    F5 Trailer Header - Version: 1
        Magic: 0xf5deb0f5
        Length: 122
        Version: 1
    Low Details
        F5 Trailer Header, Provider: 1, Type: 1
            Provider: 1
            Type: 1
            Trailer length: 44
            Version: 2
        Ingress: False (OUT)
        Slot (1-based): 1
        TMM (0-based): 2
        Virtual Server: /Common/VirtualServer-443
            Length: 32
            Name: /Common/VirtualServer-443
    Medium Details
        F5 Trailer Header, Provider: 1, Type: 2
            Provider: 1
            Type: 2
            Trailer length: 70
            Version: 4
        Flow ID: 0x00004001830ea800
        Peer ID: 0x0000000000000000
        Connflow Flags High Bits: 0x01202080
        Connflow Flags: 0x04808024
        Flow Type: 0x40
        HA Unit: 0x01
        Reserved: 0x00010008
        Priority: 3
        RST cause: [294f5e2:1864] iRule execution error
            Length: 30
            0000 000. = Version: 0 (0x00)
            .... ...0 = Peer: 0
            Value: 0x00000294f5e2
            Line: 1864
            Cause: iRule execution error

I've never seen that before to be honest.

@seamlessfirework Are you seeing any errors generated in the F5 ltm logs for the iRule applied to either of the virtual servers?

@Paulius I had the same thought but there is no error in the log. I opened a support case. I'm curios what they say about this issue.

@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.



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?

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

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.