I 100% agree with @johnpoz here. With a Microsoft Active Directory shop, you want everything DHCP and DNS related to be handled by Microsoft products in my opinion. Most definitely DNS! And because of the seamless dynamic DNS updating performed by Microsoft's DHCP server, it is better and easier to run DHCP there instead of on pfSense.

And handing out two different DNS servers each of which may have some zones unknown to the other server is sure to cause an issue as described by John. Clients do NOT use multiple DNS servers sequentially until one of them finds an answer. They ask one of the servers randomly, and if that server says NXDOMAIN (non-existent domain), then the client does not ask the next server because it has already gotten an answer. The only time clients try one server and then move on to the next in a multiple DNS server configuration is when the first server is completely dead and does not answer at all.

@aGeekhere Okay, so the real trouble is actually because of the few clients that you want to bypass the DNS filtering done by 1.1.1.3/1.0.0.3

1: Unbound DNS in pfsense by default does caching of all DNS lookups as TTL records allows. This is the same caching as Lancache does unless you start configuring some out of spec extra caching (of invalid records). If that is your reason to keep lancache in the loop configure Unbound to do the same (out of spec) caching of stale records - it can be done in the advanced settings.

2: Configure Unbound in pfSense to use forwarding instead of the default root recursive resolution. Then Unbound will do all lookups by forwarding to the DNS servers in "SYSTEM -> GENERAL -> DNS Servers"
It will still cache all records, so just hand the clients your pfSense DNS and drop the lancache server.

Using forwarding mode prevents us from exempting specific clients from being DNS filtered pr. the forwarding servers filters. So to have a few clients NOT being filtered things become a little more troublesome. For this you could:

1: Keep the lancache servers for those clients - make a DHCP reservation with a DNS override to hand them the lancache server as the only DNS
2: Configure Lancache to use your preferred public DNS as forwarding servers (1.1.1.1/1.0.0.1).
3: Create a stubzone on Lancache for you internal domain name for clients (the domain name used for your overrides in pfSense), and point that stubzone to forward to pfSense instead of 1.1.1.1/1.0.0.1

This will create the scenario you are looking for.

@johnpoz Thanks on Safari I was able to figure out!!: Screenshot 2025-01-02 at 04.34.24.jpg I had to delete this and then it clears all domains entries in the local storage with .home.arpa!

@johnpoz I admit the setup isn't ideal, however somehow despite the error messages the system seems to work -- clearly I don't really understand all the underpinnings of how things work.

How should I be constructing things??

Two pfsense installations running unbound with same domain. Each pfsense installation has domain overrides for subdomains running on their installation. Additionally each pfsense answering DNS over DOT on port 853.

domain.com------->>>Pfsense #1 (domain=domain.com) -> Overrides--->test.domain.com --->test2.domain.com --->test3.domain.com ------>>>Pfsense #2 (domain=domain.com) -> Overrides --->test4.domain.com --->test5.domain.com --->test6.domain.com

Each installation can resolve locally, however if pfsense installations connected by vpn, I need name resolution for devices on Pfsense #1 network accessible to devices on Pfsense#2 network -- and vice versa. If VPN is broken or down, local domain overrides will still work.

I'm just making use right now of the unbound domain overrides section similar to this:
Screenshot 2025-01-01 at 5.40.14 PM.png

In terms of DOT -- no I don't need it between the pfsense nodes on either end of the tunnel -- however how do I have it only active for LAN clients but not for the tunnel?

I'm not looking actually to forward DNS requests, rather have unbound "resolve" them and then pass the answer back to the clients. In terms of resolving (not forwarding), how does each unbound server know what DNS server is definitive for a specific local domain that's split? I thought I was accomplishing this by listing the servers within the domain overrrides section.

I put the pfsense into prod today. I have an old unmanaged 10/100/1000 Cisco switch that I plugged into my LAN port, and I have all physical cables plugged into it. I don't love adding another switch in the middle, but it allows me to keep everything flat and on my 192.168.x.x CIDR block. Once its all stable, I can look into whether I want to create separate networks and use more physical ports on the pfsense box.

I have a question about a repetitive entry in my System Log. I am getting: "arpresolve: can't allocate llinfo for 10.x.x.x on igc0". This my WAN port that is plugged into my ISP modem/gateway device, so it is double NAT. If I reset the port, the message stops for a little bit but then comes back. I see it in the logs sometimes multiple times per second.

