Yes the IP is in scope - but the firewall gui which should never be available on that IP should not be… You turn on pfsense out of the box there is NOTHING open on the wan, ZERO services available - shoot it does not even answer a ping. Any traffic you allow inbound would be involved in the scan,not services that would never be available on that public IP.. You creating a firewall that allows access to the gui from the wan is what would put it in scope - why would you do that... There is ZERO anything pci compliance that would suggest you would open up a devices admin gui to the public internet.. A pentest against this IP would be in scope... They can pentest all day - but you opening up the web gui to the public should of never happened.  If they can access the webgui via a pentest when you have not allowed it then that would be in scope - and would be a whole shitcan of worms.. But you creating a specific firewall rule that allows access to the gui or any any to the wan IP is just not correct way to do this sort of scan or any sort of pentest or compliance test at all. Like saying hey we want to test the lock of your door.. Unlock it please - oh yeah that lock doesn't do shit, it opened right up... A pentest or compliance test is against service that would be open or finding stuff that is open and should not be. auditor: Hey you have ntp open on port 123 user:  Yeah we need that auditor: Ok it must meet xyz if your going to have it open. user: Ok we will do xyz auditor:  Ok scanning, yup its version X, it doesn't allow that or this - your good user: thanks. auditor: Hey you have ntp open on port 123 user: Oh shit really -  we don't need that.  Closed audiotr: Ok let me check - yup no ntp anymore your good.

based on https://forum.pfsense.org/index.php?topic=144026.0 i changed: /etc/inc/system.inc         if ($captive_portal !== false) {                 $nginx_config .= "\tlimit_conn_zone \$binary_remote_addr zone=addr:10m;\n";                 $nginx_config .= "\tkeepalive_timeout 0;\n";         } else {                 $nginx_config .= "\tkeepalive_timeout 75;\n";    <--------- 75s         } to this:         if ($captive_portal !== false) {                 $nginx_config .= "\tlimit_conn_zone \$binary_remote_addr zone=addr:10m;\n";                 $nginx_config .= "\tkeepalive_timeout 0;\n";         } else {                 $nginx_config .= "\tkeepalive_timeout 0;\n";  <------------ changed to 0s         } and it seems to do the trick?

Have a look at this Captive Portal !

@Clouseau: ….. Is there any work around to fix this? Yep. Telling us more / the whole story. The error says that an instance of the GUI is already running, thus the 'bind' error - but probably not in a good shape. Check out the logs files after booting. Something must show up that is not "normal". edit : I can rip out the WAN cable (WAN connection for me is a DHCP client, connected to an up stream ISP router) and this does not break my GUI. pfSense works just fine (well, sort of) without an enabled WAN connection, because,remember, when pfSense was started the very first time, right after you installed it, there was NO WAN connection setup, and you had to use the GUI to setup LAN first.

DOH!!  Couldn't see the forest for the trees… Thanks. Looked at it so long and it was right in front of me.

Tested, all fixed. Good show Steve.

I don't know if this will help or not but I had similar issues recently with several pfsense firewalls I have deployed.  It ended up being my Bitdefender antivirus on my laptop that was "protecting" me and causing the web gui to come back with the empty response.  I have to either disable the protection now or add all the sites/ips to the safe list to access the firewalls.  Looking for a new A/V software program now too…

Dude if your box has been compromised and remoted.. What is 2FA going to do for your password to your firewall?  And how would they know your password? You storing it in clear text on your machine.. I think your tin foil hat is a bit too tight really…  But as stated if you want to really lock it down - only allow vpn in.. to hit your gui, and use OTP for that...

Why don't you just set a reservation for such devices so when they boot, they always get the same IP.. Then you don't need a webpage to look you will KNOW what IP said device is.. OR just access them by name if you have pfsense set to register dhcp leases. Best of both worlds - set reservation so pi1 is always 192.168.1.100 for example.. And then access it via pi1.yourlocaldomain.tld

I have the same problem with the 2.4.2 in the french WebGui. The Gateway list is empty. But it works well in English WebGui. Try to change language in System/General Setup.

Problem solved with 2.4.2**-RELEASE-p1** version 8) Good job PfSense team.  ;D

Add the following in Additional RADIUS Attributes (REPLY-ITEM) Class := admins

@KOM: i dont know is it possible, if ya how can i do it. I don't know.  That looks more like a development question, not pfSense specific, and it may be outside the scope of these forums. thanks, i solved the Problem. there is two solution: i could use tcpdump to see all the traffic including data which i send from my Computer. using tcp socket finally i choosed second way, wrote a tcp socket as Server in c and execute it from console. Now i can send commands through tcp to second System (my Gateway) with some Parameters and execute the Shell script with These parameters.

Hey look at that!  It works! Thanks so much Gertjan!!

@johnpoz: Pretty sure that is the default… Do you have this checked or not checked? Under System Advanced.. Enable webConfigurator login autocomplete When this is checked, login credentials for the webConfigurator may be saved by the browser. While convenient, some security standards require this to be disabled. Check this box to enable autocomplete on the login form so that browsers will prompt to save credentials (NOTE: Some browsers do not respect this option). I  have now checked this settings and disabled autocomplete , chrome is not offering to save password now but Mozilla still does. Thanks  for your help.

I don't think so, but let me check

For future Putty>>Restart Web Configurator I had a similar issue once and this fixed it