Connecting to services outside of the host machine

[chazragg]

so my current setup has 5 containers running on my raspberry pi which are the following:

PIA
Sonarr
Radarr
Jackett
Qbittorrent

all the containers run their networking through the PIA container via Network_mode: "container:pia"

i am able to get these containers to talk to each other by referencing localhost(127.0.0.1) followed by the service port number but i am having trouble connecting them to services which are on other host devices

radarr and sonarr have a feature where is will tell plex to scan for a new episode/movie once sonarr has finished renaming/organizing the file. I run Plex from my nas drive but the containers have an issue connecting. is there some settings i can change to allow them to talk to other devices?

[qdm12]

That's an interesting point. I don't think there is an easy way out for this except through by using iptables to re-route traffic of a certain LAN IP address to your host eth0 interface and not the tun VPN interface. Try asking this on reddit.com/r/iptables they may be able to help us out.

On the other hand, you might be able to achieve what you want by exposing your plex server online (check out Caddy with Let's Encrypt https 👍) and telling your service to go talk to your Plex server at https://yourplexdomainname.com for example.

[chazragg]

so i managed to connect to to plex through my external IP address, thanks for the tip.

would be interesting to look into the Iptable options as it is something else to learn.

thanks for the help

[qdm12]

Be warned that accessing your Plex server through its public Ip address means the connection is unencrypted from your PIA VPN server Endpoint to your IP address. That's why https comes into play to encrypt the connection. I'll look for iptables to solve this but I'm quite busy unfortunately currently.

[qdm12]

I'll look into it. Have you tried using the EXTRA_SUBNETS environment variable with your LAN network? It should allow devices on the subnet to talk to each other.

[chazragg]

I'll have to look into it. I took my raspberry pis to work for a mini dev environment so it is currently not running my media server setup.

[jenil]

I'm also struggling with this. I have managed to allow LAN access to my services using EXTRA_SUBNETS=192.168.1.0/24 but I would like to allow WAN access to a few of the containers.

[qdm12]

Actually I noticed I have the same problem on other containers (i. e. alpine only or debian only) where I can't access other LAN devices. That is a Docker/LXC/Docker firewall issue, not related to this particular image. I will dig if I can find a way around it. That's a docker desktop issue, never mind.

I will dig into the issue.

[qdm12]

@jenil your issue is about #82 I think.

You want Internet -> services, while this issue is about PIA connected containers -> other LAN devices.

@chazragg I think it would need some additional routing but I'm not sure this is possible unfortunately. I'll keep this opened if one day I find a way.

[zkhcohen]

@qdm12 it's interesting... on Docker Desktop I can access the services behind the container using the host's IP, but I can't on the Debian distros I've tried.

If you run TCPTRACK on one of the containers behind the PIA shared-namespace, you can see that when you attempt to access the port from outside of the host, the originating IP is your IP (of course), but when you attempt to access it from the host itself, or any container on the bridge network (even using the host's IP), the incoming IP will always appear as the gateway of the pia_vpn bridge network. Most interestingly, the origin IP is ALWAYS the bridge gateway on Docker Desktop, regardless of where you're accessing the service from. It's also important to note that after it hits the container behind PIA, it never gets past "SYN".

It could be related to this in some way: docker/for-mac#180

Attempt to connect from another device on my test LAN:

Successful attempt to connect using the <host_ip>:<service_port> on another container:

I'm also struggling with this. I have managed to allow LAN access to my services using EXTRA_SUBNETS=192.168.1.0/24 but I would like to allow WAN access to a few of the containers.

This didn't resolve the issue for me, neither did disabling the firewall using the flag you created a few hours ago.

...I'm sort of stumped. The iptables are also identical between the Desktop and Linux versions. It truly seems like traffic just stops dead once it hits the service if the origin IP is anything other than the gateway address.

---

EDIT:

aha... ColinHebert/pia-openvpn#4

[qdm12]

Wait @zkhcohen sorry if I misunderstood you, but are you trying to make a container connected to gluetun (pia) access a service on another machine in your LAN (that's the topic of this issue)? Or are you trying something else? Because the issue you referenced seem to be something else, please open another issue if so. Thanks!

[zkhcohen]

Wait @zkhcohen sorry if I misunderstood you, but are you trying to make a container connected to gluetun (pia) access a service on another machine in your LAN (that's the topic of this issue)? Or are you trying something else? Because the issue you referenced seem to be something else, please open another issue if so. Thanks!

Sorry, to clarify, technically the 'service' on another machine in my LAN is just access to the web GUI of the service on the VPN container network, but you could easily extend this to inter-service communication in general.

See the README I just discovered here:
https://github.com/dperson/openvpn-client/

---

EDIT: The issue I referenced seems related in that the way that addresses are routed and how they appear to the containers of bridge networks seems fundamentally different in certain situations (OS in particular). I have noticed the same effect when investigating the LAN communication issues when using shared-namespaces. Unfortunately no one can seem to identify the cause.

[qdm12]

That is another irrelevant problem. This issue is about a connected container to reach another service on the physical lan. Although it may sound similar, inter service communication doesn't work that way because of vpn-ish routing-ish issues. Reaching a port of a container using the gluetun network stack is documented in the readme of the repo. Please create another issue describing your configuration (docker run, docker-compose etc.) so I can help you figure it out. Also Docker desktop on osx/windows uses a linux virtual machine with strange port forwarding, so that may be why it works... Thanks!

[qdm12]

(Just a note to future myself)

That might be possible adding an ip route of the LAN via the tunnel interface (tun0) instead of via the default interface (eth0),

If anyone feels like trying you could try running the container (as gluetun) and then, assuming you LAN is 192.168.1.0/24 and your default gateway 10.0.0.1 (see the logs to find it):

docker exec gluetun ip route add 192.168.1.0/24 via 10.0.0.1 dev tun0

Maybe the 10.0.0.1 should be changed to something else though, like the VPN gateway IP address (see the logs for that too).

[qdm12]

Hey guys, I think this is solved by using the FIREWALL_OUTBOUND_SUBNETS environment variable. Can any of you confirm your situation is solved with it? Thanks!

[qdm12]

I'll close for now until someone encounters the issue again.

[seb3point0]

I'm also trying to access gluetun services from WAN. Has anyone found a working solution for this?