pfSense

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.

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.

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

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.

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.

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.

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

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.

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.

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

fix:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/463

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.

Marcos Mendoza wrote in #note-17:

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.

Found an issue:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/590