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

After uninstalling Snort the issue has gone away for me.

Huh. Must have missed the release announcement. I'll drop it in and re-test.

Yeah it's just weird that it doesn't happen here, the lines are always there. The closest I get to a problem is that the number labels kind of move up/down a little as it updates, but only slightly. And that only happens on Mac. Probably something that either FF will notice/fix or will be fixed next time we update the graphing library.

"if you are not careful you could get back a answer that you didn't actually want." Which is why is best to always use FQDN ;)  Which is also why I am not personally a fan of search suffix even ;)  You should always use fqdn to be sure!

I assume his isn't connected to the web?  If so, port forwarding to the gui would also be insane.

@gustavovilaverde: [2.3.3-RELEASE][admin@fw.local]/usr/local: netstat -na | grep 4343 The service is not working. You don't know that  ;) TEST if it runs (another port ?) and check when it start in the logs, and see if and why it fails. @gustavovilaverde: The service on port 4343 should be listen. I agree. As said above, pfSense isn't on strike. It will start de web server (web GUI), up to you to see why it bails out (see logs - always the logs - problem ? => see the logs  ;D) Use also ps ax | grep 'nginx' (you will see the used config files - check them out) sockstat -l | grep 'nginx' (to see all the ports used by nginx)

Yes it was me… ::) There is a setting "Formatted/Raw Display" in Status> System> Logs> Firewall> , which I must have accidentally turned on.

You are right, that is a little weird. I just pushed a fix, which will be in 2.4.2 and whatever 2.3.x release happens next. https://redmine.pfsense.org/issues/8069

Ok, I solved the issue. When you are using VM's, be sure the network interface on your host computer did not assign the same address that you assigned for the LAN address of your pfSense firewall. I assigned the network range on VMnet5 to 172.16.1.0/24. Using that information, VMWare assigned the first available IP 172.16.1.1 to the host VMnet5 interface. Not knowing this, I assigned the LAN interface of my pfSense to 172.16.1.1. I changed the static IP of my host VMnet5 interface to 172.16.1.2 and now I can connect to the WebGUI!

Thank you for the quick response.

Thank you for your time. I'll try the reset in a few min. Still not that good with *nix systems. First use of pfSense lasted 3 years, got it set up in about a month and left it alone after that. Power went out during an update, oh the joys of nuke and pave. https://www.securifi.com/almond http://www.tp-link.com/us/products/details/cat-5506_Touch-P5.html https://www.reddit.com/r/raspberry_pi/comments/1lfkvm/miniature_linux_firewall_with_builtin_screen/ But those are toys. When you get up to Enterprise class systems, they use: https://www.google.com/search?tbs=isz:l&tbm=isch&q=rack+mount+console&chips=q:rack+mount+console,online_chips:server&sa=X&ved=0ahUKEwjX297o75jXAhWBx4MKHfy2Dr4Q4lYINSgO&biw=1680&bih=896&dpr=1 Just because it has not been done before, dose not mean it's not useful. I'm using a IBM/lenovo ThinkCentre (9481-a4u if it matters), the console has been plugged into it for the last few days. After I get it set up, I agree, the screen is not going to do much good. The ThinkCentre will be unplugged from the KVM. In the meantime, having full control at one spot would help a lot.

@Dalesjo: If I may be so bold i would like see a solution with a checkbox in System / Advanced / Admin / Access saying something like, "only allow access through Lan Interface IP". Which would change the current listen 443 ssl; to listen 192.168.0.1:443 ssl; (or whatever your lan ip number is) in /var/etc/nginx-webConfigurator.conf And after some time you renumbering your subnets, change LAN interface IP and BAM! You have no WebGUI. And no means to reactivate it, because this setting is, you know, in WebGUI. Also - restricting bind to only 1 IP is very restrictive in administrative perspective - I had multiple situations when I needed access to WebGUI through non-LAN interfaces. Also - Captive Portal… Considering 'OpenVPN on TCP/443' is pretty popular scenario, but definitely not standard (and considered ''advanced'') - this collision should be resolved only by moving WebGUI binding to some other than 443 port and disabling autoredirect rule.

@electronm: I just upgraded to 2.4.1 today, and when I hit the add user button on user manager it edits the admin user versus adding a new user.  Any thoughts? It's your browser that pre-fils in some fields Username and Password. Just removes the "admin" etc and put in place your Username and password (twice) etc. It will work. It did so for me, using 2.4.1 - the user was created, the admin NOT edited.

The password show in the xkcd comic is extremely difficult to crack. Even if an attacker learns that the password is made of dictionary words slapped together it doesn't help him much because then he has to guess the number of components used and the exact length of the plaintext password. Even if he manages those he runs against a combinatorial explosion of different word combinations and it's pretty much as hard as a simple brute force attack. Please don't try to tell me that pre-calculating plain text words into password hashes would help with such multi-component passwords, if such thing was possible the hash function/password scheme would break immediately and completely.