I have OpenVPN clients running on Carambola2 devices [1] and when I use 3g/umts stick or wired ethernet then OpenVPN clients establish vpn tunnel every time.

When wifi is used then OpenVPN client fails due to TLS timeout if wifi signal is not perfect 10/10! Logs show LS timeouts after 60 seconds.

If carambola device (clients) are in same room as AP then OpenVPN gets establishes without any issues!

When carambola device in other room (two walls between it and AP, signal shows around -80dBm), there are no dropped pings, but OpenVPN fails after 60 seconds because due to TLS timeout.

I tried setting "tls-timeout 120" on clients and on server but these is still TLS timeout after 60 seconds, what am I doing wrong?

Should I switch to tcp instead of udp on OpenVPN server? Are there some other tweaks I can try?

I have read that sometimes less powerful devices (smartphons and small home wifi routers) or while using very slow connection (GPRS in area with low signal coverage) cause TLS timeout issues during TLS handshake, because a timeout occurs before clients are done calculating the respective session keys.

But why do these devices establish OpenVPN connection without TLS timeout when wifi signal is ideal 10/10?

[1] http://8devices.com/carambola-2

  • Maybe this is the answer, testing now: wiki.amahi.org/index.php/…
    – valentt
    Mar 9, 2014 at 23:05
  • Nope, adding ta.key doesn't help anything. Currently thing that helped was using tcp instead of udp.
    – valentt
    Mar 10, 2014 at 15:30
  • LOL, UDP on a bad link. Repeating TomTom: "What do you expect?" :)
    – user65677
    Sep 29, 2015 at 18:43

2 Answers 2

   --hand-window n
          Handshake  Window  -- the TLS-based key exchange must finalize within n seconds of handshake initiation by any peer (default = 60 seconds).  If the handshake fails we
          will attempt to reset our connection with our peer and try again.  Even in the event of handshake failure we will still use our expiring key for up  to  --tran-window
          seconds to maintain continuity of transmission of tunnel data.                                                                                                             

You should try using reneg-sec 0.

Just sayin.

  • 7
    While this may be correct it would transition from being correct to being useful were you to explain what that command is doing and why it may fix the issue.
    – Scott Pack
    May 16, 2015 at 2:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.