DHCP lease screen not loading

skitapa

I have ran into the same problem with dhcp leases page not loading.

I am on the latest community edition.

It think it is related with CORS.

The logs just add on in a loop. So it seems they get called for every line in the leases or something.
Hope it helps to identify what is wrong here.

From my developer console in Safari but with my real local IP replaced:

[Error] XMLHttpRequest cannot load https://192.168.1.1/widgets/widgets/snort_alerts.widget.php?getNewAlerts=1632238566520 due to access control checks.
	(anonym funktion) (Skriptelement 1:1:780)
	send (csrf-magic.js:41)
	send (jquery-3.5.1.min.js:2:82618)
	ajax (jquery-3.5.1.min.js:2:78228)
	fetch_new_snortalerts (snort_alerts.js:80)
	Global kod (Skriptelement 2:1)
[Error] XMLHttpRequest cannot load https://192.168.1.1/widgets/widgets/interfaces.widget.php due to access control checks.
	(anonym funktion) (Skriptelement 1:1:780)
	send (csrf-magic.js:49)
	send (jquery-3.5.1.min.js:2:82618)
	ajax (jquery-3.5.1.min.js:2:78228)
	make_ajax_call (index.php:1685)
	executewidget (index.php:1722)
	(anonym funktion) (index.php:1734)
[Error] XMLHttpRequest cannot load https://192.168.1.1/getstats.php due to access control checks.
	(anonym funktion) (Skriptelement 1:1:780)
	send (csrf-magic.js:49)
	send (jquery-3.5.1.min.js:2:82618)
	ajax (jquery-3.5.1.min.js:2:78228)
	make_ajax_call (index.php:1685)
	executewidget (index.php:1722)
	(anonym funktion) (index.php:1734)
[Error] XMLHttpRequest cannot load https://192.168.1.1/widgets/widgets/interfaces.widget.php due to access control checks.
	(anonym funktion) (Skriptelement 1:1:780)
	send (csrf-magic.js:49)
	send (jquery-3.5.1.min.js:2:82618)
	ajax (jquery-3.5.1.min.js:2:78228)
	make_ajax_call (index.php:1685)
	executewidget (index.php:1722)
	(anonym funktion) (index.php:1734)
[Error] XMLHttpRequest cannot load https://192.168.1.1/getstats.php due to access control checks.
	(anonym funktion) (Skriptelement 1:1:780)
	send (csrf-magic.js:49)
	send (jquery-3.5.1.min.js:2:82618)
	ajax (jquery-3.5.1.min.js:2:78228)
	make_ajax_call (index.php:1685)
	executewidget (index.php:1722)
	(anonym funktion) (index.php:1734)
[Error] XMLHttpRequest cannot load https://192.168.1.1/widgets/widgets/pfblockerng.widget.php?getNewWidget=1632238571520 due to access control checks.
	(anonym funktion) (Skriptelement 1:1:780)
	send (csrf-magic.js:41)
	send (jquery-3.5.1.min.js:2:82618)
	ajax (jquery-3.5.1.min.js:2:78228)
	fetch_new_pfBlockerNG_widget (pfblockerng.js:99)
	Global kod (Skriptelement 3:1)
[Error] XMLHttpRequest cannot load https://192.168.1.1/widgets/widgets/interfaces.widget.php due to access control checks.
	(anonym funktion) (Skriptelement 1:1:780)
	send (csrf-magic.js:49)
	send (jquery-3.5.1.min.js:2:82618)
	ajax (jquery-3.5.1.min.js:2:78228)
	make_ajax_call (index.php:1685)
	executewidget (index.php:1722)
	(anonym funktion) (index.php:1734)
[Error] XMLHttpRequest cannot load https://192.168.1.1/getstats.php due to access control checks.
	(anonym funktion) (Skriptelement 1:1:780)
	send (csrf-magic.js:49)
	send (jquery-3.5.1.min.js:2:82618)
	ajax (jquery-3.5.1.min.js:2:78228)
	make_ajax_call (index.php:1685)
	executewidget (index.php:1722)
	(anonym funktion) (index.php:1734)
[Error] XMLHttpRequest cannot load https://192.168.1.1/widgets/widgets/interfaces.widget.php due to access control checks.
	(anonym funktion) (Skriptelement 1:1:780)
	send (csrf-magic.js:49)
	send (jquery-3.5.1.min.js:2:82618)
	ajax (jquery-3.5.1.min.js:2:78228)
	make_ajax_call (index.php:1685)
	executewidget (index.php:1722)
	(anonym funktion) (index.php:1734)
[Error] XMLHttpRequest cannot load https://192.168.1.1/getstats.php due to access control checks.
	(anonym funktion) (Skriptelement 1:1:780)
	send (csrf-magic.js:49)
	send (jquery-3.5.1.min.js:2:82618)
	ajax (jquery-3.5.1.min.js:2:78228)
	make_ajax_call (index.php:1685)
	executewidget (index.php:1722)
	(anonym funktion) (index.php:1734)
[Error] XMLHttpRequest cannot load https://192.168.1.1/widgets/widgets/interfaces.widget.php due to access control checks.
	(anonym funktion) (Skriptelement 1:1:780)
	send (csrf-magic.js:49)
	send (jquery-3.5.1.min.js:2:82618)
	ajax (jquery-3.5.1.min.js:2:78228)
	make_ajax_call (index.php:1685)
	executewidget (index.php:1722)
	(anonym funktion) (index.php:1734)
[Error] XMLHttpRequest cannot load https://192.168.1.1/getstats.php due to access control checks.
	(anonym funktion) (Skriptelement 1:1:780)
	send (csrf-magic.js:49)
	send (jquery-3.5.1.min.js:2:82618)
	ajax (jquery-3.5.1.min.js:2:78228)
	make_ajax_call (index.php:1685)
	executewidget (index.php:1722)
	(anonym funktion) (index.php:1734)
[Error] XMLHttpRequest cannot load https://192.168.1.1/widgets/widgets/pfblockerng.widget.php?getNewWidget=1632238581520 due to access control checks.
	(anonym funktion) (Skriptelement 1:1:780)
	send (csrf-magic.js:41)
	send (jquery-3.5.1.min.js:2:82618)
	ajax (jquery-3.5.1.min.js:2:78228)
	fetch_new_pfBlockerNG_widget (pfblockerng.js:99)
	Global kod (Skriptelement 6:1)
[Error] XMLHttpRequest cannot load https://192.168.1.1/widgets/widgets/interfaces.widget.php due to access control checks.
	(anonym funktion) (Skriptelement 1:1:780)
	send (csrf-magic.js:49)
	send (jquery-3.5.1.min.js:2:82618)
	ajax (jquery-3.5.1.min.js:2:78228)
	make_ajax_call (index.php:1685)
	executewidget (index.php:1722)
	(anonym funktion) (index.php:1734)

Gertjan

@skitapa said in DHCP lease screen not loading:

with my real local IP replaced:

Why ? We all have the same local RFC1918 IP's or on our LANs.
Like we all have a room in our house called 'kitchen'.

The IP you were hiding is firing requests that the "access control" logic can't understand.
I'll propose : remove that device from your network, and the messages idssapear.
Or make it stop hammering the pfSEnse (192.168.1.1) web interface.
.

skitapa

@gertjan said in DHCP lease screen not loading:

Why ? We all have the same local RFC1918 IP's or on our LANs.
Like we all have a room in our house called 'kitchen'.

Because unnecessary information leakage is unnecessary even if seemingly unimportant.

The IP you were hiding is firing requests that the "access control" logic can't understand.
I'll propose : remove that device from your network, and the messages idssapear.
Or make it stop hammering the pfSEnse (192.168.1.1) web interface.
.

This last part I can not understand. I get the access control errors when connecting, with a browser, to my PfSense device, removing my router from my network surely will make the errors go away, but then again also my admin webgui, my routing capabilities and the very center of my network as well.

The "hammering" you are referring to is done by the Admin webgui in PfSense and is not something I am responsible for, well more than wanting to load a page with information.

And just to be super clear, the IP:s I replaced is replaced only in the logs when pasting them in here.

My post may sound hostile, and it is not my intention. Just trying to clear some things up

Gertjan

@skitapa said in DHCP lease screen not loading:

I get the access control errors when connecting, with a browser, to my PfSense device, removing my router from my network surely will make the errors go away

Not pfSense. pfSense works, as you and me use the same version.
Remove the device you use that hits pfSense. For example, use your 'phone' instead to visit the pfSense GUI.
Or use another browser.
Or tell the browser that you use that accept 'Java'/'ajax' stuff. You're using some addon in your browser that blocks something ?

Also : is your connection to pfSense wired ? Wifi ? The IP LAN isn't changing ?
If the connection gets killed, your device isn'"t considered connected ( == authenticated as 'admin' any more and subsequent dashboard updates/refreshes fail. Normally, the browser should get redirected to the login page, and ajax calls from your browser should stop.

skitapa

@gertjan said in DHCP lease screen not loading:

@skitapa said in DHCP lease screen not loading:

I get the access control errors when connecting, with a browser, to my PfSense device, removing my router from my network surely will make the errors go away

Not pfSense. pfSense works, as you and me use the same version.
Remove the device you use that hits pfSense. For example, use your 'phone' instead to visit the pfSense GUI.
Or use another browser.
Or tell the browser that you use that accept 'Java'/'ajax' stuff. You're using some addon in your browser that blocks something ?

Also : is your connection to pfSense wired ? Wifi ? The IP LAN isn't changing ?
If the connection gets killed, your device isn'"t considered connected ( == authenticated as 'admin' any more and subsequent dashboard updates/refreshes fail. Normally, the browser should get redirected to the login page, and ajax calls from your browser should stop.

Hi!

The problem has sorted itself right now. I do not know why it started working all of a sudden. I have done a lot of changes to the domain, IPs and so on.
Because the problem stems from an issue where the webpage is addressing another domain it is very hard to implement a website, or an admin web interface, that is resilient to this as the very idea of PfSense is to be able to change this thing on the fly.

I saw this on a laptop so the errors were over a wireless connection, did not test it from a wired one. If it happens agin I will test it from a wired connection.

viktor_g

Could you test this patch: 401.diff ?

See https://docs.netgate.com/pfsense/en/latest/development/system-patches.html

skitapa

@viktor_g I can indeed, but I will wait until I experience the problems again.

That way I can verify that it is the patch that solves the problem and not something else

onzippy

@viktor_g The patch resolved the issue for me.
Status / DHCP Leases page now loads immediately. (had been taking ~40 seconds since the 2.5.2 upgrade).
Thanks.

Gertjan

@viktor_g said in DHCP lease screen not loading:

Could you test this patch: 401.diff ?

Hard coded 8.8.8.8 and 8.8.4.4
So these are now needed because the a (local) DNS is 'unavailable' for pfSense ?

chance

Someone please tell me this is just a testing patch and nobody realistically expects us to have 8.8.8.8 and 8.8.4.4 hard coded and allowed to be contacted by the pfsense box?

hazarjast

@viktor_g Applied the patch but no joy. DHCP Leases page tries to load for over 2 minutes before ending in a 504.

Gertjan

@chance said in DHCP lease screen not loading:

Someone please tell me this is just a testing patch and nobody realistically expects us to have 8.8.8.8 and 8.8.4.4 hard coded and allowed to be contacted by the pfsense box?

I installed the patch - it installs just fine on 2.5.2 CE.
The good news : the patch is just a safety net, and not actually using "8.8.8.8" to resolve.
8.8.8.8 and 8.8.4.4 are just two (worlds most) known IPs used to 'test' if pfSense itself can resolve.
If it can't, the call to following PHP function "gethostbyaddr()" is bypassed. This happens on several places in the GUI code.

The test determines if it can get the reverse PTR of 8.8.8.8 and/or 8.8.4.4.
If it can't, local DNS seems to be not available, and calls to "gethostbyaddr()" will get skipped.

@hazarjast said in DHCP lease screen not loading:

Applied the patch but no joy. DHCP Leases page tries to load for over 2 minutes before ending in a 504.

The patch works.
When NOT installed, everything works fine for me.
When I stop the resolver, and I visit, for example, Status> DHCP Leases, it takes forever to load that page.
When I install the patch, Status> DHCP Leases shows up immediate, with or without the resolver running.

Actually : @viktor_g :

What about adding a global pfSense notification, the one that show up on the top of main dashboard page, that tells the admin that local DNS is not working ?

hazarjast

@gertjan I have neither the forwarder nor resolver enabled (I use NextDNS daemon DNS). With the patch applied 'DHCP Leases' still loads for an eternity before finally returning a 504. Screenshots attached below. Perhaps there is something additional required for the patch to work which I am missing?

hazarjast

This post is deleted!

hazarjast

UPDATE
It seems this issue exists when using DNS Resolver (Unbound) or when using an external DNS server like NextDNS CLI daemon. In my case I reverted the patch provided in this thread and switched back to using DNS Forwarder for local lookups with NextDNS for external lookups. This allowed the DHCP Leases page to load more consistently without 504s although randomly it still takes longer to load than before I upgraded to 2.5.2. Really hoping the root issue is found and remediated in the next release. Until then at least this is no longer a showstopper for me.

For anyone using something like NextDNS wanting a reference configuration, I am using the configuration at the end of the thread here. Below are my DNS Forwarder (dnsmasq) settings in pfSense for reference (do not use strict binding if IPv6 is required):

hazarjast

Forgot to include that under General Settings I selected 'Use local DNS (127.0.0.1), ignore remote DNS Servers' in conjunction with the DNS Forwarder selections:

This is probably implied but, for transparency, DHCP DNS server is set to the LAN IP of pfSense which is running the NextDNS CLI daemon:

ssp

In CE 2.6.0, I get the 504 time out. I comment out this line in /etc/inc/system.inc, and it loads instantly even with a few thousand IPs leased:
$hostname = gethostbyaddr($item['ip']);

Yes using a DNS forwarder because of many internal systems that we need hostnames mapped to. Everything is on one device with our gateway firewall functions, dhcp, dns forwarding.

In the status screen at /status_dhcp_leases.php, the "Hostname" column seems to be indicating something against most leases, corresponding to their device's internal name (computer name, etc.).

Could someone kindly explain why a DNS lookup would even be happening for DHCP leases? Aren't all the devices internal?

Gertjan

@ssp said in DHCP lease screen not loading:

Could someone kindly explain why a DNS lookup would even be happening for DHCP leases? Aren't all the devices internal?

These are your leases : /var/dhcpd/var/db/dhcpd.leases
As you can see, the client host name is present. This is the name that the device gave to pfSense, and isn't necessarily the name pfSense gave it. That is, the name you gave it when you created a static DHCP lease.

gethostbyaddr() is used to get the registered DNS host name using the IP, found in the lease.

The (your) issue is : the DNS isn't working.
What gethostbyaddr() does : it uses /etc/resolv.conf to get the address of the 'nameserver', normally 127.0.0.1. Then it connects to 127.0.0.1 port 53 and does the DNS request.

So, does your DNS forwarder listen on 127.0.0.1 - or whatever IP you found in /etc/resolv.conf ?

ahsunh

@ssp As far as i observed PfblockerNG python mode cause issue for dhcp lease page loading please test if you use python mode in PfblockerNG devel version.
Without Python mode it works fine as expected.

ssp

@gertjan Thank you for explaining that!

I use DNS Forwarder in pfSense. It listens on LAN port 53. I have the "Do not forward private reverse lookups" checked. I have a few host overrides which map to a few of our internal hosts. That's it. System - General Setup - DNS Servers list the OpenDNS servers that we use (these are reflected in /etc/resolv.conf). I suppose those would not respond to reverse IP lookups anyway.

Not sure what I would do differently. The getaddrbyhost is not a functionality I would need. Have not changed settings for years but DHCP leases page stopped loading last few CE versions.