@newkansan: I did determine that rebooting the ISP modem will temporarily fix this problem. You can restart the apinger service instead of rebooting. The issue is not addressed in 2.2.1. Current bug status shows as targeted for 2.2.2.

Hi Charliem, thanks for the reply. I believe i have the same issue as the owner of the other thread. I will add my comments into that thread so we can both come to a solution. Cheers

@doktornotor: @mikepogi: I just unplug the main switch without shutting it down the pfsense :-[ [/quote] You might want to rethink your strategy…  :o https://redmine.pfsense.org/issues/4523 Yanking the power plug does not cause a kernel panic. That's specific to kernel panics only, not unclean shut downs. With nanobsd versions, you definitely want to cleanly shut down/reboot so it saves your RRD data, etc. With full installs, it doesn't really matter. I very rarely do a normal shut down of any dev or test system and can't recall ever breaking anything from doing so. That said, I would never just yank the plug out of any important production system running any OS if it's avoidable. There is always a possibility, though extremely remote, that Windows, Linux, BSD, etc. will end up with some kind of not easily repairable issues if you happened to pull the plug at exactly the wrong time. Certain use cases are much more likely than others to suffer such problems (like Windows servers with Exchange or SQL, *nix systems with busy MySQL, Postgres, similar servers).

When there are rules that use a schedule, pfSense will add a cron job: 0,15,30,45  *  *  *  *  root  /etc/rc.filter_configure_sync That job is set to run ever 15 minutes. It will effectively cause the ruleset to be parsed for rules that are in/out based on schedules and do its stuff. So you need that cron job to run every 5 minutes also. It's somewhere in the code - I will let you find it as a learning exercise :) And remember, after every upgrade you will need to re-check what mods need to be made and then re-apply your changes.

@johnpoz: Where are you when you go to either http or https www.myurl.com - are you inside pfsense or outside on the public internet? IF you don't see any http getting to the box how are you getting redirected to https://www.myurl.com:9909?  Where are you doing the redirect, pfsense can not do such a redirect that I am aware of. Externally and thats the problem we aren't doing that redirect anywhere. I thought this was the culprit WebGUI redirect Disable webConfigurator redirect rule When this is unchecked, access to the webConfigurator is always permitted even on port 80, regardless of the listening port configured. Check this box to disable this automatically added redirect rule. I understood that option was doing the redirect. I have this box ticked and it makes no difference

@Harvy66: I just leave mine at Adaptive and my 3.2ghz CPU is pretty much always at 300mhz any time I check it. I'm using Adaptive too, it works pretty stable. But I usually switch into minimum at midnight to save little more power. However, if I could do that in cron job that would be perfect. In Adaptive mode : Intel(R) Pentium(R) D CPU 2.66GHz Current: 1329 MHz, Max: 2659 MHz 2 CPUs: 1 package(s) x 2 core(s)

It's apparently the default for us and not explicitly set

@hege: @eskild: ipsec is unable to read the private key. with ipsec listcerts you should see a line like   pubkey:    RSA 4096 bits**, has private key** If that's not the case, try the following commands ipsec rereadall ipsec restart (restart not reload!) What's the output of ipsec listcerts ? I had the same issue with pfSense 2.2 after creating a CA and a certificate (annoyingly, StrongSwan apparently does not and will not support wildcard certs).  IPSec log when I connect: charon: 05[IKE] no private key found for 'C=US, ST=Illinois, L=Naperville, O=ITS Inc, E=support@example.com, CN=router1.example.net' ipsec listcerts output: List of X.509 End Entity Certificates: subject:  "C=US, ST=Illinois, L=Naperville, O=ITS Inc, E=support@example.com, CN=router1.example.net"   issuer:  "C=US, ST=Illinois, L=Naperville, O=ITS Inc, E=support@example.com, CN=router1-ca"   serial:    02   validity:  not before Mar 17 23:10:33 2015, ok             not after  Mar 14 23:10:33 2025, ok   pubkey:    RSA 2048 bits   keyid:    xxxx   subjkey:  xxxx   xxxx $ ipsec restart Stopping strongSwan IPsec… Starting strongSwan 5.2.1 IPsec [starter]… no netkey IPsec stack detected no KLIPS IPsec stack detected no known IPsec stack detected, ignoring! After those commands, I get "pubkey:    RSA 2048 bits, has private key".  Unfortunately despite that, I still get error 13801 from Windows when using the common name or IP address.

I literally haven't had a single watchdog timeout on an interface that wasn't set to WAN. Both interfaces I tested are on the same card, but that doesn't explain why they stop misbehaving IFF they aren't WAN. I'll try another mobo when I get the chance, but it's odd that only the WAN interface complains. I'll try setting the 10/100 NIC as WAN too, 100Mbit is better than nothing!

2.2.1 has fixed this issue. WOL works again for me.

I'm posting an update to my struggle with this issue with the hopes that someone might be able to help. Since my original post I have installed new hardware with a fresh (non-upgraded) install of 2.2 and with all my settings rebuilt from scratch. The problem remained. So I admitted defeat and reverted back to 2.1.5. This fixed the problem and made it very clear that something in 2.2 was the cause. I may just need to report this as a bug, but I'm going to bounce it off the community one more time just in case there's something I'm overlooking.

As dok has mentioned if your using the windows cmd line ftp, it has NEVER supported passive.  So you must of been using active, pfsense before 2.2 had a ftp proxy/helper that would of helped with that. Now there is none, use the new package if you need active connections to work. In a passive connection the server sends you the port to connect to and the client connection.  Unless your filtering outbound traffic from the client there would be no issues in using passive from a client behind pfsense to a server on the public internet or on then wan side of pfsense. https://doc.pfsense.org/index.php/FTP_without_a_Proxy Active mode FTP through NAT will not function as that relies on a proxy or similar mechanism. Use Passive mode instead. Another option is the recently added FTP Client Proxy package which leverages ftp-proxy(8) in FreeBSD to allow clients on local interfaces to reach remote FTP servers with active FTP.

The OpenVPN log will show more specifically what's happening, what does it show?

Well - If you have settings that SHOULD chew up 70% of your disk but instead all of your disk space is being used, then you have a problem.