You'll need to eliminate the HW at either end before you can look at the ISP infrastructure. Do you spot any patterns like excessive number of states in the state table, whats the ram usage like, is the swap being used and anything else thats seems unusual when you experience the slow down. Might even be worth checking the workload on each core to see if there is a problem with the FreeBSD OS scheduler, as its quite easy to make various programs run on a particular core which then slows that core up as it gets overloaded leading to slowdown of the rest of the cores on cpu. If you cant find anything wrong with your hw, then looking at the internet infrastructure seems like the only option left, and yes ISP's can do bandwidth throttle-ling quite easily even if you have an unlimited data package at either end, its also why the market forces didnt win out in the rigged game as theres little technical difference between adsl and sdsl modems, other than upload speed. I believe its harder to bruteforce crack large amounts of ssl data compared to short bursts, but with the fact the ISP/Govt will have a complete oversight of the entire communication from TLS handshake to goodbye, getting your certs should make it easier to bruteforce crack the transmission to then see what you were transmitting which is why having so much functionality on your firewall increases the risk. One way to eliminate the FW hardware being at fault is to shift the openvpn functionality onto separate machines at either end and then just use pfsense to do the routing and fw. Theres also nothing stopping you using pfsense again to manage openvpn on your seperate vpn boxes. Where you create and manage the certs for your vpn is up to you, personally I am of the view to isolate various functionality onto individual machines as a zero day could give complete access to a machine and with so many eggs in one basket, makes it easy picking for hackers. When looking for HW changes, also keep an eye on other devices in your network, just this morning I caught my TalkTalk isp supplied set top tv box exploring the network looking for other network service facilities as it couldnt get online, despite all its network settings being correct. Its interesting to watch how devices react when different aspects of net functionality become no longer available. I'd like to suggest its harmless but as most of it is encrypted or uses an algorithm which makes it hard to decipher the meaning of the plaintext context, one cant help but be increasingly suspicious especially as its quickest to hack from a rogue device inside your network.

Fixed. The server was faulty. Installed a different server and works.

Or to Reset the webConfigurator password ;)

OK, I have found the problem. There was many updaterrd script running. I disabled RRD graphs, clean graphs, kill old rrd related process. Everything is normal now.

Sorry, one more question. Can we set the time interval for CARP? I mean pfsense send the CARP  message to another pfsense. Please advise.

I have went back to the old machine that was working like it should, but apperantly the same thing happen to it as well. The only thing I did was remove tftp package. I bring it back afterwards but that did not change a thing. So I found post that brings a clue  - http://serverfault.com/questions/506592/pfense-needs-to-be-rebooted-to-effect-a-change-in-existing-nat So what I did was I run - /etc/rc.filter_configure_sync And then I check the system logs and I found the updates performed : Oct 22 13:11:42 php: rc.filter_configure_sync: Adding TFTP nat rules Oct 22 13:11:42 php: rc.filter_configure_sync: Adding TFTP nat rules So regardless of how much I run this, it always do that. I do have now problem with the TFTP, I have add another TFTP server and change the address to that TFTP server and the configuration its not working until I reboot the system. I have factory reset a machine with pfsense and try to change something on the DHCP , map an IP and no result till reboot. How I can fix this problem ?

@cmb: Leave everything there at their defaults. Make sure you've bumped nmbclusters (though that'd result in a diff error log generally). https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards The second crash was everything at default.  The third crash was with the nmbclusters bumped to the recommended number for the Intel card.  I've tried turning off all hardware offloading for now and will see how it goes.  Been up for 1.5 days but it had done that before.  I'll report back. Off topic:  I've noticed that the chip runs hotter with PowerD turned on with "hiadaptive" than off (at least the first core).  Seems, from reading around, that PowerD allows 'turbo' speed to kick in whereas it will not kick in if PowerD is turned off (or another system setting is added).  I've turned PowerD off for now (default) for testing until the lockups quit.  Just found that interesting.

