@johnpoz Thanks for the reply. I had tried Edge and Brave to get into the system. Out of curiosity, I switched Edge to Internet Explorer mode, and it worked. Checking setting on my browsers now.

@cool_corona I really do appreciate your input and ideas but I've only provided part of the information and the business case as I didn't feel in warranted explaining. In summary with 150 desktop/laptops in the estate and the impact of Teams A/V on our centralised infrastructure it was much more cost effective to move our hosting requirements online rather than hosting internally as we had been doing. We were at a point where the server estate needed major investment which wasn't a viable or sustainable option. So going back to a Terminal Server/VDI solution is off the cards just so we can manage the network.

Irrespective of my particular circumstances, the key 'positive' thing here is that netgate/pfSense has now matured to such an extent that much larger deployments use cases are being considered. To break into the next market, they need to consider the ease on managing an 'estate' rather than an 'individual' devices. I don't mean that to be a slur on netgate/pfSense in any way. Many companies out there have great products but get to a point where chasing the 'next new thing' out weighs the more mundane tasks on optimising the less glamorous management functions larger/complex organisations require.

@willemb
Just what is says. Someone is trying to access non-existent pages on the web server. I would suggest you not leave your web gui open to the Internet.

@rcoleman-netgate Done, thanks

@alex-the-firewall

Nearly all 'webgui is slow' issues are really 'I have DNS issues'. Checking out the many 'webgui is slow' forum threads normally end with ..... nothing, as the author silently undid his previous DNS settings and doesn't erport back here, or are explained in the forum and then DNS is corrected.

After all, DNS needs to work for not only the pfSense WegGUI, but pretty everything on your local networks.
I mean, when pfSense default DNS settings get altered, its very possible that overall DNS functionality gets impacted.

Btw : most host names shown by the GUI are only known to the local DNS == the resolver or the forwarder. Resolving them doesn't produce any time taking requests to public resolvers. These public resolvers can't even resolve host names that are only known to your local network - they will try, searching through their billion records database, and give up by sending back a "we don't have what you are asking - unknown on the Internet", also known as a NXDOMAIN answer.

I advise you to do everything that is possible to reduce the number of restarts of the resolver (or forwarder). It will build a cache with previously resolved host names

Then you activate :

672ff694-acfd-4a92-99c9-755e9c5e7a6c-image.png

and after a while you enter 'DNS warp speed'.

These are some of my unbound/resolver stats.
Note that unbound can get restarted by, for example, pfBlockerng-devel (other events might also restart unbound/dnsmasq). The cache will get dumped just before the stop, to get read back in while it's starting.

Last but not least : the core functionality of pfSense, routing and firewalling, is build into the kernel. pfSense is more then that, and adds a lot of other options, functionalities and even gadgets. Most of these are implemented using some web server scripting like PHP, perl, python etc. So, all these take processor == webserver (nginx) time.
Depending the type of processor, and Intel Mega Lax Core isn't equal to some low power ARM processor.

Why did you add the waterfall download example of a zillion js files ? That's not DNS related.
That's just downloading those stupid js files that declare themselves most often as 'non cache-able' by your web bowser, to visiting these sites using these bootstrap js file will always be slow == depending your uplink/downlink.

We do try to keep things phrased positively for new options so that checked=enabled=on and things might be set by default if they default to on.

For existing options it's tough to reword things and also change any logic that touches the option to ensure it works the other way with an appropriate default behavior. There is a lot of room for error there in some cases which makes it tough to make a case for changing code and introducing bugs to correct the wording, even if it ends up more logical. And aside from that, having to accommodate both forms in the docs during the transition is very confusing for existing users.

The docs would be full of things like "Prior to x.x.x this would not do foo when checked, after x.x.x the default is to do foo when checked".

Not saying it wouldn't ever happen for older options just that it takes a lot more work and care than one might think, and would likely need to be done slowly over time and not all at once.

@aaronssh For what it's worth, this fixed it for me:

pfSense General Setup page was configured to use NextDNS I changed it to use my local AD Domain Controllers instead. Suddenly DHCP Leases loads instantly.

@mcdiesel said in Colors for interfaces:

New pfSense 2.3 gui style is nice, easy to use, well done.

Colors on interfaces would be useful.

eg Red, Green, Blue.  Colour wouldn't actually do anything, it's just a 'tag'.

Two tones for each colour - the dark color when used for text / primary / icon, and the light shade for background bands.

Abstracting further, colour is just a word, and words are tags, and tags can be represented already with aliases.

So if the existing alias feature can have a color attribute, that colour in it's two tones could be used where the alias is involved.

I think the light background colour would be the most often used - rules lines, log lines, dhcp lease lines would all be subtly banded with the interface colour, which improve understanding, without making the interface any busier by adding elements.

Taking it one step further, if an alias could have an icon attribute, we could have subtle pictures of desktops, printers, switches on the various lists.

Many humans think in colours & pictograms, so I think this would make pfSense more intuitive, and faster to use, while maintaining it's great look and feel.

Appologies if this suggestion is duplicated elsewhere, or belongs in another part of forum/tracker/suggestion box.

Good time of the day. I can't help but agree that colors on interfaces would be helpful. Only Vod would suggest using not red, green and blue (it's just banal), but pastel colors - Pink, Rose Gold, Plum from the palette https://create.vista.com/colors/color-names/rose-quartz/. As for me, this is a good idea :)

Has someone came up with a solution of this severe problem?

@mystique_ one can also restore parts of a configuration, if you’re duplicating.

@gertjan this worked perfectly, thanks

