@stegbth the pfB virtual IP for DNSBL is usually attached only to localhost and listening on that VIP. Note in 25.11 and now 26.03 the VIP needs to be manually added to localhost and set in pfB DNSBL settings. May be related. Edit: that may be if uninstalled before the update, IIRC if it’s left installed it will keep it?

~~CVE-2025-1647 is an XSS vulnerability in Bootstrap 3.x's data-template attribute in Tooltip and Popover components. The severity in pfSense's specific context is worth understanding before deciding how to respond. The risk in pfSense is significantly lower than the CVE score suggests for a few reasons: The pfSense WebGUI uses Bootstrap tooltips and popovers, but the data-template values are set by Netgate's own PHP code, not by user-supplied input in most cases If your WebGUI is only accessible from trusted internal networks (as it should be), the attack surface is limited to already-authenticated administrators That said, for a vulnerability assessment the finding is legitimate since Bootstrap 3.4.1 is documented as EOL and carrying this CVE. What you can actually do: Upgrade to pfSense Plus 26.03 if you're on CE 2.8.1 and eligible. Netgate has been updating frontend dependencies in the Plus track. Check the release notes to see if Bootstrap was updated. For pfSense CE: there is no supported path to manually upgrade Bootstrap without breaking the webGUI, since the templates are tightly coupled to Bootstrap 3's API. Manually replacing bootstrap.min.js with a 5.x version will break the UI. Mitigation for your assessment: document that WebGUI access is restricted to trusted management networks/VLANs only. This is the standard accepted mitigation for bootstrap-in-admin-UI findings. Most security auditors accept this with a network diagram showing access controls. The "Patches" package chpalmer mentioned can apply unofficial fixes, but there is no community-maintained patch specifically for CVE-2025-1647 at the moment. If you're stuck on CE 2.8.1 with a hard requirement to remediate, the only fully clean path is migrating to pfSense Plus where Netgate controls the update cadence. ~~

@leroyx Thanks for the feedback. I think this "Norton" process scans local network resources once in a while and it checks if known 'bad URLs' gets a web server answer = a web page. In that case you'll see a "Norton local network security issue message" on your PC. That's why you saw these web requests on your pfSense web server log. Remember this one : said in Questionable Error Messages in General Log: Anyway : it's not hard to find out what is happening = what or who is sending these https requests to your pfSense. File names like "index.asp"and "get.cgi" are to generic, but you might have a chance with "loginMsg.js" : locate this text string in every file on your system, and you will find what file it is. Finding this file on your PC, and you can see who made the request. which means that in one of the Norton executables or Norton DDLs you would have found the text "loginMsg.js" so you would have known it was Norton sending these URLs. This : @leroyx said in Questionable Error Messages in General Log: I started TcpLogView on the Computer was a good idea Btw : Normally, when you start to use a PC, you have to go through the rather tedious process called : "remove bloatware". Most PC users don't need Antivirus stuff anymore. And the ones who do, even something like "Norton" can't protect them. so ... remove it all, and keep the CPU for yourself.

Can access to debug cert using Chrome and 'thisisunsafe' at error page (previously nogo because my web search showed spaces, which fails). -No need at all to reinstall pfSense!

I’m not sure whether this is still relevant for you, but I came across your post because I had the same problem. The good news: I found a solution. You can disable the alias pop-ups, which also prevents the preloading (tested in CE 2.8.1). Go to System → User Manager, edit your user using the pencil icon, and make sure Custom Settings is enabled. Then tick the checkbox for Alias Popups.

Disregard previous file - found bad logic error generated by vnstat. Fixed file below. vnstat_usage.widget.php.txt

@Gertjan Thank you. I removed the file, and it loads. I copied the file from a working router (same version) and got the same error. But for now, I can use the dashboard. I will look deeper into why even a new file causes the issue.

This one : Call for Testing: pfSense Plus 26.03 RC Now Available! says : WebGUI Optimizations - The WebGUI code has been optimized. Users may experience a dramatic increase in GUI performance. For me, on a 4100 MAX, the dashboard access time has been in half.

@SteveITS Thank you!

@johnpoz with that music going haha

@timbaeten on Plus it’s almost always old Boot Environments: https://docs.netgate.com/pfsense/en/latest/troubleshooting/filesystem-shrink.html

@Alamoodi Also : now you've your system back up, and ssh works, and the console works, and you know how to use the IPMI works (wow, didn't even know the 8300 had that access : just great !), go to the /var/log/ folder ans save all the logs files. It's very possible that you find in the system.log (or older, rotated versions of that file) what the reason was things went wrong in the first place. Get, for example WinSCP, you can use the SSH credentials and SSH port 22, to access the pfSense file system like Windows explorer. If you can't find anything, start by adding a UPS.

@Gertjan said in WebGUI inaccessible locally, through TS and multiple browsers.: @almostmagic said in WebGUI inaccessible locally, through TS and multiple browsers.: Anyone else experience this? yep. known (sort-of). Throw "csrf-magic.ph" into : [image: 1763157990105-0ea57f40-d002-4f74-ae86-c5edac43c360-image.png] and hit enter. 3 occurrences. Read ... and you'll know what not to use (use the GUI command line) : use the real one : SSH, or even better : the console access. Thanks. I increased memory beyond what support had suggested earlier, and so far no more errors.

@truist Here's the gun and a bullet : Add the LAN IP right here : [image: 1762242565881-a088330f-5214-4f43-b272-a5fd3bc724a0-image.png] Btw : the ssl (port 443 normally) nginx will be 'locked' to the LAN IPv4 - as you can it still listens on all IPv6 interfaces. Further down you'll find the place where you can do the same thing for the http (non-ssl) access. I didn't test this. The file is : /etc/inc/system.inc Happy hunting

I just ran into this issue and in my case it was due to an asymmetric routing situation that had developed because of static routes defined within the OpenVPN "remote network" settings. The behavior I experienced was very similar to what you describe, and I believe it was because return packets were flowing across a different interface than the origin packets. The firewall couldn't see the return packets, and closed the state. In my case the "aha" moment came from reading https://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.html