Closed austinulmer closed 2 years ago
You might need to give more permissive privileges to the container if you want to run the daemon from within a container, however the daemon wasn't designed to run from within a container. The daemon itself needs access to system resources that are singletons (nftables
, for example). Then there's the open question of how the daemon should behave when ran inside a container - should it ensure that only traffic within the container never leaks?
Anyway, I don't think this is a bug, but it might be a feature request. We haven't considered making the daemon be usable from within containers.
As for solving your issue, if you want to tunnel all your proxmox guest and host traffic through mullvad and you can't run the app directly on the host, the best you could do is run our client on a different host and route all the traffic through that host - be it a virtual machine or a real one.
Closing as running the app from within containers is not supported.
This worked for me:
Edit: The Mullvad app was working, but caused issues in the cgroups2-only Proxmox-VE 7.x, making it think legacy cgroup was enabled while /sys/fs/cgroup/unified doesn't actually exist. Just went with a wireguard implementation.
Here is a workaround for the net_cls mounting : https://forum.proxmox.com/threads/mullvad-vpn-daemon-issues.97555/page-2
Issue report
Operating system: Host: Proxmox 7, Debian 11 | Containers: Debian 10, 11; Ubuntu 18.04, 20.04
App version: 2021.01-04 so far
Issue description
I can't get the daemon to start, and I've already emailed the support team. Their response was to use wireguard/openvpn but each have their problems (wireguard blocks LAN, openvpn resets tracker connection daily) and I'm still relatively new to linux. The CLI app was working with zero issues before upgrading to proxmox 7
Error message