/tmp/php_errors.txt or maybe /tmp/PHP_errors.txt If there are any errors to report, it goes in that file as ordinary text - easy to view. And the dashboard should report it.

Can't you just authenticate the webgui with RADIUS and do your multi-factor there?

@vbentley: That used to be a dependable solution up to 2.1.5 but not any more for me. I have just done a reinstall-restore from 2.2.4 to 2.2.4 and the WebGUI is OK for up to 1 day, sometimes only a few hours. What packages do you have installed?

@Sn3ak: I found installing pfblockerNG, finding it broken, and telling it to reinstall it removed all previous entries and gave me a working version. Not sure if this will work in your instance. HTH Worked like a charm in 2.2.4

I don't believe it is something anyone has put much thought into. In some places our hands are tied depending on what certain utilities support, but it may be possible to have a format option in general. If someone were to code it up and submit it as a pull request it would likely be approved if it is coded well.

That's awesome. I was under the impression the webGUI didn't interface to BIND. I'll give it a shot.

@jimp: Any command run via Diag > Command does a switch to rw first and then back to ro before returning. Thanks, that solves the mystery of why Diagnostics->Command Prompt could be a lot slower than ssh shell running the same command. What I still don't understand is why switches from rw to ro can be fast (~5s) for a number of hours after booting and then get slow (52s) and stay slow until the next boot.

Thanks. I'm going to remove it. I understand all that. I am just a bit confused as to why the password isn't just left blank. At least it's an easy fix :) Thanks again.

thank you

Under Interfaces Localhost? Quite the old thread you have unearthed, but the answer is yes.

I found this on the web, Nitro Key User authentication on local computers (e.g. Windows, Linux) and networks (e.g. Firefox, OpenSSH, OpenVPN, IPSec, OpenID).

@cmb: The redirect listens on port 80 regardless of your HTTPS port. Just disable the redirect under System>Advanced. That did it! Thank you!

@phil.davis: Status->System Logs, Settings - Reset Log Files - that will make sure those are in current format to be interpreted correctly by current code. This seems to have resolved the issue.  Thank you both for your help!

The best solution is this: @Derelict: Install a certificate signed by a trusted root or tell your browser to trust the certificate. Big problem  ;) : it's won't be 'free'. I bought a domain name, like 'my-domain.tld' (give or take a few $ a year). Then, visit startssl.com to obtain a free valid signed certificate for 'my-domain.tld' and "portal.my-domain.tld" (I did not take the included 'www.my-domaine.tld'). You get all the files needed to install into pfSense. Switch portal authentication to https - no errors for all browsers. Works for me for years now.