@SteveITS Thanks for pointing that out! That is indeed very close to what i need. The customisable message will do fine for my clients, i hope it will allow for an image to be put into it.

And my nerdy self would still like to replace the pfsense logo with something else. So i could be able to have a clean black login screen with merely a login prompt and a HAL9000 eye staring at me, for example :-)

Updated for pfSense CE 2.8.0

https://github.com/HVR88/pfSense-Patches

EDIT: Figured it out. Evidently, it is unwise to plug in a second WAN source before the interface is configured. Unplugged it and walla...working. Configured and it still works.

@Gertjan thanks. I managed after doing this post. 😊

@w0w
I used tail -f /var/log/system.log after restarting php-fpm

May 30 11:23:32 Obamium-fw rc.php-fpm_restart[87304]: >>> Restarting php-fpm May 30 11:23:32 Obamium-fw check_reload_status[88770]: check_reload_status is starting. May 30 11:26:47 Obamium-fw nginx: 2025/05/30 11:26:47 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /widgets/widgets/interfaces.widget.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:26:53 Obamium-fw nginx: 2025/05/30 11:26:53 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/status_logs.php" May 30 11:27:02 Obamium-fw nginx: 2025/05/30 11:27:02 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /widgets/widgets/interfaces.widget.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:27:18 Obamium-fw nginx: 2025/05/30 11:27:18 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /widgets/widgets/interfaces.widget.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:27:33 Obamium-fw nginx: 2025/05/30 11:27:33 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /widgets/widgets/interfaces.widget.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:27:49 Obamium-fw nginx: 2025/05/30 11:27:49 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /widgets/widgets/interfaces.widget.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:28:05 Obamium-fw nginx: 2025/05/30 11:28:05 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /widgets/widgets/interfaces.widget.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:28:20 Obamium-fw nginx: 2025/05/30 11:28:20 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /widgets/widgets/interfaces.widget.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:28:25 Obamium-fw nginx: 2025/05/30 11:28:25 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /getstats.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:28:30 Obamium-fw nginx: 2025/05/30 11:28:30 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /getstats.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:28:36 Obamium-fw nginx: 2025/05/30 11:28:36 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /getstats.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/" May 30 11:28:36 Obamium-fw nginx: 2025/05/30 11:28:36 [error] 81351#100414: *675 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.168.1.251, server: , request: "POST /widgets/widgets/interfaces.widget.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "192.168.1.1", referrer: "https://192.168.1.1/"

Or do you mean another file?
And are there logs from php-fpm that I can maybe look at? If so, where can I find them?

@luckman212 said in WebGUI populates syslog when dashboard running:

but in my opinion, "normal" nginx access logs belong in /var/log/nginx/access.log like on a standard system,

A normal FreeBSD, or actually any OS, true, and that folder and file even exist.
Or, pfSense isn't 'normal, it groups all log files into the same /var/log/

That said, if you trust your devices - trust yourself and those who access pfSense, then there is nothing that can stop you from doing what you want : change the default pfSense behaviour.

Have a look at /var/etc/nginx-webConfigurator.conf - probably line 22.

Because it's just for you, no need to create a

d446ed0c-d5e6-4597-ae56-9db90af50e4f-image.png

go ahead a change this one : here it is.

and I get it, that "Status > System Logs > System > GUI Service" log only has - default - 2000 entries are so, which means "useful info" will be gone pretty fast. 👍 to send it to a remote syslogger right away, and your internal pfSense drive will say "thank you". Knowing that some of us use internal drives that just 'die' if to much solicited ...
I'm pretty sure this access_log option permits you to do do.
Best solution imho would be : make you own patch, and put it into the System > Patches.
Then click on it, and your own patch is active. (you will have to restart the nginx web server process)
Click again, and your pfSense is 'native' again.

Anyway, that is what I would do ^^

@Gertjan thanks for your continuous help! I ended up just restarting the GUI from the console (option 11) and this somehow fixed the issue....I am no longer getting the time out error and can use the https link.

[filed as https://redmine.pfsense.org/issues/16163]

After a ~month of correctly displaying the v6 gateway state, a reboot of pfSense again causes the widget to incorrectly display the state. WAN_DHCP6 is the active v6 gateway, however the gateway address shows as a ~ and the default gateway globe icon does not appear.

Runnining 24.11 + System_Patches 2.2.20_4 as before.

7f713db0-e55f-4dc7-bb14-3096663fdbe4-image.png

Output from previous post's script is consistent with widget display.

gateway: WAN_DHCP6 ... friendly iface: wan ... isdefault: false ... gateway status: enabled ... get iface gateway: '' gateway: WAN_DHCP ... friendly iface: wan ... isdefault: true ... gateway status: enabled ... get iface gateway: '99.121.58.1' gateway: E1V95_LTEGW ... friendly iface: opt12 ... isdefault: false ... gateway status: enabled ... get iface gateway: '192.168.95.1'

netstat -rn output differs from the case where the widget correctly displays the output in that the "S" flag for the v6 gateway does not appear.

[24.11-RELEASE][admin@pfSense.home.arpa]/root: netstat -rn | grep default default a.b.c.d UGS igc0 default fe80::be9a:8eff:fe0b:3b81%igc0 UG igc0

System>Routing>Gateways appears as follows.

1b3f964f-028b-4a9a-8a17-87b2c07ff75c-image.png

@javierrz said in Can someone help me please? I can't access to pfsense web GUI.:

@bmeeks
I managed to get it to work following what you told me. I configured the LAN interface correctly, and it finally worked, and I added the route to Windows. However, I don't understand why it cannot be accessed from the other interface OPT1, which was the one I was trying to use to access the GUI despite having done "the same configuration".

In a default pfSense install, only the LAN interface gets the rule which allows all inbound traffic (including to the GUI interface). That's the anti-lockout rule. Optional interfaces such as OPT1, OPT2, etc., have zero rules applied to them and thus all inbound traffic is blocked unless a rule is created to allow it. Stated another way, only the LAN has some pre-configured rules applied to it out of the box that allow communication to the GUI and also allow any LAN host to access anything else. OPT1, OPT2, and similar interfaces are initialized with zero rules and thus all traffic is blocked on them until the admin creates the necessary rules for traffic to pass.

One other thing that looks strange to me is the unusually large subnet mask on that 200.75.x.x address. Are you sure that /16 is correct? If not correct on pfSense, it will cause communication issues. A subnet that large is going to have a huge broadcast domain.

@jimp Thanks for the heads up - I missed that! Maybe you can shed some light on my IPSec "double subnet" BiNAT P2 issue posted here:

https://forum.netgate.com/topic/197061/ipsec-with-multiple-subnets-and-binat-not-nating-a-specific-network-non-local

I searched but couldn't find any detailed information on this specific issue - it works only on the "first" subnet you specify, not on any additional different than the first.

@FrankZappa said in Lost access to pfsense:

but suddenly ...

You've probably triggered :

Go here : System > Advanced > Admin Access and scroll down to :
"Login Protection"

When you make an error while logging in, after a couple (2 or so) errors, your (LAN) IP will get firewalled (blacklisted) for a moment.
You still can access pfSense, use another device, or change the LAN IP of the device you are using.

If you trust all your LAN devices, you could set :

ba2cc5a9-7cdf-4d61-a96c-091da9a71130-image.png

( if 192.168.1.0/24 is your LAN network )

@patient0 said in Lost access to pfsense:

Not sure what service lighttpd_p is on 10.10.10.1, but it's not the LAN IP anyway.

That's the pfBlockerng DNSBL Webserver (it uses lighthttp, not nginx) :

a7c2ce43-f3ac-404c-a9de-96dfb793c98f-image.png

@johnpoz said in Missing info on system widget regarding memory usage:

Not seeing what your showing - both show % of memory

Try "hiding" it in the first one. And I beat you with 4 MB. 😉

@SteveITS : Cool, that it is going to be fixed in 25.03. Thanks for the information!
Regards, Mike

@sammiorelli

What is your pfSEnse version ?
I didn't see any errors.

[24.11-RELEASE][root@pfSense.bhf.tld]/root: grep ^date -v-1d +"%D" /var/log/snort/snort_igb0*/alert | awk -F, '{a[$5]++;} END {for(i in a) print a[i]" "i}' | sed 's/"//g' | sort -r ; echo grep: No match.

Just : No match.

edit : I get it : you entered that command here :

ea836970-e55f-4f19-8675-1cd4eab6cca9-image.png

My advise : don't use the GUI for the more 'complex' commands.
Ok for a

ls -al /

and that's it.
Use the command line, console or better : SSH access.

@svandive

Look at the logs ?

Have a look at what happens on the 'server' side : the web server GUI logs.
Console or SSH access, option 8, and then :

tail -f /var/log/nginx.log

@mbarlow

So you use 24.11 ?

The thing is, this file /usr/local/www/head.inc and line :

76180f08-ef13-4e57-aade-40f47834143c-image.png

doesn't seem to match with what you have.
There is no PHP on line 535.
Ok, true, you use a 1100 so it's not 'amd/intel" based, you have an arm version.
I'm presuming the GUI is still the same ...

The fact that you use ZFS will protect you from file system issues.
Just for the fun, when you have time, do the file check as explained in the video. It can't hurt ^^

@khb ah misread, sorry

Having gone ahead and created an explicit gateway group, with both WAN's Tier 1 .. and adjusting the LAN firewall rules to use that gateway group, enable/disable now works to simulate a wire pull for failover.

I'll also note that performance is now very good, at peak 2x our previous best observed peaks (up+down)

@opoplawski

The one liner method works also :

$config = parse_config(true); print_r($config); exec