UNDEF user with big uptime

[svimik]

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,173.10.81.161:55555,5534537,49579722,Fri Sep 30 00:26:53 2011
Virtual Address,Common Name,Real Address,Last Ref
00:ff:d7:11:b6:55,UNDEF,173.10.81.161:55555,Fri Sep 30 07:56:09 2011

[svimik]

Here is my server configuration:

local 188.40.74.**
port 1194
proto udp
dev tap0
mode server
server-bridge 10.117.0.1 255.255.0.0 10.117.0.2  10.117.31.255
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
client-to-client
keepalive 10 30
comp-lzo
max-clients 100
user www-data
group www-data
persist-key
persist-tun
status openvpn-status.log 30
log openvpn.log
verb 3

[svimik]

Client configuration:

client
remote 188.40.74.** 1194
proto udp
dhcp-option DNS 213.133.100.100
redirect-gateway def1
ca ca.crt
cert ******.crt
key ******.key
ns-cert-type server
dev tap
resolv-retry infinite
explicit-exit-notify
nobind
persist-key
persist-tun
comp-lzo
verb 4
mute 20
#Windows specific
route-method exe
route-delay 2

[svimik]

Here is new example with log.

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

Log is here: ​http://svimik.com/ovpnundef.txt

(I filtered log with | grep 91.23.46.217, 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.

[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).

[Gert Döring]

So, this ticket is 11 years old, and has not seen any activity since then... I know that we did improve quite a bit on the TLS side, so it might have been long fixed.

Anyone around who can re-test this on 2.5 or 2.6_beta2?