@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

@Gertjan On a separate note

Thank you for sharing the screenshot. I had been pulling my hair for the past few days trying to figure out why I could not access my WAN GUI from a external network.

I had followed the steps and setup the rule. But your screenshot showed me that I also needed to specify the port within the rule to allow access rather than a choosing HTTP or HTTPS as the destination port

FYI for anyone reading this, you need to pick Port Range as "other" and insert the Port you chose for your GUI which was set in System>Advanced> TCP Port

I'm enjoying learning about all this all thanks to you @Gertjan. On behalf of all the newbies and rookies, thank you for all your contributions

@madmaxpr said in 24.11 GUI crash report from firewall log:

nach Korrekturen suchen.

thanks, i have installed the patch and is worked now without errors

@patient0 said in Error Response Received / Can't access the Web GUI But seems to be Working:

And I would have thought that installing AdGuard (not an pfSense package AFAIK)

@doug_gordon41 :
A non pfSense package that uses the DNS port, thus blocking the resolver from using it.
It has a web server, thus blocking the pfSense GUI from using it.
Etc.

Read Using Software from FreeBSD again ...

Imho : re install pfSense.

@Fitin said in I can't access the web gui after changing hardware, but all services are working fine:

now the only thing I can't access again is the pfSense webgui in any way😐

What does the console menu shows you ?
And :

ifconfig

Double check that you didn't mix WAN and some LAN port.

ps aux | grep 'nginx' sockstat -4 | grep 'nginx'

The new system has new ? other network interface ?
If they got reordered at start, what previous firewall rules will be assigned to what interface ? ( just thinking out loud here )