Setting tls-timeout to 0 (zero) leads to traffic spikes and anomalous behavior

[nemesifier]

Describe the bug
Inadvertently setting the tls-timeout option to zero generates traffic spikes and anomalous behavior which can stress the underlying network infrastructure.

To Reproduce

This is the config I was using (replaced some sensitive info with asterisks):

nobind
persist-key
persist-tun
pull
tls-client
auth SHA1
ca /etc/x509/ca-1-******.pem
cert /etc/x509/client-*******.pem
cipher AES-128-CBC
dev gw2_staging_udp
dev-type tap
fragment 0
keepalive 10 60
key /etc/x509/key-******.pem
log /var/log/gw2_staging_udp.log
mode p2p
mssfix 0
mute 20
proto udp
remote *********** 1199
reneg-sec 0
resolv-retry infinite
tls-timeout 0
verb 3

Expected behavior

I am not sure why I had set tls-timeout to zero, maybe it was a mistake, it doesn't seem to make sense.
I would expect OpenVPN to let me know if this is a mistake and fail.

However, the daemon starts but cannot initialize the VPN session successfully. In the meanwhile the IT team on the remote site reported anomalous traffic that is causing issues to their firewall and even denying the traffic causes issues. This is probably an issue with their firewall that we are going to report to the firewall vendor, but it's nonetheless something that I wanted to let you know.

If I set tls-timeout to >= 1 the VPN session instantiates successfully and no anomalous traffic is observed.

My impression is that setting this value to zero should not be allowed.

Version information (please complete the following information):

• OS: OpenWrt 22.03
• OpenVPN version: 2.5.7
• Peer: PfSense 2.5.2, OpenVPN 2.5.2

[schwabe]

Yeah tls-timeout 0 can work if you have incredibly fast setup and there is always the next packet but generally a tls-timeout of 0 does not really make sense. You basically recreated the 500 mail radius problem OpenVPN does not really do hand-holding, so if you want stupid, give the user something stupid. We might still want to ignore 0 or error out.

[cron2]

OpenVPN does insane amounts of hand-holding on option sanity... :-) - so indeed, it would make sense to require n >= 1 here...