Nimbostratus
Employee
1. Passthrough - this is what you're doing now. No client or server SSL profiles and no other layer 7 (ex. HTTP) profiles. The encrypted SSL passes right through a layer 4 VIP. The biggest benefit of this approach is that you can get the client's certificate (if doing client certificate authentication) directly to the server. The downside is that you lose ALL layer 7 functionality of the F5, including several of the persistence mechanisms.
2. Terminate and re-encrypt - this is where you apply client AND server SSL profiles. The client SSL profile negotiates SSL with the client to decrypt the client side SSL, and the server SSL profile negotiates SSL with the server to re-encrypt. In the middle is unencrypted layer 4-7 data that you can manipulate with iRules and use for robust persistence mechanisms.
3*. ProxySSL - I mention this because it's there, but I don't think you need to factor in this option. ProxySSL is an SSL "man-in-the-middle" option that allows the F5 to essentially decrypt and re-encrypt using the session encryption key established between the client and server. It allows for direct client certificate authentication while still being able to use *some* layer 7 iRule and persistence functions.
How you configure the server SSL profile is dependent on how you've configured the SSL on your servers. If you simply enable SSL in IIS, then the generic "serverssl" profile is generally enough. Consider that the server SSL profile is the client in this transaction, so the client says CLIENTHELLO (I'd like to start an SSL session with you and here is a list of ciphers I support), the server says SERVERHELLO (I've chosen *this* cipher from you list to use and here is my public certificate), and so on. The generic serverssl profile will not be able to validate the trust of the server's certificate, but is configured to ignore it and proceed anyway.