Project

General

Profile

Actions

Bug #12141

open

Lack of DNS or Internet connectivity causes GUI to be slow

Added by Kris Phillips 6 months ago. Updated 1 day ago.

Status:
New
Priority:
Normal
Assignee:
Category:
Web Interface
Target version:
Start date:
07/17/2021
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Plus-Next
Release Notes:
Default
Affected Version:
2.5.x
Affected Architecture:
All

Description

If a device is being configured offline, if the device is unable to query DNS, the webConfigurator causes a noticeable delay between every page load. As soon as WAN is connected and have uplink connectivity the webConfigurator responds normally. There seems to be an issue where pfSense is checking DNS on every page reload for some reason.

Actions #1

Updated by Andrew McCann 6 months ago

Kris Phillips wrote:

If a device is being configured offline, if the device is unable to query DNS, the webConfigurator causes a noticeable delay between every page load. As soon as WAN is connected and have uplink connectivity the webConfigurator responds normally. There seems to be an issue where pfSense is checking DNS on every page reload for some reason.

Kris, hope you dont mind me adding comments, but I think this is related to an issue another person and I are having, https://forum.netgate.com/topic/165102/gui-faling-to-respond-developer-comment-requested, when my ISP went down, the web interface was unusable after approx 2-4 mins, physically disconnecting the wan link and a forced reboot prevented the freeze from occurring, but if you let it freeze with WAN enabled, you could not make it responsive by disconnecting the WAN. Happy to provide any further info/logs if required.

Actions #2

Updated by Marcos Mendoza 6 months ago

  • Status changed from New to Feedback

I'm not able to reproduce this on 2.5.2.

There are instances in which no internet/DNS connectivity will result in delayed page loads, but I would not expect that to happen for every page load. For example, see #12093. In some situations when there is no connectivity, the login page will also be delayed due to the browser trying to verify the certificate - the workaround in this case in my experience being to access the login page by IP instead of fqdn.

With this in mind, if the issue can still be reproduced, check the following:
  • The network tools of the browser may show an issue with a specific resource.
  • Set Unbound log level to 3 and check if there are any specific domain resolution failures that correlate to the page loads.
Actions #3

Updated by Jim Pingle 6 months ago

If it's every page load then most likely it's related to authentication settings, like it's trying to check privileges against an LDAP or RADIUS server by hostname. If that is the case, then there is not much to be done there since it's attempting to properly validate that a user should be able to access the page, then falling back to local privilege checks.

In most cases I'd only expect this to happen on pages like the Dashboard or ARP table or something else that heavily uses DNS.

Actions #4

Updated by Andrew McCann 6 months ago

Hi Jim

Apologies, I haven't had a chance to test yet, but just a FYI, by pfsense box is a home machine, nothing special, no Domain/LDAP/RADIUS, I will try and runs some tests this afternoon using Unbound log level 3. I will also try and ssh into the box while its locked to see if I can see anything....

Actions #5

Updated by Kris Phillips 6 months ago

Jim Pingle wrote in #note-3:

If it's every page load then most likely it's related to authentication settings, like it's trying to check privileges against an LDAP or RADIUS server by hostname. If that is the case, then there is not much to be done there since it's attempting to properly validate that a user should be able to access the page, then falling back to local privilege checks.

In most cases I'd only expect this to happen on pages like the Dashboard or ARP table or something else that heavily uses DNS.

Jim,

Is there a particular reason the Dashboard needs to be doing DNS lookups? The only component of it that I can think of that would need to do DNS would be the update check widget. I will have to test a device with no network connectivity with the dashboard update check disabled.

Actions #6

Updated by Kris Phillips 6 months ago

Oddly setting the WAN interface of a firewall to None for IPv4 and IPv6 causes no slowness in the webConfigurator. It seems only when physical link is lost that the issue is present.

Actions #7

Updated by Kris Phillips 5 months ago

Still seeing this randomly with customer firewalls. If the WAN interface is disabled or physically disconnected, the issue goes away. If it is enabled, thinks it has WAN access (gateway thinks its up) but has no route to the internet (such as a customer with double NAT) the firewall hangs for a very long time before loading to the dashboard. Disabling the update check does not appear to resolve this.

Actions #8

Updated by Marcos Mendoza 5 months ago

I tried reproducing this on a lab. The gateway is online but pfSense is not able to reach any internet resources (including any DNS). The issue only exists on pages with DNS queries (e.g. update check page which times out with 504).

Actions #9

Updated by Kris Phillips 2 months ago

Marcos Mendoza wrote in #note-8:

I tried reproducing this on a lab. The gateway is online but pfSense is not able to reach any internet resources (including any DNS). The issue only exists on pages with DNS queries (e.g. update check page which times out with 504).

I wouldn't expect a 504 to be expected behavior here. The update page should produce an "Unable to check for updates" error message, but not bomb completely.

Actions #10

Updated by Marcos Mendoza 2 months ago

I agree. There are certain places in the GUI that are affected - the ACB page also being an example (see https://redmine.pfsense.org/issues/12093).

This redmine describes the issue being present on all page loads which would be a different issue.

Actions #11

Updated by Viktor Gurov 2 months ago

we can use check_dnsavailable() from #11512 to optimize this behavior
see also #12335 and #9677

Actions #13

Updated by Jim Pingle 2 months ago

  • Status changed from Feedback to Pull Request Review
  • Assignee set to Viktor Gurov
  • Target version set to 2.6.0
  • Plus Target Version set to 22.01
Actions #14

Updated by Viktor Gurov 2 months ago

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100
Actions #15

Updated by Marcos Mendoza 2 months ago

Perhaps we should hardcode / fall back to different DNS providers; e.g. use 1.1.1.1 and 8.8.8.8 (and IPv6 counterparts) instead of just Google's DNS.

Actions #16

Updated by Jim Pingle about 2 months ago

  • Subject changed from Lack of DNS/Internet Connectivity Causes webConfigurator to be Painfully Slow to Lack of DNS or Internet connectivity causes GUI to be slow

Updating subject for release notes.

Actions #17

Updated by Marcos Mendoza 1 day ago

  • Status changed from Feedback to New
  • Release Notes changed from Default to Force Exclusion

Tested on 2.6.0-RELEASE by blocking upstream any connection to the internet. Trying to load the dashboard took 40 to 60 seconds without DNS. Changed the General Setup settings to use remote DNS and ignore local DNS, same result.

Actions #18

Updated by Marcos Mendoza 1 day ago

  • Target version changed from 2.6.0 to CE-Next
  • Plus Target Version changed from 22.01 to Plus-Next
  • Release Notes changed from Force Exclusion to Default
Actions

Also available in: Atom PDF