Valid OpenVPN client connections rejected due to extraneous output to ovpn_auth_verify
OpenVPN was observed rejecting client connections that were previously accepted and had not expired. Research lead to /usr/local/sbin/ovpn_auth_verify. When using TLS, this code calls
/usr/local/bin/php-cgi -q /etc/inc/openvpn.tls-verify.php and compares the response to "OK". In my case the response received was "....OK", which did not match and caused the connection to be dropped. A log file is attached to this report.
Others have experienced the same problem, as shown in the last half of the forum discussion at: https://forum.netgate.com/topic/171706/user-auth-failed/5
Issuing the same php-cgi command manually showed that the leading dots are apparently a progress indicator for a (not very) long running process. This suggests that the problem will only impact slower or heavily loaded systems.
As a workaround I altered ovpn_auth_verify as follows as compared to git commit 8f2f85c:
@41a42 > RESULT=$(echo $RESULT | tr -d ".")
A copy of the modified ovpn_auth_verify file will be attached to this report.
I first observed and patched this problem 15/Jul/2021. I am available to test proposed changes.
Updated by Jim Pingle about 1 month ago
- Status changed from New to Rejected
There isn't enough information to go on here. This is working for us in the lab and for most if not all users of the current release.
The linked forum thread references 2.4.5 which is very outdated. We can only accept reports against the most recent release.
If you can find a way to replicate it on a clean installation of a current release, or ideally on the latest development snapshot, please provide the entire procedure to reproduce the problem.
Updated by Brian Martin about 1 month ago
I neglected to mention in the bug report and the forum thread that I'm on release 2.6.0, the current stable release. Further, the affected file, ovpn_auth_verify, has not been subsequently changed from the master according to GitHub, so I'm at the very latest version of that file at least.
Regarding replicating the problem, I think the key is the hardware I'm running it on, and the fact I'm using TLS.
Here are excerpts from the pfSense dashboard that may help on the hardware side:
CPU Type Intel(R) Atom(TM) CPU C2758 @ 2.40GHz 8 CPUs: 1 package(s) x 8 core(s) AES-NI CPU Crypto: Yes (inactive) QAT Crypto: Yes (inactive) Memory: 4G Current load average: 0.14, 0.19, 0.16
So, an old system but perfectly adequate for my needs except for this one issue.
I'm using TLS-verify, which causes ovpn_verify_auth to take a different path and call /etc/inc/openvpn.tls-verify.php. I don't know enough PHP to understand the script well, but I see it calls openssl in several places, and openssl often prints dots as a progress indicator. This may be the source of the stray dots that you saw in the log attached previously.
I don't have a lab system to test on, and I'm somewhat hesitant to move off of STABLE on my production system, but I have good backups and can do that if you think that is necessary.
I'll attach a copy of my OpenVPN configuration (hopefully adequately sanitized -- please alert me if I've published anything sensitive) so you can see all my settings.
The problem occurs every time without my patch, and never occurs with the patch. Some others are seeing it too, although not very many.
I've previously offered to test patch candidates. How else can I help you reproduce the problem? I'm ready to assist in any way I can.
Updated by Massimo Vannucci about 1 month ago
I'm experiencing the exact same problem reported by Brian Martin.
Unfortunately I don't have enough knowledge of PHP to understand why it returns a "....OK" for us, so it is difficult for me to tell you how to reprodure the steps.
2.6.0-RELEASE (amd64) built on Mon Jan 31 19:57:53 UTC 2022 FreeBSD 12.3-STABLE
Intel(R) Celeron(R) CPU J3160 @ 1.60GHz 4 CPUs: 1 package(s) x 4 core(s) AES-NI CPU Crypto: Yes (active) QAT Crypto: No 4GB of RAM
Let me know if there are other tests I can run to help everybody to fix this issue.