Single client tunnel can not connect to primary hub

book

Article ID: 34951

calendar_today

Updated On:

Products

DX Infrastructure Management NIMSOFT PROBES

Issue/Introduction

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




 

 

 

Cause

A security device was decrypting and encrypting the SSL packet causing the SSL error 5

Environment

UIM 8.x,9.x,20.x
HUB 7.x,9.x

Resolution

Note:
This issue was not a hub or UIM specific.
The problem is external to Nimsoft/UIM 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 re-encrypt 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