I think I may have figured this out, even though I never managed to collect a proper crash dump.  After reading through the responses to my posts I checked in the bios and found that on the HP T5740 / T5745 thin client there is no way to disable hyperthreading (HT) in the bios.  I did a bit of research and found a sysctl toggle for hyperthreading. By adding: machdep.hyperthreading_allowed=0 to /boot/loader.local.conf I was able to disable hyperthreading. This seems to have quelled the random crashes on my N280 Atom cpu when running i386 nanobsd in conjunction with ipsec. Big thanks to all those who chimed in, and especially robi, who put me on to exploring hyperthreading.  I hope that this info helps someone else as well.  If I run into any more problems I will update this thread. UPDATE After some further reading about IPSec crashes on i386, I came across a thread here indicating that a different sysctl toggle may alleviate the problem in a more finely targeted manner than shutting off hyperthreading. I have now remove the HT tweak discussed above, and I'm testing to see if setting: net.inet.ipsec.directdispatch=0 fixes the issue. Here is the thread and relevant post: https://forum.pfsense.org/index.php?topic=88606.msg501050#msg501050 Cheers, Bennett

https://forum.pfsense.org/index.php?topic=90830.msg502489#msg502489

Hey @all, I had the same probleme. Solution: In PuTTy-Option "Serial" set "Flow Control" to "None" instead of the standard option "XON/XOFF" Hope someone could use this :-)

That removed the notice not to change anything from the GUI.  Hopefully I didn't just turn off the Check Engine light without filling up the oil first. Two services aren't running. One wasn't running before the update but as I never use it, I didn't care (Darkstat Bandwidth Monitor, which always seems to stop working anyway).  The second is Secure Shell Daemon which I've not noticed before.  If I start the service it stops immediately.  As I'm not connected via SSH at the moment perhaps it's not needed currently?

I was having the same difficulty on a RCC-VE 2440. I solved it by booting my box with a memstick in liveCD mode, dropping to a shell and running: tunefs -t enable /dev/ada0s1a reboot YMMV

None. I specifically tried some regular Kingston CF cards which had DMA errors on that motherboard. I moved to Apacer Industrials, and problems gone. Note also, that it also happened the other was around with some other motherboards too, pfSense would not boot from Apacer Industrial CF cards, but works just fine with regular Kingston and other chinese no-name brand CF cards. Also noticed that when used with passive CF-IDE adapters with Windows, Apacer Industrials are detected a fixed disks (like regular PATA hard disks), while Kingstons and friends were detected as removable disks. Perhaps that's the difference between them, in the CF card's firmware.

There are at least thee different things, and different types of logs, that you may be talking about.  Can't tell without more info. Bandwidthd data files (*.cdf) are stored in /usr/pbi/bandwidthd-amd64/local/bandwidthd. (Adjust if needed for i386).  To move those, I first would install bandwidthd on the new server, then copy the old *cdf files as well as the old etc/bandwidthd.conf to the new system.  Files in htdocs should be created as needed. System log files are binary in a 'circular log'  format, and live in /var/log.  In a console you can generate plain text by using the clog utility, ie "clog /var/log/system.log |less".  No sense, IMHO, in copying these to a new system. The rrd data files are used to create the rrd graphs you may be referring to, and these live in /var/log/db.  I'm pretty sure there are ways to back up the rrd data, and I think they are moved automatically when upgrading a system, but I'm not sure of the correct way to move old data to a new install with a potentially different configuration.  They are binary, so if you are going i386 to amd64, they are not compatible.  There are ways around that, but require some manual intervention, essentially a dump & restore.  Maybe somebody can chime in with proper way to move rrd data.

See comment #34 The ‘free’ AMIs are gone. We dropped the price on the remaining AMIs. By paying for the AMI, you help support the project.

@hec: Last time i tried carp with vmware we had a lot of packetloss and a the vips did not work. You have a config issue at the ESX level somewhere in that case. Those possibilities are all outlined here: https://doc.pfsense.org/index.php/CARP_Configuration_Troubleshooting#Hypervisor_users_.28Especially_VMware_ESX.2FESXi.29

If all you want is a proxy style VPN then pfSense just needs one NIC, the WAN, and a VPN set up to tunnel all client traffic and NAT it out of the WAN interface. However I would recommend having a LAN interface so you can manage pfSense without allowing WAN traffic to reach the web GUI.

https://doc.pfsense.org/index.php/Upgrade_Guide#Disk_Driver_Changes

how did it work?

it seems when the tunnel is started that time the rule works fine but after a while when in idle state or the states refresh, the tunnel still remains up but the rule doesnt seem to match the traffic and send out of the tunnel gateway. can any1 please help or point me to any bug that was introduced in 2.2.1 or probably fixed relating to this. i tried creating the aliases and rules from scratch but the issue still persists

pfSense will do vlans just fine. In fact it will do everything DD-WRT does and then some.

Easy fix for that: https://doc.pfsense.org/index.php/Boot_Troubleshooting#pfSense_2.2_and_later I assume you're running a cf card in older hardware. Steve

Hi, I upgraded to 2.2 from the Web UI after a successful installation of 2.1.5 and it works. I've got pfSense running on my net6501 and I'm really impressed so far with this project. However, out of curiosity I tried the latest 2.2.1 release to see if this problem is still present–and it is. A USB installation using the memstick serial image does not work on the popular net6501 boards. Details at the beginning of this thread. I think this deserves a bug report. I'll prepare one soon unless someone advises me otherwise. -- GH

Good to know.