Where as the answer can almost always be found in a packet capture, 99% of the time it will be faster to understand what is expected to happen, what the configuration is, and what it actually happening via the normal logs on both the f5 and the backend server.
First clue: tcp:80 ----> :443 SSL handshake failed.
Knowing you cant pass clear case traffic to an encrypted backend and expect the SSL handshake to function. You will need to dive deep into your actual config.
I like to think of the VIP - The LISTEN - as the left side of the equation.
a. - are you listening on port 80, port 443, both or other?
b. - is there a redirect at the f5 or the server in place to move you to another port?
c. - Are there a SSL certificates on the VIP(s)? Client side / server side?
d. - are there any policies or irule in place? if so what is their purpose
On the Pool, translate , backend server, right side of the equation.
a. - what is the service port ? 80, 443, other?
b. -how many members are in the pool?
c. -what kind of monitor are you useing? ICMP - and TCP - are lower quality monitors and should be used sparingly, a HTTP/HTTPS monitor is better, however they will not provide the best detail. Going with a customer monitor that checks for a recv string is usually best.
d. - Have you tried doing a curl to all of the backend nodes? Is the output the same or differnt? use -ivk switches
e. - checking the output of curl - or the server itself, is there a valid cert bound to the port?
f. - if curl fails - can you telnet to the port?
------------------------------------------------------------------------
more details of your actual config would be necessary to provide better troubleshooting. If i were to take a blind stab at the problem, you are listening on port 80 (left) and translating to port 443 (right) , its likely that you dont have "serverssl" or other profile configured to handle the server side encryption.