I do have the boxes unchecked on the WAN port for the Block Bogon and Block private networks.

Should this arpresolve error be happening this much and is it something I can resolve?

Thanx guys, for your reply

@johnpoz I can follow the logic, as you explained it, using the main breaker example.

Thanks.
I've made the change @patient0 suggested. As to @johnpoz, the DNS Server Override was already clear.
The Good News is that ipconfig gives my firewall as the DNS for the ethernet connection and 1.1.1.2 for the VPN. Looks like either that change cleared the situation or there was no prob in the first place.
Thanks again!

@MarinSNB my understanding is yes some code in the + changed, not sure when but it was for sure before 24.11 this showed up.. My guess is when CE 2.8 drops will see the same thing in CE

@johnpoz Yes, I changed it. thank you for the tips. I ended up spending the rest of the day messing around with cloudflares zero trust platform with their DNS blocking/filtering features now that I finally control the DNS on my network.

@bmeeks said in ISC DHCP Dynamic DNS feature and Kea DHCP?:

Your issue is updating secondary DNS servers and not the unbound daemon running on pfSense.

Correct. All hosts on my network get IP addresses from pfSense ISC DHCP servers those sends dynamic updates to FreeIPA-integrated BIND DNS servers.

Why use FreeIPA-integrated DNS? Because FreeIPA is a great OpenSource identity management software and it also uses ISC DNS service.

I was able to get this working. I now have sites blocked, etc. I still have to make sure that DNS over TLS works and I also need to configure this for IPv6 so a bit more to do.

I needed to add the appropriate rules to my firewall as specified in these recipes. I added a total of 3 firewall rules and 1 NAT rule.

DNS redirect:
https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html

DNS Blocking:
https://docs.netgate.com/pfsense/en/latest/recipes/dns-block-external.html#blocking-external-client-dns-queries

93ee7da2-b049-491f-88d7-e6bafcf4065a-image.png

79a7645d-3820-433b-9dcf-c25d65f571e0-image.png

seems a bit brutal to have to default the devices...

I've got this in a HA pair - the interface PPPoE is defined on is actually kind of a dummy interface but I've set up a gateway for it to make it into a WAN interface - and its made no difference....

I used to have loads of config on there - but I've paired it right back to try and isolate the problem...

this is a real pain in the ar$£....

config file having manually changed it to what I want...

{
"Dhcp4": {
"interfaces-config": {
"interfaces": [
"em0.20"
]
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/kea/dhcp4.leases"
},
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "syslog"
}
],
"severity": "INFO"
}
],
"valid-lifetime": 7200,
"max-valid-lifetime": 86400,
"ip-reservations-unique": false,
"echo-client-id": false,
"option-data": [
{
"name": "domain-name",
"data": "home.arpa"
}
],
"option-def": [
{
"space": "dhcp4",
"name": "ldap-server",
"code": 95,
"type": "string"
}
],
"hooks-libraries": [
{
"library": "/usr/local/lib/kea/hooks/libdhcp_lease_cmds.so"
}
],
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea4-ctrl-socket"
},
"authoritative": true,
"subnet4": [
{
"id": 1,
"subnet": "10.7.20.0/24",
"option-data": [
{
"name": "domain-name-servers",
"data": "10.7.20.1"
},
{
"name": "routers",
"data": "10.7.20.1"
}
],
"valid-lifetime": 60485000,
"max-valid-lifetime": 60486000,
"reservations": [
{
"hw-address": "44:19:b6:28:57:37",
"ip-address": "10.7.20.31",
"hostname": "cam1"
},
{
"hw-address": "44:19:b6:4f:59:0a",
"ip-address": "10.7.20.32",
"hostname": "garagecam"
},
{
"hw-address": "ac:cb:51:3c:97:2a",
"ip-address": "10.7.20.35",
"hostname": "cam6"
},
{
"hw-address": "ac:cb:51:3c:97:34",
"ip-address": "10.7.20.36"
}
],
"reservations-in-subnet": true
}
],
"reservations": [
{
"hw-address": "44:19:b6:28:57:37"
},
{
"hw-address": "44:19:b6:4f:59:0a"
},
{
"hw-address": "ac:cb:51:3c:97:2a"
},
{
"hw-address": "ac:cb:51:3c:97:34"
}
]
}
}

