Zerotier gets RELAY at a certain physical location

[zeroduck]

I deployed Zerotier in 3 different geographical locations, temporarily called A, B, C respectively. Locations A and B are in the same city, about 4 km apart. Every device at location B when pinging to A and vice versa is about 150-200ms, file transfer speed is about 10mbps or less. At first I thought everything like that was normal, until I brought my laptop home in position C and remotely controlled the devices in position A. It was strange that when I tested the ping it was only about 10-20ms, file transfer speed up to 100mbps. I checked the peer with zerotier-cli and found that devices at A and C both connect “DIRECT” but B to other locations and vice versa all “RELAY”.

All 3 locations use the same service provider and the same price. Network equipment at points B and C are the same. The test equipment for measuring is the same (I brought my laptop and smartphone from B to C).

From the above, I think the problem is not with the device or the installation, but with the network at location B. More precisely, it may be because the service provider has blocked something on the network at location B. I tried searching online and every keyword I noticed was “NAT strict”. But I’m still not sure if it’s due to it and how to tell the service provider to unblock it. In addition, at location B, using the IPTV service of the network service provider, they said that the IPTV line and the regular internet connection are two different lines. However, when installing, I saw that they only plugged an optical cable into a Modem (which also functions as a router and also broadcasts wifi) and then connected to the TV and other devices via LAN. I don’t know if that has anything to do with it? I don’t have much background in networking so please help me figure out the problem and how to fix it.

Diagram of locations

[l0crian]

You’re definitely correct in that something is likely not being allowed to/from your B site.

ZeroTier will attempt to make a direct connection using UDP, and then fallback to a TCP relay if a connection doesn’t work. Some ISPs (often ISPs on the smaller side) will be intentionally hostile towards UDP. This is largely because UDP is the protocol of choice for volumetric DDoS attacks. Larger ISPs can afford DDoS mitigation, but smaller ones some times just go for the more extreme approach of blocking (most) UDP. It’ll be unlikely that they would allow your traffic specifically, but you can ask them to allow UDP/9993 to/from your ‘B’ site.

Another possibility is the provider equipment has issues with STUN, which is a mechanism to get around NAT issues. There’s unfortunately not a lot of room to modify Provider equipment.

You may have noticed I said they block most UDP. There is some UDP that is required for normal network traffic to operate. A good example of this is DNS which uses UDP/53. It’s possible to trick your ISP into allowing the traffic by changing the port in use to 53. Your ISP may still rate limit traffic to/from UDP/53, which would cause serious issues with your traffic. You’d likely only be able to do this for something where you can modify the local.conf file.

In Summary, there could be a number of issues causing this. It’s a long shot, but if you’re ISP will allow UDP/9993, then you’d likely be good. Other than that, solving this is possible, but it can get a little complex if you’re not comfortable with networking.