Switch Statement Routing to Separate VS Using 'Virtual'

The logic seems fine to me. Some suggestions:

1. Can you check by removing the "return" in the above logic ?

    

2. The api_https virtual server, can you test it by enabling it on all Vlans ?

    

Best

The return was only added after initial attempts that failed (exact same behavior) after finding a suggestion on a previous response here. I've also tried dropping down to the http version of the VS along with https. The issue seems to be it's just not assigning the traffic to the new VS despite the command being there.

Here's the first part of the iRule attached to the api_https (and api_http for that matter) virtual server. I only included the first part to show that immediately upon hitting the Vs, it should hit this iRule resulting in the log statement firing. I never receive that statement. Also, I can hit the api_https (or api_http) directly, so the IP restriction you see has been validated.

when HTTP_REQUEST {
    if { [IP::addr [IP::client_addr]/24 equals IP1]
        or [IP::addr [IP::client_addr]/23 equals IP2]} {
            log 10.10.0.9 local0.info "Host: [HTTP::host] -- URI: [HTTP::uri] " 

            ....

Hmm ok I do see the connection set up. Perhaps it's just the secondary iRule that is broken. My .NET code is getting a "Underlying connection is closed." Let me dig into this more, perhaps I missed something. Though the fact the secondary iRule/VS works on it's own is odd.

It's also open to all VLANs.

Couple of things. Since you're running iRules on these, I'm assuming that you have an SSL-Client side profile on both the API vip as well as the front end. That being the case, sending to the HTTPS virtual could very well be your problem since you've already decrypted the traffic on the first VIP.

We do this handoff using the virtual comand all the time without issue. Other than the previosly mentioned "return", there's nothing wrong with what you're doing... as long as you're not having to deal with to SSL-CS profiles.

Thanks. I'll go back to HTTP and try to get it working there, and then try to figure out if I can do the SSL part. If not, I may have to adjust the strategy here.

Just to clarify what's going on with the "virtual" command. The traffic never actually leaves the box when using this method. No reason to worry about it being unencrypted in transit. If you run a tcpdump, you can watch the transition from the first vip to the second, never exposed outside of the hardware.

tcpdump -s0 -ni0.0 -w /var/tmp/ host or host

https://devcentral.f5.com/wiki/iRules.virtual.ashx

Note: In version 9.4.0 and higher, 'virtual ' can be used to route the connection to another virtual server, without leaving the BIG-IP. This functionality did not exist in previous versions. In order to make this functionality work, one must precede the virtual command with an LB::reselect command if a pool member has already been selected.

Just to clarify what's going on with the "virtual" command. The traffic never actually leaves the box when using this method. No reason to worry about it being unencrypted in transit. If you run a tcpdump, you can watch the transition from the first vip to the second, never exposed outside of the hardware.

tcpdump -s0 -ni0.0 -w /var/tmp/ host or host

https://devcentral.f5.com/wiki/iRules.virtual.ashx

Note: In version 9.4.0 and higher, 'virtual ' can be used to route the connection to another virtual server, without leaving the BIG-IP. This functionality did not exist in previous versions. In order to make this functionality work, one must precede the virtual command with an LB::reselect command if a pool member has already been selected.

Yeah I do see it hit the second VIP and associated iRule. The issue is, I see it trip the CLIENT_ACCEPTED block but not the HTTP_REQUEST block. By trip, I mean I can get a log message out to my syslog server. That's where I'm stuck, is why it's not getting into the HTTP_REQUEST part.

Correct. We have to VIPs defined, one with SSL, one without. If I target the one without, it still exhibits the same behavior. I have to dig into more why it's opening the connection but then dying before it enters the http_request. But I haven't had time yet to try and see why that's the case.

if the back end virtual server is https, serverssl profile is needed on the front end virtual server. it has been configured, hasn't it?