Manually copying the openssl 3.0 libraries from a pfsense CE 2.7.1 system to /usr/local/lib on the 2.7.0 system fixed the issue for me. This isn't ideal but ISC BIND is working on pfsense CE 2.7.0 now:

[2.7.0-RELEASE][rsh@balsa.home.arpa]/home/rsh: ls -l /usr/local/lib/lib*.so.30 -rw-r--r-- 1 root wheel 4588560 Nov 23 10:00 /usr/local/lib/libcrypto.so.30 -rw-r--r-- 1 root wheel 694560 Nov 23 10:00 /usr/local/lib/libssl.so.30 [2.7.0-RELEASE][rsh@balsa.home.arpa]/home/rsh: ldd /usr/local/sbin/named-checkconf /usr/local/sbin/named-checkconf: libjson-c.so.5 => /usr/local/lib/libjson-c.so.5 (0x2fde82caf000) libprotobuf-c.so.1 => /usr/local/lib/libprotobuf-c.so.1 (0x2fde83cbc000) libfstrm.so.0 => /usr/local/lib/libfstrm.so.0 (0x2fde84396000) libssl.so.30 => /usr/local/lib/libssl.so.30 (0x2fde8579e000) libcrypto.so.30 => /usr/local/lib/libcrypto.so.30 (0x2fde861d3000) libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x2fde84451000) libz.so.6 => /lib/libz.so.6 (0x2fde84ceb000) libuv.so.1 => /usr/local/lib/libuv.so.1 (0x2fde86bbb000) libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x2fde8711e000) libthr.so.3 => /lib/libthr.so.3 (0x2fde87801000) libc.so.7 => /lib/libc.so.7 (0x2fde8849e000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x2fde8931d000) libm.so.5 => /lib/libm.so.5 (0x2fde894f9000) libelf.so.2 => /lib/libelf.so.2 (0x2fde8a3a7000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2fde8be5a000) libmd.so.6 => /lib/libmd.so.6 (0x2fde8a578000) [vdso] (0x2fde821ab620)

@eriksalo said in Migrating to KEA broke my network:

You should not have to understand packet capture [ . . . ] Wouldn't you agree?

i would, and that was but merely one possible troubleshooting suggestion.

@eriksalo said in Migrating to KEA broke my network:

If there's some procedure I need to complete to make this work, I'd be happy (and able) to do it.

you might try to actually configure Kea—and include any such information with any future request for free help—should you choose to move away from a now-deprecated application again.

@Jarhead OMG! that was it... Now I feel really stupid.... Thanks for the quick response!

@RobbieTT said in DNS Resolver stops when WAN goes down so DNS Overrides don't work when there is no Internet connection.:

@bmeeks

Ok, didn't realise there was a dpinger setting at play - TVM!

Presumably you mean this one:

2023-11-21 at 16.19.55.png

I've not noticed a delay with pfBlockerNG although that may be due to having a small list or just a decent CPU & bandwidth to mask it.

Yes. That setting will disable the "restart all packages" and "cycle the interface" actions. That may or may not be desirable depending on your situation.

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!

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...)

Screen Shot 2023-11-10 at 2.25.50 PM.png

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"