Yeah, I would try that if you can. You might also try booting FreeBSD 12.2 (or 13) and see if it does the same. Or a 2.6 snapshot.

@tomz said in Problems with Netflix and Amazon. NOT using a VPN.: I agree. They gave me a new IP in a completely different pool, and now everything is working again! Last time, it worked until the next day. I'm not going to touch anything on the router over the weekend, and see if it stays up. Thank you for all your help. It really helped bolster my argument, and pointed me in the right direction to to negotiate with my ISP. I'll post back with what happens. Glad you got it sorted out. I would watch your firewall's WAN IP and see if it changes. If it does, and Netflix breaks again, you know the cause. Your ISP might want to investigate the original IP netblock you were assigned. Perhaps it is on a VPN list by mistake, and if they use it with some of their other customers, they might have the same issue.

This will probably do it: https://forum.netgate.com/topic/155698/how-can-i-get-this-udp-relay-package-for-casting-across-vlans Or you could try PIMD bur the UDP broadcast relay is more likely IMO. Requires some work to setup though as it's not a pfSense package. Steve

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.