Upgraded earlier to Beta release 22.05.b.20220531.0600 and now to RC release 22.05.r.20220604.1403.
Problem still persists on both versions.

EDIT:
Seems that the problem appears if you have 2 (or more) System Information widgets with different contents on the Dashboard.

EDIT 2:
Looks like it's specifically caused by the "CPU Type", "Uptime" and "Current Date/Time" fields, as log as all of them are visible in all System Information widgets, everything is ok. If one or all of those fields are hidden in one of the System Information widget, then they start to act up.

So, after a few days I (in desperation!) reached out to the great people at Protectli who sold me the router hardware in the first place. Their support was awesome. Thanks protectli!

Someone there set up a working example and then exported the xml description (diagnostics > backup & restore) so that I had something to compare against, line-by-line. After an hour or so combing through mine and theirs, I discovered I had wrongly configured a static route early in my experimenting with pfsense, which was disrupting access on the WAN interface to the gui. Once removed (and after a reboot) access via WAN was restored. "Problem" resolved.

Many thanks @Bob-Dig and @johnpoz for helping me through the initial stages patiently; much appreciated.

@larrym04 To avoid all of this, IMO the best (and most secure) option is to download the Acme package and get yourself a free LetsEncrypt cert so you can have that tasty green padlock. It's not too difficult, and you won't need to keep hitting that Advanced button.

@gianpaoloracca UPDATE:
you can scroll dragging the column header.
So it's clunky but it works.

I know this topic is old but I experienced the same behavior...

Like you I'm also forced to use double nat as my primary WAN come from an openMPTCProuter which aggregates my WANs in front of pfSense and I also have failover to the same WANs (but in load balancing) in case of MPTCP failure so I'm also dependent on the checkIP service to update my DNS when the MPTCP gateway is the active one.

I update 4 DDNS with the same IP for this gateway and the 4 cached IPs continuously turn Red for some second, sometimes one at a time, sometimes 2 of them at the same time.

After found your post I changed the checkIP service from the default "http://checkip.dyndns.org" to the other one "https://ipinfo.io/ip" and the problem is gone.

So it's definitely a dyndns service problem, maybe that the frequency of the requests from the same IP to update 4 DNS causes the dyndns service to refuse to respond to each one.

Thanks for sharing your solution.

@bingo600 still not working. I even forwarded port 80 and 443 on OPT1 interface but still not working

Same issue here. WAN is on em1 - no other VLANs on that interface. The dashboard traffic widget:

Screen Shot 2022-05-09 at 11.51.21.png

Screen Shot 2022-05-09 at 11.51.26.png

Half the actual throughput. Settings same as yours.

The Traffic Graph graph shows this (/status_graph.php):

Screen Shot 2022-05-09 at 11.51.44.png

which is correct (I have a symmetrical line - upload was 897Mbps during this test)

@rcoleman-netgate Thanks for your quick response!
Indeed it works now! Thanks!

@jimp Thanks. I will dig deeper into Brave.

@nogbadthebad thanks for your reply. (I work with @emasi on the project.) We are aware that the scenario is not ideal and we have already taken the necessary precautions (change management) so we don't trigger the issue anymore.
The fact remains that this issue is easily triggered. We have tested many scenarios. The conflict handling when creating rules alone is pretty neat really. But as soon as we add separators to the scenarios not only the new changes are conflicting - but the actions delete existing firewall rules. And that's dangerous, worth to mention and worth to fix. (At least we think it is.)
So we are following the pfSense bug report guide and are documenting our observations here to discuss first. Maybe you folks can confirm this is an issue so we can report it to pfSense Redmine. (We have never done that, so sorry if our procedure seems a bit wonky:)

@worlddrknss Sounds like you can reproduce it so I suggest opening a report at http://redmine.pfsense.org/

Has no one successfully done this yet?

I'd like to tag the thread as [SOLVED], but I can't edit my initial post any more.

What should I do?

Same problem here. We have about 100 users deployed across 10 openVPN server instances on our core pfsense VM using tap/bridge mode. There are a number of reasons we prefer this arrangement over a routed tunnel when VPNing into a cooperate windows domain network.

I'm tempted to roll back to 2.5.2 because we can't see connected users on either the openVPN status page or the dashboard widget. Are there any plans to make these interfaces display connected users again with a future update (soon?)

@xanaro said in Full screen theme for 2.3:

full width really improves a lot of the pages as well, traffic graph, squid real time, etc...

Thats correct!

Ah .. System_Patches
Thanks a lot !

@johnpoz said in Rearranging interface order?:

Or you could change the names on them so the alphabetical ordering is how you want them to be ;)

I set the sorting to alphabetical and prefixed all of my interface names with numbers. Much easier than trying to use the actually alphabetical names.

I run everything in VM's so I got to a point where I ran a clone on the sister VM and got it working.

I have absolutely no clue to why the dropdown was empty....

the .conf file was as it should be and everything was running as it should and it was showing packages as it should.

Only thing was the system -> update.

To update this post, I apparently posted it again later on and received a answer found in this thread...
https://forum.netgate.com/topic/169870/dnsbl-reputation-404-error-solved/4?_=1647182583544

@shupiluliuma said in WebGUI no longer works; login page never displayed:

The mask on the interface was set to /32 instead of /24. I either missed the setting or messed up the selection and didn't notice.

nothing serious has happened, you just ran over it, it happens, by default the GUI offers /32 and if you don't watch it well, this could be the problem.... :)

Yep i did it. thanks.

But another question. I gave the Modem IP to the Wan ip of Netgate without brigde mode. There is no Internet connection.

I dont understand the problem.