Opened 7 years ago

Closed 20 months ago

#681 closed Bug / Defect (fixed-external)

CPU at 100% when attaching to OpenVPN management socket

Reported by: lattucaf Owned by:
Priority: major Milestone: release 2.3.14
Component: Generic / unclassified Version: OpenVPN 2.3.10 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:


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
dev-node /dev/tun1
writepid /var/run/
#user nobody
#group nobody
script-security 3
keepalive 10 60
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/
client-disconnect /usr/local/sbin/
client-config-dir /var/etc/openvpn-csc/server1
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"
ca /var/etc/openvpn/
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

Attachments (1)

Screenshot from 2016-05-04 13:14:09.png (9.5 KB) - added by lattucaf 7 years ago.

Download all attachments as: .zip

Change History (6)

Changed 7 years ago by lattucaf


comment:1 Changed 7 years ago by lattucaf

That is with no VPN connected users.

comment:2 Changed 7 years ago by Gert Döring

Milestone: release 2.3.14

comment:3 Changed 7 years ago by 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/

then typing

backtrace full

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

Thank you.

Version 0, edited 7 years ago by mandree (next)

comment:4 Changed 6 years ago by 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:

comment:5 Changed 20 months ago by Gert Döring

Resolution: fixed-external
Status: newclosed

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.

Note: See TracTickets for help on using tickets.