Setting up a HUB environment with NAT

[Baltasar_Infante]

I'm trying to setup the following environment:

 

- Primary Hub with public IP Address: 130.119.150.170

 

- Remote Hub with private address 10.0.3.15 NATed to 141.202.201.38

 

I've tried to run this setup as follows:

 

 

1) Install the Remote Hub by using the Hub installer and selecting Custom and choosing "robot", "hub" and "libraries". The install was successful.

 

2) After that, I went to the primary Hub and added a Network Alias of 10.0.3.15->141.202.201.38.

 

3) After that, I added a Static Route pointing to 141.202.201.38 and I got the error message: Could not connect to Hub: 141.202.201.38! Reason: communication error. The same error is seen if I point to 10.0.3.15.

 

4) After some research, all I got was that "static routes are not a good option, better go with Tunnels".

 

5) I've just created a Tunnel, following the Wiki, but still, I just get to see my Primary Hub on my IM.

 

6) Checking the primary Hub's log, I can see the following errors:

 

Nov 11 16:11:33:244 [3536] hub: ssl_connect - connect to '10.0.3.15:48003' failed (10060)

Nov 11 16:11:33:244 [3536] hub: TSESS could not connect to tunnel 10.0.3.15:48003 (-2)

Nov 11 16:11:33:244 [3536] hub: CTRL could not connect to server 10.0.3.15/48003

Nov 11 16:11:33:244 [3536] hub: CTRL could not connect to 10.0.3.15/48003; 1

 

My first question would be, when you want to connect to Hubs that are in different Networks but there's no firewall in between, shouldn't I go with the "Static Hub Route"?

 

Also, the way I understand tunnels is that you use them when there's a firewall involved or when you want to add security (VPN). Would we use tunnels "just" to connect two Hubs that are in different networks?

 

Finally, any idea on why I can't get my Hubs connected with the configurations I've already tried?

 

Thanks a lot!

 

Balta.

[Anon Anon]

Hi Balta,

 

Hope you are fine.

First simple question based on your logs:

 

Connect to '10.0.3.15:48003' failed (10060)

 

So......do you have your port opened between your host and 10.0.3.15?

Telnet is your friend

[Baltasar_Infante]

Thanks Nico .

 

I don't have any firewall on any of my Hubs, all ports are opened.

 

Telnet on 130.119.150.170 48003 works just fine.

 

Telnet on 10.0.3.15 on 48003, however, doesn't work.

 

But I think that, because the 10.0.3.15 is a private one, shouldn't the communication be done on the 141.202.201.38, which is the public one? Otherwise not even a ping will succeed.

 

After running "netstat" on both Hubs, I just see mention to port 48002, but nothing on port 48003 in any of them.

 

One of the parts that I'm missing is the following:

 

Important! You should be aware that when a tunnel is configured, it replaces the static hub and NAT setup in the hub configuration.

 

This is said on the Hub's doc. But, if that means that once the tunnel is configured, the Hub doesn't care about the Network Alias field on the Name Services tab, how does the Hub know that, when something needs to be sent to 10.0.3.15, in reality, it has to look for 141.202.201.38?

 

Otherwise, it will never success while dealing with 10.0.3.15 since it's a private ip address and shouldn't be accessible from the outside.

 

Thanks

 

 

[NicolasRoyo81983169]

Hey Balta,

 

How are you doing with this issue?

Tunnel service only listens on the server, this is your 130.x.x.x

If your client is able to get that ip/port, something else is failing.

 

I guess you already setup certificates without issue.

What about the "robotip_alias"? Did you try setting up the NAT IP here?

Try this

robotip_alias = <NAT'ed IP through which Robot can be reached>
robotip = <Robot's Local IP address>

 

Regards!

[Baltasar_Infante]

Hi Nico,

 

I've just got back to it and still can't make it run.

 

In my scenario, my tunnel server is the remote Hub, which is the one using NAT (10.0.3.15->141.202.201.38).

 

