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

@dennypage said in Is it possible to prevent installed packages (e.g. ntopng) from accessing the Internet?:

@wolffire said in Is it possible to prevent installed packages (e.g. ntopng) from accessing the Internet?:

I really like ntopng, but I'd rather it not be able to access the internet whenever it wants.

Is it possible to block package processes from doing so?

You can't block individual packages. The closest you could get is to find the domain or addresses the package is accessing and block those.

With specific regard to ntopng, I haven't examined all the callouts but I don't recall it doing much unless you were using the licensed version (activation check), or had one of ntopng's "active" modes enabled.

Make sure you have Active Network Discovery disabled in ntopng. It's in Settings / Preferences / Network Discovery / Active Network Discovery. This option should never be enabled on pfSense. Ditto for Active Monitoring.

Thanks for the quick answer.

I'm a little surprised about not being able to lockdown individual processes for those 'who watches the watcher?' types of situations. Finding a dynamic workaround will be painful.

As far as ntopng, I just don't want it to be able do anything online unless I've configured it to do so; I loath the idea of telemetry being sent off to various companies.
Not that I've found anything (I haven't taken a serious look yet); I'm just a bit weary.

Speaking of the settings, after reading that post about inadvertently scanning the Internet, I definitely ensured active monitoring and network discovery was turned off. 😆

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

@Euroguy said in Router advertisement not sending default gateway:

So, followup after a reinstallation of the system

Short answer is, things now seem to work.

Glad to see you got it up and running :)

I get both DHCP4 and 6 clients with leases now (although status of lease seems broken, always showing black down arrow even though lease is active and remote machine is up and active

I see that from time to time too. I think there are some timers that you can tweak (can't recall which ones though) that determines how long it takes without a "sign of life" before the client is marked as offline. For IPv4 there's an ARP timer ... and for v6 it should be an equivalent NDP timer. Can be set in System / Advanced / Tunables once you find out what they are called :)

DHCP6 server fails as DHCP requests / Discovery is done on fe80::/10 and that is not considered to be LAN it seems. I had to add a LAN allow rule for fe80::10 to ff02::/16 like this for DHCP6 to work:
e98b2093-2534-4c7e-9c09-6d54251d537d-image.png

That rule shouldn't be needed, it is part of the automatic rule set added by pfSense. I get those by means of pfSense magic: (check in /tmp/rules.debug)

pass in quick on $WAN proto udp from fe80::/10 port = 546 to fe80::/10 port = 546 ridentifier 1000000463 label "allow dhcpv6 client in WAN" pass quick on $LAN inet6 proto udp from fe80::/10 to fe80::/10 port = 546 ridentifier 1000002551 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 546 ridentifier 1000002552 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 547 ridentifier 1000002553 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from ff02::/16 to fe80::/10 port = 547 ridentifier 1000002554 label "allow access to DHCPv6 server" <snip>

Update:
the timer tweak I used a long time ago was

net.link.ether.inet.max_age=60

which make the cached ARP-entry lifetime 60 seconds, I wanted clients to go offline faster. Default is 1200s. See https://man.freebsd.org/cgi/man.cgi?query=arp&sektion=4

24319ba3-b5d5-4add-b251-9993249ff5a6-image.png

@stephenw10 i have same issue

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

For 25.07 RC, this worked for me (run sh first)

[25.07-RC][root@r1.lan]/root: sh # export IGNORE_OSVERSION=yes # pkg add https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/tailscale-1.84.2.pkg # service tailscaled restart # tailscale up # tailscale version 1.84.2 go version: go1.24.4 # tailscaled -version 1.84.2 go version: go1.24.4

@cdal

This could be a great security improvement ... It's the only way to do MFA with "LDAP/AD" backend for exemple (using oauth 2 proxy for exemple)

@rocket

Updated July 20-2025

pfsense 24.11 - Telegraf freebsd-15

pkg add -f https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/telegraf-1.35.1.pkg

pfsense 2.7.2 - Telegraf freebsd-14

pkg add -f https://pkg.freebsd.org/FreeBSD:14:amd64/latest/All/telegraf-1.35.1_1.pkg

https://www.freshports.org/net-mgmt/telegraf/#history