Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keepalive params too low - causing restart spin #74

Closed
robshep opened this issue Feb 12, 2019 · 3 comments
Closed

Keepalive params too low - causing restart spin #74

robshep opened this issue Feb 12, 2019 · 3 comments

Comments

@robshep
Copy link

robshep commented Feb 12, 2019

Regarding this client config line

keepalive 2 4

... and this server config line

keepalive 2 4

I have an atom 686 CPU board which isn't too quick at crypto. On a fast network, it can't bring up a VPN connection within 4 seconds and so constantly restarts.

I can change this setting manually in the client OVPN config file, keepalive 10 120 which seems to be working fine. It remains as compiled on the server, but doesn't seem to be causing issue.

Thanks

@robshep
Copy link
Author

robshep commented Feb 13, 2019

Further to this, after much to-and-fro with settings.

It appears that the server will always override the setting via push.

On the first boot of the client it goes well because it is using the locally overridden timeout (120s).

PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,route-gateway 10.9.0.1,topology subnet,ping 2,ping-restart 4,ifconfig 10.9.0.12 255.255.255.0'
Feb 13 09:56:28 vpn-client ovpn-952[678]: OPTIONS IMPORT: timers and/or timeouts modified

Then on a disconnect/server-restart etc. It honours the value of timeout that was pushed. (4s)

[localhost] Inactivity timeout (--ping-restart), restarting
Feb 12 13:21:31 vpn-client ovpn-952[704]: SIGUSR1[soft,ping-restart] received, process restarting
Feb 12 13:21:31 vpn-client ovpn-952[704]: Restart pause, 2 second(s)
Feb 12 13:21:33 vpn-client ovpn-952[704]: Socket Buffers: R=[163840->163840] S=[163840->163840]
Feb 12 13:21:33 vpn-client ovpn-952[704]: UDPv4 link local: [undef]
Feb 12 13:21:33 vpn-client ovpn-952[704]: UDPv4 link remote: [AF_INET]51.15.238.226:1197
Feb 12 13:21:33 vpn-client ovpn-952[704]: TLS: Initial packet from [AF_INET]51.15.238.226:1197, sid=58eb4330 57b29417
Feb 12 13:21:34 vpn-client ovpn-952[704]: VERIFY OK: depth=1, CN=CA
Feb 12 13:21:34 vpn-client ovpn-952[704]: VERIFY OK: nsCertType=SERVER
Feb 12 13:21:34 vpn-client ovpn-952[704]: VERIFY OK: depth=0, O=OVPM, CN=localhost
Feb 12 13:21:42 vpn-client ovpn-952[704]: [localhost] Inactivity timeout (--ping-restart), restarting
Feb 12 13:21:42 vpn-client ovpn-952[704]: SIGUSR1[soft,ping-restart] received, process restarting
Feb 12 13:21:42 vpn-client ovpn-952[704]: Restart pause, 2 second(s)

Using an OpenVPN 2.4 client I am able to use the pull-filter option (new in 2.4) to ignore the server-pushed value

pull-filter ignore "ping-timeout"

Which seems to work; the client merrily sets up the connection.
But back on the server-side it is sticking with it's value of 4s and just drops the client unilaterally, waiting for the client to reconnect. Which it does when its timeout kicks off, but the server still drops again if the connection can't be completed within 4s.

After much promise, ovpm is now inoperable for me and I don't seem to be able to recompile it myself as a local workaround.

@robshep
Copy link
Author

robshep commented Feb 13, 2019

I worked out how to build it locally and testing an modest increase in ping-timeout setting from 4s to 10s which works fine.

My build notes.
https://gist.github.com/robshep/96f46233e03c0f417eeeeb12f1b7d1e8

@cad
Copy link
Owner

cad commented Mar 10, 2019

Sorry for causing you so much burden. But thanks to you now the Wiki has a Development page. 😄

For the timeouts and keepalive settings etc. The reason I picked these values was completely related to the nature of the applications of OVPM in my company.

The wise thing to do is to make these values configurable through OVPM and use OpenVPN defaults as the defaults. I've created #77 for this purpose and closing this issue in favor of #77.

@cad cad closed this as completed Mar 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants