Domain unreachable by some internet connections


I’ve opened a domain edu3d, teaching people (essentially to Italian teachers willing to teach with virtual worlds in their classes), but apart from the technical hardware problems with graphical cards, it appears that this domain is sometimes not reachable (i.e. not connected appears) from some internet connections.

This is very frustrating for some of the participants… They are able to reach other public domains, but not this particular domain. The problem may cease if they change provider or go to another house or city.

My question is: what should we exactly check on the client/server logs (which files exactly) and which debug settings we might set to understand what is happening and possibly understand how to fix this?

This is happening to me right now being connected with a mobile connection. I’m able to connect to bank of high fidelity, but when trying to connect to edu3d have this error:

logs are apparently just showing something not understandable:



So this is something I’ve heard of before, which is that some network connections are using strict NAT. If you can access the primary High Fidelity Inc domains (help, thespot, rust, etc) but only some can access edu3d, this may be the culprit. Another way to test is try visiting my domain, Voxel.

If the above is true and you can access Voxel without issue, then that definitely points towards a strict NAT issue, which can only really be resolved if you are running the server yourself (as in, fully setup manually), since it’s based on server configuration and port forwarding.

So that would be the first part to help out:

  1. What are you using as a server? (Digital Ocean Cloud Server w/ High Fidelity support, Amazon EC2, self run server, etc)
  2. If running the server yourself (say your own network), do you have any firewalls active on the server’s connections?
  3. Does this issue also occur when accessing Voxel or any High Fidelity Inc domain? (Voxel uses a custom set up for being strict NAT friendly, so that’s why I’m throwing it in the test)


Hi @FlameSoulis thanks for this answer I’m really anxious to solve this problem: High Fidelity has already so many reachability problems (hardware internet etc), that this should be fixed in some way.


  1. I tried with different servers, but current one is a debian 9 on Hetzner

pakkio@s30:~$ cat /etc/issue
Debian GNU/Linux 9 \n \l


  1. I’m not aware of any firewalls active, but I’m running it via docker with the following instruction (maybe this is wrong?)

docker run -d -p 40100-40110:40100-40110 -p 8000-8010:8000-8010 -v “edu3d:/root/.local/share/High Fidelity” --name hf70.edu3d highfidelity/hifi:0.70.0

  1. When I experiment this directly again will try to reach the Voxel domain as well.


Hmm… judging by the docker setup, it looks like it SHOULD be assigning the ports between 40100 and 40110… but how it is doing that, I’m not sure, since the ability to specify a minimal and maximum port number was never implemented…

Sadly I never really set up a docker system (been doing it manually) so I’ll have to figure out what is going on


@claudio.pacchiega make sure those ports are open for UDP at the server level, not only at the Docker level.
I’ve tried to connect to that server and the domain never responds to my UDP ping packets on 40102.


hi @c, I did relaunch the docker with the following options:

docker run -d -p 40100-40110:40100-40110 -p 40100-40110:40100-40110/udp -p 8000-8010:8000-8010 -p 8000-8010:8000-8010/udp -v “edu3d:/root/.local/share/High Fidelity” highfidelity/hifi:0.70.4

docker inspect gives the following status where all udp ports seems now open
can you give me the statements I can use to check if they are really answering?

this is the firewall status:

apparently if I check the opened UDP port on 40100/40109 it seems they are open only as udp6, do you have any idea if this is correct or not?

> pakkio@s30:~$ sudo netstat -aunp | grep 401
> udp6       0      0 :::40100                :::*                                16532/docker-proxy
> udp6       0      0 :::40101                :::*                                16507/docker-proxy
> udp6       0      0 :::40102                :::*                                16479/docker-proxy
> udp6       0      0 :::40103                :::*                                16454/docker-proxy
> udp6       0      0 :::40104                :::*                                16428/docker-proxy
> udp6       0      0 :::40105                :::*                                16398/docker-proxy
> udp6       0      0 :::40106                :::*                                16370/docker-proxy
> udp6       0      0 :::40107                :::*                                16345/docker-proxy
> udp6       0      0 :::40108                :::*                                16318/docker-proxy
> udp6       0      0 :::40109                :::*                                16290/docker-proxy
> udp6       0      0 :::40110                :::*                                16260/docker-proxy
> pakkio@s30:~$

This hould open the 40100-40110 ports also for udp. Can you check it this is true?

I tried with nmap on the server:

pakkio@s30:~$ sudo nmap -sU -p 40100-40109

Starting Nmap 7.40 ( ) at 2018-08-06 23:18 CEST
Nmap scan report for (
Host is up.
rDNS record for Debian-94-stretch-64-minimal
40100/udp open|filtered unknown
40101/udp open|filtered unknown
40102/udp open|filtered unknown
40103/udp open|filtered unknown
40104/udp open|filtered unknown
40105/udp open|filtered unknown
40106/udp open|filtered unknown
40107/udp open|filtered unknown
40108/udp open|filtered unknown
40109/udp open|filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 3.14 seconds

and on another server I see the following

root@ubuntu-4gb-nbg1-1 ~ # nmap -sU -p 40100-40109

Starting Nmap 7.01 ( ) at 2018-08-06 23:20 CEST
Nmap scan report for (
Host is up (0.024s latency).
rDNS record for
40100/udp closed        unknown
40101/udp closed        unknown
40102/udp open|filtered unknown
40103/udp closed        unknown
40104/udp open|filtered unknown
40105/udp closed        unknown
40106/udp closed        unknown
40107/udp closed        unknown
40108/udp closed        unknown
40109/udp closed        unknown

Nmap done: 1 IP address (1 host up) scanned in 3.87 seconds
root@ubuntu-4gb-nbg1-1 ~ #

Does this mean that the 40102 is ok?


@claudio.pacchiega Looks like that fixed it, I can connect to the server now.
Docker probably wasn’t letting UDP through.


now I will try to check with my students if they can come easier to this domain from their connections. Thanks for assisting.


No problem, let me know how it goes.