Opened 2 years ago

Last modified 18 months ago

#681 new Bug / Defect

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:
Cc:

Description

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

Attachments (1)

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

Download all attachments as: .zip

Change History (5)

Changed 2 years ago by lattucaf

Screenshot

comment:1 Changed 2 years ago by lattucaf

That is with no VPN connected users.

comment:2 Changed 21 months ago by Gert Döring

Milestone: release 2.3.14

comment:3 Changed 20 months 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/openvpn_server1.pid`

then typing, into gdb7111,

backtrace full
detach
quit

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

Thank you.

Last edited 20 months ago by mandree (previous) (diff)

comment:4 Changed 18 months 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: https://github.com/sephiroth1395/nagios-plugins/blob/master/check_openvpn.pl

Note: See TracTickets for help on using tickets.