Issue deploying Twingate Docker connector on Proxmox LXC

I am deploying a Twingate Docker connector on a Proxmox LXC running Ubuntu 22.04.2 LTS on my home server.

Apologies, as I am a newbie.

Every time I paste and run the Docker command provided by the copy & paste section, I get this error:

docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: write /proc/sys/net/ipv4/ping_group_range: invalid argument: unknown.

This is basically what I copied the from copy & paste section.


docker run -d
    --sysctl net.ipv4.ping_group_range="0 2147483647"
    --env TENANT_URL="https://MYTEAM.twingate.com"
    --env ACCESS_TOKEN="XXMYTOKENXX"
    --env REFRESH_TOKEN="XXMYREFRESHTOKENXX"
    --env TWINGATE_LABEL_HOSTNAME="`hostname`"
    --name "twingate-MY-CONNECTOR"
    --restart=unless-stopped
    $(docker run --help | grep -- --pull >/dev/null && echo "--pull=always")
    twingate/connector:1

I followed the guide from Networkchuck, and followed essentially the same instructions, with the difference of running on a Proxmox LXC vs a Raspberry pi

You forgot to mention whether your lxc container runs privileged or unprivileged.
I expect it to not work within an unprivileged lxc container.

Hello! Thank you for your reply!
You were correct where the container I am currently attemping to run Twingate on is unprivileged!
I’ve just deployed an identical test LXC container that is priviledged, but I got a different error this time:

docker: Error response from daemon: AppArmor enabled on system but the docker-default profile could not be loaded: running `/usr/sbin/apparmor_parser apparmor_parser -Kr /var/lib/docker/tmp/docker-default3726602040` failed with output: apparmor_parser: Unable to replace "docker-default".  Permission denied; attempted to load a profile while confined?

I use Proxmox kvm vm’s for my docker hosts. I just tested privileged vs. unprivileged a while ago, and didn’t use it.

Let’s hope that someone who actually uses lxc to run containers sees your post.

I searched for

failed with output: apparmor_parser: Unable to replace "docker-default"

on Google and found this:

I never used Proxmox, but I tried LXC to run Docker containers even in unpriveled LXC container, but that was long ago. Now I always add --vm to the lxc launch to have a virtual machine.

AppArmor is a kernel (extension as the kernel docs mentions) module so even in privileged containers I don’t know how it would work exactly. Maybe you could try (just for testing) add ā€œ--security-opt apparmor=unconfinedā€ to docker run.

You could learn a little more about AppArmor and Docker in the Docker docs

But I recommend using a virtual machine instead of container or using unprivileged LXC container. I don’t know what post I read when I played with unprivileged LXC and Docker, but I am pretty sure I used the same solution as mentioned in the following article:

The most important part of it is this line in the LXC settings

features: keyctl=1,nesting=1

nesting allows you to use nested containers (container in container) and keyctl allows a required system call.

You can read about this too from the Proxmox wiki

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

It also mentions:

nesting= (default = 0)

Allow nesting. Best used with unprivileged containers with additional id mapping. Note that this will expose procfs and sysfs contents of the host to the guest.

1 Like

I was having the same issue with Proxmox unprivileged LXC/Docker.
So decided to try the following as no one else appears to suggest it so far:

Removed the following parameter from the docker run command of the connector:

--sysctl net.ipv4.ping_group_range="0 2147483647"

And instead, specify my DNS server

--env DNS_SERVER="192.168.xxx.xxx"

To my surprise, not only the connector started without error, and it appeared straightaway connected within Twingate.

So I tried it so far it seems to work fine with both my CIDR and DNS resources.

Note I have AdGard Home & Nginx Proxy Manager on the same docker instance as the connector.

Now, what could be the side effect of such a workaround?

1 Like