'keepalive' reconnect fails if 'remote' is specified with hostname from /etc/hosts file.

[mis@…]

O/S: Centos 6.4
Architecture: i686

When client configuration file has 'remote <hostname>' and hostname is defined in /etc/hosts file, OpenVPN startup is successful.

Using 'keepalive 10 120', if the remote server goes down (reboots), when the client determines that it needs to attempt reconnect, it tries and cannot.

Repeated log messages show 'RESOLVE: Cannot resolve host address: <hostname>: No address associated with hostname'.

Works fine if 'remote <hostip>' is used instead of 'remote <hostname>'.

# uname -a
Linux node0002 2.6.32-358.23.2.el6.i686 #1 SMP Wed Oct 16 17:21:31 UTC 2013 i686 i686 i386 GNU/Linux
# openvpn --version
OpenVPN 2.3.2 i686-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Sep 12 2013
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@…>
Compile time defines: enable_crypto=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_eurephia=yes enable_fast_install=yes enable_fragment=yes enable_http_proxy=yes enable_iproute2=yes enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_password_save=yes enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_pthread=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_win32_dll=yes enable_x509_alt_username=yes with_crypto_library=openssl with_gnu_ld=yes with_iproute_path=/sbin/ip with_mem_check=no with_plugindir='$(libdir)/openvpn/plugins' with_sysroot=no

[Samuli Seppänen]

Did some reading and testing. From the openvpn man-page:

--ping-restart n

    If the peer cannot be reached, a restart will be triggered, causing
    the hostname used with --remote to  be  re-resolved  (if  --resolv-
    retry is also specified).

and

--resolv-retry n
    If hostname resolve fails for --remote, retry resolve for n seconds
    before failing.

    Set n to "infinite" to retry indefinitely.

    By default, --resolv-retry infinite is enabled.  You can disable by
    setting n=0.

and

--keepalive n m
    A  helper  directive  designed to simplify the expression of --ping
    and --ping-restart in server mode configurations.

    The server timeout is set twice the value of the  second  argument.
    This  ensures that a timeout is dectected on client side before the
    server side drops the connection.

    For example, --keepalive 10 60 expands as follows:

    if mode server:
        ping 10
        ping-restart 120
        push "ping 10"
        push "ping-restart 60"
    else
        ping 10
        ping-restart 60

The "If the peer cannot be reached" might mean two things:

1. "If the ping can't reach the peer"
2. "If connecting to the peer's (numeric) IP-address fails"

Not sure which interpretation is correct.

Anyways, I was unable to produce this myself, because I had probably unrelated issues with the keepalive directive. Can you attach sample client and server configs with which you encountered this issue? Of course strip out all sensitive information first...

[Gert Döring]

From the description, it should be pretty straightforward - have "--keepalive 10 60" on the server, connect to it (using a --remote $hostname, with $hostname in /etc/hosts) and then kill the server process. Client should try to reconnect.

There is a known issue that re-resolving using DNS can fail if DNS info is pushed and the DNS is (obviously) unreachable while the tunnel is up but not working, but for /etc/hosts it should work just fine. So maybe there is more involved, like a DNS server being pushed leading to resolving timeouts.

A client log showing the issue would indeed be helpful.

[tct]

Replying to mis@…:

O/S: Centos 6.4
Architecture: i686

When client configuration file has 'remote <hostname>' and hostname is defined in /etc/hosts file, OpenVPN startup is successful.

Using 'keepalive 10 120', if the remote server goes down (reboots), when the client determines that it needs to attempt reconnect, it tries and cannot.

Repeated log messages show 'RESOLVE: Cannot resolve host address: <hostname>: No address associated with hostname'.

I tried to replicate this with v2.5.5 but could not.

The client is Linux and if pushed DNS is the issue then the --down script should take care of that.

However, my hunch here is that the client config drops privileges and /etc/hosts is not world readable. In which case openvpn waits for DNS resolution via DNS Server. Presuming that which the hosts file contains is not a valid A/AAAA record then DNS resolution will fail, in one way or another.