Opened 11 years ago

Last modified 11 years ago

#167 new Bug / Defect

UNDEF user with big uptime

Reported by: svimik Owned by:
Priority: minor Milestone:
Component: Generic / unclassified Version:
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:


In status file I see user with name "UNDEF".
Google says, that it's unauthorized user, and the name should be resolved shortly, or user should be disconnected.
But, in my case, this user stays online over 7 hours, and has 50 mb traffic.

Here is status file example (reduced for tidiness):

Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
UNDEF,,5534537,49579722,Fri Sep 30 00:26:53 2011
Virtual Address,Common Name,Real Address,Last Ref
00:ff:d7:11:b6:55,UNDEF,,Fri Sep 30 07:56:09 2011

Change History (4)

comment:1 Changed 11 years ago by svimik

Here is my server configuration:

local 188.40.74.**
port 1194
proto udp
dev tap0
mode server
ifconfig-pool-persist ipp.txt
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
tmp-dir /etc/openvpn/tmp
keepalive 10 30
max-clients 100
user www-data
group www-data
status openvpn-status.log 30
log openvpn.log
verb 3

comment:2 Changed 11 years ago by svimik

Client configuration:

remote 188.40.74.** 1194
proto udp
dhcp-option DNS
redirect-gateway def1
ca ca.crt
cert ******.crt
key ******.key
ns-cert-type server
dev tap
resolv-retry infinite
verb 4
mute 20
#Windows specific
route-method exe
route-delay 2

comment:3 Changed 11 years ago by svimik

Here is new example with log.

Updated,Thu Oct  6 00:46:16 2011
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
UNDEF,,18324074,429938051,Wed Oct  5 21:39:42 2011
Virtual Address,Common Name,Real Address,Last Ref
00:ff:3b:0f:6d:46,UNDEF,,Thu Oct  6 00:46:15 2011

Log is here:

(I filtered log with | grep, because there are many other clients. hope nothing is lost).

In the log I can see, that it's user_440505, so it actually has name, but there are some Authenticate/Decrypt? errors.

comment:4 Changed 11 years ago by Samuli Seppänen

Preliminary analysis from IRC meeting on 6th Oct 2011:

andj 23:12:13
svimik: I think the following happened: certificate expired
at some point, and the controlchannel still existed but a new
control channel can't be set up. The session then still exists
but can't be used anymore
SviMik 23:14:38
So the user should be kicked in that case because session is
not usable anyway.

andj 23:15:27
Yeah, and the error should be a little clearer as well. Failed 
TLS connections could be handled more cleanly.

SviMik 23:18:28
Andj so, the expired certificate may be only a part of condition
to reproduce this bug.

andj 23:19:41
Hmm, it's something that needs looking at, but I'm afraid I
haven't got time right now (getting late here).

SviMik 23:17:36
Actually in my previous tests connection was working well even
after certificate expiration (upon first reconnect).
Note: See TracTickets for help on using tickets.