The following causes are those of the most generous causes that clients get reset from F5:
2, If F5 does not support any of the SSL versions/ciphers client wants to use, F5 would respond with TCP/RST immediately with reset.
3, ssl handshake timeout by default 10 secs
4,Application caused reset.The simplest is when you close the socket, and then write more data on the output stream. By closing the socket, you told your peer that you are done talking, and it can forget about your connection. When you send more data on that stream anyway, the peer rejects it with an RST to let you know it isn’t listen
5, one arm scenario, vip need have snat configured in case the backend server has default gw bypass f5, it that case, f5 connection towards backend server will timeout, after that f5 will send reset to client side
6, following item5, if automap is configured, source is translated to self IP on egress interface heading toward servers, if no self ip on that vlan configured on f5, f5 will send reset packet.
7, The Server SSL profile Secure Renegotiate setting is set to Require or Require Strict. The back-end SSL server lacks support for the Transport Layer Security (TLS) Renegotiation Indication Extension
8, HTTP header size exceeded by server
9, HTTP header size exceeded by client
10, When an existing client-side connection has been detached from the server-side connection and reselects a new server, the BIG-IP system sends a TCP RST to the server to close the existing server-side connection. This behavior typically comes from using iRule commands such as LB::reselect.
11, No route to host
12, The BIG-IP system receives a SYN for either one of the following conditions:
- A virtual server of type reject
- A port that is protected by the Port Lockdown settings on a self IP address