@talon4x4: @sos: Similar thing happened to me - kept dropping the internet at 0230 every night. Turned out to be a monitored security alarm which "grabbed" the copper phone line every morning at that time so it could check the line. check to see someone or something isn't messing with your phone line, as the logs you have seem to indicated something similar. I have a cable modem (Ubee DDW3611), so no phone lines and no security system. @tim.mcmanus: What model router do you have from your ISP? This link is invaluable for cable internet users. http://homepage.ntlworld.com/robin.d.h.walker/docsdiag/ Time Warner locks the modem down so I can't do anything mentioned on that website.  Thanks though Did you try any of it?  Most modems will respond to an SNMP query, and that's what this is doing.

Thankyou for that! It fixed the problem instantly. It was the TX offloading from the virtIO interface.

@divsys: A little ugly, but you could look at the config.xml backup file and add the appropriate WOL entries (enter a few through the GUI to understand the format). Then just restore the modified backup to get the entries loaded. Yep, that's what I ended up doing. And it works, but, like you said, it is pretty messy.

Have you enabled UPnP?

An interface is an interface, computers dont care whether you call them wan lan or optx, they just follow the configs & rules, so if you wanted to learn something, maybe setup a captive portal on a separate interface (optx), log and censor the traffic and see what you can find & learn from your visitors if you fancy it.  :)

I have a fairly similar issue. The Graph will work fine for a while then on any disruption that will fire off the apinger alarm it will drop to what appears to be the stddev rather than the average RTT. Attached are related graphs and the following set of pings are taken from the pfSense box directly against the listed DHCP IPv4 gateway. PING <redacted>(<redacted>): 56 data bytes 64 bytes from <redacted>: icmp_seq=0 ttl=64 time=9.573 ms 64 bytes from <redacted>: icmp_seq=1 ttl=64 time=7.227 ms 64 bytes from <redacted>: icmp_seq=2 ttl=64 time=7.479 ms 64 bytes from <redacted>: icmp_seq=3 ttl=64 time=8.459 ms 64 bytes from <redacted>: icmp_seq=4 ttl=64 time=7.100 ms 64 bytes from <redacted>: icmp_seq=5 ttl=64 time=7.493 ms 64 bytes from <redacted>: icmp_seq=6 ttl=64 time=7.792 ms 64 bytes from <redacted>: icmp_seq=7 ttl=64 time=7.877 ms 64 bytes from <redacted>: icmp_seq=8 ttl=64 time=9.792 ms 64 bytes from <redacted>: icmp_seq=9 ttl=64 time=9.007 ms --- <redacted>ping statistics --- 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 7.100/8.180/9.792/0.926 ms</redacted></redacted></redacted></redacted></redacted></redacted></redacted></redacted></redacted></redacted></redacted></redacted></redacted> Apinger log for an entry during the time it is "broken" Sep 3 17:10:23 apinger: #87242 from WAN_DHCP(<redacted>) delay: 7.140ms/7.425ms/4.248ms received = 3076 Sep 3 17:10:23 apinger: (avg. loss: 0.0%) Sep 3 17:10:23 apinger: (avg: 0.790ms)</redacted> Upon restarting the apinger service: Sep 3 17:15:17 apinger: #34 from WAN_DHCP(<redacted>) delay: 7.831ms/7.664ms/77.859ms received = 33 Sep 3 17:15:17 apinger: Polling, timeout: 0.985s Sep 3 17:15:17 apinger: (avg. loss: 0.0%) Sep 3 17:15:17 apinger: (avg: 7.676ms)</redacted> Any thoughts or ideas? Edit: Rummaging through the Redmine I see the issue has been reported: https://redmine.pfsense.org/issues/4081. It appears it is being corrected in Version 2.3. :) [image: gateways_low_rtt.png] [image: gateways_low_rtt.png_thumb] [image: quality_graph.png] [image: quality_graph.png_thumb]

@virgiliomi: With the mention of IE, I'm assuming you're on a Windows version of some sort… you might want to make sure that Windows isn't "zooming in" some applications to increase their size. Windows is often set to do this (usually zooming an additional 25% by default) if the screen resolution is very high (and 1920x1080 usually triggers this). Changing the graphics adapter being used may have led this setting to be re-enabled. If you have Windows 7 or 8, you can check this setting by going to... Control Panel > Appearance and Personalization > Display (if you prefer not to use the "Categories" view, go to Control Panel > Display). If that's set to 125%, set it to 100%, log out, and see if that makes things better. Since IE is a Microsoft application, it's likely aware of the setting and adjusts its display natively, while Chrome and Firefox will end up being "zoomed" by Windows, making things look fuzzy. Thanks for the suggesion. I checked, it was set to 100%.  What I was really puzzled is that only the texts on the drop down menu were blurry/fuzzy.  All other texts were all fine including the texts on the main menu bar and those on the webGUI web pages.

To my knowledge there is nothing you can do. normally it would still work if the mtu is set to automatic in the adapter settings (standard) unless the ISP is blocking ICMP traffic which is needed to automatically adjust the MTU value. (often done to prevent ddos attacks) So you'd have to ask your ISP for a solution.

pfBlockerNG has a proxy blocklist (based on MaxMind data).

Im having the same exact problem, did you finally got it working?

Ah, OK did not realize the difference, was just trying to save a few bucks. Thanks!

dmidecode atleast shows the sn of the board…thanks jimp..will try the rest

Are you using the Custom List box for these IPs? or are you saving the IPs to a file in the pfSense box and adding it to the URL / local file entry? The "state" is only for the URL / Local file entry. The Custom list needs to be empty or it will create a Firewall rule automatically. I'm using a URL (not local) and the file is not empty.  So there's no way to "disable" without deleting the entry?

@chpalmer: So-  your trying to limit access to the firewall pictured from one host with a dynamic address? Yes. This source name is my dyndns host. I need limit access to the only one dyndns host name. THX

…or if the users happened to all be taking a bath...

Beyond LADVD, no… (Doesn't support LLTD if that's what you mean.)

Why not just enable the SNMP service and then use your favourite network monitoring tool?