2.2.1 and 2.2.2 issue with FreeRadius and OTP - seems like a bug
JasonR2 last edited by
Sorry in advance if I'm posting in the wrong place.
I've been using pfsense in a few applications with excellent success, but I'm recently having a repeatable issue with pfsense 2.2.1 and 2.2.2 when configuring OpenVPN with FreeRadius and OTP. The documentation appears to be accurate and I have no trouble getting it working initially.
If the system reboots, or if I add a user, the authentication of all FreeRadius users will fail until I go to Services > FreeRadius > Interfaces tab, and "Edit" and then "Save" the 127.0.0.1 interface. I don't have to make a change - just touch it basically.
I've been able to reproduce this bug on both 2.2.1 and 2.2.2 versions with both the AMD64 image installed to the hard drive on a VM, and a 32-bit NanoBSD installed on a thin client. The process to most easily duplicate this issue appears to be this:
- Ensure NTP started successfully
- SSH in and really make sure the time matches (since it isn't fair to troubleshoot OTP without this first)
- Try a non-OTP FreeRadius account in Diagnostics > Authentication and make sure it works.
- Try an OTP account. In my experience, after a reboot, it will always fail.
- Go to Services > FreeRadius > Interfaces
- Hit "Edit" on the 127.0.0.1 interface (the only one present in a simple implementation)
- Hit Save
- Hit Save on the next page too
- Confirm by hitting "OK"
- Test the OTP account again in Diagnostics > Authentication – it should work fine now.
Any help would be greatly appreciated.
JasonR2 last edited by
Thanks for moving this to the right place.
I did some more searching, and this post helped isolate the problem, and the last line has a valid workaround:
"chflags schg /usr/pbi/freeradius-amd64/etc/raddb/scripts/otpverify.sh"
On the x86_64 architecture I tested today, the script /usr/pbi/freeradius-amd64/local/etc/raddb/scripts/otpverify.sh gets modified upon reboot so that the first line is just "#!" rather than "#!/usr/pbi/freeradius-amd64/bin/bash". Setting an immutable bit prevents the bad modification, but obviously that could be a problematic workaround to support.
Thanks to grinyas for isolating the issue. I'll set an immutable bit for now so we can keep this in production.