User Auth Failed

bpmartin

@blasterspike I'm having the same problem with ovpn_auth_verify (no _async). The equivalent fix seems to resolve the problem, but I can't see where the "...." prefix is coming from. I'm no PHP guy, but the routine it calls to generate ${RESULT} appears to just be returning "OK" (no dots). Yet when I run it from the command line, dots appear.

My fix was to leave the conditional as-is, and insert immediately above it:

[ "${RESULT}" = "...OK" ]] && RESULT="OK" # Remove dots if present

If yours is the fix, is it going into some future update? I don't want to have to keep patching this myself.

blasterspike

Unfortunately I know very little too about PHP to be able to debug this issue.
I don't think that Netgate is aware of this, therefore I don't see a patch coming. I have seen a tendency in their issue tracker that you have to provide the complete debug and point at where the error is for the bug to be taken into consideration.
I have already spent enough time debugging it, hopefully someone more capable on PHP will be able to help us.

I hate too thinking about patching this at every upgrade.

ryoung81

@blasterspike we actually just went ahead and moved our production over to fortigate. No issues :/

bpmartin

Looking into the further, I believe I've found out why it's happening. When ovpn_auth_verify runs the php-cgi command to run /etc/inc/openvpn.auth-user.php, ovpn.auth-user.php or some lower level command may conditionally print dots as a progress indicator. On fast systems, no dots appear. On slower systems, 1 or more dots may appear. Probably they would appear on a fast system too, if the system were under a heavy load.

This also means that the number of dots preceding "OK" is variable. Matching a specific number of leading dots is not reliable. My new patch is:

41a42
> RESULT=$(echo $RESULT | tr -d ".")

The variable number of dots also explains why reports aren't more widespread. It only happens on variably, depending on system performance and load.

bpmartin

I neglected to mention that I'm experiencing this on the current stable release, 2.6.0, built 31/Jan/2022.

bpmartin

@blasterspike I know you've subsequently migrated off of pfSense, but is there any chance you can tell me what release of pfSense you were running when you last experienced this problem?

I have but 13327 open with the developers, but they're rejecting it because they think the report is on an outdated release. I'd like to document which release you were experiencing this problem with, and what hardware you were running pfSense on.

Also, was this the reason you migrated off, or or there other issues?

blasterspike

@bpmartin I'm still using pfSense, I think you are confusing me with ryoung81.

I'm using

2.6.0-RELEASE (amd64)
built on Mon Jan 31 19:57:53 UTC 2022
FreeBSD 12.3-STABLE

In total, I had to edit 2 files with this "....OK" trick to have OpenVPN working again
/usr/local/sbin/ovpn_auth_verify
/usr/local/sbin/ovpn_auth_verify_async

I discovered this problem about User Auth Failed while debugging this other issue
https://forum.netgate.com/topic/171707/openvpn-server-certificate-verify-failed-on-pfsense-2-6-0/3

I don't even think that my hardware is suffering to justify this behaviour, I'm using pfSense at home and the traffic is low.
However this is the box where it is running

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

bpmartin

Apologies for the confustion @blasterspike ... I was obviously reading and writing too early in the morning.

The bug report can be found at:

https://redmine.pfsense.org/issues/13327

It's currently in "Rejected" status because the developer thought it was in regards to an obsolete release. I'd appreciate it if you and others that are on current releases would update the ticket to include that it's affecting you, too. I think it may be performance related, so basic hardware information may be useful too. I just copied my CPU info off the pfSense Dashboard, and added the amount of memory I have.

Right now I'm afraid I have a credibility problem, understandably, since this is a widely used package and I'm the only one reporting it. Showing that more sites are experiencing it might be enough to get it fixed. Especially so since one possible fix is just one line of code that I've already provided.

blasterspike

@bpmartin I have replied to that issue as well. Unfortunately as it is closed, I believe it will go into oblivion...

bpmartin

@blasterspike Thank you for updating the bug. Since Jim Pingle took ownership and rejected it, I'm hoping he'll get update notifications, review it, and consider reopening it. If not, I'll look for other ways to reach out. I suppose you could open a bug of your own, too, if you thought that was a good idea. You could just refer to 13327 and report you're having the same experience on the current release. I'm not sure which approach will be the most effective. We know it's a real bug - it's just that the developers don't.