@hansolo77 Checking what pfSense does every hours sharp - or some other regular moment, is a good start. But don't stop there ! Check also : all devices connected to your pfSense LANs ! as these can all do something at that very moment. ISP love to sell you numbers. Like 'a 1 Gbit/sec connection just for you'. If the country where you live has some enforced consumer rights movements, these ISPs add now at the bottom of the contract "... or whatever we have avaible for you". After all, ISP tend to hookup up entire roads, cities, etc to one main equipment with, guess what, a limited, up front determined throughput. For example : you all share the same 100 Gbits very expensive router/switch. If more then 100 clients are hookup up to this expense router, then ... you get it : what happens when every all these clients, all their devices, do 'something' at xx sharp ? So you have to check all of them (which you probably can't do) - or disconnect them all while you are testing. You can even go one level higher, and check all the POP of your ISP .... Inspecting the cron list is one thing. You still have to use the console or better, the SSH access, and use menu option 8, and type 'top'. Make sure the list is sorted at 'CPU usage'. Use also this command : ps aux and look for the process that mention minicron, these are also timed processes. On my pfSense : [25.07-RC][root@pfSense.bhf.tld]/root: ps aux | grep 'minicron' root 89370 0.0 0.1 13980 2484 - Is 18Jul25 0:00.00 /usr/local/bin/minicron 240 /var/run/ping_hosts.pid /usr/local/bin/ping_hosts.sh root 89826 0.0 0.1 13980 2480 - Is 18Jul25 0:00.00 /usr/local/bin/minicron 300 /var/run/ipsec_keepalive.pid /usr/local/bin/ipsec_keepalive.php root 90216 0.0 0.1 13980 2500 - I 18Jul25 0:00.17 minicron: helper /usr/local/bin/ipsec_keepalive.php (minicron) root 90313 0.0 0.1 13980 2476 - Is 18Jul25 0:00.00 /usr/local/bin/minicron 3600 /var/run/expire_accounts.pid /usr/local/sbin/fcgicli -f /etc/rc.expireaccounts root 90699 0.0 0.1 13980 2500 - I 18Jul25 0:00.01 minicron: helper /usr/local/sbin/fcgicli -f /etc/rc.expireaccounts (minicron) root 90868 0.0 0.1 13980 2504 - I 18Jul25 0:00.20 minicron: helper /usr/local/bin/ping_hosts.sh (minicron) root 91166 0.0 0.1 13980 2480 - Is 18Jul25 0:00.00 /usr/local/bin/minicron 86400 /var/run/update_alias_url_data.pid /usr/local/sbin/fcgicli -f /etc/rc.update_alias_url_data root 91830 0.0 0.1 13980 2504 - I 18Jul25 0:00.00 minicron: helper /usr/local/sbin/fcgicli -f /etc/rc.update_alias_url_data (minicron) root 84792 0.0 0.1 14076 2688 0 S+ 08:49 0:00.00 grep minicron The "/etc/rc.expireaccounts" is an hourly process, and afaik it doesn't communicate, and takes a split second to execute. Normally, with a vanilla pfSense (no addons, no pfSense packages) there is no 'download every hours xx Mbytes' process. pfSense will update some small files ones a month, will check up with the Netgate update servers to see if there are pfSense or package updates avaible, but this will not create big loads of traffic, and last probably for a second or two.

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.

Yes, it's in the RC.

Do you have the NDI from the device? If you send that to me in chat I can check for an ACB key.

@stephenw10 Alright might have been dropped after i initially logged in and then appeared when i went to the update tab. thanks again really appreciate your reply and time as always.

@jhg said in Installing 2.8 behind archaic PPPoE/VLAN from CenturyLink: Is this available yet? It's in testing now. No issues so far so should be available soon,

What gets logged when you run that in 2.8?

@wc2l said in Teams Issues: teams.microsoft.com works just fine. Host "msg.teams.microsoft.com" could not be resolved. Same for me. edit : while waiting, read also C:\Program Files (x86)\Microsoft Teams Network Assessment Tool\Usage.docx - this is a Microsoft tool with a manual / notice .... ( )

@luckman212 Click on the image : [image: 1753189717239-1c8c8a2b-ed5f-4dd1-8694-8be0e58350e8-image.png] I didn't test other search engines ... edit : the link @kpa posted is, imho, the best answer ( and totally not-FreeBSD related ^^ ).

Yes that's correct. The 1100 has only one NIC (mvneta0) and an internal switch with VLANs to separate the ports. But, as I said, you shouldn't need to make any changes there it's detected and set automatically for any Netgate device.

@Gertjan shame on me! Didn't see that ... thanks a lot!

Because 10.60.0.252 is the server end of the VPN tunnel at pfSense. The local DNS resolver (Unbound) listens and responds on that IP and that is where the override is set. Where as 8.8.8.8 is Google's DNS service that knows nothing about any local overrides you might have set. When clients use that DNS server is bypasses any local DNS overrides.

@SteveITS Thank you for the clarification. You're right — better to be safe. I’ll update FW2 when I'm on site, and then FW1, which is my usual one.

Mmm that^. However what you will see is that after booting back into the 24.11 BE the update branch will still be set to 25.07-RC because that was the last thing that was done before the upgrade took the snapshot. So if you plan to run 24.11 for some time after reverting you would need to set the update branch back to 24.11 in that BE before doing any package operations.

@70tas Indeed the global token does not work anymore, you must use the API token. And then for the login, do not use your email address. As I wrote before: "One must use the Zone ID when using the API token." I have this working using the DDNS GUI. I only needed the script for debugging.

It's not a bug because that's the expected behaviour. You could consider it a missing feature if you need to make changes there. Open a feature request: https://redmine.pfsense.org/ This is the first time I've seen anyone ask about it in 10 years though so it's clearly not a huge problem. You could just patch the file to create the config with the values you need then carry that as a custom patch in the patches package.

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

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

@patient0 OK, that helped. I'm fairly certain I had tried clicking Add time before and it hadn't worked - with the error I previously reported. In any case, it worked for me now. Thank you!

@stephenw10 I believe that is mpt attempting to talk to the RAID card as if it was in IT mode, trying to count the individual drives ("REPORT LUNS"), and the card replying "No, this is RAID, you can't talk to the drives directly" ("ILLEGAL REQUEST"). I'll run a fs check next time it's convenient to take down the entire network. Probably this evening.