rrr01

Hi. I think It is a different issue. For me, the problem is that the webui and dockers that are in bridge mode, cannot be accessed from a different LAN subnet 10.17.147.0/24. The dockers on a user defined custom network mode can be accessed from a different subnet. I feel it looks like a firewall issue? But I can’t find any settings for changing the firewall or making unraid think 10.17.147.0/24 is also a LAN address.

Same issue here

Hi I found the unraid webui and docker containers in bridge network were not accessible from a different subnet. In my home network, 192.168.31.10 is my unraid server; 192.168.31.1 is my openwrt router, which runs zerotier and route traffic from 10.147.17.0/24 to 192.168.31.0/24 and vice versa (configured automatically by the plugin). My unraid webui is configured at 8080 port I have another PC (10.147.17.145), in a different place, that is connected to my home network with zerotier. It can access all other devices in my home network, as well as the docker containers that are in a custom network mode by browsing 192.168.31.10 and the corresponding ports. However, it refuses to connect to any docker contianers that are in bridge network, as well as the unraid webui. For testing, I tried to port forward 8080 port in router settings. Directly accessing the public IP of my home address and the correct port is working fine for both bridge mode containers and the webui. I tried to change the webui port to 8081, but it does not work. Is there anything I do wrong? Any ideas will be much appreciated!

FYI there are people having similar issue as me https://github.com/zerotier/ZeroTierOne/issues/787 One solution is to disable allowmanaged, but that means there needs to be a way to manually specify the IP address of the zerotier adapter, either a script in the container or a script in userscript maybe. Thanks!

Hello Thank you for the prompt reply. I feel it should be an issue within Unraid. To summarise the problem, once there is no available router or DHCP server in the network, as they actually boot after unraid and dockers, unraid server will acquire route rules for the physical subnet from Zerotier, instead of getting those later from router and DHCP servers. Therefore, as long as the router is added after unraid booting, it does not matter what router or what setting I have on the router. The unraid server simply wouldn't communicate with anything in the subnet, including the router, as it route all the traffic through the zerotier virtual nic. The most comprehensive solution might be avoiding adding to the route table until the physical nic gets the right information in the route table. But I guess it is a lot of work. To prevent this from happening, I speculate adding an option to disable this 'adding to route table' behaviour will be sufficient.

Same problem

Hi. I found a serious issue of this docker container when used in conjunction with an OpenWrt VM. Auto-start of this docker container makes me unable to access the unraid server after rebooting. I used an OpenWrt VM as my router for internet access as well as a gateway for Zerotier virtual network. As shown below, the IP of the router in Zerotier is 10.147.17.131 and my physical subnet is 192.168.31.0/24. I have a Zerotier docker container on my unraid as a backup. When I reboot, as the unraid server boots before the OpenWrt VM, it is not able to get the correct route information for the physical NIC. Instead, it places the route acquired from Zerotier first. This makes it impossible to access the unraid server from LAN or from Web, as the route is wrong and it will keep trying to connect to anything in the subnet including the OpenWrt router through the Zerotier gateway at 10.147.17.131. I speculate this behaviour can be avoided if either 1. like other clients, add an option to disallow route through zerotier 2.. the container configures the route table after the correct one is acquired.

Same. It was working but after one day, I cannot connect to my unraid server anymore. An upgrade will be very much helpful.

Hello. It seems the read permission issue still exists. Is there any way to fix it?