CPU at 100% when attaching to OpenVPN management socket

[lattucaf]

I actually uncovered this working on my pfSense 2.2.6 & 2.3 boxes (FreeBSD 10.1 OpenVPN 2.3.9 & FreeBSD 10.3 OpenVPN 2.3.10 respectively). When connecting to the management socket with net cat (nc -U server1.sock) after about 60 seconds the openvpn process spikes the CPU.

The following is the server config:

dev ovpns1
verb 4
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto tcp-server
cipher AES-128-CBC
auth RSA-SHA512
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local 192.168.179.10
tls-server
server 192.168.180.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/server1
username-as-common-name
auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user 'Local Database' false server1" via-env
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'openvpnserver' 1"
lport 443
management /var/etc/openvpn/server1.sock unix
push "route 192.168.179.0 255.255.255.0"
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.1024
crl-verify /var/etc/openvpn/server1.crl-verify
tls-auth /var/etc/openvpn/server1.tls-auth 0
comp-lzo adaptive
topology subnet

[lattucaf]

Screenshot

[lattucaf]

That is with no VPN connected users.

[mandree]

lattucaf, can you rebuild the port (2.3.13_1) from source with make WITH_DEBUG=yes, install, run and see if the problem reproduces with an additional "verb 9" in the config?

Also install gdb7 from ports or package.

If the problem is reproducible, please grab a stack backtrace while it's at 100%, by just typing

gdb7111 /usr/local/sbin/openvpn head -n1 /var/run/openvpn_server1.pid

then typing

backtrace full
detach
quit

and attach what you get from gdb7111 along with the OpenVPN log.

Thank you.

[ev1z]

Bug still exists on OpenVPN 2.3.14 running on TCP from CentOS 7 from the EPEL repository. I'm not very familiar with rebuilding packets but I can give it a shot if you want.

Example of a source code (Nagios plugin) that makes the bug occur here: ​https://github.com/sephiroth1395/nagios-plugins/blob/master/check_openvpn.pl

[Gert Döring]

So, cleaning up stuff - I've tried to reproduce with latest master, on FreeBSD 12.2, and can't.

Standard server setup, with management active, and a password set.

Connecting to management (TCP) -> "PASSWORD:" prompt. Doing nothing (for a few minutes), load normal.

Typing the password, not pressing return (for a few minutes) -> load normal.

Pressing return -> talking to management interface -> load normal.

Both for UDP and TCP servers.

Unix sockets show the same...

$ nc -U /var/tmp/s1.sock
>INFO:OpenVPN Management Interface Version 3 -- type 'help' for more info

and the server logs

2021-10-19 18:13:48 us=758831 MANAGEMENT: Client connected from /var/tmp/s1.sock

and then nothing exciting happens. Load stays at normal.

Since we never got traces for 2.3, and we are now retiring 2.*4* out of active support, I can only conclude that we seem to have fixed this somewhere on the way - so unless it can be reproduced in 2.5 or master, I consider this a bug that was accidentially fixed, and close the ticket.