TLS handshake in passthrough scenario

Question

Hi All, &nbsp;
This might be a basic question but i would like to know how the SSL/TLS handshake takes place in a SSL passthrough scenario. If we are not doing the offloading, there is no certificate on the F5 installed than how will the handshake happen? Will the tls hello packets be forwarded directly to the backend server? &nbsp;
I couldn't find any documentation on this scenario. Any help would be great. I assume this would be the case for any loadbalancer and not just F5. &nbsp;
Thanks! &nbsp;

acedawg_204810 · Answer

You are correct. In a scenario where the load balancer  does not perform ssl encryption/decryption (offloading), ssl negotiation is performed directly between the client and backend pool members (servers). &nbsp;
A typical F5 configuration would be comprised of a virtual server that listens on port 443, server type of standard or layer 4 and backend pool members listening on port 443.&nbsp;

acedawg1 · Answer

You are correct. In a scenario where the load balancer  does not perform ssl encryption/decryption (offloading), ssl negotiation is performed directly between the client and backend pool members (servers). &nbsp;
A typical F5 configuration would be comprised of a virtual server that listens on port 443, server type of standard or layer 4 and backend pool members listening on port 443.&nbsp;

saad_malik_2068 · Answer

Hi Ace,&nbsp;
thanks for the confirmation, i thought so too but my confusion starts when i think of the load balancing. So the client hello comes through, the load balancer sends it to one of the available nodes....how does the stickiness persist in this case when the other handshake packets comes?&nbsp;
So in this scenario, the VIP has a natted IP on the firewall which is exposed on the internet, the external clients connects to that IP. So my understanding was the load balancer will make the connection with the external client and make another connection with a particular back-end node and once the connection is established, it will just pass the ssl/tls traffic through. Offloading would be if we decrypt the tls/ssl packets which we are not in this case.&nbsp;

saad_malik_2068 · Answer

Hi Ace,&nbsp;
thanks for the confirmation, i thought so too but my confusion starts when i think of the load balancing. So the client hello comes through, the load balancer sends it to one of the available nodes....how does the stickiness persist in this case when the other handshake packets comes?&nbsp;
So in this scenario, the VIP has a natted IP on the firewall which is exposed on the internet, the external clients connects to that IP. So my understanding was the load balancer will make the connection with the external client and make another connection with a particular back-end node and once the connection is established, it will just pass the ssl/tls traffic through. Offloading would be if we decrypt the tls/ssl packets which we are not in this case.&nbsp;

acedawg_204810 · Answer

There are several flavors of persistence. Cookie persistence is typically the more popular choice for web traffic but can only be employed if the F5 has access to the HTTP session -- not possible if SSL negotiation is performed directly between client and pool members. Source IP address persistence is a possible candidate but this can bring about complications if clients are behind a firewall. That said, SSL persistence is probably the better choice in your setup -- the SSL session ID is used to persist.&nbsp;
The scenario you described (FW, NAT, TCP proxy) is correct. &nbsp;

Forum Discussion

TLS handshake in passthrough scenario

10 Replies

Recent Discussions

Find GSLB pool membership from vip IP

Pool Members communication with B-party via F5 VIP

Server 2 causing application slowness

F5Access | MacOS Sonoma

AS3 Deployments (shared objects)

Related Content

Using Distributed Cloud DNS Load Balancer with Geo-Proximity and failover scenarios

Passthrough IPSec with AFM

SSL Profiles Part 1: Handshakes

TCP Internals: 3-way Handshake and Sequence Numbers Explained

Especial Load Balancing Active-Passive Scenario (I)