Stuck @ 75% connecting

[brendan4t]

Saw a few other issues reporting this but never saw any resolution. I am able to successfully activate my key, but I cannot connect to any servers worldwide. Stuck @ 75% then fails.

[brendan4t]

Either tries to connect and fails, or just stuck at connecting.

[tt83]

It also doesn't work for me on old kernel 4.x, try newer one >= 5.x

[avaryx]

@brendan4t did you ever get this working? I'm facing the same now. When I run diagnostics, I see:
Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)

I'm wondering if this is perhaps part of it.

[brendan4t]

@brendan4t did you ever get this working? I'm facing the same now. When I run diagnostics, I see: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)

I'm wondering if this is perhaps part of it.

No,

I think it has to do with the old network kernel on my synology. My only solution was to VPN the entire NAS through network settings in the actual OS

[avaryx]

I think I just got it to work:

I'm going to see if I can get this worked into the docker-compose.yml instructions.

[brendan4t]

I think I just got it to work:

I'm going to see if I can get this worked into the docker-compose.yml instructions.

If I can remember correctly, I think I got it to connect after trying over and over 100x times. But my synology was too old to link multiple containers to be under the VPN.

[avaryx]

So, I've tried a bunch of things in docker-compose.yml and nothing is working for me. What I've found is this:

1. I execute docker-compose up -d from command line using the provided example in the README.md, and the container comes online.
2. ExpressVPN fails to connect. It gets stuck at 75%, and gives up.
3. I execute the following from inside the container:
   /bin/bash -c 'mkdir -p /dev/net && mknod /dev/net/tun c 10 200 && expressvpn connect'
4. ExpressVPN connects at 100%

Image example:

I found this solution due to issues with OpenVPN others were having, here. My solution uses what was done here.

@polkaned is there any way you can make this happen? I'm trying my best but cannot seem to get it to work properly in the docker compose.

[avaryx]

Following up to state this is no longer working for me today. Not sure why it was before.

[polkaned]

You should not have to create the /dev/net interface because of use of --device=/dev/net/tun arg at the run time.
Take a look to system messages (container and host), you will find some clue.

[wbudd]

@avaryx @polkaned
I had this same issue on a Synology NAS DS220+ running DSM 7.1.1, but it turns out the cause and solution is quite simple: this DSM distribution (the host OS) doesn't load the TUN kernel module automatically — nor does apparently the --device=/dev/net/tun Docker flag cause said module to load.

This can be checked by ssh-ing into the host, and running sudo lsmod | grep -w tun (nothing shows up), sudo insmod /lib/modules/tun.ko, and then sudo lsmod | grep -w tun again (tun should show up now).

Of course, you'd want to make this kernel module loading persistent across reboots so create a /usr/local/etc/rc.d/tun.sh file (don't forget to chmod a+x it) with something like:

#!/bin/sh -e
insmod /lib/modules/tun.ko
EOF

Verify all is good by rebooting and running docker-compose up -d on this repo's Dockerfile: no more TUN-related errors and ExpressVPN connects just fine now.

BTW, @avaryx's workaround also works, but the reason for that seems to be that the mknod indirectly causes the kernel module to load — which is possible from within the container because the NET_ADMIN and (or?) the privileged flag passed to the Docker service. As @polkaned points out, manually creating devices/interfaces in /dev should not be necessary.

[avaryx]

Thanks for giving us a much better explanation and solution.