config file after I tried to start the service...

{
"Dhcp4": {
"interfaces-config": {
"interfaces": [
"pppoe0"
]
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/kea/dhcp4.leases"
},
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "syslog"
}
],
"severity": "INFO"
}
],
"valid-lifetime": 7200,
"max-valid-lifetime": 86400,
"ip-reservations-unique": false,
"echo-client-id": false,
"option-data": [
{
"name": "domain-name",
"data": "home.arpa"
}
],
"option-def": [
{
"space": "dhcp4",
"name": "ldap-server",
"code": 95,
"type": "string"
}
],
"hooks-libraries": [
{
"library": "/usr/local/lib/kea/hooks/libdhcp_lease_cmds.so"
}
],
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea4-ctrl-socket"
},
"authoritative": true,
"subnet4": [
{
"id": 1,
"subnet": "86.140.132.253/32",
"option-data": [
{
"name": "domain-name-servers",
"data": "10.7.20.1"
},
{
"name": "routers",
"data": "10.7.20.1"
}
],
"valid-lifetime": 60485000,
"max-valid-lifetime": 60486000,
"reservations": [
{
"hw-address": "44:19:b6:28:57:37",
"ip-address": "10.7.20.31",
"hostname": "cam1"
},
{
"hw-address": "44:19:b6:4f:59:0a",
"ip-address": "10.7.20.32",
"hostname": "garagecam"
},
{
"hw-address": "ac:cb:51:3c:97:2a",
"ip-address": "10.7.20.35",
"hostname": "cam6"
},
{
"hw-address": "ac:cb:51:3c:97:34",
"ip-address": "10.7.20.36"
}
],
"reservations-in-subnet": true
}
],
"reservations": [
{
"hw-address": "44:19:b6:28:57:37"
},
{
"hw-address": "44:19:b6:4f:59:0a"
},
{
"hw-address": "ac:cb:51:3c:97:2a"
},
{
"hw-address": "ac:cb:51:3c:97:34"
}
]
}
}

@Gertjan my computer is using my pfsense DNS but not all is working well. Going to reinstall it anyway on a different device and start the config from scratch.

@chrcoluk said in PSA: If you are using DHCP options with Windows 11 and DHCP/networking ceased to function after upgrading to Windows 11 24H2 ...:

, I use option 43 to make sure Netbios is disabled

Ah - ok that use case seems like it would be more common on a user machine vlan..

@datpif Actually just found watchdog starts a different service . so the simplest fix i found was to edit

/etc/inc/service-utils.inc

search for case 'kea-dhcp4':

and add

case 'kea-dhcp4': exec("rm -f /tmp/kea4-ctrl-socket.lock");

Did you manage to resolve this? I've recently encountered the same problem, and this seems to be the only thing I can find mentioning it. Keen to know if there's an easy fix before I reinvent the wheel.

@Gertjan

Thanks Gertjan,

I tried it, and it did get rid of that process. I still had the "FAIL" message come back on the same regular basis all on its own though, with varying PIDs. When I finally found an opportunity to reboot pfsense though (30 mins ago) it went away completely though :-)

So yes, probably some ghost.

Thanks again!

Alex

@swemattias
The error above doesn't come from HAproxy, rather from Cloudflare. So I don't think, that the hostname resolves properly to your IP.
Seems you're using the Cloudflare proxy service.

@whosmatt said in pfSense KEA DHCP problems after reassigning interface:

@mcury I'm not sure that's the same issue. I've actually added and removed members from my lagg many times without DHCP being affected. My issue arises when I assign an interface to a different NIC and then back to the original NIC, which just happens to be a tagged interface with a lagg as the parent. I'm not sure the lagg is relevant.

hmmmm 🤔
I think that the ticket issue is related to yours but I got it wrong, the problem was not adding or removing members from the LAG.
See, previously I had some VLANs, and the issue happened after I moved them to the LAG interface.
At the same time I added a member and that confused me.

So, I really think we have the same issue and I got it wrong when I reported.
This explains why Netgate team couldn't replicate it..

Edit: It happened three times, guess what ?
I have three VLANs..