-
|
Hi! I've been spending the last few evenings testing out Gluetun. I have a media stack (qbittorrent, *arr, jellyfin) where each service have their own docker container. My goal have been to have a Gluetun container with Mullvad which I then could use as a proxy for other containers. My issue right now is that my qbittorrent container cannot resolve hostname of trackers while connected to Gluetuns HTTP proxy. As described in the logs (see very bottom), the request fails as the hostname cannot be found: Disabling the proxy will resolve tracker hostnames without issue, but this is not a good solution. I've tried multiple setups during these last few days and so far none of them have worked:
Anyone got a clue to what might be the culprit? Any pointers are greatly appreciated. EnvironmentHost OS - Ubuntu Server 22.04 LTS Configversion: "3"
services:
gluetun:
container_name: gluetun
image: qmcgaw/gluetun
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
ports:
- 8888:8888/tcp # HTTP proxy
- 8388:8388/tcp # Shadowsocks
- 8388:8388/udp # Shadowsocks
volumes:
- ./data:/gluetun
environment:
- VPN_SERVICE_PROVIDER=mullvad
- VPN_TYPE=openvpn
- OPENVPN_USER=[redacted]
- SERVER_CITIES=Stockholm
- TZ=Europe/Stockholm
- HTTPPROXY=on
- FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24
- DOT=off
restart: always
networks:
default:
name: boulderLogs |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
|
The way you're trying to utilize Gluetun from other containers, via http proxy, is not the typical approach. Maybe you have specific reasons for wanting to do it this way, but just in case you don't, a more standard stack would look something like this: version: "3"
services:
gluetun:
image: qmcgaw/gluetun:latest
container_name: gluetun
cap_add:
- NET_ADMIN
ports:
- 8080:8080 # qBittorrent webui
- 6881:6881 # qBittorrent listening port
- 6881:6881/udp # qBittorrent listening port/udp
environment:
- VPN_SERVICE_PROVIDER=perfect privacy
- OPENVPN_USER=abc
- OPENVPN_PASSWORD=abc
- OPENVPN_CITIES=Amsterdam
- FIREWALL_VPN_INPUT_PORTS=6881
- PUID=1000
- PGID=1000
- TZ=Europe/Amsterdam
volumes:
- /data/openvpn:/gluetun
qbittorrent:
image: lscr.io/linuxserver/qbittorrent:latest
container_name: qbittorrent
environment:
- PUID=1000
- PGID=1000
- TZ=Europe/Amsterdam
- DELUGE_LOGLEVEL=error
volumes:
- /data/qbittorrent:/config # Change to your desired config directory mapping
- ~/Downloads/complete:/downloads # Change to your desired download data directory
network_mode: 'service:gluetun'
depends_on:
- gluetunThis sets up your dependent containers to use the Gluetun container as the one and only path to the Internet. Add any other container you want to the stack, with the ports you want published for those containers added to the list of ports for the Gluetun container. |
Beta Was this translation helpful? Give feedback.
-
|
Hi bnhf! I've actually seen one of your Gluetun stacks in a previous thread, it's great but not quite what I'm looking for at the moment. From what I can gauge from your profile and previous replies in this repository, you seem to know a thing or two about network structures and practices. As I continue to debug this issue, do you have any suggestions or advice that might be applicable? |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I just wanted to give this an update: I did not manage to make my desired HTTP proxy setup work as intended. Inter-container connection worked without issue, but tracker resolution for the qBittorrent container was not possible. I have resorted to running qBittorrent as a dependency to gluetun as suggested by @bnhf. Trackers, both HTTP and UDP, now resolves without major issues. My version: "3"
services:
gluetun:
image: qmcgaw/gluetun:latest
container_name: gluetun
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
ports:
- 8080:8080 # qBittorrent Web UI
- 6881:6881 # qBittorrent
- 6881:6881/udp # qBittorrent
- 8888:8888/tcp # HTTP proxy
- 8388:8388/tcp # Shadowsocks
- 8388:8388/udp # Shadowsocks
environment:
- VPN_SERVICE_PROVIDER=mullvad
- VPN_TYPE=wireguard
- WIREGUARD_PRIVATE_KEY=<private-key>
- WIREGUARD_ADDRESSES=<wireguard-addresses>/32
- FIREWALL_VPN_INPUT_PORTS=<mullvad-forwarded-port>
- SERVER_CITIES=<server-cities>
- TZ=Europe/Stockholm
- HTTPPROXY=on
- HTTPPROXY_STEALTH=on
- FIREWALL_OUTBOUND_SUBNETS=<local-ip-subnet>/24
- DOT=off
volumes:
- ./gluetun:/gluetun
qbittorrent:
image: lscr.io/linuxserver/qbittorrent:latest
container_name: qbittorrent
environment:
- PUID=1000
- PGID=1000
- TZ=Europe/Stockholm
- WEBUI_PORT=8080
volumes:
- ./qbittorrent:/config
- /library/torrents:/library/torrents
network_mode: 'service:gluetun'
depends_on:
- gluetun
networks:
default:
name: <network-name> |
Beta Was this translation helpful? Give feedback.
-
|
@Stylback This is the approach that I'm also currently trying to get to work. I have 3 containers in the gluetun network. Jackett, radarr and qBittorrent. They all individually have external access through the gluetun. However inter-container communication is making me loose my hair. Jackett cannot talk with radarr at all, even though I have the ports mapped per the gluetun documentation. Have you encountered this issue, or do you not have radarr / sonarr setup running? |
Beta Was this translation helpful? Give feedback.
-
|
I wish I could help, but I actually dropped HTTP-proxy altogether a couple of months after my first post due to constant breakage. I do have sonarr/radarr in my setup, if you want to make an attempt without the proxy you can take a look at my compose templates here. Do note that I haven't made updates in a while as I'm doing an overhaul, but most setting should still apply. |
Beta Was this translation helpful? Give feedback.
@Stylback
The way you're trying to utilize Gluetun from other containers, via http proxy, is not the typical approach. Maybe you have specific reasons for wanting to do it this way, but just in case you don't, a more standard stack would look something like this: