There isn't anything built in to do that. You could open a feature request: https://redmine.pfsense.org/ But I would suggest tuning the gateway parameters to not log that latency level if it's expected during normal operation. Steve

Found it - truncate -s 0 does the trick. FYI for anyone interested - here is what you can do to dump, save, clear the current and old logs: tail -100 /var/log/filter.log | cp /var/log/filter.log /var/log/oldfilterlogs/filter_date +"%Y%m%d_%H%M".log | truncate -s 0 /var/log/filter.log | find /var/log/oldfilterlogs/ -type f -mtime +30d -delete

Ah nice! Something probably changed in the route. Fireware update, router swapped etc. You could probably find where it was failing with enough tracetroute and pinging but finding someone to admit it's a problem and fix it is a different matter! Steve

Update: I have fixed the problem now, turns out I chose a bad speedtest server I am now getting 800-900mbps down by choosing a good speedtest server.

What version of pfSense software are they running? That option is a recent addition in pfSense CE 2.5.x or pfSense Plus 21.02.x and later.

@gertjan said in Stay at 2.4.5-p1 or go to 2.5.2?: ou should share the logs, all details of the setup, so some one can test them out one by one, or some one recognizes details of your problem, and he will share the already known answers. You might even find a unknown bug. I've currently out of standby devices, because I have to install them on new locations... and new ones have a hugh backlog... i will test with a spare device as soon as possible...

Known issue, fixed in 2.6: https://redmine.pfsense.org/issues/12107 Just check the 'Disable SMTP Notifications' box and it will save. Steve

@stephenw10 Some great options there, thanks

@gertjan And the Status > Monitoring : Quality / WAN_DHCP chart. Thanks for this tip. Works nicely. +1 The recent spike in packet loss and delay clearly shows a WAN outage.

Just add firewall rule with logging enabled for that IP. Put it above any other rules so traffic to that always hit it. Steve

Sounds like an ARP issue? Or an IP conflict maybe? Anything logged? How does it fail? is pfSense still sending traffic but without responses? Steve

I have 2 cisco sg300's, 28 and 10 ports.. Yeah such features are a bit above your entry level smart switch.. But more full featured switches can be had for reasonable prices.. The 28 port is pretty much my core switch in what is my office/computer room ;) while the 10 port sits in my av cabinet in the living room.

@gertjan Thank you VERY much for your assistance.

Could also be an IPv6 issue. It looks like the Nest Hub will use only v6 if it thinks it's available. If pfSense is handing out v6 addresses but doesn't actually have upstream v6 connectivity it would look like this. A pcap should show it doing that though. Steve

Nice. That's some weird behaviour. Steve

Ok, yes that appears to be issue. The error you're seeing is unhelpful though and I'm not sure why it doesn't just show offer as unavailable. We raised that with Azure. Since you already have supported instances deployed please open a ticket with use to discuss the available options: https://go.netgate.com/ If you can reference this thread in the ticket it will save time initially. Steve

Have not had any issues with RDP on much slower connections.

@stephenw10 I think this is mostly ironed out after a restart. My connectivity was oddly intermittent prior to that. When I plug in laptop via ethernet directly to my vlan AP it still says I'm on my lan network, but assigns correct IP and I can connect to my pi. Thanks again for your help!

So I had a very similar scenario last week - PFsense would nicely close the PPPoE connection (3 or 4 times over a couple of days) and then take ages to reconnect. My ISP (Aquiss) got OpenReach out to check the Fibre and everything seemed to check out fine, though they reported they could see rather more drops than just the 3 or 4 I could see - 18 or so - no further issues since though. So I think the connection was dropping, but only a few times it was long enough for PFsense to give up and shut up shop? However, the other end of PPPoE link (run by OpenReach?) would stay up longer and we had to wait until it timed out before Pfsense would reconnect? I've since added the Gateways widget to my Dashboard and replaced the monitor IPs with something further down the line - as ISP provided gateway didn't respond to ping - [image: 1627999309109-056ae178-4059-4e09-a5e1-eba95bb921fd-image.png] Can't seem to get the IPv6 address to respond (though IPv6 is running fine). Noting that I assume I've got a reused IPv4 address as my firewall is repeating blocking an attempt to connect on port 500 (IPSEC VPN?) from some other address! Bottom line - my problem has disappeared for the moment, - so either fixed by re-seating of cables during OpenReach Test or some other hidden change - but if it's some random issue...

That just looks like the same crash. It happens at 'configuring firewall'. Do you have any odd rules that might apply to the pfsync intercace? Floating rules for example? Does the 'infinite dashes' appear differently to this? Steve