Page MenuHomeVyOS Platform

OpenVPN insufficient privileges for rtnetlink when closing TUN/TAP interface
Closed, ResolvedPublicBUG


OpenVPN 2.5 uses rtnetlink instead of iproute2 which has resulted in openvpn being unable to delete IP addresses or otherwise modify the interface after root privileges are dropped.

Resetting an OpenVPN client interface (to NordVPN), I get the following errors:

openvpn-vtun0[155033]: Closing TUN/TAP interface
openvpn-vtun0[155033]: net_addr_v4_del: dev vtun0
openvpn-vtun0[155033]: sitnl_send: rtnl: generic error (-1): Operation not permitted
openvpn-vtun0[155033]: Linux can't del IP from iface vtun0
openvpn-vtun0[155033]: TUN/TAP device vtun0 opened
openvpn-vtun0[155033]: net_iface_mtu_set: mtu 1500 for vtun0
openvpn-vtun0[155033]: sitnl_send: rtnl: generic error (-1): Operation not permitted
openvpn-vtun0[155033]: Linux can't set mtu (1500) on vtun0
systemd[1]: openvpn@vtun0.service: Main process exited, code=exited, status=1/FAILURE
openvpn-vtun0[155033]: Exiting due to fatal error
systemd[1]: openvpn@vtun0.service: Failed with result 'exit-code'.
systemd[1]: openvpn@vtun0.service: Scheduled restart job, restart counter is at 2.
systemd[1]: Stopped OpenVPN connection to vtun0.

Multiple restarts end up with vtun0 gaining multiple addresses. which breaks routing via that interface.

However, with OpenVPN 2.5 and rtnetlink, it should now be possible to run openvpn as non-root from start to finish, using systemd capabilities. I tried the following (based on the archlinux solution):

Remove user & group directives from /run/vtun0.conf and add the following to /etc/systemd/system/openvpn@.service.d/override.conf


Ensure that the runtime directory and existing files were writable by openvpn user:

chmod -R openvpn:openvpn /run/openvpn

After executing systemctl daemon-reload and reset openvpn interface vtun0 everything appears to be working nicely, with the openvpn client running without root from start to finish.


Difficulty level
Easy (less than an hour)
VyOS 1.4-rolling-202108090815
Why the issue appeared?
Design mistake
Is it a breaking change?
Perfectly compatible
Issue type
Bug (incorrect behavior)

Event Timeline

Does it work if you grand the capabilities to the openvpn group in /etc/security/capability.conf?

Unfortunately not. I reverted my changes and then added:

cap_dac_override,cap_setgid,cap_setuid,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_sys_chroot,cap_audit_write   @openvpn

to /etc/security/capability.conf but got the same errors as before (I rebooted to make sure).

Can you please share a version of your anonymized client configuration?

Certainly, here it is:

openvpn vtun0 {                                                  
    authentication {                                             
        password ******                                          
        username ******                                          
    encryption {                                                 
        cipher aes256                                            
    hash sha512                                                  
    mode client                                                  
    openvpn-option fast-io                                       
    openvpn-option "remote-cert-tls server"                      
    openvpn-option "resolv-retry infinite"                       
    openvpn-option "pull-filter ignore redirect-gateway"         
    openvpn-option "tun-mtu 1500"                                
    openvpn-option "tun-mtu-extra 32"                            
    openvpn-option "mssfix 1450"                                 
    openvpn-option "comp-lzo no"                                 
    openvpn-option "ping-restart 0"                              
    openvpn-option ping-timer-rem                                
    openvpn-option "ping 15"                                     
    openvpn-option "reneg-sec 0"                                 
    protocol udp                                                 
    remote-port 1194                                             
    tls {                                                        
        auth-key ****************                                
        ca-certificate ***************                          
        tls-version-min 1.2                                      
c-po changed the task status from Open to Confirmed.Wed, Sep 8, 12:28 PM
c-po triaged this task as Normal priority.
c-po changed Difficulty level from Unknown (require assessment) to Easy (less than an hour).
c-po changed Why the issue appeared? from Will be filled on close to Design mistake.
c-po changed Is it a breaking change? from Unspecified (possibly destroys the router) to Perfectly compatible.
c-po changed the task status from Confirmed to Needs testing.Wed, Sep 8, 12:37 PM
c-po added a project: VyOS 1.3 Equuleus.
c-po moved this task from Need Triage to Finished on the VyOS 1.4 Sagitta board.

A new ISO 1.4-rolling-202109081242 is currently build - you may check in 30 minutes and try if this works for you - it did in my example config.

If you say that this change works as expected - I am going to backport it to VyOS 1.3 for the upcoming release.

c-po moved this task from Need Triage to 1.3.0-epa1 on the VyOS 1.3 Equuleus board.
c-po edited projects, added VyOS 1.3 Equuleus (1.3.0-epa1); removed VyOS 1.3 Equuleus.
c-po moved this task from Need Triage to Finished on the VyOS 1.3 Equuleus (1.3.0-epa1) board.

Sorry, I haven;t managed to test yet, due to some configuration migration errors leaving me unable to login. Will comment once I've confirmed though, most likely tomorrow.

Change works as expected for me. Thank you!

FYI, if your OpenVPN config relies on cert files or anything you uploaded into the config directory, you may need to change the owner to the openvpn user or widen file permissions. Oddly this only seems to affect equuleus, not sagitta (OpenVPN seems fine reading files owned by "root" out of "/config/auth").