TLS handshake in passthrough scenario

Hi Ace,

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?

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.

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.

The scenario you described (FW, NAT, TCP proxy) is correct.

Great! So in my case, there will be 2 connection....client to loadbalancer and than loadbalancer to back-end server. Currently, the persistence method deployed is the source persistence with a refresh of 48 hours. In that case any connections coming in from a particular client, within the 48 hours time frame will be sent to the same back-end server where the first packet was sent.

That explains alot....would be nice if F5 has the tls passthrough document someplace.

Hi Ace,

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?

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.

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.

The scenario you described (FW, NAT, TCP proxy) is correct.

Great! So in my case, there will be 2 connection....client to loadbalancer and than loadbalancer to back-end server. Currently, the persistence method deployed is the source persistence with a refresh of 48 hours. In that case any connections coming in from a particular client, within the 48 hours time frame will be sent to the same back-end server where the first packet was sent.

That explains alot....would be nice if F5 has the tls passthrough document someplace.