Option ping-timer-rem is ignored in OpenVPN 2.7-beta2

[mikaku]

Hello,

I've configured OpenVPN 2.7BETA2 on a Rocky Linux 10 (aarch64) and I see that the logs get big because the server keeps restarting by timeout even when there is no client connected at all.

The option ping-timer-rem seems it doesn't have any effect.

The following is an excerpt of the log file:

[...]
2025-10-20 10:40:42 Server poll timeout, restarting
2025-10-20 10:40:42 net_addr_ptp_v4_del: 192.168.4.1 dev tun0
2025-10-20 10:40:42 SIGUSR1[soft,server_poll] received, process restarting
2025-10-20 10:40:42 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
2025-10-20 10:40:42 TUN/TAP device tun0 opened
2025-10-20 10:40:42 tun/tap device [tun0] opened
2025-10-20 10:40:42 net_iface_mtu_set: mtu 1400 for tun0
2025-10-20 10:40:42 net_iface_up: set tun0 up
2025-10-20 10:40:42 net_addr_ptp_v4_add: 192.168.4.1 peer 192.168.4.2 dev tun0
2025-10-20 10:40:42 Could not determine IPv4/IPv6 protocol. Using AF_INET
2025-10-20 10:40:42 UDPv4 link local (bound): [AF_INET][undef]:6000
2025-10-20 10:40:42 UDPv4 link remote: [AF_UNSPEC]
2025-10-20 10:42:42 Server poll timeout, restarting
2025-10-20 10:42:42 net_addr_ptp_v4_del: 192.168.4.1 dev tun0
2025-10-20 10:42:42 SIGUSR1[soft,server_poll] received, process restarting
2025-10-20 10:42:42 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
2025-10-20 10:42:42 TUN/TAP device tun0 opened
2025-10-20 10:42:42 tun/tap device [tun0] opened
2025-10-20 10:42:42 net_iface_mtu_set: mtu 1400 for tun0
2025-10-20 10:42:42 net_iface_up: set tun0 up
2025-10-20 10:42:42 net_addr_ptp_v4_add: 192.168.4.1 peer 192.168.4.2 dev tun0
2025-10-20 10:42:42 Could not determine IPv4/IPv6 protocol. Using AF_INET
2025-10-20 10:42:42 UDPv4 link local (bound): [AF_INET][undef]:6000
2025-10-20 10:42:42 UDPv4 link remote: [AF_UNSPEC]
[...]

and here is the server configuration at /etc/openvpn/server/vpn_0.conf:

tls-server 
dev tun
proto udp
port 6000

cert linux.crt
key linux.key
dh none

ifconfig 192.168.4.1 192.168.4.2
route 192.168.4.0 255.255.255.0

push "route 192.168.4.1 255.255.255.255"
push "route 192.168.3.1 255.255.255.255"
push "dhcp-option DOMAIN XXXXXXXXXX"
push "dhcp-option DNS 192.168.3.1"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "dhcp-option WINS 192.168.3.1"

<peer-fingerprint>
<REDACTED FOR PRIVACY>
</peer-fingerprint>

# notify clients when you restart the server to reconnect quickly
explicit-exit-notify 1

# 1400 avoids problems of too big packets after VPN encapsulation
tun-mtu 1400

# ping every 10s, restart if no data received for 2 minutes
keepalive 10 120
ping-timer-rem
persist-tun

verb 1
log /var/log/openvpn_0

Any idea how to make the server just idle until a client is connected?

Thanks.

[schwabe]

This is NOT a server config (no --server). You are doing a p2p config. This will also only accept a single peer. The behaviour you are seeing is expected in p2p mode.

[schwabe]

On a related note, we should print warning if you have push commands in a p2p config. A setup like that is not expected to work very well as negotiation will fail.

[mikaku]

The same configuration I had on an OpenVPN 2.4 and the server didn't restart by timeout all the time, only if a client lost its connection while connected. So, it looks like this has changed between 2.4 and 2.7.

Why you cannot keep the same behavior on "p2p" mode?, I think it shouldn't be difficult to make the option ping-timer-rem also work on this mode.

Regarding your comment:

A setup like that is not expected to work very well as negotiation will fail.

Why you say that? it's working fine, besides the annoying effect to have logs growing excessively on the server side.

[cron2]

A setup like that is not expected to work very well as negotiation will fail.
Why you say that? it's working fine, besides the annoying effect to have logs growing excessively on the server side.

Basically, it's an unsupported and un-tested configuration. P2P mode operates on the assumption "both ends know their configuration", P2MP mode (--server) is for "the server can send PUSH info". This is what we test, and when we change protocol and negotiation details, this is what we ensure will keep working - which is hard enough, with people expecting full compatibility between 2.3 and 2.7 in arbitrary combinations.

There are many different ways to run OpenVPN that have historically worked due to the way the code is written. "not officially supported" means, basically, it could break at any new major version, so we recommend against doing things in certain ways.

[schwabe]

OpenVPN 2.4.x is a long time ago. In this case basically 3 major versions ago. There might be some change that caused this change.

It would be really helpful if you could try different OpenVPN versions (or even better do a git bisect) to narrow down when the behaviour was introduced when ping-timer-rem stopped working.

A setup like that is not expected to work very well as negotiation will fail.

Why you say that? it's working fine, besides the annoying effect to have logs growing excessively on the server side.

Because I have written the negotiation code and p2p instance is not going to negotiate any of the newer features with a peer that is using pull. Ie no cipher negotiation, no new data channel features, no new security features.

[mikaku]

OK, it look like it's time for me to change the way I configure OpenVPN.
Thank you very much for your assistance.

[schwabe]

It would still be good to understand when the regression with ping-timer-rem was introduced.

[mikaku]

It would still be good to understand when the regression with ping-timer-rem was introduced.

Ah, yes, that would be awesome, as it would give me sometime while I make all the changes in my configurations. :-)

[schwabe]

@mikaku there are two issues here that you seem to be mixing up:

• ping-timer-rem no longer working. This is something we want to fix. And we are asking for your help if you know when this stopped working
• using p2p with push, that is not supported and will not be in the future either

[mikaku]

ping-timer-rem no longer working. This is something we want to fix. And we are asking for your help if you know when this stopped working

I can only say that it is currently working on a Rocky Linux 9 (RHEL9) which comes with the OpenVPN package from EPEL openvpn-2.5.11-1.el9.x86_64. But it no longer works on a Rocky Linux 10 (RHEL10) which comes with the OpenVPN package from EPEL openvpn-2.7_beta2-1.el10_0.aarch64 (neither with beta1).

As you can see the architectures are different. I guess this is not the problem.

using p2p with push, that is not supported and will not be in the future either

OK. That won't be a problem as soon as I completed the changes to go to --server mode.

[mikaku]

UPDATE:

I have a Fedora 41 with the OpenVPN package openvpn-2.6.14-1.fc41.x86_64 and I can confirm that in this version the option ping-timer-rem is still working.

This is the configuration file in /etc/openvpn/server/vpn0.conf (if it helps):

port 6000
proto udp
dev tun

ifconfig 192.168.4.1 192.168.4.2

tun-mtu 1500
tun-mtu-extra 32
mssfix 1450

secret vpn0.key
cipher AES-256-CBC
max-clients 1

# restart control
keepalive 10 120
persist-key
persist-tun
ping-timer-rem

# no compression
compress

# UID
user nobody
group nobody

# verbosity
verb 1
log /var/log/openvpn_0