Hi, sorry everyone for the delay, I really thought I posted here that I found the solution to this problem. The problem was, on Proxmox, I had set static IP on the NIC and it was way out of the one I was using into PfSense. As said I'm just dipping my toes on network management and on virtualization, so please excuse my ignorance. Thank you everyone for your help.

@Qinn said in Kea DHCP: Do you mean ignored now, but leave them checked, as assigned hostnames will be implemented in the near future? Sure. And you can go back anytime and or swap at your liking, so I wouldn't mess with the config in pfSense.

@oracle_sod I've set up my DHCP6 LAN servers to update the reverse on my BIND DNS server. My BIND isn't somewhere local, but on the Internet, as my primary domain name server for all my domain names. I'm not updating IPv4 stuff, as IMHO it doesn't make sense to make available to the public that the IPv4 of my (example) LAN based NAS has the IPv4 192.168.1.45 - neither the reverse. If your bind is doing stuff for your LAN? then I can imagine that it does make sense. For IPv6 GUA's, it does make sense. 10-Nov-2023 12:21:29.441 update: client @0x7fd4dc004fa0 82.127.26.100#63539/key update: updating zone 'c.d.6.a.7.0.9.0.9.1.b.c.1.0.a.2.ip6.arpa/IN': deleting rrset at 'c.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.d.6.a.7.0.9.0.9.1.b.c.1.0.a.2.ip6.arpa' PTR 10-Nov-2023 12:21:29.441 update: client @0x7fd4dc004fa0 82.127.26.100#63539/key update: updating zone 'c.d.6.a.7.0.9.0.9.1.b.c.1.0.a.2.ip6.arpa/IN': adding an RR at 'c.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.d.6.a.7.0.9.0.9.1.b.c.1.0.a.2.ip6.arpa' PTR epackferpar22.bhf.tld. 10-Nov-2023 12:22:31.211 update-security: client @0x7fd4dc004fa0 82.127.26.108#63539/key update: signer "update" approved As I'm using KEA (for testing) right now, this updating stopped. I don't care, as my IPv6 prefixes are static, so the GUA is static. The ISC DHCPv4 uses 'nsupdate' which is the same ting as this : Services > Dynamic DNSRFC 2136 Clients. My pfSense acme package uses the exact same 'nsupdate' = RFC2136 to talk to the same BINS server so I can obtain a certificate for my locally used domain name. About my NAS on my LAN : On my PC : reverse lookup : C:\Users\Gauche>nslookup 192.168.1.33 Serveur : pfSense.bhf.tld Address: 2a01:cb19:ffff:a6dc:92ec:77ff:fe29:392c Nom : diskstation2.bhf.tld Address: 192.168.1.33 This always worked out of the box. And again : I'm using the rather limited 'kea' right now, not even isc dhcpd. No "bind", just unbound with default settings.

@dh377 the ^M is a DOS/Windows line ending. Did you edit that file on windows or something? The original file for sure doesn't have them as we all are using it without issues. Either use a file editor and save the file with unix format line endings or just get a source copy of the file, can't help you any further as that is a local issue.

