Route outgoing traffic of a docker bridge network through VPN

Comments

• BruisedMoose@piefed.social ⁨1⁩ ⁨day⁩ ago

  First off, take this for what it is: a guy who can follow instructions but does not understand all the inner workings of docker.

  I use Gluetun and have a set of apps that I run through it. They are all in the same compose file. Each of the ports is defined in the Gluetun section and not with the individual app. Then each app’s network_mode is set to service:gluetun

  This routes all the traffic for those apps through the VPN while maintaining my regular network for everything else.

  source

  • BakedCatboy@lemmy.ml ⁨1⁩ ⁨day⁩ ago

    I second this. Gluetun makes it so easy, working with docker’s internal networking is such a pain.

    source
  • theunknownmuncher@lemmy.world ⁨1⁩ ⁨day⁩ ago

    Yep, this is exactly what I do.

    source
  • d00phy@lemmy.world ⁨1⁩ ⁨day⁩ ago

    This was my thought as well. Anything by that requires VPN is added to that stack and if I can bind it to the “tun” device I do - but the container requires gluten to be up.

    source

    • d00phy@lemmy.world ⁨1⁩ ⁨day⁩ ago

      So I got back to my server, and here’s what I do:

      gluetun settings:

      services:
        gluetun:
      *snip*
          ports:
      *snip*
            - 8090:8090 # port for qbittorrent
      *snip*
      

      qbittorrent (in the same compose.yml):

        qbittorrent:
          image: linuxserver/qbittorrent:latest
          container_name: qbittorrent
          environment:
      *snip*
            - WEBUI_PORT=8090
      *snip*
          network_mode: service:gluetun # run on the vpn network
          depends_on:
            gluetun:
              condition: service_healthy
      *snip*
      

      Also, in qbittorrent settings you can bind it to a network device. In my case it’s “tun0.” This same thing can probably be done w/ a docker network in a gluetun container and separate containers that rely on that network being up, but I haven’t looked into it. Right now, I have 2 other services that require VPN, and I’m looking at possibly 1 or 2 more. That’s pretty manageable as a single stack, I think.

      source
  • xana@lemmy.zip ⁨1⁩ ⁨day⁩ ago

    Thank you very much for your reply but this is not really what I need. Please see the edit for more context :D

    source
• moonpiedumplings@programming.dev ⁨22⁩ ⁨hours⁩ ago

  Yes, this is where docker’s limitations begin to show, and people begin looking at tools like Kubernetes, for things like advanced, granular control over the flow of network traffic.

  Because such a thing is basically impossible in Docker AFAIK. You’re getting these responses (and in general, responses like those you are seeing) appear when the thing a user is attempting to do is anywhere from significantly non trivial to basically impossible.

  An easy way around this, if you still want to use Docker, is addressing the below bit, directly:

  no isolation anymore, i.e qbit could access (or at least ping) to linkwarden’s database since they are all in the same VPN network.

  As long as you have changed the default passwords for the databases and services, and kept the services up to date, it should not be a concern that the services have network level access to eachother, as without the ability to authenticate or exploit eachother, there is nothing that they can do, and there are no concerns.

  If you insist on trying to get some level of network isolation between services, while continuing to use Docker, your only real option is iptables* rules. This is where things would get very painful, because iptables rules have no persistence by default, and they are kind of a mess to deal with. Also, docker implements their own iptables setup, instead of using standard ones, which result in weird setups like Docker containers bypassing the firewall when they expose ports.

  You will need a fairly good understanding of iptables in order to do this. In addition to this, if you decide this in advance, I will warn you that you cannot create iptables rules based on ip addresses, as the ip addresses of docker containers are ephemeral and change, you must create rules based on the hostnames of containers, which adds further complexity as opposed to just blocking by ip.

  A good place to start is here. You probably don’t know what a lot of the terminology here is. You will have to spend a lot of time learning all of it, and more. Perhaps you have better things to do with your time?

  *Um, 🤓 ackshually it’s nftables, but the iptables-nft command offers a transparent compatibility layer enabling easier migrations from the older and no longer used iptables

  source

  • xana@lemmy.zip ⁨12⁩ ⁨hours⁩ ago

    Thank you very much for your response!

    source
• KaninchenSpeed@lemmy.blahaj.zone ⁨1⁩ ⁨day⁩ ago

  I’ve never used network manager on a server and don’t understand your routing configuration, im assuming you have wg0 configured to have a default route (ip route list).

  You should be able to connect a docker network to the vpn by using a macvlan insted of a bridge type network and set the parent interface of it to the wg0 interface.

  docker network create -d macvlan \ --subnet=<internal vpn network>/24 \ --gateway=<gateway ip> \ -o parent=wg0 vpn-net
  

  modified from the docker documentation

  Make sure the allowed ips in the wireguard configs are set correctly.

  You can also do ipv6 like this, see the end of the linked documentation page.

  source

  • xana@lemmy.zip ⁨1⁩ ⁨day⁩ ago

    Thank you very much for your reply but this is not really what I need. Please see the edit for more context :D

    source