Web GUI main page very slow to load if wan interface is enabled but not connected.
I noticed this annoying bug in pfSense 2.4.4:
by configuring the wan interface and leaving it disconnected,
the main page of the web GUI becomes very slow to load (you must wait many minutes!) though you can reach every other page.
you can verify this by enabling and disabling the WAN interface from the interfaces menu (always available), then by clicking on the logo.
#1 Updated by Jim Pingle 4 months ago
- Priority changed from Normal to Very Low
- Target version set to Future
There are several things on the dashboard that need working DNS and connectivity, like the update check, packages widget, etc.
Without connectivity it has to wait for DNS to timeout for various things. There isn't a way around that.
Using the local DNS Resolver/Forwarder can help -- see #1407
There may be something more we can do here in the future, but it's doubtful.
#2 Updated by James Howel 8 days ago
To add to this bug we've been using pfSense 2.3.5 for an internal project and its been working brilliantly.
We're using pfSense as a cluster but it has no internet connectivity and 2.3.5 has no issues with this.
I upgraded the first cluster node with 2.4.4_p1 and noticed this laggy behaviour generally when trying to load the dashboard. After spending several hours trying to figure out what was wrong I ended up having to roll back to snapshot and leave the cluster on 2.3.5.
Testing this further, I have found that on top of the dashboard hanging for up to 2 minutes, certain other configuration saves behave the same way, such as DNS Resolver, Advanced Settings and others. Firewall Rules saves do not exhibit the same issue.
Essentially this will preclude pfSense from being deployed where there is no internet connectivity as this issue means that configuration will take 10 times longer to perform and for some people they will see this as a bug and opt to use another platform.
I'm a long term pfSense user and its gaining traction on this project but ultimately will have to be abandoned without some resolution or workaround to this problem as this will be a showstopper for using pfSense here.
#5 Updated by Joshua Sign 8 days ago
I just test it :
- Loading dashboard normaly takes about 1 second or less.
- Without WAN connectivity, it takes about 30 seconds.
- Adding theses options in resolv.conf, it now takes only 5 seconds :
options timeout:1 options attempts:1
I don't know if it can help, but when WAN connectivity goes down, we got an alert in systems logs like :
Jan 15 15:51:52 php-fpm /rc.linkup: Hotplug event detected for WAN(wan) static IP (xxx.xxx.xxx.xxx) Jan 15 15:51:51 kernel em0: link state changed to DOWN Jan 15 15:51:51 check_reload_status Linkup starting em0
So (there are many cases to consider),
it can be a workaround to add them 'on fly' in resolv.conf when WAN goes down and then remove them when WAN goes UP.
It's a suggestion...
#7 Updated by James Howel 2 days ago
Thanks for looking at this.
We don't have a WAN in a down state, it is connected but it has no NAT and is basically just another interface but on a totally isolated network.
It appears that if pfSense has NEVER been connected to the internet, the way it behaves with the timeouts is different to IF it has been connected at least once and then disconnected.Build scenario: 2.4.4 p1 build, 2 interfaces, vsphere 6.5 VM, no configuration aside from adding ip addresses from console and setting the admin pass from gui. Never internet connected.
- Dashboard access once logged in: 66 seconds
- General page save after adding one dns ip: 63 seconds
- General page save with no config changes: 66 seconds
- Rules save: instant
- Post rules save Apply Changes: Instant
Architecturally, there is a significant dependency on internet connectivity in pfSense which for most people is fine but if an internal pfSense tier or the entire pfSense implementation can never be connected to the internet then it's very slow to configure and troubleshoot. When compared to an offline hardware firewall from another vendor pfSense behaves like its buggy and slow.
I've also discovered that it's also fundamentally impossible to install any packages in an offline state which is another problem but that's a separate issue.