TLS 5 second delay before establishing TLS client Hello

When you say "SSL passthrough", can I assume you mean no client and server SSL profiles on the VIP? If so, the CLIENTHELLO should be coming from the back end server? Can you watch both sides of the connection in parallel to verify?

So your capture shows an immediate response from the server, but a 5s delay client side? What type of VS have you configured please?

There are no client/server SSL profiles applied to this connection for this VIP, although there are other VIPs that do have those configurations. I do see the CLIENTHELLO coming from the backend server and I have packet captures from both sides of the connections at the same point in time to verify. They both show the 5 second delay from the https packet to the CLIENTHELLO packet.

Yes, that is correct. So as to be clear, when the client makes the request to the server, when it responds on the AutoSNAT translated port that is not 443, it takes +5 seconds. You can see the delay on packet captures that align in time from both f5 and the server.

Type of VS is host, standard

A few more questions:

I have a packet capture and have noted the delay seems to be between the https (port 443) from VIP to client and another packet sent from VIP to client for TLS client Hello.

The TLS CLIENTHELLO message should be coming from the client. Can you elaborate on where this delay is happening? Is it consistent? And is it only in the TLS handshake, or throughout the session?

I have tried both Performace and standard with no change. I am seeing the TLS Clienthello from the VIP. I have verified that it always appears this way in the packet captures. The delay is After the VIP send TCP https (443) traffic, then there is a 5 second delay. Then the CLIENTHELLO from the VIP (i also agree this is wierd). After that there is an immediate Serverhello. Certificate from the real ip to the vip.

Sorry, i have reconfirmed with my tester and he is saying we are seeing the CLIENTHELLO from the floater IP.

I have to say I'm at a loss. Unless I'm missing some detail, or there's something unusual about this configuration, there is absolutely no reason why a CLIENTHELLO message would be coming from the server side of a TLS handshake. Is there an iRule? Is there anything going on in the web server's application logic that might be causing a reach-back? Can you post the network capture from both sides of the F5?