Forum Discussion

Stefan_Klotz_85's avatar
Feb 09, 2016

OCSP with Route Domains

At the moment I don't know exactly which heading best to use for my problem. So let me explain my current pain. We are migrating an existing F5-configuration from a different service provider. One of the VS is using client certs with OCSP checking. In addition to that they are using Route Domains. They don't use the APM, but standard LTM features. For their OCSP-URL they used another internal VS (, I assume as a workaround due to Route Domain restrictions. The original VS is in RD3 and the workaround VS is in RD0 (Common). This workaround VS has an iRule assigned with the command "node %3". I also found out that all their Route Domains have the "strict isolated" option disabled (but I don't know if this comes from an older version, where this was the default or if it was required to get it working).


I migrated all the config 1:1 to our new F5 and my current problem is, that I don't see any outgoing traffic towards the OCSP-URL with tcpdump. And as I'm not really familiar with OCSP, I don't know how to further troubleshot this. The new F5 has also the APM licensed, so an implementation via an APM-policy could also be an option if this is maybe easier. And we are running on 11.5.3.


So one of my questions is, are there any restrictions with OCSP and Route Domains? And as I already mentioned, how can I further troubleshot this. It would also be fine to built it from scratch or even using the APM.


Any additional hints and tips would be very helpful.


Thank you!


Ciao Stefan :)


3 Replies

  • I found out that the ocsp-iRule triggers correctly so I made a copy to include some log-statements.

    The AUTH::status is 2, but I didn't get any result for the AUTH::response_data. Maybe I'm using the wrong syntax as I'm not a TCL-expert and I don't fully understand the example in the iRule-wiki.

    I tried it with this syntax:

    array set auth_response_data [AUTH::response_data]
    log local0. "Auth response: [array get auth_response_data]"

    Can you please help me with the correct syntax to hopefully getting one step further?

    I also found an older post from hoolio, who stated that the AUTH::subscribe command is mandatory. As I don't know where the variable "tmm_auth_subscription" comes from, I removed the if-statement and called AUTH::subscribe directly. But still without any success. I don't see any outgoing traffic.

    Ciao Stefan ­čÖé

  • First of all, I got it working. But before providing all the details I'm still struggling with an annoying behavior.


    Yes it seems that OCSP is only working in the Common partition, so I created (as already mentioned from the existing configuration) a "forwarding" VS in the Common partition. The reason, that I don't saw any traffic as mentioned in my previous posts seems to be related to a missing route in the Common partition. Although the VS is somehow directly connected, the internal traffic handling seems to first check the routing table (I guess some F5-expert can shade some lights on it). I removed the route again to double check if it's really the issue and yes it's not working anymore (the internal VS will not be triggered anymore). But now the strange thing is, when I add the route again it's still not working anymore. I had the same issue already this afternoon, but it was working again after while and after some changes (but I don't know which ones).


    So does anyone out there knows this behavior/issue and how to solve it?


    Thank you!


    Ciao Stefan :)


  • Ok, I have now the whole picture. The "forwarding" VS, which is Standard-type VS in our setup needs to have an IP-address out from a directly connected VLAN. Before I used a dummy 192er address, that's why I never saw traffic or required a dedicated route for this IP. We used a VIP-address from our heartbeat VLAN, as there were still some free IPs available. But you can also create a complete new dummy VLAN with at least one self-IP in it. In both cases this VLAN needs to be part of the Common partition/route domain. Additionally you need to set the "Parent Name" of the route domain where you need the OCSP feature to "0". This allows your non-Common route domain to check the routing table of the Common route domain, which includes the "forwarding" VS as a directly connected VLAN. So no additional static route is required and even "Strict Isolation" can be left enabled.


    On top of that I combined this solution with the proxy emulating iRule, because the LB in our setup is not allowed to communicate towards the Internet. This works also like a charm.


    Ciao Stefan :)