APM profile with OCSP Authoring and Clientless mode configured, but need to reload page

what causes the 404? is the backend server expecting something that isn't send the first time?

also how do you request the certificate, if it is needed you could also do it via the ssl client profile and perhaps inspect it in the apm policy.

As far as I know, the backend server doesn't expect something specific. (I only click the refresh button in my browser)

In short:

Irule that determines the destination:

when HTTP_REQUEST {

when I have VS1 -> VS2, I get a 404. Refreshing gives me a 200 and the requested page

You could try to add some logging in your iRule just to verify where things are going and what the URI is. Then from the CLI (using PuTTY or some other SSH client and command

tail -f /var/log/ltm

when HTTP_REQUEST {
    log local0. "URI: [HTTP::uri]"

    if { [HTTP::uri] starts_with "/xxx/" } {
        log local0. "  Routing to IP_address_VS2"
        node IP_address_VS2 80
    } else {
        log local0. "  Routing to IP_address_VS3"
        node IP_address_VS3 80
    }
}

you could also loop and log the cookies that exists for the request if those matter on the back end.

log local0. "  Cookies:"
foreach cookie [HTTP::cookie names] {
     Log the cookie name and value
    log local0. "  $cookie: '[HTTP::cookie value $cookie]'"
}

personally i don't see why virtual server routing would be the issue? you go to vs2 or vs3 and one causes the first time a 404, but not afterwards.

i think the only cause of the 404 can be the backend server. so determine if this is case with tcpdump and check if there is a difference on the first and the second request.

a nice test would also be to directly access the backend server, does it work fine on the first try then? check the difference between that request and the one through the BIG-IP.

Simultaneously, I created a support case at F5 for this problem. During the investigation, I have found something interesting. VS1 has snat activated. Using the SNAT address, and added logging in the irule I mentioned above, I checked the network captures and found this:

the first time I make a request, I see the GET being delivered to VS3 instead of VS2. However, in my LTM logs, the irule I mentioned above logs that VS2 will be used. When I do a refresh, I see the GET package now being delivered correctly to VS2. It is as if the irule isn't executed correctly the first time, or the node command is not executed the first time the irule is called.

interesting, do you use any persistence profile?

In the meantime, we have found a solution for this problem:

there seems to be an issue with using an apm profile together with irules which use the node or pool command. Instead, I created now a forwarding policy in LTM which takes over the role of the irule. In this policy, I defined the forwarding to VS2/VS3 based on http-uri. (2 rules were created in the policy, 1 for each VS)

Tested this with my browser and an external client. Both work ok now