[Mostly Solved] "TLS: soft reset" every 60-61 minutes - causes 30 sec outage

Finger79

TLS: soft reset sec=0 bytes=16110227/-1 pkts=29432/0

This is a recent problem that just started happening. I have a persistent OpenVPN client on pfSense connected to my 3rd party VPN provider. Every hour or so, there is an outage, and it appear to do a soft reset then a new connection.

I've read that OpenVPN renegotiates keys every hour, but this isn't supposed to cause an outage. Plus, this just started happening a week or two ago. It also doesn't happen (that I know of) when I connect to my VPN provider directly from a client computer.

I set log verbosity to 5 to try to find the culprit, but everything seems fine.

Apr 18 08:15:13 openvpn 4285 Initialization Sequence Completed
Apr 18 08:20:36 openvpn 4285 PID_ERR replay-window backtrack occurred [8] [SSL-0] [00000000_00005666688889999999>>>>>>>>>>EEEEEEEEEEEEEEEEEEEEEEEEE] 0:1183 0:1175 t=1492518036[0] r=[0,64,15,8,1] sl=[33,64,64,528]
Apr 18 09:15:11 openvpn 4285 TLS: soft reset sec=-1 bytes=43442644/-1 pkts=72293/0
Apr 18 09:15:11 openvpn 4285 WARNING: file '/var/etc/openvpn/client1.up' is group or others accessible

^ For example, at 8:15 the "Initialization Sequence Completed" and everything was groovy. Then 5-10 minutes later, a "PID_ERR" happens. No idea what that is. Then nothing happens in the logs for about 60-61 minutes until the next "TLS: soft reset"

Side question: The warning on client1.up seems like it should be addressed. That refers to the username/password. I'd read in the OpenVPN manual that those things should be chrooted or whatever to restrict read access from other processes.

Finger79

Bumping to update. I read the OpenVPN 2.4 Manual more thoroughly.

OpenVPN defaults to renegotiating keys every 3600 seconds (1 hour), possibly to mitigate some attacks such as Sweet32 on 64-bit block sized ciphers such as Blowfish, which is the default cipher. Unless the reneg-sec 0 directive is specified to disable time-based renegotiation, it will renegotiate the keys. I had just never noticed an outage before, which is why it was strange to me with the disruptive outage every hour.

Since I'm using AES cipher (128-bit blocks), the Sweet32 attack is automatically mitigated (at least within reason), so I set the directive to reneg-sec 0 which disables the renegotiation based on elapsed time. In its place (just out of an abundance of overkill paranoia), I set the directive reneg-bytes 1073741824 so that keys are renegotiated every 1 GiB, which is more reasonable, and I may increase that in the future yet. Unless I'm downloading an ISO or something, I could go an entire day or two before 1 GiB of traffic is moved, so it's less disruptive. Streaming video like YouTube isn't affected by key renegotiation since it buffers 3-5 minutes at a time.

This is what I currently have in the Custom Options in the GUI:

# Advanced Configuration Settings from GUI
remote-cert-tls server
auth-nocache
tls-version-min 1.2
reneg-sec 0
reneg-bytes 1073741824

db22

I'm having the same issue, and would like to try your fix. I inherited our PFsense/openVPN environment and am still learning the ins and outs of it. Just to be clear, I would:

1. Log into PFsense >VPN >OpenVPN
2. Under the Servers header, Actions >Edit
3. Scroll to Advanced Configuration, and paste this into Custom Options, and save:

Advanced Configuration Settings from GUI

remote-cert-tls server
auth-nocache
tls-version-min 1.2
reneg-sec 0
reneg-bytes 1073741824

After doing this, will I need to re-issue OpenVPN installers for our employees? Or will this start to take effect right away?

Thanks in advance

Finger79

pfSense 2.3.x uses OpenVPN 2.3.x. pfSense 2.4.x (still in Beta) uses the newest OpenVPN, 2.4.x, and I've found that key renegotiation is much faster and smoother in the 2.4 version of OpenVPN, so I can't wait until pfSense 2.4.0 is ready to ship.

At any rate, my thread was mostly about the Client configuration, but some directives apply to Server configuration as well. The most important directive to use is reneg-sec 0 to disable the timeout every 3600 seconds (1 hour). I've since disabled the reneg-bytes 1073741824 directive since it got to be annoying, since it still takes about 1 minute to renegotiate.

I'm not sure if remote-cert-tls server applies to a server configuration (in fact, it may not).

tl;dr: the most important directive to use is reneg-sec 0 to disable the key renegotiation timer.

Re: your question about having to re-issue OpenVPN installers to all employees: I doubt it. It really depends on what you have in the employee configuration files. reneg-sec 0 in the server config should disable it for the connection unless your client configs have some other number set in reneg-sec.