@Gertjan said in Modifying Login Screen looks / logo.svg:

so no documented way of doing things.

Until now :)

I have tweaked a bit and found out how to clean up the login screen, with the end result like so

pfsense_simple.png

This was fairly easily achieved. But remember, I am just a guy, i like to play around with stuff for fun to see how it works and what i can mod, so dont blame me if stuff breaks. Do this at your own risk, and always make sure you can roll back. But really we are just editing some css values and its likely fine, or easily fixed. Because pfSense is built beautifully. So to be more exact, this is how i did it:

in system > advanced > Admin Access, check 'Enable Secure Shell' , so we can SSH into the pfSense box.

in System > User Manager > Users, enable the 'admin' user, to enable root access to the SSH server *(It is considered good practice to disable this account afterwards again, to create a separate account from 'admin' and elevate it to the adminstrators group. But in pfsense 'admin' seems to be bound to the Linux 'root' account, so enabling this will allow us to SSH in using the 'root' user and modify the login page.

In System > General Setup, enable the pfSense-dark theme. *(This is the theme I worked from. The results for other themes may vary)

and also in System > General setup, select a background colour for the middle part of the login screen. You can add custom colors to this list, by editing /usr/local/www/system.php, near the end of that file is an item called 'Login page color'. You can add one or more items to this comma separated list like: ' "00ff00;" => gettext("newcolorname"), ' and your new color will be selectable.
But you will have to modify 'login.css' by hand to include your new color if you want a uniform login screen. Since the banner at the top, and the footer at the bottom of the login screen are defined in this file, seperate from the 'login page background' color option you choose here.

Then, SSH into the pfSense box as user 'root' and the password for the pfSense 'admin' user

choose option '8) Shell'. (notice the prompt ending in '/root:', indicating you now have root access.

type 'cd /usr/local/www/css'

type 'vi login.new', and the VI editor will open a new file.

press 'i' to start inserting text, then paste the following (right click in putty/kitty will paste the clipboard)

@import url("/css/logo.css"); body, html { height: 100%; padding: 0; margin: 0; background-color: #000000; } body { width: 100%; } header { } #headerrow { position: fixed; height: 90px; top: 0; width: 100%; background-color: #000000; } .pagebody { position: absolute; top:90px; bottom:25px; width: 100%; color: #2a8c8e; overflow: hidden; } .pagebodywarn { position: absolute; top:140px; bottom:25px; width: 100%; color: #2a8c8e; } .nowarning { height: 80px; padding-top: 10px; } #hostspan { text-align: right; font-weight: bold; color: #ff0000; text-shadow: 2px 2px 2px #0000ff; } .msgbox { padding-right: 60px; padding-top: 25px; } @media only screen and (max-width : 768px) { /* only size 'xs' and below */ #headerrow { height: 100px; } .pagebody { top: 100px; } .pagebody2 { top: 250px; } .nowarning { height: 60px; } .msgbox { padding-right: 0px; padding-top: 0px; } #hostspan { text-align: center; } } #footertext { position: fixed; height: 1px; bottom: 0; width: 1%; background-color: #000000; color: #000000; text-align: center; } .loginCont { position: absolute; top: 50%; left: 50%; transform: translate(-50%,-50%); height: 55%; width: 80%; } .error-panel a { color: #2a8c8e; } p.form-title { font-family: 'Open Sans' , sans-serif; font-size: 25px; font-weight: 999; text-align: center; color: #ff0000; margin-top: 5%; text-transform: uppercase; letter-spacing: 12px; } form.login { max-width: 270px; margin: 0 auto 20px auto; } form.login input[type="text"], form.login input[type="password"] { width: 100%; margin: 0; padding: 10px 10px; background: 0; border: 0; border-bottom: 1px solid #FFFFFF; outline: 0; font-style: italic; font-size: 18px; font-weight: 600; letter-spacing: 1px; margin-bottom: 5px; color: #FF0000; outline: 0; } form.login input[type="submit"] { width: 60%; font-size: 14px; text-transform: uppercase; font-weight: 700; border: 4; border-color: #ff0000; color: #ff0000; margin-top: 36px; outline: 0; cursor: pointer; letter-spacing: 1px; display: block; margin : 0 auto; margin-top: 36px; background-color: #000000; } form.login input[type="submit"]:hover { transition: background-color 0.5s ease; color: #ffffff; } form.login label, form.login a { font-size: 12px; font-weight: 400; color: #00ff00; } form.login a { transition: color 0.5s ease; } form.login a:hover { color: #2a8e8c; } .logoCol { height: 100%; } #logodiv svg#logo { width: 1px; height: 1%; background-color: #ff0000; } /** Re-style web-kit browser autocomplete boxes (Fixes Chrome's ugly yellow background) **/ @-webkit-keyframes autofill { to { color: #00ced2; background: transparent; } } input:-webkit-autofill { -webkit-animation-name: autofill; -webkit-animation-fill-mode: both; }

then press 'Escape' to exit editing mode

write ':wq' to write the text to file and quit the VI editor.

then write 'mv login.css login.old'

and 'mv login.new login.css'

then type 'exit'.

Then, after you opened your browser and enjoyed your new clean login screen, you can disable the 'admin' user and Secure Shell again :)

Some notes:

These modifications will presumably be reset by every update. this is mainly why i made this write up ;)

The fix for the original question about removing the logo.svg, and the footer, was to make the logo and the footer 1px high by 1% width in the login.css file.

With minor modifications it is easy to make any 2 color setup with this, by adding a custom color for the background to system.php, and modifying login.css and pfSense.css/pfSense-dark.css to include the new background and foreground color.

Where it says 'Login to pfSense' is also where the hostname would be if you select the option to display the hostname on the login page. It is possible to remove this text, as well as the 'SIGN IN' text above the user field, by editing the login.css and making the text the same color as the background and 1px high.

The 'Sign In' button will always fade to the default green button once you press it. I have not yet found how to fix that behavior.

I have not yet found how to edit the grey color of the 'Username' and 'Password' that are pre-filled in the input boxes. I think that is a default behavior like the green Sign in button on-press, and since it is not defined it is hard to find. The text filled into those boxes do correspond with the red in this theme, and are defined in login.css as well.

The CSS for pfSense is highly customisable, it will allow for text decorations and some shadow effects up to a limit. above the limit the effect will disable itself.

If you also edit pfSense.css or pfSense-dark.css, you can edit some colors from the pfSense interface as well, to match the login screen. Mainly the pfsense logo color and the highlighted text color are nice to get in line with the color scheme chosen for the login screen.

@Gertjan Thank you sir

What error? You did not post anything related to the actual text of the error message.

@SteveITS Thank you Steve, looks like you went through a lot of troubleshooting to get that to work. Nice going. I think that's a good workaround that I may try over the weekend. That said, I'm not sure, from Netgate's perspective, they should put that in the resolved category as not every user will come across this thread of always have direct and easy access to the hardware console. For the time being, I just went in to /etc/rc.ramdisk_functions.sh and set RAMDISK_DEFAULT_SIZE_ to my values... also not the best resolution, but it works for now.

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 ^^