It would seem the answer to my question is "/etc/rc.gateway_alarm" is run.

Nothing in there for DHCP leases from what I see. More about restarting VPN sessions and flushing states.

Mmm indeed, I would expect that to be they or it depending on whether 'peer' refers to the user or the device. More likely it's a device in that reference.

Good to hear.

Reverti o servidor para outra versão e atualizei, não funcionou a parte de Data Encryption Algorithms, ela não voltou.

Decidi parar de procurar solução, já que não obtive ajuda aqui e na internet, e resolvi colocar o wirguard no local. Mas estou ainda com algumas questões. Funcionou, estou acessando o fileserver do outro lado, mas alguns serviços como Impressora que usa SMB para fazer scaner, não envia via túnel.

You can download it here now:

https://raw.githubusercontent.com/ianb/alexa-sites/refs/heads/master/top-1m.csv

The problem is solved; it was indeed the network cable that had a loose connection.
It's in the trash!
Thank you all for your help.

@viragomann I lost oversight. The customer edited stuff on his own ... and wrote he succeeded by adding fw rules and policy-based-routing. Sounds like overkill a bit, but ok if he's happy.
I have to accept that this box is out of my control somehow now ;-)

thanks for your help. I might report back if I get access again and see things.

Yesterday we built a new pfSense 2.7.2 cluster, master firewall was running for over a week without problems, but about half an hour after setting up CARP and pfSync to the new slave it died with known hvevent problem. It then died several times, again and again.. Not sure but maybe it has something to do with either CARP/ConfigSync/pfSync or multicast traffic (because we know dying pfsense setups without carp configured, so might be multicast traffic in the network which triggers something).

We have had the same experience with our only OPNsense setup, of which the master is running smoothly since we removed the slave firewall.

@phthatcher said in SG-1100 as VPN client only (no dhcp) adding to existing network:

just assure that when the server reaches out to the web it is behind the vpn

So all you need is to configure pfSense as default gateway on the server.

The pfSense only needs a single interface (LAN, router-on-a-stick), connected to your LAN.
On the VPN interface you have to add an outbound NAT rule, as mentioned in the ExpressVPN tutorial.

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

https://github.com/pfsense/FreeBSD-ports/pull/1420

Merged I could not test it but it is in there with the make file now and the distinfo file

@stephenw10

Let me know if you can test that out

Dont use this I am having issues with the MASTER SITES and patches folder it wont make clean install all the way

@cybrnook

It looks if you are referring to the pimd engine version

854cb5be-fd74-43b0-848a-b83df5637c1b-image.png

Which is quite old, and as far as I know not working under FreeBSD. I have compiled the never released pimd-3.0.b1 version (using FreeBSD15 current).

@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

Yes, those are the correct versions in 25.07-RC. The newer pkgs are currently only in head, what will be 25.11. They may be pulled back into 25.07 at some point if necessary though.

@Gertjan oh I missed that - my bad.

@stephenw10 Correct. Way longer than the tunnel rekey times, so something must prompt a configuration reload outside of that.
Or maybe the tunnel went down at some point and the config was reloaded when a reconnect was attempted.

@PiAxel said in update from 25.07 beta to 25.07 RC:

The last version doesn't work for me!

??

How do you know that the latest version doesn't work for you, before installing that latest version ?

( 😊 )