Long wait for GUI to appear
-
Netgate 8200.
Just upgraded my pfSense+ from 24.11 to 26.03.
The firewall is operating correctly, but accessing the GUI takes a frustratingly long time to respond (at least a minute).
Once connected to the GUI most of the dropdown menus respond very quickly in the way I'm used to.
I have tried this with Firefox, Chrome, and Edge and they all exhibit the same behavior.
If I am not currently logged in to the GUI, the login screen comes up immediately. But after I enter credentials, there's a big delay before Status/Dashboard comes up. If I do something else and then come back to Status/Dashboard, there is again the long delay.
Never saw anything like this with 24.11.
Conjecture: Something that the status page is trying obtain status for is either not responding or responding very slowly. But there is no indication on the status page that any status was difficult to obtain - they all look normal.
Any ideas on how to address this or debug it?
In case it's of help, here's a list of installed packages:
bandwidthd
Cron
iperf
ipsec-profile-wizard
mailreport
Netgate_Firmware_Upgrade
Nexus
ntopng
nut
Shellcmd
Status_Traffic_Totals
suricata
System_Patches
tftpd
WireguardI hesitate to randomly start uninstalling packages, but if there's a specific suspect package I could easily try uninstalling it. I did notice that I think Nexus is a new package that got installed with my upgrade, and since the description says it's for multi-instance management of pfSense and I only have one pfSense device, could this be a candidate for the slowdown issue?
The only other package present that I don't think I use is ipsec-profile-wizard.
Here's a list of widgets present on Status/Dashboard:
System Information
UPS Status
Gateways
Interfaces
Firewall Logs
Wireguard
Disks
Interface Statistics
RSS
Thermal Sensors
Suricata AlertsThey are all populated normally.
-
@hspindel said in Long wait for GUI to appear:
bandwidthd
Cron
iperf
ipsec-profile-wizard
mailreport
Netgate_Firmware_Upgrade
Nexus
ntopng
nut
Shellcmd
Status_Traffic_Totals
suricata
System_Patches
tftpd
WireguardIf active and you have 'a lot of traffic', the black ones are known resource hogs.
Worth trying : widgets : remove Firewall Logs and Suricata Alerts ?
Most info, needed to construct the dashboard info, is aviable locally.
But if 'dns', which needs outside access, is slow, the speed of the dashboard is affected.Btw : From what was promised, and what I've seen myself, and the latest pfSense version (or the version before ? don't recall) made the dashboard access twice as fast as before. Yours became slower ?
-
Yeah it's going to be one of the widgets. The firewall logs widget would be my first guess. If your log files are set to something huge that can take a while.
-
Thank you for the responses.
I removed both the Firewall Logs and Suricata Alerts widgets. It made no difference.
I do not have a lot of traffic. I am a single home user, not an office.
First level of DNS is local, but of course that has to refer to outside DNS (I use 9.9.9.9).
Yes, my dashboard became horribly slower with 26.03. It was fine with 24.11.
I made no system configuration changes between 24.11 and 26.03 besides installing the update.
Noticed something very strange: While the web browser is sitting there waiting for the status page to appear, the CPU usage bar in the System Information widget keeps changing. I don't see how anything on the page can be updated if I'm waiting for the page to be displayed. I can cause this behavior by viewing the System Information widget and refreshing the page..
-
If you go to Diag > DNS Lookup are all configured servers responding in a reasonable time?
-
@stephenw10 said in Long wait for GUI to appear:
If you go to Diag > DNS Lookup are all configured servers responding in a reasonable time?
Actually, no. Lookups take a long time from that diag page.
I tried disabling all DNS servers except 9.9.9.9. The I tried changing the configured DNS server from 9.9.9.9 to 1.1.1.1 and neither change made any difference.
Lookups from a PC using nslookup are very quick. Those lookups also use 9.9.9.9, but usually they bypass the Netgate 8200. So I change nslookup with server <ip of Netgate> and tried again, and they still complete very quickly.
I tried changing on the DNS setup page the resolution behavior from its current "use local DNS, fallback to remote" to "use remote, ignore local" and that made no difference.
On the diagnostics page/Ping page, ping requests to any address (IP or FQDN) complete normally, even if the FQDN has to be looked up.
On the Diagnostics/DNS lookup page I see the following:
Name server Query Time
127.0.0.1 68 msec
::1 No response
9.9.9.9 12 msec
10.255.255.2 16 msecSo I was suspicious that the problem has something to do with IPv6 timeouts, but I believe I have IPv6 disabled everywhere (interface is static IPv4). I found one place where IPv6 might be doing something: Interface/IPv6 Configuration Type was set to "track interface", so I disabled that. Still no difference.
Note that as I was performing these tests, I continually changed the FQDN I was looking up so that caching should not be an issue.
At a loss as to what to try next.
-
@hspindel said in Long wait for GUI to appear:
Lookups take a long time from that diag page
Remember :
said in Long wait for GUI to appear:
But if 'dns', which needs outside access, is slow, the speed of the dashboard is affected.
?
I propose a test : what about switching back (for a while) to the resolver's default mode, the one Netgate choose, the mode you found when pfSense was installed ?
After all : external DNS resolvers like 1.1.1.1, 9.9.9.9 8.8.8.8 and all the others are 'free'. But conditions still apply. Like, for example, rate limiting.
-
I propose a test : what about switching back (for a while) to the resolver's default mode, the one Netgate choose, the mode you found when pfSense was installed ?
After all : external DNS resolvers like 1.1.1.1, 9.9.9.9 8.8.8.8 and all the others are 'free'. But conditions still apply. Like, for example, rate limiting.
I have no idea what Netgate's default resolver settings were. It's been three years since this unit was installed and configured. The only thing I can find on the web is that pfSense defaults to resolver mode, which is what I think my unit is set to. (DNS Resolver is enabled, DNS Forwarder is disabled)
Recall above I said that nslookups proceed normally from a network client machine when nslookup is pointed at the Netgate as a DNS resolver. Not only that, but ping tests from the Netgate's internal ping test page resolve normally. So if this is a DNS issue it has to be something that is completely inside the Netgate that affects only some of the paths that the Netgate is using for DNS resolution. Not only that, it has to be something that changed from 24.11 to 26.03 since I made no configuration changes.
Perhaps this is not a DNS issue at all?
-
@hspindel said in Long wait for GUI to appear:
I have no idea what Netgate's default resolver settings were ....
Good point.
and
(I've also installed pfBlockerng).
I guess these settings are close to what is default (it's 10+ years for me)
-
I tried another test. Under the DNS Resolver configuration page, I disabled DNS Query Forwarding. If' I'm understanding what it does, by doing that I bypassed the DNS servers in General Configuration and unbound is using root servers.
This does not solve the problem. So I think that proves that whatever external DNS servers I'm using is not the issue.
-
As immediately previous, I tried disabling Forwarding Mode for DNS Query Forwarding. After doing that, I re-enabled Forwarding Mode and mysteriously the problem has disappeared (at least for now).
I made no other changes than trying to disable/re-enable that one setting. Must have managed to internally reset something important, but I don't know what that would have been.
And although the GUI page loads normally now, Diagnostics/DNS Lookup is still very slow. This is especially strange because it's slow for local host names which should resolve instantly. On the DNS Resolver/General Settings page, at the very bottom I have domain overrides for my local domain to point to my local DNS server.
I guess I don't care if the Diagnostic page is slow or not. ;-)
-
Crap. I spoke too soon. The GUI responded fine for a while, and then stopped again.
Disabling/Reenabling DNS Query forwarding didn't fix it, so that was a fluke.
-
I compared my configuration to the default configuration @Gertjan provided above. A number of my fields were different, particularly on the Advance Settings. I changed mine to match.
I do not have Python Module enabled. If I enable Python Module, Python Module Scripts says "no python module scrypts found", so I can't enable pfb_unbound. Nothing Python appears in my available packages. Do I need this, and if so, do I install via command line?
I do not have pfBlockerNG installed. It looks to me that that is what Python is needed for, and since I don't use pfBlockerNG it shouldn't matter that I don't have python scripts?
The above changes did not fix the problem.
-
@hspindel said in Long wait for GUI to appear:
On the Diagnostics/DNS lookup page I see the following:
Name server Query Time
127.0.0.1 68 msec
::1 No response
9.9.9.9 12 msec
10.255.255.2 16 msecThose are not especially long response times. Other than v6 localhost not responding. It should respond there though.
If you're not using IPv6 at all try setting 'Prefer IPv4 over IPv6' in Sys > Adv > Networking. See if that changes anything.
-
@hspindel said in Long wait for GUI to appear:
so I can't enable pfb_unbound
Because :
@hspindel said in Long wait for GUI to appear:
I do not have pfBlockerNG installed.
and that's ok.
@hspindel said in Long wait for GUI to appear:
don't use pfBlockerNG it shouldn't matter that I don't have python scripts?
Exact.
Some tests (command line) :
dig @127.0.0.1 google.com +shortGives you an IPv4 'rapidly' ?
-
Some tests (command line) :
dig @127.0.0.1 google.com +shortGives you an IPv4 'rapidly' ?
Yes, I get a rapid IPv4 response to that: 142.250.69.174
The GUI still takes a long time to come up.
-
Definitely try setting IPv4 as preferred. It will try to use IPv6 and if that's failing entirely for some reason that has to timeout.
-
@stephenw10 said in Long wait for GUI to appear:
@hspindel said in Long wait for GUI to appear:
On the Diagnostics/DNS lookup page I see the following:
Name server Query Time
127.0.0.1 68 msec
::1 No response
9.9.9.9 12 msec
10.255.255.2 16 msecThose are not especially long response times. Other than v6 localhost not responding. It should respond there though.
If you're not using IPv6 at all try setting 'Prefer IPv4 over IPv6' in Sys > Adv > Networking. See if that changes anything.
I agree those are not long response times. My issue is not necessarily that DNS responses take a long time - it's that the GUI takes a long time to appear. It's just a theory that this is DNS related (although, yes, I know, it's always DNS).
Prefer IPv4 over IPv6 was already checked.
Thank you for responding.
-
Do you have Unbound set to listen on All interfaces?
-
If you're the tinkering type, I had similar "slow GUI" issues and ended up compiling the Xdebug module for PHP, and it really helped me track down the source of the slowness- which ultimately resulted in a nice speedup fix that was added in 26.03.
I can provide the steps I used to build that module, or if you trust enough, happy to compile it for you and link a downloadable here.
