Bridge network of gluetun safe?

[iluvatyr]

Hello,
thank you for your amazing app first of all.

##Edit: or is the correct way to do this to join the reverse proxy container into the gluetun container network and then inside the reverse proxy point to the containername gluetun and the port of the container that is connected to gluetun instead of the actual containers name?

I have a question regarding the use of a bridge network with the gluetun container.
Lets say I have some containers that use gluetuns network via "network-mode: gluetun and I publish the ports to the host so that other containers that are not in this network can access those containers.

E.g. I have a IRC Client that I connect to the internet via gluetun. Then I have a reverse proxy container to the irc-client to access it. The port of the irc client is published in gluetun. That way I can access the irc client normally and it connects to the internet via gluetun.

But instead of publishing those ports, would it be possible (and safe in the sense that there is no possibility of leaking the IP or else) of bridging the gluetun container with another network so that I can connect containers to each other?.

Since I set the "network-mode" on the containers that should be connected to gluetun, I cannot set custom networks for that container. It has to be set on gluetun container. I would then make a new network called : bridge_network and add gluetun and the reverse proxy to it so the gluetun docker-compose.yaml would look like this:

version: '3.8'
services:
  gluetun:
    image: qmcgaw/gluetun
    container_name: gluetun
    environment:
      - PUID=998
      - PGID=100
      - VPNSP=VPNPROVIDER
      - OPENVPN_VERBOSITY=3
    volumes:
      - /srv/Config/Gluetun/:/gluetun
    ports:
      - 9001:9000 #IRCCLIENT
    cap_add:
      - NET_ADMIN
    secrets:
      - openvpn_user
      - openvpn_password
    restart: unless-stopped
    networks:
        - default
        - bridge_network


networks:
    bridge_network:
        external: true

I would also add the Reverse proxy container to that network in the same way so I can point to the container name instead of the host IP. Would it be possible that the IRC client exposes my real ip that way? Is the question clear?

[qdm12]

would it be possible (and safe in the sense that there is no possibility of leaking the IP or else) of bridging the gluetun container with another network so that I can connect containers to each other?

That's exactly what I do! So I have the same Docker network for my main reverse proxy and gluetun, so that I can access an app someapp connected to gluetun at https://mydomain.com/someapp. That way you don't even need to publish ports on gluetun, although having them as expose helps documentation-wise 😉

And no it would not leak anything, although maybe your someapp could be aware of the client IP address you are accessing it through. But all the outbound traffic would still go through gluetun.

[FunctionDJ]

@qdm12 I've read the documentation about expose but after reading other online articles that also cover EXPOSE in the Dockerfile, i'm confused if expose is truly for documentation purposes only or if it actually has an effect (assuming the container has already EXPOSEd it's relevant ports through the Dockerfile).

So is it truly idiot-proof to always add expose to a docker-compose.yaml for documentation purposes, or could it potentially create new network communication paths (i.e. 'risks')?

[qdm12]

It's only for documentation purposes. Even if it wouldn't be, the container would need some listener on the port 'exposed' and for gluetun, there is the firewall filtering inbound traffic (except from local docker network). You can dig in https://github.com/moby/moby/search?l=Go&p=3&q=ExposedPorts but I'm on my phone right now and it's also cumbersome to proof something doesn't exist 😸

[FunctionDJ]

@qdm12 I understand. I wasn't trying to be sceptic, i was just interested and a bit confused by the resources online. Thank you for your reply! :)

[qdm12]

No worry 😉 Better skeptic than blind 😸

More information on https://www.geeksforgeeks.org/docker-expose-instruction/

It is also important to understand that the EXPOSE instruction only acts as an information platform (like Documentation) between the creator of the Docker image and the individual running the Container.

In Gluetun, it's already set in the Dockerfile here for documentation if someone inspects the docker image really.

For docker-compose it's really for you to remember what ports are available, but you don't want to publish them on the host with ports:, since expose: and ports: conflict I recall. I personally use expose: to document ports that can be accessed from other containers in the same docker network, but that I don't want publish on the host. I also use custom firewall rules with the DOCKER_USER chain of rules to restrict communication between containers and coming out of containers, but that's a pain in the ass to implement and maintain so I wouldn't recommend 😄