DHCP lease screen not loading
-
@pfkitwargarrant I can almost guarantee this issue is related to DNS forwarding or DNS setup in general.
Once I turned off forwarding from my DNS server the issue went away. Didn't start until I upgraded to the new release but the issue is definitely DNS.
-
@bobby_hill1983 it's being quite a while, but I solved it by disabling DNS forwarding I just updated the host file on all my machines.
Under general I set t to ignore local servers and use external DNS only.
I've since tried enabling it a couple of times but I don't trust the DNS forward and DNS resolver at this point.
If you don't have a lot of machines it's no big deal to update their hosts or LM host file for Windows
Pre March 2020 I had an update kill one of my netgate machines and I had to ship it to them. Thing lit up red. Since that time I'm pretty reluctant to do updates and that last one that screwed up the DHCP, well let's say I haven't done any updates since
-
@pfkitwargarrant - I went to Services > DNS Forwarder and unchecked the "Enable DNS Forwarder" box. I then went to Services > DNS Resolver and checked the "Enable DNS Resolver" box.
@Gertjan - I meant to reply to your post from two weeks ago (see my post above about a week ago) but I think I replied to the main thread. Do the steps I listed in that post make sense? I've been using pfSense since maybe version 2.2 and each upgrade went relatively smoothly until the DHCP Leases page broke when going from 2.4.5_p1 to 2.5.1. The 2.5.x upgrade leaves the existing DNS settings alone which apparently may cause some things to break. In my case coming from 2.4.5_p1, DNS Forwarder was enabled and DNS Resolver was disabled, but reversing those settings (disabling DNS Forwarder and then enabling DNS Resolver) seems to have solved my problem.
2.5.x seems to be doing something very differently than previous versions.
It's been about a week since I made the changes and the DHCP Leases page still loads quickly.
-
@cmwang Ah that is exactly how my setup is configured at the moment, issue still persists.
-
Hi there i dont use DNS forwarder ( it is unchecked)
I use DNS resolver ( checked Enable DNS resolver) Checked DNSSEC , checked DHCP registration.In General setup I have my remote DNS servers
unchecked server Override
DNS Resolution Behavior : Use remote DNS servers, ignore local DNSThis is my setup.
-
@pfkitwargarrant said in DHCP lease screen not loading:
Ah that is exactly how my setup is configured at the moment, issue still persists.
That is : it's the other way around ;)
Your code, the base you used to install pfSense, is identical at byte level among all of use.
We all introduce small differences as Im using em NIC drivers - and have a Toshiba had disk and on older Pentium processor, or you have re drivers, a Seagate disk and a AMD processor.
We also have different WAN IP's.
If the rest of all other settings -our config - matches, and I have no issues, you can't have issues.So, as usual, I tend to propose :
Backup your config.
Goto the console, and reset to default config.
When the system reboots, assign interfaces, change the password.
And stop there.
Now, your issue is gone.Enjoy it for a while.
Now, import your backed up config - and reboot.
The issue came back .....Now you'"ll know what to do ;)))
-
Hi everyone,
Just to inform that I updated to 2.5.2 Pfsense version but I still have the same isue.
One interesting thing :
When I am log on, I have the 504 after few mintures loading.
However, if I am writing anything after my pfsense ip, it works.
For example http:/... ... ...... /vpn_openvpn_server.phpWhen I am erasing dhcp leases from the WebUI, it doesn't work.
-
@hita352 said in DHCP lease screen not loading:
One interesting thing :
When I am log on, I have the 504 after few mintures loading.
However, if I am writing anything after my pfsense ip, it works.
For example http:/... ... ...... /vpn_openvpn_server.phpWhen you visit http://192.168.1.1 you load the default web page, and that is the dashboard page.
This page shows a lot of info. Most of it is cached, but refresh after a couple of seconds.
Some of the info isn't available locally, but needs request over the Internet to get shown.
if the upstream connection isn't available, or, very popular, DNS is broken, the requests going "outside" need a lot of time, and will finally time out.Pages like https://pfsense.your-network.tld/vpn_openvpn_server.php can fully load with the info locally available, so nothing will block the creation of the page.
-
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)
-
@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.
. -
@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
-
@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. -
@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.
-
Could you test this patch: 401.diff ?
See https://docs.netgate.com/pfsense/en/latest/development/system-patches.html
-
@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
-
@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. -
@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 ? -
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?
-
@viktor_g Applied the patch but no joy. DHCP Leases page tries to load for over 2 minutes before ending in a 504.
-
@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 ?