iRule to log SSL cipher version

The thing is, that last requirement isn't something you can really do with an iRule. If you're looking for a handshake failure based on non-acceptance of a given set of client-supplied ciphers, then

1. This essentially happens before or rather in lieu of the server's first SSL handshake response - the connection is reset (FIN).

    

2. There's no response event in the client side context (as in an event triggered when the BIG-IP responds to a client), so there's really no way to collect the BIG-IP's SSL alert message.

    

That said, as a programmable platform there isn't much the BIG-IP can't do, and so I'd caveat my last statements by saying that it technically can be done, but the solution may be a bit more complex. The idea is basically something called "VIP targeting". This is where you put one virtual server in front of another and use a special virtual command in an iRule on the external VIP to steer traffic to the internal VIP.

when CLIENT_ACCEPTED {
    virtual internal-vs
}

In this way you can actually create a response event in the client context because the internal VIP's response (the one you care about) is a response in the server side context of the external VIP. Confusing yet?

client -> external VIP -> internal VIP -> server

Assuming you continued to do SSL offload on the internal VIP and used the external VIP as a layer 4 proxy, it would be able to see an SSL handshake alert coming from the internal VIP. Coincidentally, because the previous iRule is collecting data at layer 4 and because the client's cipher list is presented in an unencrypted portion of the SSL handshake, you could move all of that code minus the CLIENTSSL_HANDSHAKE event to the external VIP. And so the your second requirement you'd just watch for the internal VIP's ServerHello to grab the selected cipher.

Ultimately though, you may be better off simply not trying to capture the failure and troubleshooting SSL as it happens, in favor of not adding the additional complexity as described.