Proxmox setup for OpenVPN and Wireguard

[bnhf]

Mostly good news here, which is that Gluetun can be setup in a Proxmox LXC container using either OpenVPN or Wireguard.

For those familiar with Proxmox, it's the typical steps of creating a container with the latest Debian template (recommended). Before you start the container follow the tweaks in this guide from Proxmox (just those from the attached image if you're using the Proxmox WebUI for everything else). Substitute your container ID for the "123" used in the example:

https://pve.proxmox.com/wiki/OpenVPN_in_LXC

Then you'll need to install Docker for sure, but if you're like me you'll want to add a few other favorites (Portainer, Cockpit, Cockpit-Navigator and Organizr in my case). You might want to turn this container into a template at this point for future similar projects, and continue on with a clone.

Your standard Gluetun Stack should work, with the addition of (assuming you don't normally use it):

    devices:
      - /dev/net/tun:/dev/net/tun

Performance is excellent with OpenVPN as it uses the kernelspace implementation. Wireguard is good too, though for some reason it falls back to the userspace version of Wireguard. Which brings me to my question:

Anybody figured out how to get Wireguard to use its kernelspace capability with a Proxmox setup like this?

Pretty similar OpenVPN performance to what I see using Docker running on a bare metal install of Debian:

[dhenry437]

Pretty much the same set up as you, although no idea whether Wireguard is failing back to the userspace version (don't know how to check). But I am getting slightly faster speeds compared to baseline with OpenVPN. Is this due to kernel vs userspace? From what I've read I thought it was meant to be the other way around?

[chenks]

@bnhf @dhenry437 just followed your instructions and the gluetun container is still failing to create with the error error gathering device information while adding custom device "/dev/net/tun": no such file or directory

i added this to the conf file

lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net /dev/net none bind,create=dir

and this is the permissions check

root@proxmox:~# ls -l /dev/net/tun
crw-rw-rw- 1 root root 10, 200 May 21 13:07 /dev/net/tun

any ideas? proxmox 8.2.2 with the LXC being a deb12 template.

[dhenry437]

From the Gluetun wiki the bit added to the conf file should be:

lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net dev/net none bind,create=dir
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file

But I do remember getting an error along those lines and not having

devices:
  - /dev/net/tun:/dev/net/tun

in the docker-compose was the issue.

Although even after getting this set up and working, I found the speed in qBit was fluctuating a lot. So I've since switched to hotio's qBit container that has VPN built in. Much easier to set up and more stable for me. I don't know what you're using this for but if its qBit you could try that.

[chenks]

i route a few things thru gluetun, so not just qbittorrent

i already have this in the docker-compose file

devices:
  - /dev/net/tun:/dev/net/tun

i was following the screenshot in the original so wasn't aware that lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file wa also required, i will try that now.

[chenks]

this is now working, was that missing line in the conf

[anton-dealmeida]

Thanks a lot for this thread!

[robinwo]

Once this is up & running, any idea how to route traffic from other LXC through this container?

So imagine.. we have:

• LXC-A = 192.168.2.1
• LXC-B = 192.168.2.2

Gluetun runs in a docker container on LXC-A, and on LXC-B there's a couple more containers running we want to tunnel through Gluetun on LXC-A. Is this possible?

I have two options in mind:

• On LXC-A run the Gluetun container in networking_mode: "host". Then on LXC-B set networking gateway to LXC-A, and on LXC-A set iptables to tunnel all traffic from LXC-B over the tun0 interface (available on the LXC host since running on host mode).
• Rather than setting networking_mode: "host", keep this detached, and use iptables on on LXC-A to tunnel all traffic from LXC-B to the internal IP of the docker container. Probably needs some more iptables config within the container to make this work?

What are your thoughts / recommendations on this? Any vulnerabilities this approach might introduce? Tips welcome, also if you've done this before what firewall rules did you apply to make this work?

[66gmc1000]

I have been running docker inside of quite a few LXC containers and use this flag in the ones i want to route, Possibly could help you brainstorm

services:
gluetun:
image: qmcgaw/gluetun
container_name: gluetun
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
environment:
- VPN_SERVICE_PROVIDER=mullvad
- VPN_TYPE=wireguard
- WIREGUARD_PRIVATE_KEY=
- WIREGUARD_ADDRESSES=
- SERVER_CITIES=
- FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24
ports:
- 9003:8112 #app 1
- 9004:8080 #app 2
- 6881:6881 #app 3
- 6881:6881/udp #app 3
networks:
- mediastack-net

sabnzbd:
image: lscr.io/linuxserver/sabnzbd:latest
container_name: sabnzbd
depends_on:
- gluetun
network_mode: "service:gluetun"
environment:
- PUID=1000
- PGID=1000
- TZ=America/Los_Angeles
volumes:
- /opt/docker-data/sabnzbd/config:/config
- /opt/docker-data/media_download_data:/downloads #optional
- /opt/docker-data/media_download_data-incomplete:/incomplete-downloads #optio
restart: unless-stopped

networks:
mediastack-net:

[famewolf]

I'm currently using gluetun with about 10 dependent containers via a big docker compose in a dietpi vm on proxmox however since proxmox gives each service it's own ip and/or you can use caddy to set up local lan aliases like "https://qbitttorrent.lan" (without a domain for all those who keep saying it can't be done) it might be a simpler process to setup wireguard on your router along with a vlan or ip based rules that direct all traffic from a specific ip to use the vpn. If you don't want the containers using anything but the vpn and not to leak when the vpn is down then don't let them communicae any way but through the vpn.

The gluetun process works but I had to write a script to manage rebuilding the setup when I want to change endpoints and have the dependent containers wait on gluetun to be healthy. I've also had issues with qbittorrent just stopping working and the DHT nodes dropping to zero. A scheduled crontab that was restarting qbittorrent every 3 hours seemed to somewhat resolve the issue and none of the other containers had a similar issue so I'm certain it's qbittorrent specific.

./manage-gluetun.sh rebuild_all Berlin-GE
[2025-12-06 10:59:50] Using override file: docker-compose.Berlin-GE.yml
[2025-12-06 10:59:50] Rebuilding Gluetun and dependents for city: Berlin-GE
[+] down 12/12
✔ Container deunhealth Removed 0.5s
✔ Container gluetun-readarr Removed 0.3s
✔ Container gluetun-prowlarr Removed 0.3s
✔ Container gluetun-qbittorrent Removed 0.3s
✔ Container gluetun-sabnzbd Removed 0.3s
✔ Container gluetun-easynewsindexer Removed 0.2s
✔ Container gluetun-nzbhydra2 Removed 0.3s
✔ Container gluetun-flaresolverr Removed 0.3s
✔ Container gluetun-radarr Removed 0.3s
✔ Container gluetun-sonarr Removed 0.3s
[2025-12-06 10:59:53] Containers brought down. 0.3s
[+] up 1/1er gluetun Stopping 1.7s
[2025-12-06 10:59:53] Waiting for Gluetun to become healthy... 0.1s
[2025-12-06 10:59:54] Still waiting...
[2025-12-06 10:59:59] Still waiting...
[2025-12-06 11:00:04] Gluetun is healthy.
[+] up 12/12
✔ Container deunhealth Created 1.8s
✔ Container gluetun Healthy 3.5s
✔ Container gluetun-sonarr Created 2.6s
✔ Container gluetun-nzbhydra2 Created 2.8s
✔ Container gluetun-readarr Created 3.0s
✔ Container gluetun-sabnzbd Created 2.8s
✔ Container gluetun-radarr Created 3.0s
✔ Container gluetun-lidarr Created 2.8s
✔ Container gluetun-prowlarr Created 2.8s
✔ Container gluetun-easynewsindexer Created 2.6s
✔ Container gluetun-qbittorrent Created 3.0s
✔ Container gluetun-flaresolverr Created 3.0s
[2025-12-06 11:00:13] Rebuild completed.