I have several remote Windows PC’s in my ZeroTier network. They are typically sleeping. When I need them I login to a Raspberry Pi on the network they are connected to and wake them up via WOL. They generally wake up immediately but I can’t connect to them via RDP for many minutes. Any ideas why it takes so long for them to become available?
When they wake up they may attempt to use old cached hints on how to reach other devices (same for your Pi), as a test you can try to delete the peers.d in each node’s home directory before starting the node and see if that improves things. If that seems to help please let us know we might make changes to how that caching works.
I woke the PC, connected to it via TeamViewer (which I use for those times when ZT isn’t working for some reason) and deleted peers.d from the home directory. It was re-created in short order but the PC wasn’t pingable at its ZT address for a full 3 minutes thereafter. Once ping started to work, RDP also worked fine of course. Should it take that long?
Not usually, but things definitely will depend on the condition of the underlying network, what sort of NAT is in use, etc. Is it only Windows machines that take a while to be reachable?
The underlying network is behind an eero router and I have no control over what type of NAT is in use. The pi on that network is always on and I never have a problem reaching it. Just the recently-awoken Windows machines.
I recently observed a similar issue, not for the 1st time.
Far end device is OpenWrt router with ZT client installed. The router has both IPv4 and IPv6 public addresses.
My initial connection attempt was over http (instead of RDP in the example above), when I noticed that the connection cannot be established, I checked the famous online status and started pinging from my PC that has ZT client installed. I started getting responses a few minutes later, like in the above case.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.