OpenVPN: set KeepAlive default settings

[japm48]

Important notices

Before you submit a pull request, we ask you kindly to acknowledge the following:

• I have read the contributing guidelines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I opened an issue first for non-trivial changes and linked it below.
• AI tools were used to create at least part of the code submitted herewith.

If AI was used, please disclose:
I used ChatGPT (model 5.4) to find the relevant files; this text and the code (just two XML lines) are 100% hand-written.

---

Describe the problem

I came across issue #8106 (periodic OpenVPN client disconnections) while trying to migrate a server instance away from "Legacy" OpenVPN.

As indicated, this is solved by setting a couple of KeepAlive options.

In the Legacy version this was set automatically:

core/src/etc/inc/plugins.inc.d/openvpn.inc

Line 550 in 72a8f6b

$conf .= "keepalive 10 60\n";

And in the new version these are not set:

core/src/opnsense/mvc/app/models/OPNsense/OpenVPN/OpenVPN.xml

Lines 355 to 360 in 72a8f6b

	<keepalive_interval type="IntegerField">
	<MinimumValue>0</MinimumValue>
	</keepalive_interval>
	<keepalive_timeout type="IntegerField">
	<MinimumValue>0</MinimumValue>
	</keepalive_timeout>

As a result the corresponding keepalive interval timeout line is missing from the generated config file.
Keeping this new default behavior is highly inconvenient, especially when these options are hidden behind "Advanced mode".

---

Describe the proposed solution

This restores the previous default values in the new interface, which fixes the underlying issue by default.

---

Related issue

If this pull request relates to an issue, link it here: #8106

[AdSchellevis]

If I remember correctly, there's also a default in OpenVPN, are there errors in the log on the latest version?

[japm48]

Ok, so apparently this is because ping-restart is set to 120 by default on the client side:

Source: https://openvpn.net/community-docs/community-articles/openvpn-2-6-manual.html

I am not sure why the server does not have a saner default, as this wrong behavior seems triggered with the default configs...

Anyways, this is on:

• OPNsense 26.1.6-amd64
• server side: version OpenVPN 2.6.19 amd64-portbld-freebsd14.3
• client side: OpenVPN Connect version 3.8.0 (Windows 11)

I attach a the client log here (look for KEEPALIVE_TIMEOUT): OpenVPN_.log

And here are some configs:

• Client config:

dev tun
persist-tun
persist-key
proto tcp-client
auth SHA1
client
resolv-retry infinite
remote [EDITED_WAN_IP] [EDITED_PORT] tcp
lport 0

• Legacy server config:

dev ovpns1
verb 1
dev-type tun
disable-dco
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
script-security 3
daemon openvpn_server1
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto tcp-server
auth SHA1
up /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup
down /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkdown
local [EDITED_WAN_IP]
client-connect "/usr/local/opnsense/scripts/openvpn/ovpn_event.py '1'"
tls-server
server [EDITED_TUN_NET] 255.255.255.0
client-config-dir /var/etc/openvpn-csc/1
tls-verify "/usr/local/opnsense/scripts/openvpn/ovpn_event.py '1'"
lport [EDITED_PORT]
management /var/etc/openvpn/server1.sock unix
max-clients 200
push "route [EDITED_LAN_NET] 255.255.0.0"
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /usr/local/etc/inc/plugins.inc.d/openvpn/dh.rfc7919
tls-auth /var/etc/openvpn/server1.tls-auth 0
persist-remote-ip
float
topology subnet

• New server config:

dev ovpns2
ping-timer-rem
topology subnet
dh /usr/local/etc/inc/plugins.inc.d/openvpn/dh.rfc7919
verify-client-cert require
remote-cert-tls client
server [EDITED_TUN_NET] 255.255.255.0
client-config-dir /var/etc/openvpn-csc/2
client-connect "/usr/local/opnsense/scripts/openvpn/ovpn_event.py '2f97a869-65a5-4425-a7eb-0f3b015d569e'"
client-disconnect "/usr/local/opnsense/scripts/openvpn/ovpn_event.py '2f97a869-65a5-4425-a7eb-0f3b015d569e'"
tls-verify "/usr/local/opnsense/scripts/openvpn/ovpn_event.py '2f97a869-65a5-4425-a7eb-0f3b015d569e'"
push "route-metric 5"
push "route [EDITED_LAN_NET] 255.255.0.0"
persist-tun
persist-key
dev-type tun
dev-node /dev/tun2
script-security 3
writepid /var/run/ovpn-instance-2f97a869-65a5-4425-a7eb-0f3b015d569e.pid
daemon openvpn_server2
management /var/etc/openvpn/instance-2f97a869-65a5-4425-a7eb-0f3b015d569e.sock unix
proto tcp4-server
verb 3
disable-dco
up /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup
down /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkdown
port [EDITED_PORT]
local [EDITED_WAN_IP]

After manually adding the values, the line keepalive 10 60 appears again and the issue goes away.

[swhite2]

Neither the ticket nor this PR seems to explain what the actual problem is. As far as I can see this is only due to visual confusion about timeout reconnects?

[japm48]

Neither the ticket nor this PR seems to explain what the actual problem is. As far as I can see this is only due to visual confusion about timeout reconnects?

The issue is that timeouts should not happen at all on stable links, and they happen repeatedly every few seconds. E.g. any TCP connections over the VPN are immediately broken.

In the "legacy" version, there was a hardcoded line to avoid this (keepalive 10 60).
In the modern version, this is configurable under "Advanced Mode", but the default is now that this line will not appear any longer.
This patch restores the "legacy" behavior by default.

[AdSchellevis]

The issue is that timeouts should not happen at all on stable links, and they happen repeatedly every few seconds. E.g. any TCP connections over the VPN are immediately broken.

Nobody is stating that you shouldn't use the options available, it's just not a generic issue and the old defaults are just different, not better. There might even be situations where the old defaults don't work because some intermediate hop decides to drop the traffic even faster. Tracking the history, the setting was imported from m0n0wall decades ago in a time where NAT issues where probably more common.

[japm48]

The issue is that timeouts should not happen at all on stable links, and they happen repeatedly every few seconds. E.g. any TCP connections over the VPN are immediately broken.

Nobody is stating that you shouldn't use the options available, it's just not a generic issue and the old defaults are just different, not better. There might even be situations where the old defaults don't work because some intermediate hop decides to drop the traffic even faster. Tracking the history, the setting was imported from m0n0wall decades ago in a time where NAT issues where probably more common.

Is it really not a generic issue? Perhaps I am missing something, but in what setup would this now work fine out of the box?

Another data point, pfSense is apparently keeping the old default (keepalive 10 60), see:

• https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/configure-server-ping.html#ping-method
• https://github.com/pfsense/pfsense/blob/master/src/etc/inc/openvpn.inc

Anyways, if you decide not to alter this new default, I respect that (of course), but I would request, at least, to make it not an "Advanced" option.

[AdSchellevis]

it's less about the defaults and more about the rationale of changing anything, usually upstream defaults are the ones advised for the application in question for good reasons.

Before deciding anything, I do want to rule one thing out, what happens if you change the Firewall Optimization to conservative in the firewall advanced settings?

[japm48]

it's less about the defaults and more about the rationale of changing anything, usually upstream defaults are the ones advised for the application in question for good reasons.

Oh, that I can agree with, my argument is indeed that I believe the upstream defaults are wrong.

Before deciding anything, I do want to rule one thing out, what happens if you change the Firewall Optimization to conservative in the firewall advanced settings?

I'll give it a go tomorrow if time permits.

[AdSchellevis]

thanks, I have a hunch, if that's the case, we can discuss next steps.

[japm48]

Quick update: I have not forgotten this, I just haven't found the time for testing again.
I will try next week to have a go at this.

[AdSchellevis]

no problem, take your time.