Project

General

Profile

Bug #8987

Web GUI main page very slow to load if wan interface is enabled but not connected.

Added by Arnaldo Pirrone 4 months ago. Updated 2 days ago.

Status:
New
Priority:
Very Low
Assignee:
-
Category:
Web Interface
Target version:
Start date:
10/01/2018
Due date:
% Done:

0%

Estimated time:
Affected Version:
Affected Architecture:

Description

Hi,
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.

History

#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.

#3 Updated by Luke Hamburg 8 days ago

If you remove all widgets from the dashboard does that help at all? It's probably a widget that's causing this delay.

#4 Updated by James Howel 8 days ago

Hi Luke,

Thanks for the suggestion but I've tried that, same issue.

It looks like whatever is timing out due to no internet connectivity affects several areas so it's not just the dashboard...

James

#5 Updated by Joshua Sign 8 days ago

Hi,

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 if these options are good to use when connexion is down (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...

#6 Updated by Maverick Phillips 6 days ago

Hello,

One of my two firewalls has developed this issue - I can confirm disabling the WAN adapter resolved this slowness !

#7 Updated by James Howel 2 days ago

Hi Joshua,

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.

James

Also available in: Atom PDF