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.

What about System => Advanced => Admin Access and move the default "443" port to another port. From what I know, the GUI binds to every interface, WAN included. This means that it's listening on WAN port 443 by default, but as you stated : no rule for incoming traffic so : not accessible. You moved the default VPN port from 1194 to 443. I wonder how that can actually work, if already nginx (the GUI web server) is already listening on that port. (or nginx = TCP only and VPN = UDP only ? In that case change your WAN VPN rule to UDP only  ;)) edit : everything has already been explained … yesterday ... https://forum.pfsense.org/index.php?topic=138110.0

I had this when I first setup pfSense…you might find you get a better response if you post in the general question. Not sure of your setup but maybe try OpenDNS as your DNS? What rules do you have setup...the default "Any" rules, maybe rstrict ports to 53, 80 and 443? Are you "VPN'ing" to outside your country? Google can detect you are using a VPN hence the Captcha... Not a great answer but maybe a place to start trouble shooting?

@SunDalf: Nice would be a client, which must not be installed on the client system and runs on all OS. Just execute from an USB stick https://en.wikipedia.org/wiki/Ssh_tunnel#Secure_Shell_tunneling