Official tcp relay no longer responds

[Mic92]

Before filing a Bug Report

This is how a successful connection looks:

$ nc -v 95.217.199.121 443
Connection to 95.217.199.121 443 port [tcp/https] succeeded!

The official proxy doesn't respond:

$ nc -v 204.80.128.1 443

If you still want to file a Bug Report

Please let us know

• What you expect to be happening.

connection succeeds

• What is actually happening?

connection times out

• Any steps to reproduce the error.

see above.

• Any relevant console output or screenshots.

see above.

• What operating system and ZeroTier version. Please try the latest ZeroTier release.

Doesn't depends on the zerotier version. But any zerotier version cannot use the relay for this reason.

[joseph-henry]

Thanks for reporting this. Definitely looks like something is up and I'll look into it. In the meantime users can easily set up their own tcp relays with zerotier/pylon

[Mic92]

I would rather recommend using https://github.com/alexander-akhmetov/zt-tcp-relay as the above provides not a VPN but a socks interface, which is a bit tedious to be configured in various applications. But because of https://github.com/zerotier/ZeroTierOne/issues/2203 one also has to force TCP connections explicitly in the configuration for nodes that have TCP-only access.

[joseph-henry]

Sort of. The pylon application has two modes, one of which is a SOCKS5 proxy pylon refract and the other is our tcp-proxy bundled for convenience as pylon reflect.

[laduke]

How do you tell zerotier-one to use pylon refract ?

[joseph-henry]

How do you tell zerotier-one to use pylon refract ?

I assume you mean reflect, because refract is a ZT instance that multiplexes traffic to and from the ZT network and the LAN.

{
  "settings": {
    "forceTcpRelay": true,
    "tcpFallbackRelay": "1.2.3.4/443"
  }
}

[laduke]

Thanks. Yeah typo. Someone should put that in the reflect docs ;)

[aqaengineering]

Has there been progress on this? We've recently run into what we think is this issue. On a network that blocks all UDP traffic, Zerotier on MacOS and Linux used to have no problem falling back to TCP relaying with no configuration outside of what ships default. Seems they don't anymore.

Separately, does this ticket imply that all Zerotier-provided TCP relaying has been unavailable for several months? If so, is there an outage or status page that has this info somewhere?

[laduke]

Anyone notice an improvement?

[aqaengineering]

@laduke not seeing an improvement. Running version 1.14 on Debian and on the same network mentioned in our comment above - the zerotier-one service still shows offline. Have rebooted the system as well just in case but no change.

Noticed the official fallback relay referenced in OneService.cpp here appears to still be down. Per @Mic92's comment above, using nc as below still results in no response.

nc -v 204.80.128.1 443

Is there something else we should try? Let us know, happy to help test.

[aqaengineering]

nc -v 204.80.128.1 443 now returning 'Connection to 204.80.128.1 port 443 [tcp/https] succeeded!' and zerotier-cli info is now showing 200 info <removed> 1.14.0 TUNNELED. Looks like the official relay is back up!

@laduke not seeing an improvement. Running version 1.14 on Debian and on the same network mentioned in our comment above - the zerotier-one service still shows offline. Have rebooted the system as well just in case but no change.

Noticed the official fallback relay referenced in OneService.cpp here appears to still be down. Per @Mic92's comment above, using nc as below still results in no response.

nc -v 204.80.128.1 443

Is there something else we should try? Let us know, happy to help test.

[laduke]

thanks! 204.80.128.1 is actually an anycast address. there are many tcp relay instances.

traceroute 204.80.128.1 can give you some clues on what region you're getting routed to.

[aqaengineering]

Just leaving a note here about some interesting behavior we observed.

It appears that the network we're on doesn't block all UDP traffic as we previously thought. However, the zerotier-one service goes from "OFFLINE -> TUNNELED -> ONLINE", and tcpFallbackActive goes "false -> true -> false". It seems like the zerotier-one service just needs to get some sort of connectivity via the fallback relay, and then is able to switch over to a direct UDP connection.

[aqaengineering]

thanks! 204.80.128.1 is actually an anycast address. there are many tcp relay instances.

traceroute 204.80.128.1 can give you some clues on what region you're getting routed to.

Interesting and thanks for the tip!

[laduke]

It appears that the network we're on doesn't block all UDP traffic as we previously thought. However, the zerotier-one service goes from "OFFLINE -> TUNNELED -> ONLINE", and tcpFallbackActive goes "false -> true -> false". It seems like the zerotier-one service just needs to get some sort of connectivity via the fallback relay, and then is able to switch over to a direct UDP connection.

That's strange. Are are our roots (UDP) blocked somehow?

host root.zerotier.com zerotier-cli peers | grep PLANET

[aqaengineering]

@laduke doesn't appear that zt roots are being blocked.

> host root.zerotier.com
root.zerotier.com has address 84.17.53.155
root.zerotier.com has address 103.195.103.66
root.zerotier.com has address 104.194.8.134
root.zerotier.com has address 50.7.252.138
root.zerotier.com has IPv6 address 2605:9880:400:c3:254:f2bc:a1f7:19
root.zerotier.com has IPv6 address 2a02:6ea0:d405::9993
root.zerotier.com has IPv6 address 2001:49f0:d0db:2::2
root.zerotier.com has IPv6 address 2605:9880:200:1200:30:571:e34:51

> zerotier-cli peers | grep PLANET
62f865ae71 -      PLANET    -1 DIRECT   6833     25252    50.7.252.138/9993
778cde7190 -      PLANET    -1 DIRECT   1833     25025    103.195.103.66/9993
cafe04eba9 -      PLANET    -1 DIRECT   6833     25387    84.17.53.155/9993
cafe9efeb9 -      PLANET    -1 DIRECT   6833     25439    104.194.8.134/9993