Forum Discussion

Mark_Cloutier's avatar
Mark_Cloutier
Icon for Nimbostratus rankNimbostratus
Oct 17, 2014

AFter upgrade from 11.4.1 HF4 to 11.5.1 HF5 Getting RST after SSL connection setup, cert and keys are passed

I only get this error on a virtual server that front ends Notes Domino servers. I don't have this issue with Linux servers running Apache, which is our standard. I have tried disabling TLS1.2, 1.2 and 1.1, and I even tried disabling TLS all together. I tried first in just the server side ssl profile, then tried in the client side too. I moved the virtual server back over to my old, old v 9.4.8 LTM to get our external email working again, but I have a test virtual server to work with if anyone has ideas...

 

The irule I have in place to check for the LTPA token and Domino cluster token is working, in that with no LTPA token I get sent to a pool that contains all the servers and should present me with a login page, log statement in the irule is getting triggered, but I just get the reset. I even tried just using that pool with no irule, and still got the reset, so its got to be in the ssl server profile settings somewhere. I read in other posts that IBM webseal servers don't support TLS 1.2,

 

4 Replies

  • BinaryCanary_19's avatar
    BinaryCanary_19
    Historic F5 Account

    I presume you would have raised a support case by now? Someone will have to look at the network captures to tell what TLS protocol is being used, and if TLS is the issue, then what action can be taken. For monitors, the device should be able to downgrade the connection to a lower tls version if the server sends a proper ssl alert indicating an unsupported protocol version. If the server merely resets the connection, it could simply be that the monitors are marked as failing and the pool member is marked down, and the client sees a RST for "no pool member available".

     

  • Yes, I have opened a support case. Monitors seem to work fine. Local sniffer traces on my laptop show that the SSL handshake seems to complete just fine, both on client and server side, whether I force TLS 1.2, 1.1 or 1.0, but after the SSL handshake is complete, I am sent a tcp reset. Today, I will be using our enterprise sniffers to look at server side of the connection to make certain whether its is the Domino server sending the reset as I assume.... Logs on the LTM don't show any evidence of the monitor going down....

     

  • Always helps to talk thru the situation with a co-worker, which I did this morning. I did some further testing with openssl s_client and found that the Domino server is really out of date with regards to SSL and apparently does not support TLS, the only successful SSL handshake I can get is with SSL v3, which the LTM won't use, and s_client terminates with read:errno=0,

     

  • v11.5 and above disable SSL support by default. If your devices don't support TLS you will need to change your cipher sets to allow SSLv3.

     

    v11.4.1 is the last version that supports SSLv3 by default.