I've tried installing the remote Hub by selecting "DMZ" while running the install and this ends as follows:

 

1) The install finished fine, although it asked me for a password to login even though, according to the install, if the Hub was to be installed under a Nimsoft Domain that already exists, I shouldn't be asked for it:

 

 

 

 

2) Once this is done, I use the "DMZ Tunnel Setup Wizard" to setup the Server (my Remote Hub mentioned above) and the Client (my primary Hub with IP Address: 130.119.150.170). The setup goes fine.

 

3) Here it comes the problem: According to the documentation, I need to go to the Server Tunnel Hub to enable the tunnel (through Tunnel tab). However, this can't be done, because my Server Tunnel Hub shows in red in my IM. And, I think, that the reason for this to show in red is because the Tunnel hasn't been enabled yet. However, tunnel won't be enable since I can't access the Tunnel Server Hub. This is a loop.

 

 

4) If I "just" install the remote Hub as if it was "just" a Secondary Hub (without using the DMZ Wizard), I still have the same problem since the Primary Hub doesn't recognize its private IP Address, which is the only one you can select while installing it.

 

5) I'm pretty sure that I could solve this by making my Primary Hub the Tunnel Server, but I don't want to. I just want to setup my environment the way I initially planned.

 

Thanks

[Baltasar_Infante]

5) It's not turning red even if I make the Primary Hub to be the Tunnel Server...

[Anon Anon]

Tunnel is infinitely easier setup in that situation, also I really can't see a reason to avoid using one. Not quite sure which way the nat goes and which is the tunnel server.. it would sound like the primary hub should connect to 141.202.201.38 which then directs to the lan ip 10.0.3.15.. but your logs show otherwise.

[Baltasar_Infante]

Hello Jon,

 

Thanks for your answer .

 

This is the way my setup is done:

 

1) Primary Hub with public IP address of 130.119.150.170 is the Client on the Tunnel.

 

2) Remote Hub with private Ip address of 10.0.3.15 NATed to 141.202.201.38 is the Server on the Tunnel.

 

According to the Hub's doc:

 

Important! You should be aware that when a tunnel is configured, it replaces the static hub and NAT setup in the hub configuration.

 

But, if that means that once the tunnel is configured, the Hub doesn't care about the Network Alias field on the Name Services tab, how does the Hub know that, when something needs to be sent to 10.0.3.15, in reality, it has to look for 141.202.201.38?

 

Otherwise, it will never success while dealing with 10.0.3.15 since it's a private ip address and shouldn't be accessible from the outside.

 

Thanks.

 

Best regards,

 

Balta.

[Anon Anon]

It knows this because you define the tunnel endpoint as the nat IP, after which the fw or whatever device takes care of the rest. In this case you will need to disable the name check on the tunnel client though, since it'll be different than what the server is bound to.

[Baltasar_Infante]

Hello Jon,

 

Thanks for your answer.

 

I'm still working on this. I think that, because I'm setting up my remote Hub (with NAT) as the Server Tunnel and, for this Hub to show up in green in my IM it needs to have a connection communication to my primary Hub (no NAT and Client Tunnel), it will never be successful unless I switch places and I make my remote Hub the Client Tunnel. In such a way, once I set up my primary Hub as my Server Tunnel and I enable the tunneling, I think I should be able to see the remote Hub turning green on my IM.

 

Thanks

[Baltasar_Infante]

This is the topic we were talking about PeteBennett

[PeteBennett]

Hi Balta,

Thx for the ping, as we discussed I think it would be great to build some doc arpound this discussion to help you understand the moving partns and aslso share with the team as well.

Can you start putting together a high level 'cheat sheet' containing the useful info around this - it can be a living doc that you and the team add useful items into as things are discovered.

 

I'm sure the community will assist, so pls keep this thread going and post your findings.

thx

Pete

[Mark DeBoer]

Topic is probably already too old for the original poster, but I had the same issue and using a wildcard certificate on the Tunnel Server solved the problem.