@viragomann This is the traffic when the client is connected directly to the pfsense interface: 12:40:52.281149 54:ee:75:bc:44:d4 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 128, id 24190, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 54:ee:75:bc:44:d4, length 300, xid 0xb049fc35, Flags [none] (0x0000) Client-Ethernet-Address 54:ee:75:bc:44:d4 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 54:ee:75:bc:44:d4 Hostname Option 12, length 12: "Laptop-Tec05" Vendor-Class Option 60, length 8: "MSFT 5.0" Parameter-Request Option 55, length 14: Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name Router-Discovery, Static-Route, Vendor-Option, Netbios-Name-Server Netbios-Node, Netbios-Scope, Option 119, Classless-Static-Route Classless-Static-Route-Microsoft, Option 252 12:40:52.281282 ca:7d:67:06:40:f4 > 54:ee:75:bc:44:d4, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 10.219.1.254.67 > 10.219.1.102.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xb049fc35, Flags [none] (0x0000) Your-IP 10.219.1.102 Client-Ethernet-Address 54:ee:75:bc:44:d4 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 10.219.1.254 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 10.219.1.254 Domain-Name-Server Option 6, length 4: 10.219.1.254 Domain-Name Option 15, length 12: "home.technik" 12:40:56.489241 54:ee:75:bc:44:d4 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 128, id 24191, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 54:ee:75:bc:44:d4, length 300, xid 0xb049fc35, secs 1024, Flags [none] (0x0000) Client-Ethernet-Address 54:ee:75:bc:44:d4 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 54:ee:75:bc:44:d4 Hostname Option 12, length 12: "Laptop-Tec05" Vendor-Class Option 60, length 8: "MSFT 5.0" Parameter-Request Option 55, length 14: Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name Router-Discovery, Static-Route, Vendor-Option, Netbios-Name-Server Netbios-Node, Netbios-Scope, Option 119, Classless-Static-Route Classless-Static-Route-Microsoft, Option 252 12:40:56.489346 ca:7d:67:06:40:f4 > 54:ee:75:bc:44:d4, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 10.219.1.254.67 > 10.219.1.102.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xb049fc35, secs 1024, Flags [none] (0x0000) Your-IP 10.219.1.102 Client-Ethernet-Address 54:ee:75:bc:44:d4 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 10.219.1.254 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 10.219.1.254 Domain-Name-Server Option 6, length 4: 10.219.1.254 Domain-Name Option 15, length 12: "home.technik" 12:41:04.459938 54:ee:75:bc:44:d4 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 128, id 24192, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 54:ee:75:bc:44:d4, length 300, xid 0xb049fc35, secs 3072, Flags [none] (0x0000) Client-Ethernet-Address 54:ee:75:bc:44:d4 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 54:ee:75:bc:44:d4 Hostname Option 12, length 12: "Laptop-Tec05" Vendor-Class Option 60, length 8: "MSFT 5.0" Parameter-Request Option 55, length 14: Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name Router-Discovery, Static-Route, Vendor-Option, Netbios-Name-Server Netbios-Node, Netbios-Scope, Option 119, Classless-Static-Route Classless-Static-Route-Microsoft, Option 252 12:41:04.460023 ca:7d:67:06:40:f4 > 54:ee:75:bc:44:d4, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 10.219.1.254.67 > 10.219.1.102.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xb049fc35, secs 3072, Flags [none] (0x0000) Your-IP 10.219.1.102 Client-Ethernet-Address 54:ee:75:bc:44:d4 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 10.219.1.254 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 10.219.1.254 Domain-Name-Server Option 6, length 4: 10.219.1.254 Domain-Name Option 15, length 12: "home.technik"

@jimp That is / was my situation : before switching to kea I had most of my principal LAN devices listed on a "DHCP Static Mappings" list. Because they are on that list, the host (device) names I gave them are 'DNS honored' = these are the ones I saw in the /etc/hosts file. The are the ones that get also used to create /var/unbound/host_entries.conf Directly from the main config.xml, not indirectly, from /etc/host = I stand corrected here, and that is actually, IMHO, even better. I isolated my own PC, called 'burea2' (see image above), zapped the 'preferred' LAN IP that it wants to obtain from the kea pfSense DHCP server, and it still got the "DHCP Static Mappings" listed IP : 192.168.1.2. This is the only (I guess) thing that matters to me. The config file of kea (DHCPv4) listed bureau2's MAC and IP, so the 'code' was using my staticy DHCP listed devices. That as all I wanted to know : does kea honor the list below "DHCP Static Mappings". For me, after some testing, I saw it did. @jimp said in Migration to Kea: Edit a static mapping in Kea and save/apply and so on, you'll see it's not updated in those files. Before adding another one, I'll switch to DHCP first. Add a new entry into "DHCP Static Mappings". And then switch back to kea or : Plan B : Without switching back to DHCP mode first, I add "DHCP Static Mappings". I'll add a host over ride on the Resolver settings page. This will also take care of DNS visibility. Adding an entry in "DHCP Static Mappings" for my main LAN is actually a rare event. I'm not adding new devices every day or so, maybe one or two or zero a year. Non trusted devices are on the my trusted networks, my main LAN. For devices on the non trusted networks I don't care about DHCP mapping, devices names etc. Btw : will saving the resolver settings page, and the DHCP LAN settings page several times, I saw what is described here : KEA service stopping through the day : kea was in the stopped state. The DHCP log told me that the presence of its 'lock' file of a previous instance was blocking the startup. Said to myself : it can't be that easy, can it ? and zapped the file. kea started fine afterwards.

That is a known limitation of Kea and it's mentioned specifically in the release notes: https://docs.netgate.com/pfsense/en/latest/releases/23-09.html#kea-dhcp-server-feature-preview-now-available We hope to have it feature complete for the 24.03 release but it's still under active development. For now if you need any of the missing features, continue to use the ISC daemon.

