taranf

I've noticed an odd inconsistency about how a connection through this plugin seems to handle traffic to a Docker container. (I am not using the Docker integration, so I think this is the correct topic to post in despite Docker being relevant). Here are the only Tailscale settings that are enabled in Unraid: Auto Update, Run as Exit Node, Allow LAN Access while using Exit Node. All others are disabled or blank. My setup is I have all my containers behind an Nginx proxy manager container that exposes ports 80 and 443 and forwards traffic to other containers on different subnets; these other containers expose no ports. Anything that is IMO more likely to have security vulnerabilities is behind ACLs with an IP whitelist with fallback to a username/password as a very basic safety precaution. Despite listing the Tailscale IP in the ACLs I keep getting the nginx username/password prompt when accessing the server via Tailscale (it does not occur when accessing the server locally). Looking into the Nginx logs the client IP is listed as the gateway for the first listed Docker network (For me this is both the first alphabetically and the last numerically so I'm not 100% sure on the logic for the selection, but I don't think that matters for the problem). Upon inspecting the query received by Nginx and playing around with another container that echos HTTP queries I found the following for requests made via Tailscale: 1) If a container exposes ports and has no container networks the correct Tailscale IP will be used in the "ip" field of the query. 2) If a container exposes ports and has any container network the "ip" field will be the gateway IP of one of those networks, additionally the Tailscale IP appears nowhere in the query (like in an XFF header) so there is zero mechanism to retrieve the actual origin IP. Any ideas why this occurs? I had a quick look at the plugin source on Github but it seems like largely a wrapper around Tailscale so maybe it's an upstream issue. I setup a Tailscale and docker on an ubuntu virtual machine and it doesn't display this issue so unlikely to be an upstream issue. I also should clarify the container networks that result in the behaviour being triggered are all "external" networks, non-external bridge networks do not result in this behaviour.

I've been setting up Nginx Proxy Manager and am wondering, is there a reason the docker doesn't include a port mapping for port 3000 by default? Since it seems to be required for the admin interface to function correctly. As it is I ran into some trouble because I had another service that happened to default to using port 3000. If the port was mapped then it would have detected the port was already allocated to another image and refused to start the service rather than requiring going into the logs to figure out why I was unable to login.