ssl_log_error - Error shutting down SSL connection, [1] error:0x140E0197

[Akash Saini]

Hello Folks ,

We created the new tunnel connection between tunnel server to tunnel client. But tunnel is not connected .

We checked the hub log details in tunnel client server ,found the below error-

Error:-

Jan  4 07:15:48:462 [2472] 0 hub: ssl_log_error - Error shutting down SSL connection, [1] error:0x140E0197: SSL routines: SSL_shutdown: shutdown while in init
Jan  4 07:16:18:526 [6552] 0 hub: CTRL send message failed for get id command
Jan  4 07:16:18:526 [6552] 0 hub: CTRL failed to get ID from x.x.x.x/48003
Jan  4 07:16:18:526 [6552] 0 hub: TSESS-P-11227 SSL_shutdown failed.

Thanks in advance !

Akash Saini
9910641662

[Garin Walsh]

This looks like there's a proxy in place that's damaging the certificate exchange.

Step one here is to make sure there's nothing configured on whatever network equipment is between the server and client that might be filtering this tunnel traffic.

[Akash Saini]

Thanks Garin,

We already checked , proxy is not place in both server client and server tunnel.

And we also checked with network team , Nothing is configure from network end.

[Akash Saini]

Any one can help me on this issue.

Thanks in advance !

[Garin Walsh]

I would suggest going back to your network team and asking them to prove that there's nothing.


In the meantime set the log level on the hub probe to 5 on both ends and try the connection again. In particular you will be looking for information about the certificate being used on the receiving side and if it matches the sending side. 

One other thing to try is to change the port that you are using on the tunnel server.

Also note that the people contributing here are customers and Broadcom support in their free time. If you are not getting responses it's because we don't know or think it has been answered already. And not having seen your name before I presume you are a new user of the product -  in light of that understand that the logging is awful - generally when posting messages it's best to post the whole log (as an attachment) as almost always the things you will think are important about the error are just noise and the actual error happens much earlier in the log. Screen shots and cfg files are also useful to post. Generally you can't post too much information but it's easy to post too little.

[Akash Saini]

Thanks Garin,
We already checked from network team there is no blocking point. And we also checked, the telnet status , port 48003 also connect from server client to server tunnel.

And our hub version are same for client and server hubs.

[Garin Walsh]

I've had this exact error message before and it has been resolved by disabling SSL proxy/protocol inspection. Maybe your environment is different.

Did you do the level 5 logs exercise? 

Do you have the ability to build a tunnel client on the same network as the tunnel server to try the tunnel connection with nothing between them to verify the correct configuration of the tunnel hub and client without the influence of network devices? 

You can run a network packet trace on the server and client and compare.

At this point, were I in your shoes, I'd get a client working locally then move that to the destination site and verify it continues to work or not. If it does, then identify the difference in the broken client config compared to the working one and correct. If it stops working, go back to your network group and ask why since it should be and you've proven that there's something impacting the network traffic. It's completely possible they don't even know it's happening.

Otherwise open a case with support and pursue it there as there's little more that can be done here with the information provided.

[Akash Saini]

Hello Garin,

We always set the log level 5 .
And found below mentioned error on tunnel client server.

an 18 15:44:44:471 [10204] 3 hub: next_check [1642517202] now [1642517084]
Jan 18 15:44:52:578 [6732] 3 hub: TSESS-A-16 connected to x.x.x.x:48003 on socket 644
Jan 18 15:44:52:578 [6732] 3 hub: CTRL SSL_SESSION() created for TSESS-A-16
Jan 18 15:44:52:578 [6732] 1 hub: SSL cert CN=x.x.x.x
Jan 18 15:44:52:578 [6732] 1 hub: SSL using cipher: ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
Jan 18 15:44:52:578 [6732] 0 hub: CTRL send message failed for get id command
Jan 18 15:44:52:578 [6732] 0 hub: CTRL failed to get ID from x.x.x.x/48003
Jan 18 15:44:52:578 [6732] 4 hub: TSESS-P-16 releasing resources
Jan 18 15:44:52:578 [6732] 4 hub: SSL_shutdown on TSESS-P-16: CLOSING SSL connection
Jan 18 15:44:52:578 [6732] 0 hub: TSESS-P-16 SSL_shutdown failed
Jan 18 15:44:52:578 [6732] 0 hub: ssl_log_error - Error shutting down SSL connection, [1] error:0x140E0197: SSL routines: SSL_shutdown: shutdown while in init
Jan 18 15:44:52:578 [6732] 4 hub: TSESS-P-16 [] resources released
Jan 18 15:44:52:578 [6732] 2 hub: CTRL N/A terminating sessions
Jan 18 15:44:52:578 [6732] 1 hub: CTRL is waiting for 0 TSESS to terminate
Jan 18 15:44:52:578 [6732] 1 hub: CTRL waited 0 seconds for 0 TSESS to terminate
Jan 18 15:44:52:578 [6732] 2 hub: CTRL N/A is terminating with exit code 0

Can you please check.

Thanks in advance !

[David Michel]

check out:
Tunnel fails to connect with message: CTRL send message failed / failed to get ID
Article Id: 211366
https://knowledge.broadcom.com/external/article?articleId=211366

[Garin Walsh]

Issues with MTU are returned via ICMP to the sending side - so if manually changing the MTU fixes this, that indicates that the return path for the packets is filtering ICMP. 

So, if you need the larger MTU setting for performance reasons (usually storage access) then as an alternative to reducing the MTU, check the network path to ensure that the ICMP traffic can make it back.

[Akash Saini]

Thanks Garin and David for Update,

We already checked, MTU already set on 1500 (check the attachment)