SSL handshake errors

You actually have a few clients in this capture, so I'll strip out everything but the last one (569) and re-format for visibility:

New TCP connection 569: 70.198.140.97(7336) <-> x.x.x.x(443) 
569 1 0.1171 (0.1171) C>SV3.3(184) Handshake 
    ClientHello 
        Version 3.3 
        random[32]= 56 4a c5 04 f4 09 eb... 
        cipher suites 
            TLS_EMPTY_RENEGOTIATION_INFO_SCSV 
            TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 
            TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 
            TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 
            TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 
            TLS_ECDHE_ECDSA_WITH_RC4_128_SHA 
            TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA 
            TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 
            TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 
            TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 
            TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 
            TLS_ECDHE_RSA_WITH_RC4_128_SHA 
            TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA 
            TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 
            TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 
            TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 
            TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 
            TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA 
            TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA 
            TLS_ECDH_ECDSA_WITH_RC4_128_SHA 
            TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA 
            TLS_ECDH_RSA_WITH_AES_128_CBC_SHA 
            TLS_ECDH_RSA_WITH_AES_256_CBC_SHA 
            TLS_ECDH_RSA_WITH_RC4_128_SHA 
            TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA 
            TLS_RSA_WITH_AES_256_CBC_SHA256 
            TLS_RSA_WITH_AES_128_CBC_SHA256 
            TLS_RSA_WITH_AES_128_CBC_SHA 
            TLS_RSA_WITH_RC4_128_SHA 
            TLS_RSA_WITH_RC4_128_MD5 
            TLS_RSA_WITH_AES_256_CBC_SHA 
            TLS_RSA_WITH_3DES_EDE_CBC_SHA 
            TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 
            TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 
            TLS_DHE_RSA_WITH_AES_128_CBC_SHA 
            TLS_DHE_RSA_WITH_AES_256_CBC_SHA 
            TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 
            compression methods 
                NULL 

The client is issuing its request to start an SSL session. The ClientHello message contains the client's preferred protocol (Version 3.3 = TLSv1.2), a random number, and a list of supported cipher suites (in general order of preference)

569 2 0.1180 (0.0009) S>CV3.3(85) Handshake 
ServerHello 
        Version 3.3 
        random[32]= 6c 0f a3 fc 6e d1 8a... 
        session_id[32]= e8 27 5b f0 9c 4a...
        cipherSuite 
            TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 
            compressionMethod 
                NULL 

The server responds with a ServerHello that contains the selected protocol (Version 3.3), its own random number, and the selected cipher from the client's list (TLS_DHE_RSA_WITH_AES_256_CBC_SHA256)

569 3 0.1180 (0.0000) S>CV3.3(2488) Handshake 
    Certificate 
        Subject 
            C=US 
            ST=California L=Mountain View 
            O=abc, Inc. 
            OU=Network Operations 
            CN=*.abc.net Issuer 
            C=US O=thawte, Inc. 
            CN=thawte SHA256 SSL CA 
        Serial      49 a1 db 0d 32 5e a5 16 dd 0b 5c 71 eb ec f3 6a 
        Extensions 
            Extension: 
                X509v3 Subject Alternative Name Extension: 
                X509v3 Basic Constraints Extension: 
                X509v3 Certificate Policies Extension: 
                X509v3 Key Usage Critical Extension: 
                X509v3 Authority Key Identifier Extension: 
                X509v3 CRL Distribution Points Extension: 
                X509v3 Extended Key Usage Extension: 
                Authority Information Access 
        Subject 
            C=US O=thawte, Inc. 
            CN=thawte SHA256 SSL CA 
        Issuer 
            C=US O=thawte, Inc. 
            OU=Certification Services Division 
            OU=(c) 2008 thawte, Inc. - For authorized use only 
            CN=thawte Primary Root CA - G3 
        Serial      36 34 9e 18 c9 9c 26 69 b6 56 2e 6c e5 ad 71 32 
        Extensions 
            Extension: 
                Authority Information Access Extension: 
                X509v3 Basic Constraints Critical Extension: 
                X509v3 Certificate Policies Extension: 
                X509v3 CRL Distribution Points Extension: 
                X509v3 Key Usage Critical Extension: 
                X509v3 Subject Alternative Name Extension: 
                X509v3 Subject Key Identifier Extension: 
                X509v3 Authority Key Identifier 

The server immediately sends a Certificate message that should contain its own certificate and optionally any immediate issuing CAs.

569 4 0.1180 (0.0000) S>CV3.3(527) Handshake 
    ServerKeyExchange 
        params 
            DH_p[128]= b9 77 c2 e3 f9 1d 78 15...
            DH_g[1]= 02 
            DH_Ys[128]= 58 5d 21 35 30 dc 7f 35... 

The server follows the Certificate message with a ServerKeyExchange message, which generally only occurs when a Diffie-Hellman cipher is selected. Here the server is sending its DH parameters.

569 5 0.1180 (0.0000) S>CV3.3(4) Handshake 
    ServerHelloDone

The server then indicates it's done with a ServerHelloDone message.

569 0.6487 (0.5306) C>S TCP FIN 
569 0.6487 (0.0000) S>C TCP FIN 

What should be next is the client's ClientKeyExchange message, which for Diffie-Hellman is the client's DH parameters (or for RSA the encrypted pre-master secret). As the client is sending a FIN at this point, the most likely cause is that the client doesn't like something about the server's response. We can pretty much rule out cipher selection and protocol, as those were selected from the client's list. You may have scrubbed the data a little too much here, but one interesting thing I noticed is that the server's certificate chain starts with a CA (CN=thawte SHA256 SSL CA). Is that correct? At this point in the SSL handshake the client is going to attempt to validate the server's certificate. If the client cannot establish a trust chain with the server's certificate, or the server's certificate is otherwise invalid, the client agent may either prompt the user with an "untrusted certificate" warning, or in some circumstances just fail completely. My guess here, assuming the capture is mostly intact, is that the client is failing the SSL handshake because of the certificates presented. If you test access to the BIG-IP VIP with cURL,

curl -k https://x.x.x.x

(the -k tells cURL to ignore certificate trust issues) do you get any further?