Single client tunnel can not connect to primary hub

Document ID : KB000034951
Last Modified Date : 21/02/2019
Show Technical Document Details
Issue:
After setting up the hub tunnel and certificate we cannot get the tunnel to connect.

The Client side hub logs show the following errors:
May 9 15:23:33:849 [2832] hub: SSL handshake start from 69.176.98.24/48003: before/connect initialization
May 9 15:23:33:849 [2832] hub: SSL state (connect): before/connect initialization
May 9 15:23:33:849 [2832] hub: SSL state (connect): SSLv3 write client hello A
May 9 15:23:33:880 [2832] hub: ssl_connect - SSL_connect error (5) on new SSL connection
May 9 15:23:33:880 [2832] hub: SSL_connect error occured
May 9 15:23:33:880 [2832] hub: TSESS could not connect to tunnel 69.176.98.24:48003 (0)
May 9 15:23:33:880 [2832] hub: CTRL could not connect to server 69.176.98.24/48003


- You are able to telnet to the proper IP address and port
- The wire-shark? trace looks normal.
- Nothing wrong with trace route that you can see

The server side Hub logs show:
May 9 15:09:38:129 [140089799726848] hub: TSESS-A-47-124 session looping (60) wait_time is now: 605
May 9 15:09:38:199 [140090869274368] hub: SSL handshake start from 209.249.244.5/63959: before/accept initialization
May 9 15:09:38:199 [140090869274368] hub: SSL state (accept): before/accept initialization
May 9 15:09:38:205 [140090051352320] hub: Sent heartbeat on queue route 'Audit_to_On-Prem'
May 9 15:09:38:211 [140090869274368] hub: SSL alert (write): fatal: handshake failure
May 9 15:09:38:211 [140090869274368] hub: ssl_server_wait - SSL_accept error (1) on new SSL connection: 209.249.244.5
May 9 15:09:38:211 [140090869274368] hub: [1] error:0x1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher




 

 

 
Resolution:
Note:
This issue was not hub or NMS-specific but was on NMS 7.50 and hub 7.50. The problem is external to Nimsoft and could be seen on any hub version using a tunnel

We found out that there was a setting on the Client firewall called 'SSL Decryption' that was taking the certificate that we were sending out, trying to decrypt it and then reencrypt it and sending it out.

As soon as the customer removed that setting or added an exception for our two servers we were able to establish a tunnel connection.

Reference Article:
https://live.paloaltonetworks.com/docs/DOC-1412