Forum Discussion

Saad_Malik_2068's avatar
Saad_Malik_2068
Icon for Nimbostratus rankNimbostratus
Jun 23, 2018

TLS handshake in passthrough scenario

Hi All,

 

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?

 

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.

 

Thanks!

 

10 Replies

  • 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).

     

    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.

     

    • AceDawg_204810's avatar
      AceDawg_204810
      Icon for Cirrus rankCirrus

      If you are planning to use source IP persistence, my recommendation would be to use performance layer 4 as the virtual server type.

       

      While F5 doesn’t have an official document on this setup, you’ll find that DevCentral is very useful with these types of questions.

       

      Feel free to vote up my answer if this has been useful.

       

    • Saad_Malik_2068's avatar
      Saad_Malik_2068
      Icon for Nimbostratus rankNimbostratus

      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.

       

    • AceDawg_204810's avatar
      AceDawg_204810
      Icon for Cirrus rankCirrus

      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.

       

  • 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).

     

    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.

     

    • AceDawg1's avatar
      AceDawg1
      Icon for Nimbostratus rankNimbostratus

      If you are planning to use source IP persistence, my recommendation would be to use performance layer 4 as the virtual server type.

       

      While F5 doesn’t have an official document on this setup, you’ll find that DevCentral is very useful with these types of questions.

       

      Feel free to vote up my answer if this has been useful.

       

    • Saad_Malik_2068's avatar
      Saad_Malik_2068
      Icon for Nimbostratus rankNimbostratus

      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.

       

    • AceDawg1's avatar
      AceDawg1
      Icon for Nimbostratus rankNimbostratus

      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.