@doktornotor: Generally, a sign of your external auth failing badly. When the GUI cannot validate that the user has privileges to do whatever he's trying to do, things are very slow. Hi, Thanks for Reply, I am using the Built in PFSense users. Is there anything that I need to do to speed this up? I mean any settings that I need to check? Thanks, Ameet Parse

Answered about 4984 times. Block access to "This Firewall" webGUI port on the interfaces you want to block.

Hi, Thanks for the reply on this post. @Gertjan: @loppa#1337: From what little I know we access the webGUI through "VLAN30_GREENMANAGEMENT". There is also a connection on a configured port 4433 to access this site. This can't be true. You set it up. You should know. port 4433 isn't standard, https could be anything, but is 443 by default (why changing it ?) I know that 443 is default, and as I stated in my first post. This was setup by a project with very little handover. So you are right in the regard that is my responsebility.  ;) Why port 4443 was set I don't know. But from the server I can access this server this has been the URL that I have used. @Gertjan: @loppa#1337: The server which we used to access the webGUI is on VLAN30 as shown on the second picture. Can anyone give me an advice were to start trobleshoot? I want to verify if the service that runs the webGUI is down or not. I guess this doesn't run on Apache/Tomcat? How to verify if this is related to a certificate issu since it runs on HTTPS? Neither Apache nor Tomcat. You have SSH access, right ? Take option 8. Type ps ax | grep 'lighttpd ' and you see what up and running. Hopefully this will help me out to sort out the web page issue. Is this a (service "service_name" start) command? @Gertjan: Btw: telnetting to a 'ssh' port-connection makes no sense. You should use a ssh-client program to connect to a ssl port. Using "2.1.5" is 'only for the experts' (and still, they won't - live is just to short). I hope my advise is still valid for this ancient version. I knew this by the time i posted it. But thanks for pointing out my lack of network knowledge!  ::) I am also aware of the version. But this system is soon to die, so no need to change something that (used to)  work(s). Hopefully your advice will help me out. Thanks a lot!

This https://forum.pfsense.org/index.php?topic=98701.msg552794#msg552794 will help you.

@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