FayeInMay

Hello, I've been struggling with my other issue below, but maybe found a specific bug/fix for it. Therefor this new issue because it might not even fix the other one. It seems like line 166 in rc.d/rc.docker is not entirely correct. "[[ -n $NETWORK ]] && nsenter -n -t $PID ip -4 route add $NETWORK via $THISIP dev br0 2>/dev/null" translates to nsenter -n -t 9439 ip -4 route add 10.253.0.0 via 192.168.0.231 dev br0 If I understand it correctly, it attaches to the container process and adds a static route for wireguard. In my case 10.253.0.0/24 to 192.168.0.231. But it uses the br0 interface. This interface is not available within the docker container. The available interface is eth0. Therefor the command failes and the static route does not get created. The only thing I do not know is why this only happens on unraid/docker startup The static route will be added upon container restart. I believe the scripts doing both actions (initial startup / container restart) are not the same and that might explain it.

Hi there, it seems like there might be a bug with the wireguard integration in unraid. I read below that the routes for br0 access will automatically be created. Thus I should be able to connect from wireguard to unraid br0 docker container. And I am able to do that. Until I restart my machine. After restarting my machine all docker containers including my nginx proxy manager are booting up again. But after the npm docker container started, it has the wrong routings towards wireguard. It's solved automatically though when restarting the container again. Maybe some sort of race condition with docker and wireguard integration? Although I did set wait 60 on npm to test this and I still have the same result. Output in container after unraid restart: # traceroute 10.253.0.1 traceroute to 10.253.0.1 (10.253.0.1), 30 hops max, 60 byte packets 1 192.168.0.1 (192.168.0.1) 0.730 ms 0.745 ms 0.769 ms 2 192.168.2.1 (192.168.2.1) 1.256 ms 1.694 ms 1.703 ms 3 p3e9bf104.dip0.t-ipconnect.de (62.155.241.4) 21.984 ms !N 22.011 ms !N 22.006 ms !N # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 # ping 10.253.0.1 PING 10.253.0.1 (10.253.0.1): 56 data bytes 36 bytes from p3e9bf104.dip0.t-ipconnect.de (62.155.241.4): Destination Net Unreachable 36 bytes from p3e9bf104.dip0.t-ipconnect.de (62.155.241.4): Destination Net Unreachable 36 bytes from p3e9bf104.dip0.t-ipconnect.de (62.155.241.4): Destination Net Unreachable ^C--- 10.253.0.1 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss Output in container after NPM container restart: # traceroute 10.253.0.1 traceroute to 10.253.0.1 (10.253.0.1), 30 hops max, 60 byte packets 1 10.253.0.1 (10.253.0.1) 0.117 ms 0.028 ms 0.043 ms # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 10.253.0.0 192.168.0.231 255.255.255.0 UG 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 # ping 10.253.0.1 PING 10.253.0.1 (10.253.0.1): 56 data bytes 64 bytes from 10.253.0.1: icmp_seq=0 ttl=64 time=0.157 ms 64 bytes from 10.253.0.1: icmp_seq=1 ttl=64 time=0.133 ms ^C--- 10.253.0.1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.133/0.145/0.157/0.000 ms