Forum Discussion

Adam_Flowers_21's avatar
Adam_Flowers_21
Icon for Nimbostratus rankNimbostratus
Feb 05, 2016

"SSL handshake failure: End of file" errors in Horizon View Security Server logs coming from non-floating Self-IPs

We are running Horizon View 6.2, with Security Servers (not Access Points and not APM). While troubleshooting an sporadic external connection issue I noticed tons of the following errors in the Security Gateway logs on the Security Servers:

 

****replacing the actual ip's) 2016-02-05T07:54:48.388-05:00> LVL:error : [C: 1.1.1.33:45045] *** SSIGServer::SSL handshake failure: End of file (2) error:00000002:lib(0):func(0):system lib 2016-02-05T07:55:07.919-05:00> LVL:error : [C: 1.1.1.31:36795] *** SSIGServer::SSL handshake failure: End of file (2) error:00000002:lib(0):func(0):system lib 2016-02-05T07:55:18.406-05:00> LVL:error : [C: 1.1.1.33:45080] *** SSIGServer::SSL handshake failure: End of file (2) error:00000002:lib(0):func(0):system lib 2016-02-05T07:55:37.871-05:00> LVL:error : [C: 1.1.1.31:36831] *** SSIGServer::SSL handshake failure: End of file (2) error:00000002:lib(0):func(0):system lib 2016-02-05T07:55:48.439-05:00> LVL:error : [C: 1.1.1.33:45121] *** SSIGServer::SSL handshake failure: End of file (2) error:00000002:lib(0):func(0):system lib

 

It doesn't seem like these errors just started. I have review all the logs still present on the VM's and see these errors.

 

The IP addresses noted in the errors are the non-floating self ip's. The Security Servers and the Self IP addresses are on the same subnet, and can ping each other.

 

Any ideas on why Im getting these errors?

 

2 Replies

  • I'm going to guess you have health probes on your security servers that aren't doing a full SSL handshake. If you are doing just a TCP probe to 443, that could cause these errors on your backend servers as they are expecting an SSL handshake after the TCP handshake. Where as the LTM is just doing a TCP handshake and then tearing down the connection. If you want the errors to go away you could try using an HTTPS monitor that does a full SSL handshake.

     

  • Thanks Brad.

     

    It does look like it was a monitor. We removed the TCP monitor that was checking TCP Port 4172, and now the logs are much cleaner. The monitor is a built in monitor from the Horizon View iApp, so I wouldn't think we would see these errors.