Forum Discussion
Any incoming request (not just the initial connection)
To be clear, there are generally two options for allowing mutual TLS to pass through the BIG-IP, with client/server SSL profiles applied:
- ProxySSL - as described above. But note, ProxySSL can only work with non-perfect-forward-secret handshakes. That means it only works with RSA handshakes, and never with ECC, DHE, ECDHE, ECDH, etc. And since RSA handshakes have been mostly deprecated by all modern browsers, this option isn't terribly useful unless you control the browsers and are willing to force significantly weaker encryption.
- Client Cert Constrained Delegation (C3D) - https://my.f5.com/manage/s/article/K14065425. This is the modern way to handle the requested scenario, and works with TLS1.3 and below with modern ciphers.
C3D method would require provisioning / licensing of ssl Orchestrator - which i do not have licensed on my F5
This is my limited understanding of CARP:
It is a one-way hash-like algorithm that matches on a "source" and sends it to a "destination". As long as the "source" remains the same, the "destination" will be the same and it is for this reason that it doesn't store any persistence value on the F5 locally.
Now, using the above understanding, as long as the "source" values are diverse at any instance, we should have a better distribution of traffic. I think, if you have many pool members, it will increase the chances of the traffic being evenly distributed.
Least Connections (Member) is my favorite and default algorithm to implement by default. If it doesn't help, then explore other options. I don't think CARP/Hash is tied to a specific load balancing algorithm.
No, you don't have to add persistence records.
Testing - depends on the application, what you are trying to test and of course the resources you possess. If you have a great LT/Stage environment, it is easier to test or you can spin up a bunch of cloud servers in different DC from one of the public cloud providers to see if the load is evenly distributed.