Project

General

Profile

Actions

Bug #12141

open

Lack of DNS/Internet Connectivity Causes webConfigurator to be Painfully Slow

Added by Kris Phillips 2 months ago. Updated about 1 month ago.

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

0%

Estimated time:
Plus Target Version:
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 2 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 2 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 2 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 2 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 2 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 2 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 about 1 month 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 about 1 month 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

Also available in: Atom PDF