Terminating SSL on F5 and re-encrypt to end server

Have you added a cert and key to the clientSSL profile?

Hy Pete, yes of course, i did ssl handshake on External interface when i am doing ssl offloading and that is working fine.

I also have VS where i am ssl offloading and based on header i am doing redirect. But the problem is when i need to re-encrypt end send to server behind f5.

Can you explain the error in more detail?

Are you getting a specific error message?

If you're doing ssl bridging, both client and server ssl profiles on the virtual server, there will be two separate handshakes for all traffic. Each one is independent from the other and will be handled by whatever settings you have on each ssl profile. The client ssl profile needs to complete the handshake successfully with the user. Once that happens then the handshake against the selected pool member(s) begins.

If you believe your situation is ssl related you may probably need to capture both handshakes.

So when you re-encrypt you need to add a serverSSL profile to re-encrypt the data. Make sure that the pool member is listening on port 443. When doing SSL offloading, the clientside port is 443 ie SSL and the serverside port is 80 so you may need to change that when changing to SSL bridging.

Pete, i didn't catch you with this serverside is port 80 and SSL bridging.

Let me explain my situation.

I need next case in traffic flow:

Client -> F5 (here i am doing ssl offload with configured SSL Profile Client) -> pull header and based on that forward to some pool also 443 -> then WebApplicationProxy (here after user is auth ) -> End server

1. Client on Internet request https://abc.abc.com
2. It's reaching my F5 where i configured VS with SLL Profile Client (i added certificate and private key) and with port 443.

2.1 here i checked SSL handshake between client and F5(server in this case) and everything is working fine.

3 After i match my request with iRule i forward to Pool in witch i have WebApplicationProxy port 443.

3.1 Mention VS is also configured with SSL Profile server

3.2 Now when i check SSL handshake between F5 (client this time) and server (WAP) i have output from my original post. Server immediately send TCP restart (i checked cipher from side client-F5 and same is sent from F5 to WAP)

3.3 When i check this WAP server and do netstat i don't see any connection coming and yes this WAP listening on port 443

Also i use http profile in VS

So i know that i am doing something wrong on side when i need to re-encrypt but don't know what.

Second scenario

When i don't use ssl offloading and create VS that listen on 443 and just forwarding on same pool that i use in above explained scenario (without SSL Profile Server/Client) everything is working fine.

Thanks a lot guys for help.

Hello Ivan,

My instinct is that there's an issue with your server-side SSL certificate, either in configuration or connectivity. Based on your SSL dump from your F5 to your server, the client hello seems to be in order, sending accepted TLS ciphers, compression, algorithms, etc. But at the very bottom of the dump you shared there is:

1    0.0012 (0.0006)  S>C  TCP RST

That looks like a reset. i.e. your F5 did not get a response from your backend server, and is restarting the ssl exchange. I'm guessing layer 4 connectivity isn't the problem, since when you offload encryption on the F5 it worked as intended.

The openssl from client through the F5 and straight to your backend servers seems to support this idea as well. The SSL handshake is failing in a nigh identical way in this set-up; there seems to be no response from the server, which should decide on which ciphers/compression will be supported. I based this off of:

no peer certificate available
---
No client certificate CA names sent
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated

Based on the information from the ssl dump between the F5 and the back-end server, it makes sense that the certificate exchange fails, since it looks like there isn't even a Server Hello in response to the CLient Hello.

To troubleshoot, I would potentially double-check how your proxy is functioning between the F5 and the backend-servers; it could be blocking the server hello in some way. Else, maybe there's an issue with your server ssl cert.

Hope that gives you some ideas,

Austin