Hey Chris, I spent months using no-ip (free) with the Dynamic DNS service in pfSense… only to get these messages in the system logs: php-fpm[32255]: /rc.dyndns.update: phpDynDNS (xxxxx.noip.me): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry. I found myself each month getting a notification from no-ip saying… "You need to confirm that you are actually using this service or your service will be disabled" (even though it's free).  So what was happening based on the log above... is that the DynamicDNS feature in pfSense wasn't informing no-ip that even though the IP didn't change... that it was actually using the darn service.  What I was doing each month was clicking an email link, going to the no-ip page and "Confirm by pressing this button". Your point is well taken to try using the Custom DNS feature of the Dynamic DNS service in pfSense... I just didn't think about it and came cross a way that I understood when I came across some free time.  I guess I just missed the elegant way and worked out a different solution that works too.  Like they say... there's more than 1 way to skin a cat. I'll still take a look at the Custom DNS feature in pfSense.  Linode is not at all like no-ip in terms of crying that the API doesn't get hit for 25 days... so it'll probably work out just fine. Maybe it would be helpful to have a feature in the Dynamic DNS service to explicitly control the update frequency to the Dynamic DNS provider, just to keep their system on notice considering the above case that I had?  I know how it is with feature requests and software... and I don't expect this feature to ever exist.  Just my 0.02. Thanks for your thought. Best, -Will

Hi Again, If you can send your cron table then i can help you about it. Regards, SGTR

A few general pointers for WiFi that will help you out … As some of the other people that have responded in this thread have mentioned some of these points, I've collected them here: Signal strength at BOTH ends is important.  How well you see the AP is only half the puzzle.  If the AP doesn't see the client equally as well, then its not going to work well.  Remember that an AP doesn't have the physical limitations of an antenna that'd you'd find on a tablet, meaning the AP's antenna probably works better than the tablet's. Signal attenuation is a killer: walls, crappy antennas, etc.  If you have any way of measuring the signal, you want at least -70dBm (yes it will still work, but poorly at -80dBm) from the AP at the client and vice-versa.  Also don't run your APs without antennas.  The radios inside are impedance matched to the antennas, disconnecting them generally makes it not work beyond a few feet. Interference is a killer: Make sure you are on your own channel, in 5Ghz, that's possible, but avoid DFS channels (52-144) since by law the AP must switch off and find a new channel if it detects radar.  As an additional point, if you run custom firmware in your AP, it may be tempting to select certain non-standard channels, just be prepared for a visit from law enforcement agents, big fines and equipment seizure especially if you're near an airport! Most people have no clue about 2.4GHz: Stick to channels 1, 6 and 11 (or whatever is standard in your country).  Otherwise you're just creating unintelligible noise for your neighbors, which is far worse than interference on the same channel, which can at least be understood and respected by all parties. Please for the love of God don't run 802.11n 40MHz in 2.4GHz, you're just being a pig since there's only 1 usable non-overlapping 40MHz wide channel in 2.4GHz. More power != better performance; in fact in many cases more power = worse performance.  Think of how you'd want to install speakers in a whole home audio system.  One super powerful speaker in a central location, or many smaller speakers scattered throughout for a pleasing uniform sound level everywhere.  You can also use the same analogy for lighting.  Same thing applies to WiFi, RF waves are like light waves, only they penetrate somewhat the obstacles. Don't forget WiFi is a half-duplex medium:  The radio can only send or receive, it can't do both at the same time AND each and every wireless packet has to be acknowledge or retries occur.  Consequently, your expected performance will be about half the connection rate, if that. Consider using iperf to validate your throughput.  Run iperf in both directions to ensure you're getting what you're expecting. In the end, unless you have the budget for Enterprise grade wireless, you have to work within with the above realities. –A.

Thanks KOM!

Hi, Thank you for your informaiton :)

There isn't really a list like that to view. You can see the connections on Diagnostics > States, and they are listed by interface, but there is no "why" – the "why" is up to the policy routing rules on the internal interface (e.g. LAN) and that part isn't retained in a visible way.

Thank you that is much more helpful and a lot less cryptic !