@jordanet ah that is fine - not sure why it seemed like you were pointing to rfc1918, my bad.. But resvoing a 185.x. wouldn't be a rebind.

@TheNarc said in Intermittent DNS Issue:

@Gertjan Not sure what VPN @DaveP-0 is using, but it seems that Nord just started (without announcing to anyone) redirecting all DNS queries. Related post

It may not surprise you to note that I am using Nord VPN. I've read the other thread and realised I missed it because it was talking about VLANs. Never mind. I have the same issue.

@johnpoz Thanks for that. It makes sense and now I know. You would think PfSense had a warning even if they don't want to automagically unset it. Which I understand. I like that policy.

I'm online to Nord Support now and my subscription expires in a few months so new VPN may be on the menu. Pity I like Nord. Lets see what they say to me.

I'd like to thank you all for the support it is appreciated and I'll close this thread and move to the already set Related post

@McMurphy said in DNS Settings For Active Directory at a remote site:

@bmeeks

p.s. And just when I thought understood what a resolver was I found this...
14.03.2024_21.03.02_REC.png

I created a rather long post above this one to explain this screenshot.

The short version is the parameter highlighted in the red rectangle changes the mode of operation for the DNS Resolver over to forwarding mode instead of the default resolving mode. There are not many good reasons for doing that in the opinion of many of us seasoned admins. If you enable Forwarding Mode, then you must provide the DNS servers to forward the queries to under the DNS Servers section of GENERAL under the SYSTEM menu.

