Mention that you have to enable systemd-networkd

[ghost]

I am new to using OpenVPN, and was following the guide on the Arch Linux wiki that mentioned this repository. Everything worked pretty smoothly, so thanks for that :)

After rebooting, I tried systemctl start openvpn@client-unroot.service but got the following error message:

ERROR: Cannot set tx queue length on tun0-unrooted: Operation not permitted (errno=1)

It took me some time to figure out where the problem was: in order for the /etc/systemd/network/tun0-unrooted.netdev profile to be activated, I needed to start systemd-networkd. I have no idea if this service is started by default for most users and I somehow disabled it, but if that is not the case, maybe you can mention somewhere in your readme that users have to enable that service for things to keep working through reboots.

[wknapik]

Hi @Neftas

I am new to using OpenVPN, and was following the guide on the Arch Linux wiki that mentioned this repository. Everything worked pretty smoothly, so thanks for that :)

I'm glad to hear that :)

After rebooting I tried systemctl start openvpn@client-unroot.service but got the following error message: ERROR: Cannot set tx queue length on tun0-unrooted: Operation not permitted (errno=1)

The error occurs because openvpn, running as an unprivileged user, doesn't have permission to set the transmit queue length for the tun0-unrooted device. This is not a fatal error (which is not to say it's irrelevant). When openvpn-unroot creates a persistent tun device, it uses openvpn --mktun, which sets the txqueuelen to OpenVPN's default - 100. When starting, OpenVPN will blindly try to set the value again (even though it's already what it wants) and fail, but the error has no practical relevance. However, when you reboot the system and the device is created by systemd (based on the generated .netdev file), the txqueuelen may, and probably will be, different. That's the case where the error is relevant.

So how do we resolve the problem ?

Systemd should allow us to set txqueuelen in the .netdev, or .link file, but it simply doesn't. The feature is unsupported apparently. Passing --user/--group to openvpn --mktun, or setting User/Group in a .netdev file also doesn't allow the specified user to manipulate the setting. This leaves us will only one option - set the value as root after the device is created, by invoking iproute2 from an init script, or an openvpn --up script:

ip link set dev tun0-unrooted txqueuelen 100

If it could be handled in systemd, or OpenVPN configs, I'd add the functionality to openvpn-unroot, but since that's impossible, it's left for the user to handle (or not), according to their preferences. In any case, OpenVPN will work correctly, though the different txqueuelen settings may impact network latency.

It took me some time to figure out where the problem was: in order for the /etc/systemd/network/tun0-unrooted.netdev profile to be activated, I needed to start systemd-networkd. I have no idea if this service is started by default for most users and I somehow disabled it, but if that is not the case, maybe you can mention somewhere in your readme that users have to enable that service for things to keep working through reboots.

This is weird. If systemd-networkd was not enabled, how was your networking being set up after boot ? I'm not sure what happened there, but the assumption is that either a) you are using systemd (including systemd-networkd) and the generated .netdev file will be enough to bring up the tunnel, or b) you're not using systemd and you'll handle bringing up the interface yourself.

I will keep your report in mind the next time I update the README file. I haven't had much time to work on openvpn-unroot recently, but I do plan to get back to it in the near future.

Thanks for taking the time to report the issue. I hope you find this explanation satisfactory.

Cheers.

[ghost]

Thanks for your explanation. I'm not sure I understand everything completely, but your reply gives plenty of openings for me to investigate myself. Thanks again for creating and maintaining this package, it is much appreciated.

Take care.