2.3: options not pushed sucessfully in server mode after client restart

[lvp]

A system is setup in server mode for IPv6 access (only) since early 2011 on Debian squeeze running ​http://build.openvpn.org/downloads/allmerged/debian/5/openvpn_2.3-20110421_i386.deb (and earlier). Exchanging with openvpn_2.3-alpha1-debian0_i386.deb (identical configuration apart fromDN syntax in verify script), I can reproduce the following problem. Also with self-compiled versions from ​ftp://ftp.secure-computing.net/pub/FreeBSD/ports/openvpn-devel/: openvpn-201219.tar.gz and some other back to 201135 (201130, 201120, 201117 do segfault on start). (This test case done on x86_64 system.)

Everything is fine if there is no active instance on the server for the connecting client. But if the client is restarted and not timed out on the server, option pull/push is not working correctly. PUSH_REQUEST is sent every 5 seconds but not replied to. See attached server log for both cases (addresses etc. modified, verb 6).

Client is 2.1.4 on OpenWRT, in this case. (Setup pushes environment variables to allow IPv6 setup in client up-script without new IPv6 support there.)

server side openvpn --version
OpenVPN 2.3-alpha1 x86_64-linux-gnu [SSL (OpenSSL)] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110522-1 (2.2.0)] built on Feb 21 2012
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@…>

$ ./configure --enable-pthread --enable-password-save --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/usr --mandir=${prefix}/share/man --with-ifconfig-path=/sbin/ifconfig --with-route-path=/sbin/route CFLAGS=-g -O2 build_alias=x86_64-linux-gnu host_alias=x86_64-linux-gnu LDFLAGS= CPPFLAGS= --no-create --no-recursion

Compile time defines: ENABLE_CLIENT_SERVER ENABLE_DEBUG ENABLE_EUREPHIA ENABLE_FRAGMENT ENABLE_HTTP_PROXY ENABLE_MANAGEMENT ENABLE_MULTIHOME ENABLE_PASSWORD_SAVE ENABLE_PORT_SHARE ENABLE_SOCKS USE_CRYPTO USE_LIBDL USE_LZO USE_OPENSSL USE_PKCS11 USE_SSL

Lutz

[lvp]

May I ask if there is any reason for me to test a newer build regarding this bug?

[David Sommerseth]

This bug is most likely related to this proposed patch: ​[PATCH Fix reconnect issues when --push and UDP is used on the server]

I've seen this issue from the beginning of the 2.3 code base, so it's a regression since 2.2. As you can see from the patch, the bug and the patch introducing it has been identified. Now we're waiting for James Yonan to weight in on this issue as well. But if that doesn't happen reasonably soon, we'll apply the patch above and provide a better fix later on if that makes sense.

But please feel free to try the latest git tree and apply this patch on top of it.

[David Sommerseth]

A partial fix has been committed.

commit 5d4f5435a421299ed047485d8d99bdf9a0d22fd1
Author: David Sommerseth <davids@redhat.com>
Date:   Sun Sep 9 03:30:46 2012 +0200

    Fix reconnect issues when --push and UDP is used on the server
    
    When the server is configured with UDP and --push statements, reconnecting
    often fails by the client never receiving PUSH_REPLY.  The client sends
    PUSH_REQUEST and the server logs these requests but does not send them.
    
    This bug got introduced in commit ff65da3a230b658b2c1d52dc1a48612e80a2eb42
    which tries to avoid sending duplicated PUSH messages if the client/server
    connection is slow.
    
    This patch keeps this behaviour, but instead of a session wide PUSH_REPLY
    block it sets an expiry time for the PUSH_REPLY block.  The expiry time
    is set to 30 seconds.
    
    Signed-off-by: David Sommerseth <davids@redhat.com>
    Cc: James Yonan <james@openvpn.net>
    Acked-by: Gert Doering <gert@greenie.muc.de>
    Acked-by: James Yonan <james@openvpn.net>
    Message-Id: 1347154246-20143-1-git-send-email-dazo@users.sourceforge.net
    URL: http://article.gmane.org/gmane.network.openvpn.devel/7044

This will certainly improve things, but we're still investigating if there is a better fix for it.

[David Sommerseth]

Closing this as fixed, as there has been no response to this ticket since the 2.3.0 release. The referenced commit should solve this behaviour too, and other reports have indicated this as well.

$ git tag --contains 5d4f5435a421299ed047485d8d99bdf9a0d22fd1
v2.3.0
v2.3_beta1
v2.3_rc1
v2.3_rc2