@EOC2611P:

….. but i want to access the pfSense control's interface from wi-fi, i don't want every single IP address connected to my wi-fi to have access to it, but only the IP address leased to my personal laptop.
Maybe i will just try to grant access to "any" and then protect it with a password.

pfSense is always protected by a password.
Re-enforce the access by instructing the DHCP server on pfSense to give your device (laptop) a 'fixed lease (IP)'. Then, use this IP to allow access to the GUI, locking out the rest. All this happens on LAN, of course.
When you're conformable with it - and you'll be doing as I did: had a good laugh when you look at the images you posted above, try accessing the GUI pfSense from WAN.

Hi Phil, thanks for checking that. It seems there was some corruption further down the file so I suspect nonsense was getting passed into the variable or something like that.

I swapped out the disk for a new one and did a clean install. Config restored and all is working as expected now.

Thanks again for your help.

@doktornotor:

Does this file exist? /usr/local/etc/ssl/cert.pem

Yes, it exists.  The problem ended up being the networking+hypervisor setup.  We had LRO enabled and it was causing issues on the pfSense guest.  After disabling it ALL packets were properly hitting the pfSense guest.

Running in to other quarks which I don't quite understand why they were designed this way.  After establishing an IPSec tunnel I'm unable to traverse over that tunnel from the shell of the pfsense box - but if I add a route (which then causes a routing loop), it does.  An example would be to setup an OpenVPN server and have it authenticate against an LDAP server - pfSense can't reach the LDAP server if it's over the IPSec tunnel.  Quick fix to that was adding a route.  Doesn't seem like the right thing to do.

pfSense in this case is used to extend the network to a new location over an IPSec tunnel as well as act as a VPN server at that new location.

Thanks for the reply. That's what I thought but was not sure.

Asking once is just enough…. https://forum.pfsense.org/index.php?topic=100075.0

+1 for using a different browser. Also, unless you changed it, it would be on HTTPS, not HTTP. The browser may not be following the redirect.

Sure, I will try and get that this evening.
Thanks.

Or https://forum.pfsense.org/index.php?topic=98701.0

/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.