Forum Discussion

ngockq's avatar
ngockq
Icon for Altostratus rankAltostratus
Aug 03, 2023

F5 self IP TLS/SSL hand shake fail with tcp port node member

Hi all, I have a case about tls/ssl hand shake fail on F5 and need a solution:

I have a pool have two member, monitor health check use tcp port 19001 and 19002. I create VS for this pool resource and use tcp health check, too and source nat: Auto map. Client use tcp connection normal (not https)  to this VS

On server backend member, i see log:

Error TLS/SSL: Handshake failed from  IP <Selft IP F5>, every 5 seconds (time interval in tcp healcheck)

Do I need some config on F5 or backend server to resolving this issuse.

Thanks very much

 

 

application delivery
  • AubreyKingF5's avatar
    AubreyKingF5
    Aug 03, 2023

    I suspect you're correct on this. The health check types need to be https so there CAN be a handshake. TCP will have no idea what to do with SSL and should not allow a successful ACK.

    ALSO.. 

    You could try tcp half open as a type if you REALLY don't care about valid SSL. This will send a SYN, get and SYN-ACK and call it a good response, rather than trying to send an ACK, which should fail because of the SSL, I'd think. If you try this, can you let me know how it goes?

  • Paulius's avatar
    Paulius
    Icon for MVP rankMVP
    Aug 03, 2023

    ngockq It seems like your health monitor on TCP 19001 and 19002 is possibly an HTTPS health monitor or an HTTP health monitor and your server is expecting an HTTPS connection on those ports which is causing this error. Typically the F5 will not send any communication to a pool member unless it's explicitly told to do so. Can you please provide the VS, pool, and health monitor configuration so we can attempt to assist you further with this?

    • AubreyKingF5's avatar
      AubreyKingF5
      Icon for Moderator rankModerator
      Aug 03, 2023

      I suspect you're correct on this. The health check types need to be https so there CAN be a handshake. TCP will have no idea what to do with SSL and should not allow a successful ACK.

      ALSO.. 

      You could try tcp half open as a type if you REALLY don't care about valid SSL. This will send a SYN, get and SYN-ACK and call it a good response, rather than trying to send an ACK, which should fail because of the SSL, I'd think. If you try this, can you let me know how it goes?