I have a problem with our F5 to configure the CRL check for client certificates.
We have an F5 that we share for many clients infrastructure. Each client has his own partition and route domain.
I wanted to make some test with OCSP and CRLDP protocols in order to take the most appropriate for CRL update but I'm facing an issue.
Whatever the server I set on "OCSP Responders" or "CRLDP Server", the flows don't use the default route set on the partition.
The request exits through management interface every time and are of course blocked on the firewall behind this interface.
I had the same issue with AAA serveur on APM until I understood the difference with "Static" and "Pool" parameters.
Except that for CRLDP or OCSP, there is no choice to use a pool.
Of course, there is no way for us to use management interface because it has nothing to do with client infrastructure. Each client has their own architecture and active directory so it has to exits from the partition default route.
Until now, I don't have any solution except to update CRL manually.
I tried to create a VS (in client partition) with an IP in the network range of the default gateway of the partition and configure the CRLDP or OCSP with the ip of this VS but still, it goes out from management interface.
I would appreciate any help on this subject. A way to fix it or another way to update CRL?
do you have any management routes setup?
Yes, the management interface has its route. We can see the traffic exiting the F5 from management interface but we cannot route it to the correct network because management network and partition/route domain networks are on totally separated infrastructures. That's why, I need to find a way so that the CRLDP or OCSP traffic goes out from the default gateway on it's partition.
but what are you management routes? is the destination for the CRLDP / OCSP traffic ammong these?
could you share you CRLDP / OCSP config so i can have a look at reproducing?
No, as I tried to explain (sorry for my english), the management route are on totally different network/infrastructure than the default route of the partition. That's why I get trouble to contact CRLDP / OCSP server.
For example, the management interface is on 172.20.10.0/24 and the default route of the partition is on 192.168.146.0/24 (Of course with self and floating ip on this network). Both network are nothing to do together.
In this case, I configure the CRLDP / OCSP server which has 192.168.147.10 as ip. So the traffic should go through the default gateway 192.168.146.1 and then be router to 192.168.147.0/24 by the next hop.
But, in this case, the traffic is sent to the default gateway in 172.20.10.0/24 and then lost because there is no route on this infrastructure.
I found no way to force the traffic to use the default gateway of the partition.
@ebrc, did you find a solution to this problem as I am facing the same issue here.
@JorenC, Sorry for the late answer. No, I didn't find any solution...
If you do, please share!
I had the same issue.
If you make a host route for the OCSP Server on the default partition it should work.
I didn't try, but eventually it just needs to be a more specific route than the mgmt default route,
for example 192.168.147.0/24 with gateway 192.168.146.1
I found a solution for this issue!!
Recently I face exactly the same problem with "Bundle Manager List" (new feature of v13).
I had a partition "Front" and the traffic to fetch certificates where going out through management interface in common partition which is in a completely different architecture than the one for our client.
Common partition is using route domain 0 (RD0)
My "Front" partition is using route domain 1 (RD1).
So I just added a route in "Front" partition with the destination network followed by %0.
It look's like (example):
Thanks to that, the traffic is going