For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Kevin_Stewart's avatar
Kevin_Stewart
Icon for Employee rankEmployee
Jul 11, 2015

Okay, so if I understand, your primary external VIP needs to simply tunnel the client's SSL session to the secondary internal VIP(s). So here's the deal:

 

  1. If the client is establishing an SSL session with the secondary VIP, the primary VIP only sees encrypted traffic and CANNOT filter on URL. It can only see the IP and port.

     

  2. If the client is establishing an SSL session with the secondary VIP, then it is the secondary VIP's client SSL profile that matters. It frankly doesn't make any sense to do unencrypted traffic between the client and primary VIP and SSL between the primary and secondary.

     

It may be that you can solve your external IP address issue in a better way:

 

  1. A single wildcard or subject alt name (SAN) cert on your ONE VIP that decrypts client side SSL, optionally re-encrypts on the server side, and sends traffic to different pools based on request URI or hostname).

     

  2. Do the same as above with SNI (server name indication) - a TLS extension whereby the client presents a unique hostname in it's ClientHello message.