Have a particular IPFire router that drops OpenVPN connection (roadwarrior) every 40s or so for about 12s, then comes back up for another 40s, drops for 12s, and on and on. Don’t have this problem with any other IPFire router (among 15 or so) that I connect to. As soon as I can get onsite, going to try regenerating OpenVPN configuration on target router from ground up and see if that fixes. Other ideas?
OpenVPN has a setting for renegotiating the data channel encryption keys after a certain period of time. If this is misconfigured or if there are issues during the renegotiation process, it could lead to periodic disconnections. You might want to look into the reneg-sec setting in the OpenVPN configuration to see if it’s set around the 40-second mark and consider adjusting it for testing.
Have also a look at the system/OpenVPN logs, this should tell you more about what’s happening.
Wild guess - may be it is related to OpenVPN and a blocked ping?
LOL. Problem is I can’t get connected long enough to really research anything on the router end. My GUI connection to the router drops out just about the time I get in and start to bring anything up. Will go onsite as soon as practical.
And if the default setting is 40s that sounds about right since that is how long before it drops out each time (see original question). At this particular site the renegotiation takes about 12s it would seem. Not sure what the “normal” renegotiation time is, but don’t see this drop out behavior at any other site I connect in to. Would renegotiation normally take this long? It is long enough here that any RDP session, etc times out and pretty much prevents me from doing any real work on the remote network. I don’t normally enable port forwarding 3389 to allow me to RDP to some workstation at the remote site (outside of the VPN tunnel) since that is considered pretty much insecure nowadays.
reneg-sec on the IPFire openvpn server is set to 86400 secs (24 hours).
You can see what the value is by looking in
/var/ipfire/ovpn/server.conf
If the value is defined at 86400 then the server reneg-sec is not the cause of your problem.
When the renegotiation takes place it is done seamlessly, ie the data channel communication is maintained without any interruption during the renegotiation.
The client can also have a reneg-sec value defined but then if that client is having problems with renegotiation then it should have it with any server.
Recently for other purposes I tested out the server with reneg-sec at 86400 and a client with reneg-sec at 30.
Watching the logs, I could see the renegotiation every 30 seconds, which was carried out successfully and quickly (a second or less) and without interrupting the vpn connection, which continued operating.
I don’t know what is happening with your connection but I don’t believe it is related to the renegotiation.
When you are onsite, look through the logs to find out what messages are being shown every 40 seconds when the connection is interrupted. Maybe that will give more insight.
1 Like