@Ramosel said in KEA dhcp not controlling acess as used in previous versions.:

Is this the appropriate venue for this bug report or should this be input elsewhere??

Bug reports should be made to the pfSense Redmine site here: https://redmine.pfsense.org/projects/pfsense. That is the official site where the developers track bugs. Posting on the forum generally will not specifically bring a bug to the attention of the developers.

@JP-IIIT

Go one level up in the forum and check how many are posting about 'unbound hangs' or 'fails' or needs to be 'restarted' ?
Give this a thought : how many 2.7.2 are there out there ? Hundreds of thousands. Does unbound 'fail' for them ? Noop. Why would it for you ?
True, unbound does restart a couple of times per week (?) see these (my) graphs, it shows she memory used. Every time it drops to zero : it was restarted.
It wasn't crashing, it was ordered to restart by 'pfBlockerng', as I use pfBlockerng. Totally normal, as pfBlockerng can reload / update DNSBL, and if the news ones contain new host names, then unbound has to restart so they will be taken i account.
Most of my unbound restarts are actually not pfBlockerng, it's because I change the settings, also know as : messing around with pfSense, trying out new thinks.

About "Service Watchdog" : don't use it. You don't need it. Its a developer package, and can do more harm as help.
Example : Your unbound gets restarted. That's ok, it takes a couple of seconds, no one will notice it ^^
But what happens a fraction of a second later : "Service Watchdog" detects that unbound isn't running.... so it does what it was told to do : it starts unbound .... which was already in the start phase ... now you have two instances running .... and you've just managed to make things 'in-stable' with race conditions, and only lighting up candlers and other scarifies wills ave you know.
( and you'll know now it's the admin creating the issues .... (as always) ^^ )

unbound dying on you 'without notice' niether reason ? Noop. People didn't look, for the reason, that's all.

So, tell us how you use unbound, you you've set it up, and we'll help you locating the issue.

Btw : default 'Netgate' pfSense DNS settings are perfect, you should try it 😊

@jhg OpenVPN has options for DNS have you looked at hard setting them?

@jhg not like everyone doesn't know what the comcast dns servers are - they have been the same IPs for years and years. 75.75.75.75 and 75.75.76.76, ipv6 2001:558:feed::1 and ::2

So don't let dhcp override - and manually set them to hand out to your openvpn in the vpn settings.

@Gertjan I did take your suggestion of switching back to "ALL" outgoing interfaces, and things still work.

So I'm going to chalk this up to the DNS resolver getting itself into a funky state over IPv6, which was corrected by restarting the resolver.

If this happens again I'll crank up logging to see if anything interesting shows up in the logs.

For now the issue is closed.

@arad85 Needed to make sure outgoing n/w interfaces were set to All...

@vf1954 unless your running 25.03 beta and want to report stuff in that section. I see little point in pointing out what might be wrong with 24.11 version of kea. Now if your using what is about to come out, and you see problems - they still might be able to be fixed before release.

Ok. For those who need to fix that error before update comes out, here is an instruction for a solution:

If you are on web interface: Open "Diagnostics" > "Edit File" Open file in /usr/local/pkg/acme/dnsapi/dns_porkbun.sh path Search for line which starts with PORKBUN_Api= (probably row 7) and change its value from "https://porkbun.com/api/json/v3" to "https://api.porkbun.com/api/json/v3" Save the file Rerun acme renewal process If you have access to CLI Open Shell Open vi editor for /usr/local/pkg/acme/dnsapi/dns_porkbun.sh file Search for line which starts with PORKBUN_Api= (probably row 7) Press i to (INSERT) and change value from "https://porkbun.com/api/json/v3" to "https://api.porkbun.com/api/json/v3" Hit Esc and save file with :wq! Go back to Web interface and rerun acme renewal procedure

@Felix-4 said in DDNS does not work:

However, in this case it is necessary to update at least once a month to preserve your DNS name. Therefore, in the setup I have set it to "force update" every 20 days, and due to the certificate problem it fails.

The pfSense 'dyndns' software will do a forced update after some (20 ?) days.
You saw the cache file, it contains the latest successfully updated IPv4 and something else : a time stamp value.
So pfSense knows when the last successful update happened, as it knows when to update based on the elapsed time.

