@fabnavigator If I let one sit on system activity for 30-45s or so I see: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 199 ki31 0B 32K CPU0 0 39.0H 79.30% [idle{idle: cpu0}] 11 root 199 ki31 0B 32K RUN 1 38.6H 78.52% [idle{idle: cpu1}] 29905 root 59 0 154M 59M accept 1 0:40 6.25% php-fpm: pool nginx (php-fpm) 28542 root 11 0 124M 54M piperd 1 0:32 3.12% php-fpm: pool nginx (php-fpm) 1427 root 59 0 158M 61M accept 1 0:40 1.71% php-fpm: pool nginx (php-fpm){php-fpm} 12 root -55 - 0B 336K WAIT 1 58:09 1.46% [intr{gic0,s42: mvneta0}] 12 root -55 - 0B 336K WAIT 1 31:36 1.42% [intr{gic0,s45: mvneta1}] 12 root -54 - 0B 336K WAIT 1 39:56 0.63% [intr{swi1: netisr 1}] 672 root 59 0 158M 62M accept 0 0:45 0.59% php-fpm: pool nginx (php-fpm) nginx is the web server. Yours seems busier for some reason. Another where I run top -aSH at the command line doesn't have the web activity of course, as I'm not even logged in to the web GUI: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 199 ki31 0B 32K RUN 0 376.2H 96.44% [idle{idle: cpu0}] 11 root 199 ki31 0B 32K CPU1 1 381.1H 95.49% [idle{idle: cpu1}] 12 root -54 - 0B 336K WAIT 1 64:56 3.46% [intr{swi1: netisr 1}] 2 root -54 - 0B 32K WAIT 0 341:50 1.38% [clock{clock (0)}] 12 root -55 - 0B 336K WAIT 0 108:14 1.13% [intr{gic0,s42: mvneta0}] 19591 root 0 0 14M 4608K CPU0 0 0:00 0.46% top -aSH 12 root -54 - 0B 336K WAIT 0 44:45 0.39% [intr{swi1: netisr 0}] 7 root -15 - 0B 16K pftm 0 37:46 0.37% [pf purge] 12 root -55 - 0B 336K WAIT 1 49:24 0.27% [intr{gic0,s45: mvneta1}] I pulled up a rule to save it on the latter...~10s to log in, 2-3s to open the LAN rules page, 3-4s or so to apply. Just via counting. I missed that it was a max in the subject line, that should eliminate any eMMC storage speed issues.

@stephenw10 I don't use Captive Portal. [image: 1771274557698-f4211b57-fe67-46fc-82d4-c35f3ee55a41-image.png] However, I did dig in here and find something on Limiters. I don't recall ever setting this up. (I had to lookup information on how to access info on limiters just to find this.) [image: 1771274769940-aa5ac8f0-981f-421e-b5ca-f0da903e91fa-image.png] The only bit of interest seems to be this. Again, I don't recall ever doing this. However, I've had this setup for a few years now. [image: 1771275020565-b89e243c-58d4-4950-b938-6ffa6057152b-image.png]

@johnpoz said in Teamspeak Login generates Surricata alert: Base64 HTTP Password detected unencrypted on: @ghar36k if that is the case that seems insane in this day and age to be honest. I would do a packet capture, start the capture before you click your login and get the warning. Prob want to set the packet limit to 0 vs the default 1000. Do you see the alert, then look into the packet capture - download and using something like wireshark make it easier to read the pcap for sure. Do you see anything in the clear, or is all just https traffic. If something is encode with just base 64, it would be very easy to decode. There are many places on the net to paste in base64 and view it decoded. If you know where the data is being sent, you mention the IP seems legit.. Does it change when you do this test multiple times? If not be much easier to limit your packet capture to just that IP so it won't contain other traffic. I would also check on their forums, or send them a support request asking about it and the warning your seeing in your ips. I don't use teamspeak, or I would be very happy to look into it as well - quite possible other pfsense users do use it, maybe they will chime in? I tried again after running an errand and I think I caught it. It's showing a connection to Host: update.teamspeak.com\r\n User-Agent: teamspeak.downloader/1.0\r\n Then there's a section for: Authorization: Credentials: teamspeak5: With a string of letters and numbers after the teamspeak5: that I'm not going to post here. It doesn't seem like it's my login info unless it's encoded in some way. The info in the " Authorization:" section is just the Base64 of the Credentials so I think this is what's triggering Surricata.

