Nimbostratus
EmployeeIf you are getting resets back from the LTM you should be able to determine why by running a packet capture on the BigIP on 0.0 with noise like so:
tcpdump -s0 -i 0.0:nnnp host -w /var/tmp/reset.pcap
Use ctrl-c to stop the capture and an scp client to get the capture off of the box and opened in wireshark. Even without the F5 trailer dissectors you should be able to see the reset cause in the bytes view.
The reset cause will be embedded in any reset sent out by the BigIP (but not RSTs coming in from outside).
To get SSL offloading and HTTP xforwarded for header insertion working, you will need to configure the Virtual Server with a custom clientSSL profile containing the proper cert and key, an HTTP profile configured with the xforwarded header insert, and probably a serverSSL profile to re-encrypt on the back end (unless your pool members are plain text). Be aware that this will only work with HTTP traffic. If you are sending RPC over HTTP (as an example), it will fail as the BigIP rightly fails to recognize this as valid HTTP traffic.
If you look over all these things and are still not able to find why your LTM is resetting the packets, open a case with support and send in a qkview and your packet capture from above.