Also note that if you enable this DNS Resolver option to switch it to forwarding mode, you should NOT enable DNSSEC. The server you forward to either does DNSSEC or it does not, but it will not do it just because you check that box. In fact, some external DNS servers will not work correctly if you enable DNSSEC when forwarding (Quad9 being an example, see this: https://docs.quad9.net/Quad9_For_Organizations/DNS_Forwarder_Best_Practices/#disable-dnssec-validation). That checkbox really only applies to resolver mode operation.

@johnpoz

I connected two switches and pfsense so that's all I use.

I took a look at these switches you are talking about, these cisco office switches, which one do you recommend?

@pftdm007 I have 2 sites, one site cannot use Quad9 i TLS mode anymore. Works fine i normal forwarding mode, so I’m starting to think it’s my ISP doing something fishy with TLS to that site.

@tgl said in Kea DHCP not assigning addresses:

What happens if I just switch the "Server Backend" choice back to ISC? Do I lose my DHCP-related configuration settings? What about the lease database?

For the next person interested: I just switched to ISC (by flipping the radio buttons under System/Advanced/Networking), and I find that it kept all of the major DHCP settings such as lease ranges, but it just threw away the lease database. The latter's pretty unsurprising I guess given that the storage is completely different. I expect my clients will ask for their existing addresses and ISC DHCPD should grant the requests, so it should be all OK once the dust settles.

I don't have any statically-mapped DHCP addresses, so I can't say whether those would have been preserved. Also, it's worth taking a look at the DHCP configuration page(s) after you switch, because it seems like there's a few minor options that ISC has and Kea does not.

Just an update. I'm finding the same solution works in 2024. I have to reboot whenever I add a static DHCP if I want to see it in BIND. It's been this way for ever. I'd almost call it an unsolved bug (?)

@OffstageRoller said in DNS not resolving IPv6 only address via WAN/localhost only:

@Gertjan What response are you getting for this command?

dig aaaa aaaa.v6ns.test-ipv6.com

and earlier (I didn't notice) :

@OffstageRoller said in DNS not resolving IPv6 only address via WAN/localhost only:

This isn't a real world problem. This would just get me a 10/10 instead of 9/10 on test-ipv6.com.

Your right : that changed for me also :

efef5c87-5055-4cbb-b76b-d6cf549ea92f-image.png

I thought : because the unbound config only contains this - the IPv4 localhost : 127.0.0.1, I add this :

2eda141f-9479-48cf-8307-27b4bd761c1b-image.png

Now I have :

3e1f9087-d6b3-4ac4-b53e-ecacfcabd20e-image.png

checking the unbound config file :

311d54f1-284e-42a1-8083-9d7455f4703f-image.png

I closed all browsers, ditched the local DNS on my PC (ipconfig /flushdns) and redid the test :

ec999d2f-de41-4eee-8952-58f268fd1dff-image.png

[23.09.1-RELEASE][root@pfSense.bhf.tld]/root: dig @::1 aaaa aaaa.v6ns.test-ipv6.com +trace +nodnssec ; <<>> DiG 9.18.16 <<>> @::1 aaaa aaaa.v6ns.test-ipv6.com +trace +nodnssec ; (1 server found) ;; global options: +cmd . 85938 IN NS h.root-servers.net. ...... . 85938 IN NS i.root-servers.net. ;; Received 239 bytes from ::1#53(::1) in 7 ms com. 172800 IN NS a.gtld-servers.net. ..... com. 172800 IN NS m.gtld-servers.net. ;; Received 848 bytes from 198.97.190.53#53(h.root-servers.net) in 24 ms test-ipv6.com. 172800 IN NS ns1.test-ipv6.com. test-ipv6.com. 172800 IN NS ns3.test-ipv6.com. ;; Received 148 bytes from 192.26.92.30#53(c.gtld-servers.net) in 18 ms aaaa.v6ns.test-ipv6.com. 300 IN NS v6ns.test-ipv6.com. aaaa.v6ns.test-ipv6.com. 300 IN NS v6ns1.test-ipv6.com. couldn't get address for 'v6ns.test-ipv6.com': not found ;; Received 210 bytes from 176.58.89.68#53(ns3.test-ipv6.com) in 34 ms aaaa.v6ns.test-ipv6.com. 300 IN AAAA 2001:470:1:18::115 v6ns.test-ipv6.com. 300 IN NS v6ns1.test-ipv6.com. ;; Received 141 bytes from 2001:470:1:18::3:53#53(v6ns1.test-ipv6.com) in 160 ms

There is an answer in there ( 2001:470:1:18::115 ).
Running the same command without +trace :
No answer ???!?

Look at this :

[[23.09.1-RELEASE][root@pfSense.bhf.tld]/root: dig @::1 aaaa aaaa.v6ns.test-ipv6.com +trace +nodnssec +short NS e.root-servers.net. from server ::1 in 5 ms. NS l.root-servers.net. from server ::1 in 5 ms. NS a.root-servers.net. from server ::1 in 5 ms. NS k.root-servers.net. from server ::1 in 5 ms. NS d.root-servers.net. from server ::1 in 5 ms. NS b.root-servers.net. from server ::1 in 5 ms. NS g.root-servers.net. from server ::1 in 5 ms. NS f.root-servers.net. from server ::1 in 5 ms. NS i.root-servers.net. from server ::1 in 5 ms. NS h.root-servers.net. from server ::1 in 5 ms. NS j.root-servers.net. from server ::1 in 5 ms. NS c.root-servers.net. from server ::1 in 5 ms. NS m.root-servers.net. from server ::1 in 5 ms. couldn't get address for 'v6ns.test-ipv6.com': not found AAAA 2001:470:1:18::115 from server 2001:470:1:18::3:53 in 153 ms.](link url)

How should I read this ?
One NS didn't have an answer, but the second one did (2001:470:1:18::115) ?

Btw : I dig using @::1 to force it using IPv6 locally. I've added the +nodnsec to make the resolving a bit more readable.

@chiefsfan Did you find this page?
https://docs.netgate.com/pfsense/en/latest/troubleshooting/ha-dhcp-failover.html

@SteveITS said in removing 127.0.0.1 from DNS search order:

…think you meant “DNS requests” here…

Yes, of course DNS.

@Mauricio-Joel-Maidl said in kea-dhcp does not start:

I am using an NTP hostname in the DHCP settings

This is an IP address :

5e991a85-d2a8-4e8b-a407-48aa4d94cef6-image.png

not a host name ^^

If you were actually using host name like ntp.server.tld, KEA (and also ISC-DHCP) would fail to start.
The popup - this popup :

142b1b65-f1fc-4f57-8147-50ff562989d8-image.png

is wrong.
Only IP v4 and v6 addresses are allowed - a DHCP server will not (and shall not ?) resolve.

@cyberconsultants

Which issue? I described a number them.

I don't think they intended for the connection to cycle (working then fail 1/2 the client time).

hp

@alainf That's not the correct part of the log you are showing. If your Modem looses power pfSense should see a link-down event on it's WAN, and a proper link down should have pfSense attempt to renew its DHCP - and if not try to aqquire a new DHCP lease.

But if there is no link-down event involved - then you are in similar trouble to many others because pfSense offers no automation to actually release/renew WAN DHCP addresses.
See this tread:

https://forum.netgate.com/topic/186492/isp-comcast-wans-failing-on-dhcp-lease-modifications/3?_=1710174622391

@SteveITS No problem 😉 I had KEA active for a couple of weeks now but today I noticed the first time that the policy-based routing for that particular host wasn't working as expected due to the wrong IP. Not sure though what exactly triggers this incorrect DHCP lease.

@pfpv said in Updating MAC for a reserved IP problem:

Sounds like Apple is being Apple.

Yeah - they just looking out for us you know ;) hehehe /s

features related to static ARP and IP should work properly

Completely agree.. there is something going on with it still.. That is clear.. I don't really have any need of them - so no horse in the race, or dog in the hunt if you will for me.. But yeah it should work..

If I did have need/want for it - I would prob just set the static with arp directly currently and not play around with the static arp in the dhcp stuff. But now that I think about.. There are really two places.. There is setting at the server setting to allow/enable them - and then there is the setting at the reservation.. I wonder if there is something going on related.. That if you don't have that set to use static arp everywhere that the setting on the specific reservation has problems?

@pfpv said in Unbound - CVE-2023-50387 and CVE-2023-50868:

@Gertjan said in Unbound - CVE-2023-50387 and CVE-2023-50868:

[23.09.1-RELEASE][root@pfSense.bhf.tld]/root: pkg upgrade

Should we all run this package upgrade?

Depends upon whether you think your network is really vulnerable to the exploit described in the CVE reports.

For my case, with a home LAN, I'm just waiting until I update to pfSense Plus 24.03 in the future as I suspect it is going to be released soon. If I ran a business critical network that was perhaps vulnerable to the CVE exploits, then I would update.

@andmattia
One of the weaknesses of pfblocker is that its all or nothing..No granular control.
So you could create a DNSBL custom feed. Apply it. Then use the Python group to start whitelisting IPs so those IPs wouldn't be impacted by that list.
Of course, the caveat is that you do not have other lists you are using 'globally' in which case the whitelisting will be applied to them.

Another less common way and I've used this in the past is using Suricata and custom rules. Suricata can read into the SNI of a TLS stream, you can write a custom rule that says 'drop this IP from going to facebook.com''
Because this is a, hopefully, one-off request than it will work but this isn't scalable and not recommended for wide scale use.

@James92
And what doesn't work exactly?