Configuring F5 Re-Encryption

It would seem that all indications are pointing to the server side SSL connection, and there are a number of things that can cause a failure. At the very least you should set up an SSLDUMP between the BIG-IP and Tomcat server and watch that transaction. If there's an SSL handshake error, you'll see it in this capture.

ssldump -AdNn -i [internal VLAN name] port 8443 [and any additional filters]

Also consider the following:

1. It could be that the server doesn't support RFC5746 Secure Renegotiation. You'll actually see this in the LTM log, and you can control it by setting the Secure Renegotiation option in the BIG-IP's server SSL profile to Request.

2. It could be that the server doesn't support the ciphers and/or protocols presented by the BIG-IP. This one is a bit more complex to troubleshoot, but if this is the case you'll likely see the server send an alert message directly at the client's (BIG-IP's) ClientHello message. Take note of the ciphers used by your successful direct connection test and compare those to what the BIG-IP is sending.

3. It could be that the server requires a Server Name Indication (SNI) value. By default the server SSL profile doesn't send an SNI in the ClientHello, but you can add one in the Server Name field in the server SSL profile. This will usually also fail after the client's ClientHello message.

What does 'LTM' log stand for?

Local Traffic Manager

Where is this located?

/var/log/ltm

The easiest thing to do is SSH into the management shell and tail this log to show real time updates:

tail -f /var/log/ltm

I am still in the process of observing the ssldump, but understanding what one should look at (A Java developer in this case) is very confusing.

No problem, and it can definitely be overwhelming. If you get stuck you can just paste that SSLDUMP output in this thread for others to evaluate.

You said earlier that the monitor was green, so probably best to temporarily disable the pool monitor while doing an SSLDUMP capture. We want to see the actual request traffic by itself.

Reformatting:

1 1 0.0266 (0.0266) C>S 
    SSLv2 compatible client hello 
    Version 3.1 
    cipher suites 
        TLS_RSA_WITH_RC4_128_MD5 
        TLS_RSA_WITH_RC4_128_SHA 
        TLS_RSA_WITH_AES_128_CBC_SHA 
        TLS_RSA_WITH_AES_256_CBC_SHA 
        TLS_RSA_WITH_3DES_EDE_CBC_SHA 
        TLS_RSA_WITH_DES_CBC_SHA 
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA 
        TLS_DHE_RSA_WITH_AES_256_CBC_SHA 
        TLS_DHE_RSA_WITH_DES_CBC_SHA 
        TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 
        TLS_RSA_EXPORT_WITH_RC4_40_MD5 
        TLS_RSA_EXPORT_WITH_DES40_CBC_SHA 
        TLS_DH_anon_WITH_RC4_128_MD5 
        TLS_DH_anon_WITH_AES_128_CBC_SHA 
        TLS_DH_anon_WITH_AES_256_CBC_SHA 
        TLS_DH_anon_WITH_3DES_EDE_CBC_SHA 
        TLS_DH_anon_WITH_DES_CBC_SHA 
        TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 
        TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA 
        TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 
        TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 
        SSL2_RC4_128_WITH_MD5 
        SSL2_DES_64_CBC_WITH_MD5 
        SSL2_DES_192_EDE3_CBC_WITH_MD5 
        SSL2_RC4_128_EXPORT40_WITH_MD5 
        SSL2_RC2_128_CBC_EXPORT40_WITH_MD5 
        SSL2_RC2_CBC_128_CBC_WITH_MD5 
        TLS_EMPTY_RENEGOTIATION_INFO_SCSV 
TCP: 10.30.15.67(8443) -> 10.10.20.190(60064) Seq 1045211207.(0) ACK 3197015237 
TCP: 10.30.15.67(8443) -> 10.10.20.190(60064) Seq 1045211207.(0) ACK 3197015237 FIN 
1 0.0270 (0.0004) S>C TCP FIN 
TCP: 10.10.20.190(60064) -> 10.30.15.67(8443) Seq 3197015237.(0) ACK 1045211208 
TCP: 10.10.20.190(60064) -> 10.30.15.67(8443) Seq 3197015237.(0) ACK 1045211208 RST 
1 0.0717 (0.0446) C>S TCP RST

So I'm going to assume that you're looking at the client side of the F5 and that the client in this capture is actually the browser you're testing with? Or are you looking at the server side of the F5, and if so, what version of BIG-IP are you running?

You can see from the capture that the client sends an SSLv2 compatible ClientHello and then a list of REALLY old, deprecated and unsafe ciphers to the server. The server then immediately resets the connection. If I had to put money on it, I'd say the server was resetting based on the terrible list of ciphers sent by the client, and so it depends on which side of the F5 you took this capture, and who was the client (your browser of the F5 server side).

What you're showing in that last capture looks like a good SSL handshake. So to recap, where did the first capture come from and who was the client in that case? I'm worried about the very old ciphers presented from the client (some MD5, export, SSLv2, etc.). What type of client were you using?

And in the second capture, where did you take that from? And who is the client in this case?

Well, I'm not entirely convinced yet that the cert was the issue. Your (browser) client was sending a list of really old and really dangerous ciphers that the F5's client SSL profile would have surely rejected.

I'd maybe recommend taking that same ssldump capture on the client side with different browsers (browser to VIP). If you see EXPORT or MD5 or ANON in any of those cipher lists, something is wrong.

Is that the only thing you did? The F5 shouldn't care what port the traffic is on. If you have an SSL profile applied to the VIP, the F5 will attempt to communicate via SSL.

Hello everyone,

one question please, is it possible to filter ssldump by Virtual Server? I have to many SSL handshakes between F5 and server but i have one VS that is not working and i don't know is the problem with SSL or something else :(

So my setup is this: Internet -> F5 (here i am doing SSL offloading, and need to re-encrypt traffic again) -> Web application Proxy -> end server. I added SSL profile client and SSL profile server.

When i am just forwarding HTTPS it is working but i need to use scenario with offloading and re-encrypting.