If you can edit the update URL that contains the https://dyndns.dk/....., change it for http://dyndns.dk/ and your issue is gone.
True, now the traffic goes over http so its not encrypted anymore, but, imho, that's not a big deal.

@michmoor said in iCloud Private Relay:

@DefenderLLC

You're trying to get me again.......lol
let me think about this.
The biggest hurdle is converting these firewall rules. Thats a weekend task. Bad enough i have to do firewall migrations for my job but do it at home as well?

I like to use pfSense and UniFi together. In fact, that’s the way I ran it for over two years. They introduced zone based firewall rules now, so things are much more granular than they ever used to be. I guarantee you it wouldn’t take you more than a day.

@johnpoz wow, great, thanks for the quick help! works already, wonderful.

Well, not sure when i switched of to changing my DHCP server backend from ISC to Kea but that resolved it

For who may be wondering why their DHCP is not assigning leases
Step 1: Status > services > check if your dhcpd services are running or not
Step 2: In case they were not (like for me) Advanced > Networking > Set Server backend to ISC

Strange thing is despite using numerous 1-2month old backups, this sitting appears to not changed. I guess its something that isn't backed up?

Anyways, was a fun headscratcher

Hello together.
Seems almost 2 years later still an issue.
I tried out the fix with the route, only change is, that I can now ping the remote-side from the diagnostic menu.
DHCP Relay still not working.
On the remote side the is no switch, it a virtualized network without any further setting possible.
The issue might also be:
You can have only one setting for DHCP-Relay.
So if you have VLANs on the remote-side that need to communicate with the same DHCP-Server on the central side, the packets won't come from the respective VLAN-interface, and will be routed into the wrong scope of the DHCP.
What also is weird, the local DHCP in the PFSense also isn't working, or so to speak only serving the LAN-Interface, not the VLAN-interfaces althoug activated on every interface.

Wow, thanks guys! This helped me get my DHCP leases page working again. I also had reverse lookups redirected to the domain controller DNS via 'Domain Overrides' on the DNS resolver page. Somehow that did time out. I remove the overrides, and now everything works smoothly. Now I just have to figure out how to repair the overrides, or whether I need the reverse lookups for Active Directory at all. Because they obviously didn't work for a while now, and I didn't see any issues so far...

@Gorf Grab it from tcpdump or wireshark. It's truncated in the log. Should look something like this:

a3ae9da6-984e-4f95-a702-54724bd12951-image.png

@beerguzzle or just a switch capable of vlans.. Any smart switch would work.

You can then have uplink to your lan, and uplink to your opt port and they would be isolated networks on your vlan capable switch.

but sure 2 dumb switches works too.

@digitalgimpus said in Random DNS Resolver failure with Quad9 over SSL:

I'm running 1.18.0.

Yes, it is helpful in the future for posters having issues with DNS or DHCP to post the pfSense branch they are using (CE or Plus and which version). The underlying binary components of the DNS Resolver and the DHCP server are quite different between the current 2.7.2 CE branch and the latest 24.11 Plus branches, for example. A number of unbound bugs were fixed upstream in the newer version released with pfSense Plus 24.11 as compared to the much older version bundled back with pfSense 2.7.2 CE.

Ditto for kea, the new DHCP server that came out first with 2.7.2 CE. The kea binary and its connections to the DNS Resolver are quite different from (and much more feature-rich) than the original kea still bundled with pfSense CE.

When a poster does not state their pfSense version (and thus, by extension, the version of unbound or kea) they are running, it is easy for responders to make false assumptions. For instance, "it's working fine for me" might be true if you are using the latest unbound on pfSense Plus 24.11, but something may well be broken on the older unbound that is bundled with pfSense CE 2.7.2. This is a natural consequence of the growing divergence between features and versions of packages included in pfSense 2.7.2 CE and those of pfSense Plus 24.11 (and soon, 25.03).

@johnpoz Thank youuuu!!! Forgot all about this!

@sifti85 you can do whatever you want - don't make it right, running multiple layer 3 Ip ranges on the same layer 2 is just nonsense.