RTNETLINK answers: Operation not permitted in Unprivileged Container

When my openvpn client tries to establish a connection after the 24 hour period, I am unable to restore the connection. The following are the errors I am getting in syslog. I am sure it’s something I need to add to config, but I’m trying to limit the total privileges in these (unprivileged) containers as much as possible. Any suggestions?

/var/log/syslog:

  176 Jul 15 23:01:32 vpnclient ovpn-ipclient[92]: Preserving previous TUN/TAP instance: tun0
  177 Jul 15 23:01:32 vpnclient ovpn-ipclient[92]: NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
  178 Jul 15 23:01:32 vpnclient ovpn-ipclient[92]: /sbin/ip route del 45.56.4.4/32
  179 Jul 15 23:01:32 vpnclient openvpn[92]: RTNETLINK answers: Operation not permitted
  180 Jul 15 23:01:32 vpnclient ovpn-ipclient[92]: ERROR: Linux route delete command failed: external program exited with error status: 2
  181 Jul 15 23:01:32 vpnclient ovpn-ipclient[92]: /sbin/ip route del 0.0.0.0/1
  182 Jul 15 23:01:32 vpnclient openvpn[92]: RTNETLINK answers: Operation not permitted
  183 Jul 15 23:01:32 vpnclient ovpn-ipclient[92]: ERROR: Linux route delete command failed: external program exited with error status: 2
  184 Jul 15 23:01:32 vpnclient ovpn-ipclient[92]: /sbin/ip route del 128.0.0.0/1
  185 Jul 15 23:01:32 vpnclient openvpn[92]: RTNETLINK answers: Operation not permitted
  186 Jul 15 23:01:32 vpnclient ovpn-ipclient[92]: ERROR: Linux route delete command failed: external program exited with error status: 2
  187 Jul 15 23:01:32 vpnclient ovpn-ipclient[92]: Closing TUN/TAP interface
  193 Jul 15 23:01:33 vpnclient ovpn-ipclient[92]: ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)
  194 Jul 15 23:01:33 vpnclient ovpn-ipclient[92]: Exiting due to fatal error
  195 Jul 15 23:01:33 vpnclient systemd[1]: openvpn@ipclient.service: Main process exited, code=exited, status=1/FAILURE
  196 Jul 15 23:01:33 vpnclient systemd[1]: openvpn@ipclient.service: Failed with result 'exit-code'.

Not sure if it’s a container problem, to me it looks like you have a script configured in your vpn’s config which is called on reconnect. That script appears to be running some commands which it believes will run as root.
If openvpn is configured to drop privileges, chances are that the scripts from that point on will not run as root, which would explain that error.

1 Like

Yes, I do have it running as nobody…I did try a work around via cron tab to re-instantiate openvpn on tun0 being disabled, however, for some reason the ufw rules don’t clear. I’m calling:
ufw --force reset
But when I check ufw status the rules are still present. Anything funky about cron tabs in lxc? My last ditch workaround was to throw a reboot in there since they reload so quickly anyway, just not very elegant.

Can’t think of a reason why this wouldn’t work no. Cron works the same way as any Linux system. Maybe there’s some debug flag you can pass to ufw in your script to log why it’s not doing anything?

1 Like

Yep - I threw some debug in, it looks like by default the path is not set even though I have bashrc with a proper PATH variable. I full pathed all my commands and the script to monitor and re-up works just fine.

As a side question - when I attempt to do apt upgrade via an external script, I get the same type of issue with pathing, I’ve poked around /etc/skel but is there a way to ensure path is set when running a command like such:

/usr/bin/lxc-attach -n "$vm" -- /usr/bin/apt -qq update
/usr/bin/lxc-attach -n "$vm" -- /usr/bin/apt -y upgrade

I wind up getting ldd errors on upgrade (I am assuming due to default bath not containing /sbin:/usr/sbin).