search

qdm12 / gluetun

VPN client in a thin Docker container for multiple VPN providers, written in Go, and using OpenVPN or Wireguard, DNS over TLS, with a few proxy servers built-in.
https://hub.docker.com/r/qmcgaw/gluetun
MIT License
7.43k stars 350 forks source link

Allow an outgoing connection to a specific ip:port on LAN #1909

Open stickermajom opened 11 months ago

stickermajom commented 11 months ago

Discussed in https://github.com/qdm12/gluetun/discussions/1884

Originally posted by **stickermajom** September 26, 2023 I'd like to allow qBittorrent to talk to an API on my local home network. Currently I'm using FIREWALL_OUTBOUND_SUBNETS=xxx.xxx.xxx.xxx/32 environment variable with the endpoints IP to achieve this, but it's overkill, and don't really like it from a security perspective. I've seen firewall.md mentioning /iptables/post-rules.txt as a way to open incoming ports, so probably I could use it for outgoing as well, but I assume IP routing would still be a problem. I don't want to put the API behind VPN, so using gluetun's network is not an option.

For security reasons can you implement an environment variable FIREWALL_OUTBOUND_0_PORTFORWARD=ipaddress:port to allow portforwarding and routing to a specific ip/port on LAN?

NadirBourazza commented 11 months ago

I've been attempting to do a similar thing today, however I haven't had any luck setting an outbound ip/port specifically via iptables, so I would love this.

qdm12 commented 11 months ago

I don't want to put the API behind VPN, so using gluetun's network is not an option.

You can have it in the same Docker (bridge) network as Gluetun, and it won't go through the VPN, but it will be reachable from Gluetun/Qbittorrent (by container IP address though). That way no need to set FIREWALL_OUTBOUND_SUBNETS as well (the Gluetun local Docker network is allowed to communicate by default).

From the top of my head, FIREWALL_OUTBOUND_SUBNETS does some routing changes, which isn't possible by ip_address:port but only by ip address, so I would rather keep it as it is.

NadirBourazza commented 11 months ago

Yeah, I think that would work. In my specific instance I had a container with overseerr (going through Gluetun) that I wanted to connect to Plex.

Only problem is my Plex was setup before I started to use Docker so it’s not on the same network, so I had to utilise FIREWALL_OUTBOUND_SUBNETS, which isn’t ideal.

I could move my Plex to Docker, but that’s at least the reason why it would be nice to specify one IP Address/port rather than opening them all up. It would mean that Plex doesn’t need to be on the docker bridge network.

stickermajom commented 11 months ago

In my case that one API I'm accessing from within gluetun is just the tip of an iceberg, that container is tied to several others, so that would mean I'd need to put all of them behind gluetun's network. That would introduce a lot of operational risks depending on one container, hence I'd still favor the ip:port solution if it's possible.