Linux Secondary Hub Not Communicating with Primary Hub

[Anon Anon]

We have installed a Nimsoft 7.5 hub on a Linux server to act as a secondary, relay hub. It has been setup to use an SSL tunnel on port 48003 to the primary hub (also 7.5 but Windows). Firewall port opened for 48003 between the two.

 

The secondary hub is not connecting and we see many entries in the hub.log file about loopback. Is this a clue? Is there something else we need to check on the primary or secondary hub?

 

Some lines from the log file:

 

Jul 15 05:45:32:076 [140020616201984] hub: nimGetIpList called with buffer size 512
Jul 15 05:45:32:077 [140020616201984] hub: nimGetIpList - skipping loopback address 127.0.0.1
Jul 15 05:45:32:077 [140020616201984] hub: nimGetIpList - skipping loopback address ::1
Jul 15 05:45:32:077 [140020616201984] hub: nimGetIpList - found ||||||***.xx.23.45|fe80::f0c4:29ff:fe5e:4e05|

[Anon Anon]

Try putting the true IP ahead of the loopbacks in the /etc/hosts file, you can also make sure the robotip field is hardcoded in the controller.

[Anon Anon]

I'll get my colleague to try this. There is already an entry for this hostname in the /etc/hosts file. Are you saying it makes a difference if after the loopback entries?

[Anon Anon]

Yes, the NImsoft robot has been known to have issues on occasion with routing if the loopback is detected first.

[Anon Anon]

Are you currently seeing any messages in the log regarding the tunnel?

[Anon Anon]

We do now see a message that the tunnel is running. But it doesn't connect. Maybe the problem is at the primary hub end?

 

Jul 15 04:42:34:923 [140020645988096] hub: Tunnel is running

[Anon Anon]

If it's attempting to connect the tunnel between the two, you should see SSL handshake log entries at the tunnel client. Remember to beef up the log level to 3-5. How does the hub GUI status tab show the tunnel on the client hub?

 

-jon

[Anon Anon]

There is no hub GUI on the client hub - it is running on Linux. We are seeing log entries on the client like this:

Jul 15 04:39:51:938 [140020006508288] hub: SSL handshake start from ***.xx.67.58/48003: before/connect initialization
Jul 15 04:39:51:938 [140020006508288] hub: SSL state (connect): before/connect initialization
Jul 15 04:39:51:938 [140020006508288] hub: SSL state (connect): SSLv3 write client hello A
Jul 15 04:39:52:087 [140020006508288] hub: SSL state (connect): SSLv3 read server hello A
Jul 15 04:39:52:088 [140020006508288] hub: SSL state (connect): SSLv3 read server certificate A
Jul 15 04:39:52:088 [140020006508288] hub: SSL state (connect): SSLv3 read server certificate request A
Jul 15 04:39:52:088 [140020006508288] hub: SSL state (connect): SSLv3 read server done A
Jul 15 04:39:52:088 [140020006508288] hub: SSL state (connect): SSLv3 write client certificate A
Jul 15 04:39:52:088 [140020006508288] hub: SSL state (connect): SSLv3 write client key exchange A
Jul 15 04:39:52:098 [140020006508288] hub: SSL state (connect): SSLv3 write certificate verify A
Jul 15 04:39:52:098 [140020006508288] hub: SSL state (connect): SSLv3 write change cipher spec A
Jul 15 04:39:52:098 [140020006508288] hub: SSL state (connect): SSLv3 write finished A
Jul 15 04:39:52:098 [140020006508288] hub: SSL state (connect): SSLv3 flush data
Jul 15 04:39:52:203 [140020006508288] hub: SSL state (connect): SSLv3 read finished A
Jul 15 04:39:52:203 [140020006508288] hub: SSL handshake done: SSL negotiation finished successfully

[Anon Anon]

But we also saw earlier:

 

Jul 15 04:39:52:206 [140020006508288] hub: SSL certificate commonName(xx.xx.xx.xx) doesn't match peer (yy.yy.yy.yy/...)
Jul 15 04:39:52:206 [140020006508288] hub: ssl_connect - Peer certificate: application verification failure
Jul 15 04:39:52:206 [140020006508288] hub: SSL error checking SSL object after connection
Jul 15 04:39:52:206 [140020006508288] hub: SSL alert (write): warning: close notify
Jul 15 04:39:52:206 [140020006508288] hub: TSESS could not connect to tunnel yy.yy.yy.yy (50)

 

If edited the IP's because they are real addresses. xx.xx.xx.xx refers to the real IP of the primary and yy.yy.yy.yy is the NAT'd version. So if the secondary hub knows the real IP then it has communicated with it. Because of NAT because have turned off IP validation for hubs.

[Anon Anon]

Sounds like it's going alright to me.. must be something else going wrong. Are you getting any significant entries after that? Maybe about invalid SID? If so, stop the hub, delete nimsoft/hub/security.* and start the hub again.

 

Can you connect to the hub from another machine with IM installed on it? Is anything logged on the tunnel server? Is the security.cfg replicated from the tunnel server?

 

 It should appear on the primary hub server list though..

 

-jon

[Anon Anon]

You need to use the IP on the certificate that the tunnel server sees (the nat ip). Try using that or wildcard * and see if it works then. That should help you with the peer error

 

-jon

[Anon Anon]

I'm not sure I understand which entry in which log file needs to be changed to the NAT'd IP of the primary hub. We used that IP when we installed the hub on the Linux server.

[Anon Anon]

Not in the log file, but in the certificate:

 

when you create a client certificate on your tunnel server, you need to insert the IP of the client. This needs to either match the IP that the server sees the connection coming from (in this case your NAT IP) or a wild card, otherwise the tunnel wont work. If it doesn't match the IP, you will get the "peer ip address" error you posted earlier. Then again, if the handhsake is alright (did you do a change there), it should've been fixed already.

 

-jon

[Anon Anon]

I didn't create the certificate. For Authentication, there is a Common Name - is that what should be the NAT IP address or *? Because our issued certificate was setup using *.

 

But we are seeing the error:

 

 

 

 

Jul 15 04:39:52:206 [140020006508288] hub: SSL certificate commonName(x.x.x.x) doesn't match peer 

 

We also tried deleting the security files as suggested.

[Anon Anon]

Also it's the IP of the primary server running a tunnel server that has NAT. The other one shouldn't have NAT - at least I don't think it does.

 

But the error in the log file is saying the NAT'd IP of the tunnel server isn't matching the commonName. But that is *.

[Anon Anon]

Did you uncheck the "verify server common name" on the client side?

 

-jon

[Anon Anon]

Yes we edited the config so it does not validate the IP. 

[Anon Anon]

Just to make sure, IP Validation under "Advanced" or the "check server common name" under tunnel client?

 

-jon