@jimp ok, will do in a few minutes Edit: Created - https://redmine.pfsense.org/issues/11510

@jimp said in Command Prompt output in WebGUI 2.5.0: "top" requires an interactive console to output data on a continual basis. It can't work through the GUI. Since there is no active terminal, it only returns the header info. Thanks - on 2.4.5. I could at least see the "frozen" process tree. Its only cosmetic - if I have a real problem I go to the ssh console. Thanks again for your time (in these days) and regards, fireodo

@bobbenheim Excellent, thanks. I didn't know about the bug tracker!

@gertjan Thanks, this does make sense. So essentially the key is to treat WebGUI session like any other regular traffic and configure as needed using firewall rules. Thanks for pointing me in the right direction.

@viktor_g I have a double-NAT setup, pfSense is the exposed host of another router. I have set up this first router to get a new IP-address every night and a cron job in pfSense to reboot pfSense after that. pfSense is running as a gen1-VM in Hyper-V with a passed through intel-NIC (I350 Series) for WAN and LAN and is the router for my whole network at home.

Those instructions are not even for pfSense. You have broken your installation to the point where the best action to resolve it is to reinstall and restore your configuration.

@lachlanw So I assume, the router does NAT between the pfSense LAN and the computers subnet. Does it also natting / masquerading outbound traffic towards pfSense? Are you able to access the internet from the computer?

@gertjan Thank you so much for your kind information. Much appreciated. Good information you have shared. True, through VPN it is the best way & secure way to access. Once again thank you so much. Lokesh Kamath

@topperharly I´ve found the issue during an deep dive into the config.xml The SSL Certs are declared in the CertManager/ and ACME List, but aren´t stored and aren´t part of the Config Backup. So, after recreating the missing three via ACME , i was able to select them in the GUI. Strange Behavior... but now fixed. sometimes it´s worth to look under the hood ;)

@crock2348 I just came up against this. You can still apply the changes at https://redmine.pfsense.org/projects/pfsense/repository/revisions/e2e4c0d5452f36a3e468e43a78f2cc5316e34174/diff manually to 2.4.5-p1 which should pass the scanner

@jmikulic said in Can't start web gui after reboot: Any idea? yeah, a couple of million. Shall I list them all ? ;) Be aware, you only details your problem with the word .... problem .... :( Most of us have forgotten all possible issues and pitfalls of the very old 2.4.4. 2020 passed, made us focussing on other things, like good VPN access etc. ( but feel free to look at the 2018/2019 parts of the forum - you decided to use an old version, up to you to go to that dusty corner ) So, what about downloading this version ? Maybe your problems persists, but al least there will be another one pfSense user that saw the same thing, and has a solution. You'll see ^^

@teamits Hello Steve, yes I tried with Chrome, Safari, Edge and Firefox and was the same. Then I tried from another computer without Dashlane password manager extensions and works fine, then the problem is the Dashlane extension. Thanks for the support. Enjoy

From the linked page, it's these instructions, right here: To open the firewall GUI, create a firewall rule to allow remote firewall administration. Note: Do not create a port forward or other NAT configuration. Firewall > Rules, WAN Tab Action: pass Interface: WAN Protocol: TCP Source: The IP address or subnet of the client, or an alias containing management hosts/networks Destination: WAN Address Destination port range: HTTP, HTTPS (Or the custom port) Description: Allow remote management Jeff

Thank you sir, I will do more research.

Thanks @Gertjan, for sharing that. The file system appears to be dirty, but since my kids are on the network now I really cannot reboot into single mode.... On my to do list for the weekend. BTW Today I experienced the same problem again (hence my returning to this post and reading Gertjan's comment). I rebooted the SG-1100 and restarted the webgui through console. None worked, the webgui remained unavailable. When I tried to re-apply this trick I found that the webgui setting was already set to 'http'. So I set it to 'https' : after this the webgui finally started working again! It seems that flipping this setting from https to http and back is a trick to force webgui back in business. A bug?