Is the mutual exclusion of dco and iproute2 still necessary?

[rma-x]

AFAICS the --enable-iproute2 and --enable-dco configure options were made mutually exclusive, because at the time iproute2 was not able to create ovpn interfaces. This appears to be possible now at least on newer distributions and when the ovpn module is loaded.

Therefore I suggest to remove the code that prevents using these two options together from configure.ac.

[ordex]

As of now, stable iproute2 can only create P2P ovpn interfaces. There is no way to create a MP interface.
A patch has been recently merged, but I doubt it got released already (or even reached distros).

This said, what is the advantage of having iproute2 support compiled in?
The real issue is that we have to add code to make that happen and maintain it moving forward, but it doesn't make sense if we have a more modern interface.

Are you maybe after a feature that is available via iproute2 only?

[rma-x]

Thanks for your quick response. I might be wrong, but it was my understanding that iproute2 also allows unprivileged users to set up tunnels which the more modern interface does not. As a distro maintainer (SUSE) I'd like to have as many features and options compiled in as possible, because there'll always be someone who complains when you leave something out.

[ordex]

I might be wrong, but it was my understanding that iproute2 also allows unprivileged users to set up tunnels which the more modern interface does not

To the best of my knowledge, this is not the case. iproute2 just uses netlink under the hood (the same "modern interface" that OpenVPN switched to when compiled with SITNL).

Right now I don't think unprivileged users can create ovpn interfaces.

We have a patch in the pipe (for ovpn) which will allow unprivileged users to create ovpn interfaces inside a user container.

[ordex]

And for "privileged" we mean a user having the CAP_NET_ADMIN.

[rma-x]

Long time ago we got this bug report at SUSE which caused us to re-add --enable-iproute2 after it had gone "lost" in an upgrade. The upstream documentation the bug reporter meant to link to seems to have moved here in the meantime. Is this all not relevant anymore?

[ordex]

Got it.
Basically you give privileges only to the unpriv-ip script, rather than running openvpn as root. I can understand this.

Would assigning CAP_NET_ADMIN to the openvpn process violate any security requirement? At that point you could run openvpn unprivileged without the unpriv-ip trick.

[rma-x]

I am not the one running this setup, I only "fixed" the package to re-allow running it.
But thanks for the hint, let's see if it helps the bug reporter.

[ordex]

@rma-x just curious if you got any feedback?