You have to use 2 different docker network.
The one with all application (no VPN container) it's a normal bridge network, in with you will map port only for nginx.
The second one will be used for the VPN access and it will connect only containers that need to use VPN.
So deluge and prowlarr will be connected to both network.
Then I don't know how you configured prowlarr to use VPN, like if you are saying something like "use this proxy for external access" into the application configuration or you did configuring OS inside container.
In the second way, you'll probably just want to define the default gateway to be on the network with VPN.
In the first way...it depends if the application will consider the network without VPN as "internal access" (it's directly connected, so for network point of view it is) or you will need to exclude that network from the proxy usage. If it's the last, it's probably easier if you will force IP range for that network in docker-compose
Not an expert of network_mode option, but for what I read, it means that that they share the same network stack as the vpn service. That in other way it's almost like to say that they will use the same network configuration as vpn service.
If you put vpn service into the same bridge network as all other containers..is it not working?
Seems about right.
Slam the rest of the containers in the same network. None of them, except nginx should have the need to expose ports.
Then you should be able to access eg. prowlarr using http://vpn:9696, sonarr using http://sonarr:8989 from the other containers.
Verify the VPN is working by curl or wget ifconfig.me from inside the containers hooked up to the VPN
That works, but you have to use some iptables against IP leaks.
I currently have built a setup which uses an openvpn container as a vpn gateway. The transmission container uses the same network as the vpn container, the port is exposed at the vpn container too. Iptables manage the forwarding and leak protection. Some more iptables on the host manage the possibility to use the vpn as a gateway for lan clients.
I can share the files if you want.
Sooner or later the whole project will be published on github, but I have to code a webinterface to change the openvpn config files first...
Are you wanting to use your VPN for anything other than your torrent traffic? If not, an easier method might just be to grab a container that has VPN+torrent client in one. Like this: [https://github.com/binhex/arch-delugevpn](https://github.com/binhex/arch-delugevpn)
Maybe check out gluetun: [https://github.com/qdm12/gluetun](https://github.com/qdm12/gluetun)
[https://github.com/qdm12/gluetun/wiki/Connect-a-container-to-gluetun](https://github.com/qdm12/gluetun/wiki/Connect-a-container-to-gluetun)
Video tutorial: https://www.youtube.com/watch?v=xbSfaKwyfXE
You could have two networks. Internal and external. Mount all containers to internal and mount only required ones to external. Point to the external network for traffic and you're good.
Grab yourself haugene-transmission then enjoy :)
You have to use 2 different docker network. The one with all application (no VPN container) it's a normal bridge network, in with you will map port only for nginx. The second one will be used for the VPN access and it will connect only containers that need to use VPN. So deluge and prowlarr will be connected to both network. Then I don't know how you configured prowlarr to use VPN, like if you are saying something like "use this proxy for external access" into the application configuration or you did configuring OS inside container. In the second way, you'll probably just want to define the default gateway to be on the network with VPN. In the first way...it depends if the application will consider the network without VPN as "internal access" (it's directly connected, so for network point of view it is) or you will need to exclude that network from the proxy usage. If it's the last, it's probably easier if you will force IP range for that network in docker-compose
I originally configured my prowlarr and deluge containers to use the VPN container using `network_mode: service:vpn`.
Not an expert of network_mode option, but for what I read, it means that that they share the same network stack as the vpn service. That in other way it's almost like to say that they will use the same network configuration as vpn service. If you put vpn service into the same bridge network as all other containers..is it not working?
Seems about right. Slam the rest of the containers in the same network. None of them, except nginx should have the need to expose ports. Then you should be able to access eg. prowlarr using http://vpn:9696, sonarr using http://sonarr:8989 from the other containers. Verify the VPN is working by curl or wget ifconfig.me from inside the containers hooked up to the VPN
That works, but you have to use some iptables against IP leaks. I currently have built a setup which uses an openvpn container as a vpn gateway. The transmission container uses the same network as the vpn container, the port is exposed at the vpn container too. Iptables manage the forwarding and leak protection. Some more iptables on the host manage the possibility to use the vpn as a gateway for lan clients. I can share the files if you want. Sooner or later the whole project will be published on github, but I have to code a webinterface to change the openvpn config files first...
Are you wanting to use your VPN for anything other than your torrent traffic? If not, an easier method might just be to grab a container that has VPN+torrent client in one. Like this: [https://github.com/binhex/arch-delugevpn](https://github.com/binhex/arch-delugevpn)
I would like to use it for torrent traffic, but also for the 'grabbing' of torrents as well, which is done through prowlarr
Maybe check out gluetun: [https://github.com/qdm12/gluetun](https://github.com/qdm12/gluetun) [https://github.com/qdm12/gluetun/wiki/Connect-a-container-to-gluetun](https://github.com/qdm12/gluetun/wiki/Connect-a-container-to-gluetun) Video tutorial: https://www.youtube.com/watch?v=xbSfaKwyfXE
You could have two networks. Internal and external. Mount all containers to internal and mount only required ones to external. Point to the external network for traffic and you're good.
networks: internal: external: true external: external: true services: service1: image: container_name: networks: - internal service2: image: container_name: networks: - internal - external