Running nat-detection on a simple computer returns NAT status has been found to be: UPnP
Running nat-detection in a container (incus) returns NAT status has been found to be: Private
Both machines are behind the same router (OpenWRT) and have an ip-address from the same subnet on the same network. The container has a macvlan interface, so there’s no extra routing going on.
What could be the reason for the difference? Can I somehow get more verbose output from nat-detection?
Looking at the routers active dynamic port mappings, UPnP, NAT-PMP, PCP, all work from containers using other software and from computers running antnode or other software. So there’s something with containers and autonomi. antnodes in containers make connections - using hole-punching I suspect - but data storage remains empty.
Could antnode / nat-detection require extra privileges/capabilities in order to work?
By default, Docker runs each container in a separate network namespace, using an internal subnet, connected via a bridge to your host. UPnP will most likely not work properly in such a setup, at least not out of the box.
There are two things you can try to fix this:
Host-network: Instead of running the container with the default bridge network, use host network instead (--network host). Your container should then run on the same subnet as your router and UPnP might just work. You lose network isolation for your container though.
Thanks. I’m running system containers with incus, and the container has a macvlan interface directly on the LAN - bypassing the host network stack. That’s why I’m wondering why it’s not working. As far as I understand, networking-wise it should be pretty much equivalent to a standalone linux machine. All other applications that need PCP / NAT-PCP work perfectly, as does dhcp, arp, ping, mdns, etc. Only antnode / nat-detection doesn’t seem to figure it out.