Docker-transmission-openvpn: The container cannot be reached when connecting externally to my home lan by using a local Wireguard VPN server setup

[garret]

I have a raspberry pi 3B with dietpi as distro and docker, sonarr, and wireguard installed. I also installed the docker-transmission-openvpn container which works without any issue.

When I am at home and I connect inside my internal home lan to 192.168.1.3:9091 (the transmission address of my raspberry pi 3B), I can see the web interface of docker-transmission-openvpn.

However, when I am on my android phone on 4G (so externally my home lan), I can open the webpage of sonarr by connecting to 192.168.1.3:8989 or also see my octoprint server that has address 192.168.1.32. But I cannot access the transmission web interface on 192.168.1.3:9091.

So it seems like the docker container is not touched by wireguard.
Do you have any idea on how to fix this?

[haugene]

I think this is the same as #687. Have a look and let me know if that fixes it.

[jeanpaulrh]

I follow this because I'm in the same situation. I have a VPN server on my router, but even if I can reach Transmission Web UI from the Lan, I can't when I'm connected to my lan via a VPN.
I'm running haugene/docker-transmission-openvpn in bridge mode, and set LOCAL_NETWORK=192.168.2.0/24
When I come from the VPN I have a 10.8.1.X address. I tried adding a route with a command to the container via the command:
/sbin/ip r a 10.8.1.0/24 via 172.17.0.1 dev eth0
but nothing changed.
I tried starting another container with a proxy as described in the README with the command:
sudo docker run -d --link TransmissionVpn:transmission -p 8080:8080 haugene/transmission-openvpn-proxy
Where TransmissionVPN is the Name of the container running transmission and the VPN client.
But then I don't know what to do. Neither connecting to port 8080, neither to port 9091 works if I'm connected through my VPN server.
I'd really like to set this last bit.
Thanks and have a nice day.

[haugene]

@jeanpaulrh But when you're on your local network (not through VPN) you can connect to 8080? So the proxy works, just not from 10.8.1.0/24?

[jeanpaulrh]

I will try this evening when I’m back home, but as far as I remember I tried to issue via terminal a
lynx localhost:8080
And got nothing but connecting... and nothing more. I will try again later.
Thanks.

[jeanpaulrh]

Ok. I logged into my server (which runs docker) via ssh and started the proxy container with the command written above.
If I try locally ( lynx localhost:8080 or remotely via VPN I get a a 504 Error Gateway timeout from nginx ).
The good news is that in the logs of the proxy container I found this:
2019/02/06 16:46:50 [error] 6#6: *11 upstream timed out (110: Connection timed out) while connecting to upstream, client: 192.168.2.2, server: , request: "GET / HTTP/1.0", upstream: "http://172.17.0.2:9091/", host: "192.168.2.2:8080"
Which to me seems the proxy is correctly trying to connect its 8080 port to the 9091 port on the other container. The problem is that the other container seems not to respond.

By the way, if I locally try a
lynx localhost:9091
The transmission web interface shows up without problems.

[haugene]

And what is the IP of that proxy container? Are you running docker-compose?
The reason why the proxy should be able to directly access the vpn container is that they're on the same network. So if you use docker-compose, the second container need to be added to the same network.

[jeanpaulrh]

The ip of the docker container is 172.17.0.3
I don't know what is docker compose.
I'm running Openmediavault and the first container (the transmission vpn one) is started through the web interface, while the other one is started via command line.
If I run a ping from the transmission container I can reach the ip of the proxy and the other ips of 192.168.2.0/24. I can even ping the internet, but I can't reach 10.8.1.0/24 space

[garret]

I am noticing that in the command I give to start the docker container I have this option:
-e LOCAL_NETWORK=192.168.1.0/24

Could it be that that line should be instead?
192.168.1.0/32

I know my subnet is 255.255.255.0, my router is 192.168.1.1 and my raspberry pi server is 192.168.1.3.
Are these information enough?

[jeanpaulrh]

Any news on this?

[haugene]

Well. For @garret's question it should be as it is and not change to "/32". There's fun binary details below it that makes very specific rules more tough to calculate. But the very short version is that:

• /32 would match just 1 IP-address (192.168.1.0 here)
• /24 would be 192.168.1.X
• /16 would be 192.168.X.X
• /8 would be 192.X.X.X
• /0 would be X.X.X.X or "any IP"

Not sure how I can be of further assistance. As long as you're reaching the web ui locally it means that Transmission is running fine. Then the rest is networking and then you at least need to give a complete picture of IP ranges and how far out you can actually reach it. On the host, in the LAN, over WAN or over VPN etc.

One thing that is worth noting. When using the proxy and --link, nginx will not retry address resolution after the initial startup. So if you re-create the transmission container and it gets a new IP, nginx container needs to be restarted.
Also, @jeanpaulrh. You cannot reach the 10.8.1.X space from the transmission container because it's not in the LOCAL_NETWORKs. So the traffic is tunneled through the VPN. That's why you need to go through the proxy. That should make the transmission container send the packet out of the VPN to a safe/local IP and then be forwarded to you. So getting the proxy up and running is key.

LOCAL_NETWORK does support multiple values though. Comma separated. Sou you can try that, but I'm not sure about the compatibility with UFW etc. Please report back what you try and how it works 😄

[jeanpaulrh]

Yes! Adding 10.8.1.0/24 to LOCAL_NETWORK did the trick!
No need for additional proxy container
Thanks.

[haugene]

@garret, any update? I'll close this soon if there is no more activity

[garret]

@haugene actually no. From my phone when is in 4G (not in my home wifi) I cannot access the transmission webui when giving 192.168.1.2:9091. This address works when my phone is connected to the home wifi. On the other side, if I give 192.168.1.2:8989 I can access for instance the sonarr web ui. So it looks like the docker container only is seen in the local network but is not touched by wireguard... My point is that I would really like to access the transmission web ui also when I am outside my home wifi but with wireguard to add a layer of security, instead of port-forwarding the ports.

[haugene]

Aha. Not familiar with wireguard, but googled it and it seems like another vpn service so I guess you're connecting into your home network with it. My guess then would be that you get an IP on another network when you connect through that VPN. So your client is no longer in the LOCAL_NETWORK range. LOCAL_NETWORK takes a comma separated list of addresses so you should add the VPN network as well.

Or there might be a routing step along the way here that is outside that IP range.
In any case, setting up the proxy solution described in the README should definitely work. And then you can play around more with the LOCAL_NETWORK stuff later to make that work.

Just keep in mind that any IP in the LOCAL_NETWORK range will not be routed through VPN. So don't set it too wide, it will be like disabling the VPN altogether.

[garret]

@haugene Yes I have thought about the proxy container solution but wanted to avoid it if was not necessary. In any case, you can mark this as solved then I guess 👍