Yeah I'd guess it's random errors in the link occasionally corrupting a UDP packet. It depends what rate you're actually seeing but I probably wouldn't be worried if it's not continuous.

@stephenw10 ok I got to solve the problem changing my source of the route table URD from 0.0.0.0/0 to my subnet from my spoke subscription 10.20.0.0 from that is working the test vm with internet. now I will test performance to connect a cluster ks8 from each spoke. thanks for the support . [image: 1750197747112-9cae0646-7797-4c9f-bf54-d0af9349fbdb-image.png]

@phloggu said in pfSense 2.8: WebGUI unusable (due to cat and tail many logfiles in the background): The widget shows 10 lines, I had 99 logfiles at a size of 80MB each, non-compressed, The log files are 'PHP' parsed ... PHP is a 'one-core' process, great for building web pages, extremely bad when it has to deal with 'huge' text files. It will takes 'ages' - and / or usage all PHP memory (512 Mbytes max). If you really want to store/keep/use big log files : use a remote syslogger. Then you can go wild wild huge files with your firewall being impacted because you clicked 'one something' or just logged in.

@stephenw10 doh Thanks again mate - try this asap.

@stephenw10 I will give it a try, and give a feedback after.

It seems this was partially fixed with 2.8.0 in that current speed does change and reports some real-looking values. The max frequency is still wrong though.

But anyway you can see if tailscale is running in Status > Services.

@JimS FYI, Possibly related, I am mentioning this in case someone has the issue. After a modem replacement I had to power cycle pfsense 2.6.2 after a power failure. I am now on 2.7.2 but have not had a power outage since so don't know if it's fixed. Could be modem timing mentioned above. In my case I could not access anything on pfsense. I posted this March 2025: The recent S33 modem failure and change to S34 caused pfsense 2.6 not to come back up after a power failure (3 this month so far!)I hope pfsense 2.7.2 can recover from a power failure like 2.6 did with the old modem. 2.6 always recovered until the modem change, strange but true. Trying to login to pfsense 2.6 returned the dreaded "502 Bad Gateway Nginx error". Had to power off/on. Waiting to see what happens to 2.7.2. I'm thinking possible ethernet driver issue with a different chip in the S34 than the S33, which may be fixed in 2.7.2

Ah, good result!

Also verify the server is actually resolving against pfSense and doesn't have some hard coded DNS built in.

Yup that also works: [2.8.0-RELEASE][admin@m370.stevew.lan]/root: pppcfg pppoe0 dev: lagg0 state: session sid: 0x12 PADI retries: 0 PADR retries: 0 time: 00:00:21 sppp: phase network authproto auto authname "Test" peerproto auto [2.8.0-RELEASE][admin@m370.stevew.lan]/root: /usr/local/sbin/pfSctl -c 'interface reload opt2' OK [2.8.0-RELEASE][admin@m370.stevew.lan]/root: pppcfg pppoe0 dev: lagg0 state: session sid: 0x7 PADI retries: 0 PADR retries: 0 time: 00:00:01 sppp: phase network authproto auto authname "Test" peerproto auto

We use lots of different 10G SFP+ at work. They do certainly vary, but rarely have over heating issues as long as they are in a high end switch/router such as Juniper, Cisco, etc. We did have quite bad over-heating issues in a TP-Link SX3008 switch. The problem was the SFP cages, so we modified the switch adding cheap self-adhesive heatsinks. Attached pictures show the main board before & after. Approx 20degC SFP temperature reduction. [image: 1750066993481-2022-08-12-13.59.18-tp-link.jpg] [image: 1750066993527-2022-08-13-17.32.41-tp-link.jpg]

@bigbig You shouldn't need to 'cron' dhclient. See for yourself : Get the driver name of the dhclient interface used (not WAN but the NIC driver name), for example 'igc0'. You'll find a file called /var/db/dhclient.leases.igc0 - have a look at it. dhclient knows when to renew, normally half way the lease duration. So if the total lease time is 300 seconds, dhclient will renew after 150 seconds. Totally insane of course, but maybe normal knowing what transport medium is used The dhclient process stays active during the wait, check : ps aux | grep 'dhclient' and it 'sleeps' until the delay is over, and it renews. Normally, dhclient doesn't fail or abort, something that can only happen, I guess, when the interface itself is 'gone'. Check the Status >System Logs > DHCP for 'dhclient' messages (issues).

@stephenw10 not sure. Anyway, just wanted to report it in case it is something that needs to be fixed for the later releases.

@stephenw10 Yeah, no NTP servers are that good. Even the 10 gigabit ones with reflectors..

Up

Hi @patient0 , Yes. You're right. I uninstaled Squid and perform "mv /usr/lib/libc++.so.1 /root" Then install Squid again and now all is fine. Thanks, Mucip:)

@frodo Thank you Netgate! Working now :-)

Hi @Gertjan, thanks for your input. To answer your questions: • Approx. 150 leases, of which 78 are static mappings (classic MAC → IP). • DHCP lease time is default at 7200, not shortened. • Based on log parsing, I see about 3–5 DHCPACKs per hour, so roughly 80–100 per day. • One active DHCP server on the LAN. • About 20 WiFi clients, managed via a UniFi Controller, connected to pfSense. • Typical clients: mostly Linux systems (servers, VMs, containers), some macOS devices, smartphones etc. No captive portal or guest networks. Let me know if I can provide any more detail.