No Base Server connection

We are trialling Husarnet and have created a new Husarnet network. We are unable to join any elements to the network though (using clients on Ubuntu 20.04 and Windows 10), as they timeout while waiting for websetup connection.

“husarnet status” on clients (both Ubuntu and Windows) report the following:

~$ sudo husarnet status -v
Version
● CLI:                       2.0.52
● Daemon (running):          2.0.52
● Daemon (binary):           2.0.52

Dashboard URL
● CLI:                       app.husarnet.com
● Daemon:                    app.husarnet.com

Connection status
● Base Server:               188.165.23.196:443 (NONE)
● There's no Base Server connection - Husarnet will not be fully functional
● Websetup:                  not connected

Readiness
● Is ready to handle data?   no
● Is ready to join?          no
● Is joined?                 no

“journalctl --unit husarnet” reports these sorts of entries continuously:

Feb 20 09:58:49 GDS-T5810 husarnet-daemon[6890]: INFO     establishing connection to base 188.165.23.196:443                               (/app/core/ngsocket.cpp:891)
Feb 20 09:58:49 GDS-T5810 husarnet-daemon[6890]: WARNING  base TCP connection closed                                                       (/app/core/ngsocket.cpp:899)
Feb 20 09:58:50 GDS-T5810 husarnet-daemon[6890]: WARNING  Sending join request to websetup                                                 (/app/core/websetup.cpp:150)
Feb 20 09:58:55 GDS-T5810 husarnet-daemon[6890]: WARNING  Sending join request to websetup                                                 (/app/core/websetup.cpp:150)
Feb 20 09:58:56 GDS-T5810 husarnet-daemon[6890]: INFO     reestablish connection to [fc94:b01d:xxxx:xxxx:xxxx:xxxx:7639:932a]              (/app/core/ngsocket.cpp:232)
Feb 20 09:59:00 GDS-T5810 husarnet-daemon[6890]: WARNING  Sending join request to websetup                                                 (/app/core/websetup.cpp:150)
Feb 20 09:59:05 GDS-T5810 husarnet-daemon[6890]: WARNING  Sending join request to websetup                                                 (/app/core/websetup.cpp:150)
Feb 20 09:59:10 GDS-T5810 husarnet-daemon[6890]: WARNING  Sending join request to websetup                                                 (/app/core/websetup.cpp:150)
Feb 20 09:59:15 GDS-T5810 husarnet-daemon[6890]: WARNING  Sending join request to websetup                                                 (/app/core/websetup.cpp:150)
Feb 20 09:59:20 GDS-T5810 husarnet-daemon[6890]: WARNING  Sending join request to websetup                                                 (/app/core/websetup.cpp:150)
Feb 20 09:59:21 GDS-T5810 husarnet-daemon[6890]: INFO     reestablish connection to [fc94:b01d:xxxx:xxxx:xxxx:xxxx:7639:932a]              (/app/core/ngsocket.cpp:232)
Feb 20 09:59:24 GDS-T5810 husarnet-daemon[6890]: WARNING  retrying with fallback base address: 188.165.23.196:443                          (/app/core/ngsocket.cpp:882)
Feb 20 09:59:24 GDS-T5810 husarnet-daemon[6890]: INFO     establishing connection to base 188.165.23.196:443                               (/app/core/ngsocket.cpp:891)
Feb 20 09:59:24 GDS-T5810 husarnet-daemon[6890]: WARNING  base TCP connection closed                                                       (/app/core/ngsocket.cpp:899)
Feb 20 09:59:25 GDS-T5810 husarnet-daemon[6890]: WARNING  Sending join request to websetup                                                 (/app/core/websetup.cpp:150)

We have tried with ufw disabled, and also enabled with a firewall rule to allow incoming Husarnet traffic (as per https://community-mirror.husarnet.com/t/joining-network/251/3) without any change.

Do you have any suggestions?

Thanks.

Hi @geoff.s,
I’ve checked my setup and Base Server is operational, https://status.husarnet.com/ seems to confirm it.

Could you tell me more about your network environment? Are you using a cellular connection? Are you aware of any unusual NAT setups/L7 firewalls/…? Are those hosts in some kind of a large data center?

Can you ping 188.165.23.196 from those hosts?

Hi @pidpawel,

The machines are on a corporate LAN with a fibre internet connection. Not cellular, and not in a large data centre. There is a WatchGuard firewall device - it may be blocking traffic but I’m not aware how it is configured at the moment. Is there a tool I can use to diagnose Husarnet traffic?

I can ping 188.165.23.196 from the Ubuntu and Windows machines.

I’ve noticed this item in the Husarnet troubleshooting guide:
“… In order to fix this, unblock UDP on the firewall. You need at least UDP port 5582, but it’s recommended to allow all outgoing connections.”
I’m pretty sure our IT support staff will object to opening all outbound UDP ports.

I did a quick check and port 5582 to 188.165.23.196 appears unblocked:

$ nc -z -v -u 188.165.23.196 5582
Connection to 188.165.23.196 5582 port [udp/*] succeeded!

Thanks for the details. In this case I suspect that WatchGuard may be the issue here. Husarnet Daemon uses port 443 and a SSL-like traffic (with a different encryption during the actual connection) for the initial connection to Base Server, and only then tries to connect via UDP. If you’re free to ping and connect via UDP right now that means that TCP traffic is restricted. I doubt that you need to open UDP ports in this particular case, but you may need to somehow “whitelist” 188.165.23.196 for SSL traffic analysis. I’ve checked the code but we unfortunately do not have an easy way of skipping the TCP handshake step in the Daemon code.

Thanks. We examned the firewall logs and it did not appear to be blocking any traffic to Husarnet, so suspect there may be some issue further upstream with our ISP.

We tethered some of the machines to the internet via mobile phones instead of the LAN and they were able to negotiate the initial handshake with the base server. Once they did that, they were able to maintain communication with Husarnet via UDP on our LAN without problem. So, we have a workaround. Thanks for the suggestions.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.