Re: [Openvpn-users] resolv-retry always 60 sec timeout

[James K. <jk...@ya...>]

--- On Tue, 6/8/10, Jan Just Keijser <ja...@ni...> wrote:

> From: Jan Just Keijser <ja...@ni...>
> Subject: Re: [Openvpn-users] resolv-retry always 60 sec timeout
> To: "James Kohout" <jk...@ya...>
> Cc: ope...@li...
> Date: Tuesday, June 8, 2010, 6:58 AM
> Jan Just Keijser wrote:
> > Hi James,
> > 
> > James Kohout wrote:
> >> Has anyone else seen this problem?  I change
> the timeout on
> >> the client for the resolv-retry from infinite to
> 20, but the timeout
> >> is always 60 Secs.  I also tried increasing
> to 120, but stil stayed 60 secs.
> >> 
> >> Client Config:
> >> client
> >> dev tun
> >> proto udp
> >> 
> >> # The hostname/IP and port of the server.
> >> # You can have multiple remote entries
> >> # to load balance between the servers.
> >> remote host3.dyndns.org 1194
> >> remote host2.dyndns.org 1194
> >> remote host1.dyndns.org 1194
> >> 
> >> # Keep trying indefinitely to resolve the
> >> # host name of the OpenVPN server.  Very
> useful
> >> # on machines which are not permanently connected
> >> # to the internet such as laptops.
> >> resolv-retry 20
> >> 
> >> 
> >> ... More standard config
> >> 
> >> 
> >> Mon Jun 07 23:20:38 2010 OpenVPN 2.1.1
> i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Dec 11 2009
> >> Mon Jun 07 23:20:38 2010 NOTE: OpenVPN 2.1
> requires '--script-security 2' or higher to call
> user-defined scripts or executables
> >> Mon Jun 07 23:20:40 2010 WARNING: this
> configuration may cache passwords in memory -- use the
> auth-nocache option to prevent this
> >> Mon Jun 07 23:20:40 2010 LZO compression
> initialized
> >> Mon Jun 07 23:20:40 2010 Control Channel MTU parms
> [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
> >> Mon Jun 07 23:20:40 2010 Data Channel MTU parms [
> L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
> >> Mon Jun 07 23:20:40 2010 Local Options hash
> (VER=V4): '41690919'
> >> Mon Jun 07 23:20:40 2010 Expected Remote Options
> hash (VER=V4): '530fdded'
> >> Mon Jun 07 23:20:40 2010 Socket Buffers:
> R=[8192->8192] S=[8192->8192]
> >> Mon Jun 07 23:20:40 2010 UDPv4 link local:
> [undef]
> >> Mon Jun 07 23:20:40 2010 UDPv4 link remote:
> host3.dyndns.org:1194
> >> Mon Jun 07 23:21:40 2010 TLS Error: TLS key
> negotiation failed to occur within 60 seconds (check your
> network connectivity)
> >> Mon Jun 07 23:21:40 2010 TLS Error: TLS handshake
> failed
> >> Mon Jun 07 23:21:40 2010 TCP/UDP: Closing socket
> >> 
> >> 
> >> I expect host3.dyndns.org to fail, but why does it
> wait 60 Secs, when the resolv-retry is set to 20 secs? 
> Also if I change it to 120, it still only waits 60
> secs.  It looks like it ignoring the actual setting
> after the resolv-retry and always using 60
> secs.   If I leave infinite, it does not try
> the next host, so that looks like it is working.
> >> 
> >>   
> > there's a
> >  resolv-retry
> > and a
> >  connect-retry
> > both of which have default values of 60 seconds.
> Sounds to me like you want to set both to 20 seconds.
> > The first parameter only affects the resolving of the
> hostname 'host3.dyndns.org' : if the name is resolved
> openvpn then tries to connect.
> > 
> 
> whoops, after reading the manual page more carefully I see
> there's also a
>  connect-timeout
> parameter: set that to 20 seconds as well  (or if you
> want to know what affects what, try values like 8, 14 and 19
> ;-) )
> 
> cheers,
> 
> JJK
> 
> 

I tried this, however, these are only for proto tcp

Options error: --connect-retry doesn't make sense unless also used with --proto tcp-client
Use --help for more information.

I think I have fixed it with adding ping and ping-restart.   I guess the
resolv-retry is working correctly, since it is resolving the hostname
within the specified time.  

James Kohout