Zerotier one error joining network

Troubleshooting & FAQ

Ping is not working#

First, make sure your device is authorized on the network and you’re using the ZeroTier assigned Managed IP address. Aside from that, some OSes block pings in their local firewall by default.

Windows#

Windows does block pings by default. To enable pings on Windows, follow the following steps

1. Click the search bar on your taskbar and search for «Windows Firewall» then click it to open
2. Click «Advanced Settings» on the left.
3. From the left pane of the resulting window, click «Inbound Rules»
4. In the right pane, find the rules titled «File and Printer Sharing (Echo Request — ICMPv4-In).
5. Right click each rule and choose «Enable Rule»

macOS#

The firewall is not enabled by default on macOS, and thus pings will not be blocked by default. If your firewall is enabled on macOS, go into System Preferences -> Security & Privacy. Under Firewall Options, ensure «Enable stealth mode» is disabled. Stealth mode blocks pings.

Linux#

There are far too many linux distributions out there to list instructions for all of them here. Please refer to your distribution’s documentation for how to unblock ICMP packets.

Router Configuration Tips#

ZeroTier is designed to work in as many environments as possible. We provide multiple layers of fallback so that some level of connectivity can be achieved through even the most restrictive or broken physical networks. But «some level of connectivity» does not mean «optimal connectivity.» This page details the physical network configuration that we recommend for best results.

If your network configuration is hostile to peer to peer network connectivity, most of your ZeroTier traffic will end up being relayed indirectly. This slows things down considerably. Other settings such as «local isolation» can also interfere significantly with performance by forcing local traffic to traverse the Internet.

Recommended Local Network and Internet Gateway Configuration#

• Don’t restrict outbound UDP traffic.
• Supporting either UPnP or NAT-PMP on your network can greatly improve performance by allowing ZeroTier endpoints to map external ports and avoid NAT traversal entirely. IPv6 is recommended and can greatly improve direct connection reliability if supported on both ends of a direct link. If present it should be implemented without NAT (NAT is wholly unnecessary with IPv6 and only adds complexity) and with a stateful firewall that permits bidirectional UDP conversations.
• Don’t use «symmetric» NAT. Use «full cone» or «port restricted cone» NAT. Symmetric NAT is extremely hostile to peer to peer traffic and will degrade VoIP, video chat, games, WebRTC, and many other protocols as well as ZeroTier.
• No more than one layer of NAT should be present between ZeroTier endpoints and the Internet. Multiple layers of NAT introduce connection instability due to chaotic interactions between states and behaviors at different levels. No Double NAT.
• NATs should have a port mapping or connection timeout no shorter than 60 seconds.
• Place no more than about 16,000 devices behind each NAT-managed external IP address to ensure that each device can map a sufficient number of ports.
• Switches and wireless access points should allow direct local traffic between local devices. Turn off any «local isolation» features. Some switches might allow finer grained control, and on these it would be sufficient to allow local UDP traffic to/from 9993 (or in general).

What ports does ZeroTier use?#

It listens on three 3 UDP ports:

• 9993 — The default
• A random, high numbered port derived from your ZeroTier address
• A random, high numbered port for use with UPnP/NAT-PMP mappings

That means your peers could be listening on any port. To talk with them directly, you need to be able send to any port.

Should I forward any ports in my router?#

You shouldn’t need to. Between ZeroTier’s UDP hole punching techniques, UPnP, NAT-PMP, and IPv6, ZeroTier should be able to get through without you manually opening ports.

System Firewalls and Security Software#

If your computer has a local firewall, allow traffic to and from UDP port 9993. In some cases (such as the Windows built-in firewall) ZeroTier does this automatically if installed with one of our installation packages. In other cases such as Linux iptables we leave this to the user since there are too many variations and we do not want to accidentally corrupt user settings by trying to modify them manually.

Some systems may also have security software present that only allows select applications to communicate with the Internet. In that case you may need to locate the ZeroTier service binary and authorize it.

