Explanation: F5 LTM Full-Proxy Architecture && SSL Bridging
The concept of a full-proxy architecture, along with SSL Bridging has seemed to confuse a good majority of people to whom I’ve attempted to explain. In that light, here we go. I could write a long drawn-out explanation of this process (and will, if requested) but most folks reading this want a quick answer. Let’s proceed.
A few things to note:
- “Full Proxy Architecture”, this means that clients or servers on either side of the F5 never talk to each other. The client thinks the F5’s endpoint (iApp) is the server, and the server thinks the F5 is the client. They never talk to each other.
- “SSL Bridging”, this means Client -> F5 is encrypted, then decrypted for processing, then re-encrypted, and F5 -> server is encrypted.
- “F5” is actually a company name, this products have many other names, such as F5 BIG-IP LTM ADC.
- It is a networking device, not a server, you can’t RDP to it like some people have assumed (although you can SSH into the management system and the TMSH data plane).
There is typically some confusion around what certs are on what box and whether or not they match. If they use the F5, the answer is – it doesn’t matter. They ONLY need to care about, and trust the cert that’s applied by the SSL Bridging profile attached the iApp that corresponds with the endpoint for that app. In the example I’ve drawn below (thanks to a fancy bright-link board) I show that the source client (which can be a server if you want), the F5, and the destination server all have different certs. Though, again all that matters to the anyone besides the F5 is the cert that the F5 uses. Note that the steps are numbered in green.
I hope this makes your day at least a little bit easier.
Thanks,
Nubee
It was brillient and yes it made my day alittle. Can you further explain .. what happens where client is authorise itself to backend server via certificate for identity and when ssl bridging happens on f5, which will start new ssl session where f5 will become a new client for the sever. Here f5 do not have identity certificate which can be identified as a authorised client to backend server, So dose the request work which was raised by original client?
mshansen01
SSL Bridging cannot be configured where the client uses a certificate only hosted on the backend server. To properly configure SSL bridging the F5 endpoint needs to hold the certificate that is advertised as being used by the backend server. The communication from the F5 to the backend server is a completely different stream. As far as your client is concerned, though, it is communicating with the DNS name that routes to the F5 endpoint and using the certificate that is used on the F5 endpoint.
PJ
For steps 10, 11 & 12, this happens in the F5 or outside of the F5?
mshansen01
Steps 10,11, and 12 all happen within the F5’s packet inspection and processing engine in the LTM. Everything in red in this diagram happens within the F5.