I saw where the Netgate kernel developer updated the Suricata package in the pfSense 25.07 development branch to work with the new kernel PPPoE driver. But so far as I know that updated package has not been migrated to 2.8 CE.

Here is the commit into the DEVEL branch: https://github.com/pfsense/FreeBSD-ports/commit/68a06b3a33c690042b61fb4ccfe96f3138e83b72.

The repo seems to be back online today Jul 19th, I was able to complete the fresh install.

Yup the issue definitely exists. I have no fix for it yet, none of the things I tried made any difference.

@MacUsers

https://help.zerossl.com/hc/en-us/articles/360060119933-Certificate-Revocation

edit: oh you prob out of luck

You can revoke any certificate issued via the ZeroSSL portal. Currently, certificates issued via ACME can not be revoked from inside the portal - please follow the instructions of your ACME client for revoking those certificates.

the gui in pfsense does not have the ability to revoke - you prob have to move the certs to something you have certbot installed to and revoke that way.

@The-Party-of-Hell-No excellent. I’m glad some experimentation proved successful.

@pst said in 25.07.r.20250709.2036: still issues with limiters:

I have yet to test limiters in combination with floating firewall rule for buffer boat mitigation, which was an issue in earlier betas.

Still an issue in the RC. UL/DL limiters on LAN work as long as I haven't configured UL/DL limiters for WAN. Once there are WAN limiters no limits on LAN are adhered to (which I think is a regression from the beta where at least one direction worked as configured). Time to shelve those ideas of using limiters I guess.

@gemg83 I see what you're saying - it could be the jump from 12.3 to 14 on the BSD side.

It really hampers the use of limiters in multi-WAN setups so it feels like an important bug (I call it a bug as it doesn't behave at all how the UI or documentation suggests, it's more like using them on a floating rule).

@JonathanLee said in DNSSEC Resolver Test site:

https://wander.science/projects/dns/dnssec-resolver-test/

The patato checker.

Uncheck :
77b420f9-5499-4301-8050-7c1f6a6560d3-image.png

and do the test again.

So that page, and this one : http://www.dnssec-or-not.com/ test if you've checked the resolver's DNSSEC capability, or not ^^

That web site is part of my collection of web sites that test several DNS(SEC) related things.
I 'admin' several web servers ( = domain names), I also use site use this one https://dnsviz.net/d/test-domaine.fr/dnssec/ to check out a domain name DNSSEC capabilities, as I need to be sure it works = me not messing up things when deploying it.
test-domaine.fr is a domain I rent and use to test things before I apply them on the domains that can't afford down time when I mess up (again).
Remember : if you set up DNSSEC wrong on your web server, mail server ( actually DNS domain name server ), your domain name will 'vanish' from the Internet.
DNSSEC was considered rocket science not so long ago and maybe it still is, as using it really implies that you know what DNS is.

The good thing about pfSense : when you install it, and don't change (add, remove) any pfSense DNS settings, it will use DNSSEC out of the box without the user (admin) even being aware of anything.
DNSSEC = that's why resolving (yourself, locally) is such a good thing.
Forwarding means : you have to trust some one else.

Last time I checked, half of Europe's web site are using DNSSEC, and the US was ... not really using it.
That changed a lot the last several years : DNSSEC is now somewhat mandatory for all government hosted sites world wide.

@jamesdun

@jamesdun said in DNS problem:

if the new machine wasn't picking up the correct DNS server

Well, launch

ipconfig /all

and it tells you what DNS server it uses.
Normally, a new Windows PC will use DHCP is so it's 'plug and play'.

@jamesdun said in DNS problem:

Both machines show the correct DNS server when NSLookup is launched, although the old one also gives it a name and the new one fails to do the reverse lookup

Looks like the new machine isn't allowed to do DNS requests against pfSense ?

@jamesdun said in DNS problem:

and the new one fails to do the reverse lookup

Humm. The new one's DNS request gets refused ...

@bimmerdriver You need one IP that can move between the routers. Technically both WANs can be private IPs…Comcast business allows for this even if their modem is bridged, then the shared IP is a public. Maybe that helps.

@Gertjan
Hello,
Thank you.
I had exactly the same issue, and your solution helped me fix it.

Ask ChatGPT

@pfsvrb
this was an issue on my system also..
Target & Interval were default set to 0..
change to 5 & 100 fixed it

Do you see anything blocked in the firewall logs?

Connectivity from that host is otherwise good?

Is it using the same DNS server(s) when configured statically?

Ultimately I would run a packet capture when you run the failing task and see what's actually failing there.

@Lars_ said in How to update No-IP IPv6 (dynupdate.no-ip.com does not have an AAAA record):

@SteveITS Determined testing pays off. It works now 🎉

Same for
dynupdate.no-ip.com/nic/update?hostname=thisismydomain.ddns.net&myip=%IP%
with option "HTTP API DNS Options = Force IPv4 DNS Resolution" enabled.

I was actually quite close. The solution is to update the AAAA record using IPv4:

Service Type: Custom (v6)

HTTP API DNS Options = Force IPv4 DNS Resolution

Update URL:
dynupdate.no-ip.com/nic/update?hostname=thisismydomain.ddns.net&myipv6=%IP%

Note: It has to be &myipv6=, not &myip=

Is this something that makes sense to be implemented in No-IP (v6) and No-IP (free-v6)? It would not work if IPv4 DNS resolution isn't available, but I guess that is not very common in the wild.

Haven't found a way to tag this thread as SOLVED.

This solution worked for me!