@TAC57 said in ARP Table Showing Stale Hostname for Interface MAC (Cannot Clear via GUI): The hostname “jen-desktop” belonged to an old system that previously used that MAC when the NIC was installed in a different machine. That's exactly what happened.

@bschapendonk said in NANOG 96 You Don't Need The DNS Root Server System: maybe privay to a degree) Privacy? What privacy? So your upstream doesn't know you asked for the ns of .com domain? When in the next few miliseconds you gonna ask a .com ns for the ns of say.. pornhub As for load, caching is almost always there with a very high hit rate, so not much to gain here too. Redundancy? Really? If root ns go down globally, local copy will be the least of your problems. And if everybody downloads the root ns file very often, the load to root servers could be even higher. On the other hand, maintaining yet another file isn't a good idea. Things will not go wrong, and then the file is corrupted , just because, and there you go.

If you are policy routing traffic to that gateway it relies on the gateway status for things like failover. If you have two WG tunnels for example you might want to use tunnel1 unless it goes down then use tunnel2. With it marked as always online pfSense will send that traffic to it even if the traffic is 100% lost in the route. So not really a security issue. More functionality.

Hi Yannick @ynk93 did you manage to get it work? I am going to perform similar situation with 2 public IPs one for phase 1 and one for phase 2.

@stephenw10 said in Considering upgrade to Plus, only offering me 25.07.1: If you send me your NDI in chat I can check that for you. Sent via PM Andy

While following the https://docs.netgate.com/tnsr/en/latest/recipes/gui/index.html guide. still getting the error "protocol invalid-value error HTTP cert verification failed: unable to verify the first certificate[21]" Not quite sure why getting the error. I did everything in the guide. Wish the gui was simpler to access rather than this over complicated way to do certs, then install, etc.

@stephenw10 said in What exactly does the Boot Environment Verification process check and what causes it to fail?: Aha, yup that will do it. I've hit that myself with scripts that need to keep running. Yes you need to background the script in the shellcmd like for example: /usr/bin/nohup /root/7100_fan.sh > /dev/null & I had that running in older versions just calling the script directly without an issue but at some point required those mods. Anyway good catch. Yeah, I don't remember why but I thought & didn't work for some reason so I used daemon in front of the script. Ex. daemon /path/to/script.sh is what I had in the shellcmd config. If I executed that at command line via SSH, it would properly background the script. Not sure why it doesn't work on the shellcmd. Maybe something to do with PHP executing it.

You were blocking that with some manually added list? If it's a dynamic list t may have pulled something new in that blocked it.

@Kraeuter ja, die habe ich mit meinem Kabelanschluß genutzt, selbe Qualität wie Fritzbox. die Verbindung hatte alle paar Minuten aussetzer. Erst mit dem TC4400 lief der Anschluß stabil. Gruß ré

Yup changes to address that went in in 25.07: https://redmine.pfsense.org/issues/16210

Hola, Aca lo tengo disponible https://github.com/grs89/centralizegg

@stephenw10 Thank you! It is now working normally again.

This last issue is not related to the main issue, it was some lately configured monitoring IP for WAN2 gateway...

@stephenw10, thanks! That fixed it. [25.11.1-RELEASE][admin@pfSense.home.arpa]/root: pkg-static upgrade pfSense-upgrade Updating pfSense-core repository catalogue... pfSense-core repository is up to date. Updating pfSense repository catalogue... pfSense repository is up to date. All repositories are up to date. The following 2 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: pfSense-repoc: 20251120.034629 -> 20260205.051513 [pfSense] pfSense-upgrade: 1.3.16 -> 1.3.17 [pfSense] Number of packages to be upgraded: 2

Yup a clean install rewrites the ESP with a new dtb file. That's still weird though! During the install you can pull the existing config and include it which removes the need to restore afterwards. https://docs.netgate.com/pfsense/en/latest/install/install-walkthrough.html#configuration-restore