OpenVPN constantly timing out and restarting (Tomato.Toastman)

Discussion in 'Tomato Firmware' started by tji, Jul 29, 2013.

  1. tji

    tji Network Guru Member

    I have been using OpenVPN on my Tomato.Toastman build for quite a while (Build: Tomato Firmware v1.28.7501 MIPSR2Toastman-RT K26 USB VPN )

    I recently started logging from my router, trying out a cloud logging service called In the logs I noticed that openvn seems to do an inactivity timeout every 60 seconds, and send a SIGUSR1 to openvpn which restarts it.

    As far as I can tell, the VPN seems to work fine despite this. I use it to connect to my home network remotely, and it works well. But, the restarts seem excessive, inefficient, and obscure more important information in the logs.

    Is this a known issue? Or, is there some way to change the behavior?
  2. Inkrypted

    Inkrypted Serious Server Member

    You might try adding

    keepalive 10 60

    to your Custom Config and see if it makes any difference.
  3. koitsu

    koitsu Network Guru Member

    I would also suggest moving your OpenVPN configuration to use TCP (proto tcp) instead of UDP (proto udp); UDP is the default. The OpenVPN server may need to have this change applied to it as well, although some VPN providers run two instances of OpenVPN (one for TCP, one for UDP; search this for the phrase "proto udp" if you want proof of my statement).

    TCP is a significantly more resilient protocol when it comes to retrying and resiliency -- the actual TCP stack itself (in the kernels) do all this, not the application (OpenVPN), although the application may have some of its own logic that can work alongside it. But with UDP the model is quite literally "send the packet and hope it gets there".

    I also strongly advocate the use of keepalive, as Inkrypted mentioned.

    Furthermore, if your OpenVPN session is across the Internet, you need to be aware that the Internet is pretty much broken 24x7x365. BGP routing changes are often done incorrectly/wrongly at many ISPs and peering/backbone providers, where they will let BGP hold timers expire rather than "de-preferencing" a route + waiting 10 minutes before doing maintenance on a device (the latter would allow people's packets to smoothly migrate across a different path, while the former results in packets just repeatedly not reaching their destination for anywhere between 90 to 300 seconds). This is the reality of the Internet, I'm sorry to say. Monitoring/watching for those types of issues is a separate discussion topic.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice