Agreed, don't use a /16 for your subnet mask. That subnet size allows for 65,500+ machines (hosts) on a single network. That's a lot!

@johnpoz John, i need to revise my original post. Removing the DNS from the VPNs, and disabling DNSSEC fixed the checkboxes not working at all, but there is definitely a functional issue here.

Using the checkboxes to do the forwarding, the below error appears in the logs

Mar 4 21:29:24 unbound 29887 [29887:3] notice: ssl handshake failed 1.1.1.3 port 853 Mar 4 21:29:24 unbound 29887 [29887:3] error: ssl handshake failed crypto error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

disabling the two check boxes, and adding the below in the customs box, the log is clean

server: forward-zone: name: "." forward-ssl-upstream: yes forward-addr: 1.1.1.3@853 forward-addr: 1.0.0.3@853

so, there is something funny going on with these checkboxes

@gwaitsi

It really depends ...

You have told it to forward , that could mean no cache lookups are allowed.
It might still cache the lookups, when received. Just not allowed to use them.

/Bingo

Yup I would set like 1 hour or something for such IPs.. So worse case the lease expires 1 hour later.. But will continue to renew if you haven't yet changed it to a reservation.

It's happened again a few times, and a bit more troubleshooting, however still not closer to finding a resolution.

From the LAN, if I run nmap against the firewall, Ports 443 & 22 are open (https / ssh), however DNS port 53 is closed. Restarting the resolver and a subsequent nmap all is good.

d442f5a8-503f-4643-94f8-c120b3f86823-image.png

any thoughts?

@cino

pfSense uses itself several open source products, like world's most famous https://www.isc.org/dhcp/.
Going from FreeBSD 11.2 to 12.2 probably updated also that package.
With new behaviour ....

This is just what I think is that happened.

@hh77 yup that resolved it. Allowing the unbound to use the root DNS servers did the trick. What is weird that I have always enabled the query upstream server option and not had an issue. I am not going to dwell on it. I glad I got this issue resolved. Now on to others!

@ramikilany https://forum.netgate.com/topic/161624/dns-resolver-sudden-stop-and-filterdns-pid-48934/2?_=1614675790532

For anybody else trying to fix this I used the following options:
Next Server: <IP Address of my WDS Server>
Default BIOS file name: \boot\x86\wdsnbp.com
Additional BOOTP/DHCP Options:
Option: 66, Type: IP address or host, Value: <FQDN of WDS Server>

I was able to netboot a win10 installer from Windows Server 2019 with these settings

Same here. It doesn't make sense now.
Please bring back old behaviour.

@gertjan DNS settings appear to be defaults and yes /etc/hosts has the override entries. I experienced 2 issues.

DNS overrides not resolving for hosts on LAN. This is working after I forced reload of override settings and has not recurred. But I need to check again after next reboot.

DNS overrides not resolving with pfSense Diagnostics / DNS Lookup tool. I cannot be sure if this worked prior to update but it doesn’t work now. Oddly, the pfSense Diagnostics / Ping tool resolves these hosts just fine. I would expect same behavior for both and consider this a bug. The pfSense DNS Lookup tool should resolve the same as pfSense gives LAN clients.

Additional info: The DHCP client alias names are also in /etc/hosts and are not resolved by the DNS Lookup tool but are resolved by the Ping tool. Looks like the DNS Lookup tool only uses the upstream DNS servers. Almost seems like the tool needs a switch to enable local DNS entries to mimic what LAN client requests would receive. More helpful would be to always show both the internal and upstream result.

@asterix_cz said in DHCP Status page - no static leasing times 2.5.0:

Hello,

Hi,

I think this is not a problem and I never had timestamps for static leases even before on older versions. It kind of make sense, what should the timestamp tell you, when it's static lease? Static means, you assigned IP address to specific mac address from "now" till "I delete it" so it can't show any range, just maybe Start, when you assigned it, but I don't know how important it is.
You just maybe overlooked it. Timestamps are showen only when it's "Active" lease, at least on my versions I ever used.

Thanks for your answer. I have not overlooked it because in some investigation cases it was very useful to see wich device was getting when a adresse (even its a static lease) and so one ...

Active leases works as expected.

Thanks,
fireodo

Thank you for the feedback. I will definitely start the process to track this down and once I find it I will post back some quick details and comments. This at least gives me an idea of what I am up against. I had never experienced pfSense until I witnessed the login page. More to follow...

I can confirm the same pfsense sits behind ISP CPE wich provides dhcp on the pfsenses wan interface. What i have discovered so far from testing is from normal reboot wan does get an ip adress from the ISP CPE but if you do a restart with disk checking lights stay on green flashing as normaly but in the UI you can see wan gateway says pending and the wan interface never gets an ip. My solution for now is setting a static ip on the wan interface and asigning that ip as static on the CPE dhcp server.

With sat - peering is quite often a problem.. If you can find a vpn that you have good connection too, you remove the peering issues.

So even if latency to the vpn might be high, if they have better peering to get to where you need to go from them.. Then yeah that can be a solution.

When you resolve you have no idea where the authoritative NS might be - if your internet connection (whatever it is) has high latency - and bad peering, that adds to latency and drops in connections..

Normally with sat connections they provide you a NS to use - since from there they have good connections and good connection from their clients, and its also caching.

But if you can get a stable connection to somewhere, and even if that is 100ms or even 200ms - as long as from that point you have good connectivity.. Then you can be fine for resolving..

VPNs can often be a solution to bad isp peering issues. It can be a way of "routing" around a problem bottleneck connection. I have vps all over the globe I could use to route traffic through - not from a privacy standpoint. But as a way to troubleshoot where issues might be popping up do to congestion, etc.

Think of the internet as a bunch of interconnected roads.. And you just driving home from work, maybe there is a crash holding up traffic on your normal route - but hey even if it might be a mile or 2 out of your way - taking a different path might get you home quicker, etc.