@stephenw10 thanks yea I worked out my problem. Because I has a rule at the bottom of floating that blocked anything I didn't specifically allow out, I then was allowing WAN to HTTP/HTTPS for Squid and it was quick matching. I had to rejig that block all rule to avoid HTTP/HTTPS so that it allows that traffic by default (No quick rule allow needed for WAN) and then I catch any bad traffic with the explicit deny rules. Seems to work now.

@stephenw10 Yes, ZFS after reinstalled 2.5.2. Bug seems to be known and would be fixed someday... as you said, its just cosmetic :-)

Yeah gmail is a bit special - can you get it to work without 2fa? Maybe?? Don't know, don't care - have had 2fa on since like 2014, and I was late to the party ;) But just tested this with one of play domains, no 2fa - just your typical smtp server over 587 works just fine.. So clearly pfsense is parsing special characters in the password. And his issue is most likely do to the special requirements of gmail.

If there's nothing in the logs then I'd run a packet capture to see if those ping are making it to pfSense at all and if it's responding. No response to 5 pings it something significant though. An IP conflict maybe? Something ARPing with the same address could do that. Steve

It seems that I fixed the issue: Static IP should be : 10.66.66.2/24， but not： 10.66.66.2/32

@jgq85 said in Occasional ping timeout when pinging local network and weird issue.: Could ping failing be at all related to a DHCP/DNS server configuration? To dns - possible if your trying to ping via fqdn and dns failed and you would not be able to resolve what fqdn your trying to ping. But from what you posted that seems unlikely with all of the ips failing with the same amount of losses. Seems more like you had something that the machine that was pinging had a intermittent connection problem. or you switch blipped? Something on your network caused everything your pinger was pinging to not respond. So either its connection or the really the whole network was problematic. If it was dhcp related - its possible a client lost its lease, and had no ip, etc. But all the ips at the same time? It could of been your pinger machine? But once a lease has been gotten, its good for the time of the lease, etc. And only when it runs out would it have to renew.. Very unlikely to be related to dns or dhcp to be honest. Did all the 5 failures for every device happen at the same time.. They all have 5 ping losses. For being local these ping times are fairly high, 34ms - locally? That has to be wifi, and bad wifi at that.. How do you have 7ms average to google and 17,18, 34 to local IPs?? Here is ping times to my wireless harmony hub.. Which is on a different vlan that my pc ping it is on.. So its routed through pfsense, and still average of 1ms.. Ping statistics for 192.168.7.96: Packets: Sent = 26, Received = 26, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 6ms, Average = 1ms Control-C Really anything locally should be like 1 or 2 ms.. Sure wireless could give you some higher than that... But average of 34 ms to something locally - there is some off there..With min being 33?? Local wired should be sub 1ms to be honest.. What your using for ping might not support showing that? There are some tools that can report sub 1ms hrping, fping for example.. Here is what typical wired pings should be locally - you can see most are sub 1ms From 192.168.9.253: bytes=60 seq=0019 TTL=64 ID=0a7c time=0.410ms From 192.168.9.253: bytes=60 seq=001a TTL=64 ID=00a9 time=0.550ms From 192.168.9.253: bytes=60 seq=001b TTL=64 ID=9aa3 time=0.517ms From 192.168.9.253: bytes=60 seq=001c TTL=64 ID=3783 time=0.518ms From 192.168.9.253: bytes=60 seq=001d TTL=64 ID=c3d4 time=0.460ms From 192.168.9.253: bytes=60 seq=001e TTL=64 ID=9a27 time=0.530ms From 192.168.9.253: bytes=60 seq=001f TTL=64 ID=02b0 time=0.883ms [Aborting...] Packets: sent=31, rcvd=31, error=0, lost=0 (0.0% loss) in 15.010389 sec RTTs in ms: min/avg/max/dev: 0.342 / 0.667 / 4.004 / 0.659 Bandwidth in kbytes/sec: sent=0.123, rcvd=0.123 Seems really really odd that all your local are so high, but to 8.8.8.8 ts average of 7?

@fredordetre Wow. That is incredible. It's also proof that sometimes the root cause is out of our control and you just need to get someone to actually listen to what you are trying to tell them. Glad it got figured out.

@stephenw10 Not remembering how I had OpenDNS set up. I am only running pfBlockerNG. I have both IP and DNS-BL set up. Also no RAM Disks set up. Was in a hurry to get back online for my job. So after a few hours I gave up trying to figure it out and just fell back. Probably just chalk it up as an unknown. You have answered my questions. Maybe another time I will try OpenDNS. But afterwards I will reboot to make sure it holds.

It can't access a certificate revocation list so it can't check if the server certs have been revoked. That's not a problem for the connection though. I doubt Nord publish a CRL, though I've never looked into it. Steve

@stephenw10 Some home routers provided by ISPs have a 'DMZ' option that can be used to connect a downstream pfSense firewall WAN interface. You can continue to use the home router's LAN for the connections in the home that you don't want protected by pfSense. E.g. guests that just want to use your home router's WiFi without you monitoring their traffic. Your real LAN, sits behind pfSense and is only connected to the pfSense LAN interface. It is not directly connected to the home router. The pfSense WAN interface is connected to the home router by Ethernet cable and the home router's DHCP should be configured to serve a static/reserved IP address to the pfSense WAN interface so it has the same 192.168.1.x IP address every time. When the reserved IP address has been configured as a DMZ in your home router, all incoming traffic to the home router will be presented to the DMZ IP address. I have seen this implemented differently on different devices. Some will bridge the DMZ port so that pfSense will show an external IP on the WAN interface. Some will just NAT the traffic so pfSense sees the 192.168.1.x address on the WAN interface.

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