SSL Forward Proxy Issue

Let's first take a closer look at the captured SSL handshake:

ssldump -r /var/tmp/161129_SSLFail_Test-02.pcap New TCP connection 1: 192.168.10.183(50581) <-> 210.220.13.61(443) 
1 1 0.0027 (0.0027) C>S Handshake 
    ClientHello 
    Version 3.3 
    cipher suites 
        TLS_RSA_WITH_AES_128_CBC_SHA256 
        TLS_RSA_WITH_AES_128_CBC_SHA 
        TLS_RSA_WITH_AES_256_CBC_SHA256 
        TLS_RSA_WITH_AES_256_CBC_SHA 
        TLS_RSA_WITH_RC4_128_SHA 
        TLS_RSA_WITH_3DES_EDE_CBC_SHA 
        Unknown value 0xc027 
        Unknown value 0xc013 
        Unknown value 0xc014 
        Unknown value 0xc02b 
        Unknown value 0xc023 
        Unknown value 0xc02c 
        Unknown value 0xc024 
        Unknown value 0xc009 
        Unknown value 0xc00a 
        TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 
        TLS_DHE_DSS_WITH_AES_128_CBC_SHA 
        TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 
        TLS_DHE_DSS_WITH_AES_256_CBC_SHA 
        TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 
        TLS_RSA_WITH_RC4_128_MD5 
    compression methods NULL 
1 2 0.0368 (0.0340) S>C Handshake 
    ServerHello 
    Version 3.3 
    session_id[32]= 65 b6 34 e9 9c b3 af 98 59 ea b0 2b 44 f7 c2 b2 1d 03 50 01 92 97 2b be a3 53 00 95 d8 a1 1c bf 
    cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 
    compressionMethod NULL 
1 3 0.0368 (0.0000) S>C Handshake 
    Certificate 
1 4 0.0368 (0.0000) S>C Handshake 
    ServerHelloDone 
1 5 0.0380 (0.0011) C>S Handshake 
    ClientKeyExchange 
1 6 0.0380 (0.0000) C>S ChangeCipherSpec 
1 7 0.0380 (0.0000) C>S Handshake 
1 8 0.0393 (0.0013) S>C ChangeCipherSpec 
1 9 0.0394 (0.0001) S>C Handshake 
1 10 0.0772 (0.0378) C>S application_data 
1 0.1363 (0.0590) S>C TCP RST

A quick observation of this handshake reveals a few things:

1. This is the model of a perfect (RSA-based) SSL handshake. You can even see at the end the application_data exchange, which is the symmetrically encrypted message traffic that happens after a successful TLS handshake.

2. Looking at the SSL properties of this site at SSLLabs, aside from getting an F grade for its SSL implementation, it reportedly doesn't support TLS 1.1 and TLS 1.2, but clearly from this capture, you see that the client and server are successfully using TLS 1.2 (version 3.3). So I'm curious, which side of the BIG-IP did you take this capture? If SSLLabs is correct, the server side would not have been able to negotiate beyond TLS 1.0.

Using "ALL" in the cipher string just provides access to all of the possible ciphers that the F5 supports, and is generally not a best practice.

What I'm asking is that you provide a capture of the server side SSL handshake (F5 to server). This is where the reset is probably coming from.