Finally, it’s important to note that ZeroTier One’s virtual network ports appear to your system just like normal LAN or WiFi ports and are subject to local firewall rules. If everything appears okay but you can’t reach a local service like SSH or HTTP, check local firewall rules to ensure that desired traffic over the virtual network itself is allowed.

High Latency & Relaying#

If you’re experiencing high latency (or high ping times), it’s possible the connection between two nodes is being Relayed. The command zerotier-cli peers (available in 1.4.x and above) will give you information on what if any connections are being relayed. The output will look something like this:

Источник

NODE ID: Unknown is Back #758

Just as the title suggests.

As the previous bug, reinstalling fixes it until the next reboot of the system
and it goes back.

Furthermore, this may be the reason, the cli says
» missing authentication token and authtoken.secret not found» even though it exists in the said path.

The text was updated successfully, but these errors were encountered:

Hey, can you check
C:ProgramDataZeroTierOne
and
C:UsersnischkarAppDataLocalZeroTierOne

They should both have authtoken.secret. The UI copies it from ProgramData to the UserAppData when it starts up. It needs admin privileges to do this.

It both exists.
(C:ProgramDataZeroTierOne)

(appdataLocalZeroTierOne)

I also tried to change the file permissions, but it does not fix the problem.

No luck reproducing this one reliably so far. I had it happen to me on my home machine once, but it has since magically resolved itself. It appears ZeroTier was getting into a state where it was no longer listening on the TCP control port that the UI and zerotier-cli talk to, but I couldn’t figure out why before it stopped happening to me.

Experiencing this issue on multiple machines as well.

@ecapuano Can you tell us what you did, maybe the developers can recreate the issue with the steps you will provide.

I’m new to ZeroTier as of today. Installed in on a corporate laptop was able to connect from other machines and it seemed to work fine. After a reboot I see this issue, node id is unknown. If I try to join my network I get the error:
Error Joining Network: Cannnot connect to the ZeroTier Service.
The message led me to check for a ZeroTier service and found that it was set to Automatic but was not running. I started it manually and when I check now, I have a node Id. When I check ZeroTier central, it shows I’m connected. Please advise what to check or report to assist you with debugging this.

Think I found & fixed this issue. 352ec34

Turns out that the #define in WinSock that sets the default maximum number of open sockets is the obscenely low value of 64. I bumped this up a few orders of magnitude to 1024. Fix will be in the next release.

run services.msc
start ZeroTierOneService, if it is stopping.

Looks like this is merged

In my experience, the zerotier-cli error may be due to inadequate permissions accessing authtoken.secret on Windows. Try launching Command Prompt as administrator first. (I was able to get my node ID with zerotier-cli info )

got this exact issue a while back, rebooting my PC resolved it

About the solution of Node ID «Unknown» or Service stops automatically on Windows

In short, uninstall version 1.4.6 and install version 1.2.8.

1. Run «ZeroTier One.msi»(version 1.4.6) and select “remove”，uninstall version 1.4.6.
2. Enter this page: https://download.zerotier.com/RELEASES/1.2.8/dist/ ,download version 1.2.8, install it.
3. The zerotier one service is up and running.

run services.msc
start ZeroTierOneService, if it is stopping.

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Cannot connect to ZeroTier service (VPNs and Hypervisors again) #799

Possibly related to #357 and/or #308

ZeroTier One: 1.2.8
Windows 10: build 1803
VPN service: Viscosity
Hypervisor: VMWare Workstation

It seems like the previous testing and fixing revolved around OpenVPN and Hyper-V. In my particular setup, I’m running Viscosity (which honestly shouldn’t be installed anymore since I’m using ZeroTier One as a replacement now), and VMWare Workstation. I’m getting the dreaded «Cannot connect to ZeroTier service» when trying to add a network. I did this because the network list window showed I wasn’t connected to anything. I then went to my local network connections to discover the ZeroTier connection was already registered, however it is marked as «unplugged.» I tried this with both my wired and wireless NICs in both combinations of connected/disconnected to see if ZeroTier used cable state replication (something VMWare optionally does), but that didn’t change anything.