@Stan Yeah : some reading from here hover dyndns make me think they don't support "DynDNS" anymore ( ? ), as they added 2FA( ?? ) I can't be sure, of course, I'm not a client of Hover.

@johnpoz ah they are connected via wireguard, so that is the transit.. yup So when you setup the access list, what does the query look like its coming from - is it natted to the wireguard IP? You mean on the wire or in theory? I haven't checked with wireguard yet what excatly is being sent on the interfaces... Network A is 10.0.0.0/16 Network B is 10.10.0.0/16 Wireguard Network is 10.251.0.0/16 I can access 10.10.0.1 from 10.0.0.1 directly without problems, no NAT happening there I think.

thanks a lot @johnpoz for your input and the old thread. I will continues my research there. I guess I get somewhere in a loop and will review all settings and rules. I did set unbound to forward to Quad9 and pihole is set to forward to unbound. Pi-hole has its own network, so I guess it is not the problem maker. What I also need to look into, is the redirection to loopback you mentioned. Not sure I get that right. Cheers

@johnpoz Thank you again! I appreciate you!!!

@maverickws said in Unbound Resolver - failed to resolve host: my setup here at home using pfSense has undergone so many changes I can't actually remember all the issues I've gone through ... for one my memory is not the best You know what can help with that ... setup a personal wiki on a small local system or docker. Then document your changes... and anything else you may need details on in the future. For example, I've already documented this while I test the change and decide what to do with it. Yes, it currently lives as a custom patch on my system. Not that I ever would have selected the option, now i know I never can, not even by accident, because it is not on the list! [image: 1699643464034-screen-shot-2023-11-10-at-2.10.52-pm.png] Even if I never actually use it, I'll know what I did, step by step. Want to go back to say a Windows XP box, I can look in the "Legacy OS Toys" page, and have it up and running in minutes. thought I should check.. LOL yup still got it (but why...) [image: 1699644483248-screen-shot-2023-11-10-at-2.25.50-pm.png] [image: 1699644497200-screen-shot-2023-11-10-at-2.26.49-pm.png] wow, now there are a couple I haven't fired up in a while A Debian 11 system - Hosting Raspberry Pi Desktop - Hosting PiDP Always fun! or how about a good old "Welcome to SCO Xenix System V"

@johnpoz said in certain website takling long to respond or erro nx dns: but every other site looked at before going back to the forums worked just fine. The every other sites that I visit also work fine, unless they don't. But the percentage is minimal, for sure. About jumping on conclusions, from an outage "yesterday", you're jumping to the conclusion there was a forum outage today, are you not? So why am I not entitled to relate your description of the issue to my description of the issue, since the behaviour fits perfectly in what I described earlier, and on the "taking long to respond" remarks of the other users? (notice the title says "certain websites" not "all websites at a given moment"). We all can jump to conclusions at a given time, for sure. And that can make you overlook the actual issue, can it not?

@maverickws Yeah, it also seems to be happening more frequently with me, too, all of a sudden.

@johnpoz good questions, thanks for the interest. Simplest answer at this point is nothing to be overly bothered by from pfsense perspective, it's something I'm looking at but probably won't get to the bottom of it. Had some uninvited guest lurking around for a while. Could be using a logon/ssh from the inside / mgmt. To answer your questions another way, a few CCIEs and security qualifications and around 30 years experience, which makes me old and a lot slower than I used to be and I don't mind being wrong regularly these days. Thanks for your awesome support today, a great reflection for the product. Kind regards

@johnpoz after some pondering and tearing my hair I gave up and yet again reinstalled pfsense from scratch. I started pfsense with a cable from modem to pfsense wan (eth0) and a cable to windows computer on lan (eth1). It started and I did have internet. I could run ping, trace etc on pfsense. I could also surf on My computer without problem. I didnt run ”setup wizard”. Now I did a test and changed one thing: from Interfaces - Wan I removed ”dhcp6” to ”none” since I dont have anyipv6. Result: cant ping etc and dont have internet on computer. Changed back the one and only setting. No change, still cant ping or do anything on the internet. Whats wrong? Ps. Soon I Will throw this hardware thru the wall.

@noobalaboomer said in DNS issue: Unable to open /cf/conf/config.xml for writing in write_config() Two possibilities - an solution : Can't write to the file system == can't write file to disk : There is no more space left on the partition (disk) ...... unbound was telling you the same thing. You found the solution : use bigger drive ^^