Forum Discussion
CirrusSSL issues with new setup
MVPirbk Based on the second virtual server configuration, I see that you are passing decrypted traffic to the servers on 443. Did you configure the servers to receive decrypted traffic on 443 because by default they should not allow that? Now SSL bridging is nice but not necessary and completely depends on your security stance and capabilities of the receiving pool members and if they can perform all application functions over HTTP and not HTTPS. If it's not required I would stick with SSL termination at the F5 and passing decrypted traffic to the servers.
CirrusNo, that shouldn't be right. The servers have to have encrypted traffic, they aren't configured to recive it otherwise. What setting requres changing?
Actually, the servers arn't even going to be receiving on 443 in the end, this is just how I'm testing to get the certificate issue squared away but the servers do need to recieve encrypted traffic so either the BigIP needs to do a passthrough or we need to setup the SSL Bridging (which I believe is the prefered option for several reasons).
- Paulius
irbk So I think we need to sort a few configuration options first.
1. SSL Termination on F5
F5 terminations SSL using the SSL Client profile and then passes decrypted HTTPS traffic to the server on an alternate port such as 80 or 8080 so that you or the application can tell the difference between traffic that was HTTP traffic and which was HTTPS. So 443(F5) -> 8080(Pool member)
2. SSL Bridging
F5 terminates SSL using the SSL Client profile, performs varios tasks now that the traffic is decrypted, then finally uses the SSL Server profile to encrypt traffic and pass it back to the pool member on 443 or an alternate port such as 8443.
3. SSL Passthrough
F5 performs zero SSL tasks and passes the traffic directly to the server to decrypt and encryptIf you are having an SSL issue it could be directly related to the server not being configured to receive that decrypted traffic since you are only using an SSL client profile or possibly an SSL cert on the server that is rejecting the requests.
- irbk
End goal is clients will be using a client side application (not a webpage) to go to the F5, the F5 redirects them to the server, client talks with the server.
How that client side application works is a little bit more tricky. As far as I can tell, it starts out communicating on 80 and then flips to a different port using TLSv1.2. The server is expecting it's traffic encrypted so SSL Passthrough or SSL Bridging is my only option and between the two, I guess the SSL Bridging is better because the F5 gets better visability to the traffic.