Rebooting:
no change

Uninstall Viscosity and reboot:
everything is working as expected now.

It appears as though ZeroTier is still conflicting with other VPN providers (possibly mixed with other Hypervisors?)

The text was updated successfully, but these errors were encountered:

Источник

Windows coexistence problems with HyperV and/or OpenVPN #357

Receiving the following message on a Windows 10 client with 1.1.12.

I confirmed the ZeroTier service is running. Is there a log file somewhere for further information?

If I close the client and then open it again I receive the following message after about 2 minutes:

Then stopping the ZeroTier service (via services.msc) results in

The service then says it is stopped. Turning it on again takes a 1-2 seconds, but does not fix above issues.

The text was updated successfully, but these errors were encountered:

What version of Windows is this? 32 or 64 bit?

Further information. I rebooted client host (windows) and it was able to join a zerotier network. Then I joined and left it twice. On the second leave, I experienced this behavior. Unfortunately it looks to be an intermittent issue.

We’ll try repeatedly adding and leaving networks on Windows 10 x64 and see if we can reproduce.

Is this host running other VPN, tunnel, or network virtualization software or VM software like HyperV? We’ve heard intermittent reports of issues when other things like that are installed but so far have not been able to reproduce.

Good call on that. The Windows 10 host did have OpenVPN installed (client was not running, service was running though) and Hyper-V. I’ll look into those when I get some time.

This may be related to or a duplicate of #308

Absolutely no problem on CLEAN Windows 10 after many leave/joins. now installing OpenVPN.

Another question: does your account have administrator rights?

Hmm. just tried creating a normal user. It asks for an administrator user’s password when you launch the app but otherwise it works fine. Left and rejoined network several times with OpenVPN installed and it’s fine. Now trying HyperV.

Added Hyper-V and am still unable to reproduce this problem.

Can you post some information about your Hyper-V settings? Are you running any VMs? Do you have any virtual switches configured?

The account does have administrator rights.

It does have a virtual switch configured on the primary ethernet interface as well as the wireless interface. Pretty standard settings for the virtual switches. No VMs were running when this issue occurred.

Okay, going to try replicating a similar config and testing.

I believe we have FINALLY been able to duplicate this on a bare metal Windows machine with HyperV. I think this is also a duplicate of #308 since that’s part of the symptom.

Reproduced with 1.1.14 — almost certainly a driver issue related to coexistence with HyperV and possibly other things.

We’ve narrowed it down— when ZT starts on a bare metal HyperV host, a single core gets MAX’d out. but the CPU thrashing is happening in bridge.sys which is part of Windows. Not sure yet if it’s a HyperV component or a Windows component but that’s where the evil is happening.

My guess is that our virtual network port driver (which is a pretty thin fork of OpenVPN’s open source tap-win32 NDIS6 version) is not responding to something or is responding in a way bridge.sys doesn’t like and is triggering a bug in MS’s code. Unfortunately we are going to have to eat it because MS is not going to fix this for us.

Googling shows a lot of issues with bridge.sys . 🙁

@jdrews Is your Hyper-V virtual switch bridged to a wireless network card?

@glimberg Yes I had two Hyper-V virtual switches bridged to physical devices. One to my external ethernet device, and one to my wireless device. See screenshot earlier in this thread.

OK. That mirrors what we’re seeing here in the office. It only happens when bridged with a wireless network card.

We have a ticket open with Microsoft and their networking group is looking into the issue. Hopefully they can either issue a fix for Windows, or let us know what we can change in our driver to prevent the issue from happening.

@jdrews Good news! With some feedback from Microsoft we got this morning, it looks like we have this issue fixed internally and should make it into the 1.2.0 release.

Источник