Opened 10 years ago
Last modified 2 years ago
#352 new Bug / Defect
'keepalive' reconnect fails if 'remote' is specified with hostname from /etc/hosts file.
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Generic / unclassified | Version: | OpenVPN 2.3.2 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | /etc/hosts keepalive remote volunteer |
Cc: |
Description
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
Change History (4)
comment:1 Changed 10 years ago by
comment:2 Changed 10 years ago by
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.
comment:3 Changed 9 years ago by
Keywords: | volunteer added |
---|
comment:4 Changed 2 years ago by
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.
Did some reading and testing. From the openvpn man-page:
and
and
The "If the peer cannot be reached" might mean two things:
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...