TL;DR:
I am trying to install OpenVPN in a Debian 12.2-1 container (Template used: debian-12-standard_12.2-1_amd64.tar.zst).
Neither in an unprivileged (preferable) nor in a privileged container I am able to use the TUN adapter, no matter what I try.
Update 1 (see at the bottom of this too long post):
AppArmor may possibly be preventing TUN to be exposed to the container.
Disabling AppArmor is not a solution, so I'm still figuring out how to only expose TUN while keeping the rest of AppArmor's security in place.
Any help or advice is very welcome as I am not familiar with that part - yet.
Background
Following the tips in https://pve.proxmox.com/wiki/OpenVPN_in_LXC did not resolve the issue and imho this formerly fabulous tutorial now
slowly seems to become outdated (i.e. the referenced Debian version debian-10-standard_10.7-1_amd64.tar.gz can no longer be downloaded as a template.
Nevertheless, I tried using as much valuable info as possible from that tutorial, but to no avail.
Host specifications
CPU(s) 2 x Pentium(R) Dual-Core CPU T4200 @ 2.00GHz (1 Socket)
RAM usage 30.81% (1.17 GiB of 3.78 GiB) / SWAP usage 0.01% (524.00 KiB of 4.00 GiB)
/ HD space 5.83% (4.86 GiB of 83.38 GiB)
Proxmox Virtual Environment 8.1.3
Kernel Version Linux 6.5.11-4-pve
Current LXC Container specifications
Unprivileged: yes
Nesting: yes (read somewhere it might help with getting the TUN to work in the container)
Template: debian-12-standard_12.2-1_amd64.tar.zst
Firewall: disabled (for now, during testing)
IPv4: 10.x.x.x/8
DNS doman & servers: use host settings
Before starting the above container, I entered the host's Shell to adjust the config file of the container:
and added the following 2 lines at the end - as recommended at several online sources:
So that my complete 100.conf file looks like this:
X = confiscated info
I verified that the TUN device is present with sufficient permissions at the Proxmost host:
Unfortunately, when starting the container and checking its devices /dev/net/tun is still missing (/dev/net is missing, to be precise):
Any help would be greatly appreciated.
I miss my bed and cannot afford more keyboard replacements to smash my head on.
Update:
It seems that AppArmor is preventing tun to be exposed to the container.
I temporarily disabled AppArmor to exclude it and lo and behold: I am now able to see /dev/net/tun in my container.
Command used to temporarily disable AppArmor
Warning:
If you are new to this, DO NOT CONSIDER THIS A SOLUTION!
Disabling AppArmor is as unsafe as keeping your car open with a sign next to it, saying "Please don't steal my car".
If you decide to run the same test, then immediately re-enable it once you are done testing, using the command:
Update 2:
Sharing an interesting observation, just in case it helps someone else:
I re-enabled AppArmor and even rebooted the Proxmost host, but /dev/net/tun now stayed visible in the container (caching? propagation? bug?).
Even after deleting this container and creating a complete new one, /dev/net/tun appeared immediately after the first boot.
Just for future-proofing, I will still create a custom AppArmor profile for this container, that allows tun to be exposed.
After this I will include the custom profile in the container's .conf file, to make sure that /dev/net/tun will stay visible in the future, in case some update causes it to stop working otherwise.
It seems that disabling and enabling AppArmor triggered something to start working that did not work as intended before.
Can a Proxmox dev perhaps shine some light on this?
I am trying to install OpenVPN in a Debian 12.2-1 container (Template used: debian-12-standard_12.2-1_amd64.tar.zst).
Neither in an unprivileged (preferable) nor in a privileged container I am able to use the TUN adapter, no matter what I try.
Update 1 (see at the bottom of this too long post):
AppArmor may possibly be preventing TUN to be exposed to the container.
Disabling AppArmor is not a solution, so I'm still figuring out how to only expose TUN while keeping the rest of AppArmor's security in place.
Any help or advice is very welcome as I am not familiar with that part - yet.
Background
Following the tips in https://pve.proxmox.com/wiki/OpenVPN_in_LXC did not resolve the issue and imho this formerly fabulous tutorial now
slowly seems to become outdated (i.e. the referenced Debian version debian-10-standard_10.7-1_amd64.tar.gz can no longer be downloaded as a template.
Nevertheless, I tried using as much valuable info as possible from that tutorial, but to no avail.
Host specifications
CPU(s) 2 x Pentium(R) Dual-Core CPU T4200 @ 2.00GHz (1 Socket)
RAM usage 30.81% (1.17 GiB of 3.78 GiB) / SWAP usage 0.01% (524.00 KiB of 4.00 GiB)
/ HD space 5.83% (4.86 GiB of 83.38 GiB)
Proxmox Virtual Environment 8.1.3
Kernel Version Linux 6.5.11-4-pve
Current LXC Container specifications
Unprivileged: yes
Nesting: yes (read somewhere it might help with getting the TUN to work in the container)
Template: debian-12-standard_12.2-1_amd64.tar.zst
Firewall: disabled (for now, during testing)
IPv4: 10.x.x.x/8
DNS doman & servers: use host settings
Before starting the above container, I entered the host's Shell to adjust the config file of the container:
Bash:
nano /etc/pve/lxc/100.confand added the following 2 lines at the end - as recommended at several online sources:
Code:
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net dev/net none bind,create=dirSo that my complete 100.conf file looks like this:
Code:
arch: amd64
cores: 1
hostname: XXXXXX
memory: 1024
net0: name=eth0,bridge=vmbr0,gw=10.X.X.X,hwaddr=XX:XX:XX:XX:XX:XX,ip=10.X.X.X/8,type=veth
ostype: debian
rootfs: local-lvm:vm-100-disk-0,mountoptions=lazytime,size=15G
swap: 1024
unprivileged: 1
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net dev/net none bind,create=dirI verified that the TUN device is present with sufficient permissions at the Proxmost host:
Bash:
root@XXXXXX:/# ls -l /dev/net/tun
crw-rw-rw- 1 100000 100000 10, 200 Nov 24 21:25 /dev/net/tunUnfortunately, when starting the container and checking its devices /dev/net/tun is still missing (/dev/net is missing, to be precise):
Bash:
root@XXXXXX:/dev# ls
console fd initctl mqueue null pts shm stdin tty tty2 zero
core full log net ptmx random stderr stdout tty1 urandomAny help would be greatly appreciated.
I miss my bed and cannot afford more keyboard replacements to smash my head on.
Update:
It seems that AppArmor is preventing tun to be exposed to the container.
I temporarily disabled AppArmor to exclude it and lo and behold: I am now able to see /dev/net/tun in my container.
Command used to temporarily disable AppArmor
Bash:
sudo systemctl stop apparmorWarning:
If you are new to this, DO NOT CONSIDER THIS A SOLUTION!
Disabling AppArmor is as unsafe as keeping your car open with a sign next to it, saying "Please don't steal my car".
If you decide to run the same test, then immediately re-enable it once you are done testing, using the command:
Bash:
sudo systemctl start apparmorUpdate 2:
Sharing an interesting observation, just in case it helps someone else:
I re-enabled AppArmor and even rebooted the Proxmost host, but /dev/net/tun now stayed visible in the container (caching? propagation? bug?).
Even after deleting this container and creating a complete new one, /dev/net/tun appeared immediately after the first boot.
Just for future-proofing, I will still create a custom AppArmor profile for this container, that allows tun to be exposed.
After this I will include the custom profile in the container's .conf file, to make sure that /dev/net/tun will stay visible in the future, in case some update causes it to stop working otherwise.
It seems that disabling and enabling AppArmor triggered something to start working that did not work as intended before.
Can a Proxmox dev perhaps shine some light on this?
Last edited:
