Look in the BIOS - check all CPU power saving modes are disabled.  How you do that depends on your BIOS but the manual should help you.

That's normal for the ALIX boards (and WRAP too, I believe)

Just watch the 2.0 board here on any given day and you'll see how the quality can vary from day to day as bits are actively worked upon. It will be quite a while before all of the bugs and kinks are worked out.

There isn't a good place to do it, but you could always write a single script and then make sure it gets called before the shutdown command in all cases: /etc/rc.halt, /etc/rc.reboot, and /etc/rc.shutdown

I don't remember it every being asked here. What version of pfSense are you using?  Is pfSense your external (WAN connected) device, or do you have a modem or router between it and your ISP? What, as GruensFroeschli says, does the log show?

The reason that works is that NAT reflection is only supported for port forwards, which is why you need the port forwards to access them locally in the first place.  I'm working on something that would also work for 1:1 NAT rules (I've already got it figured out and just need to finish coding it), but I don't know whether it will be included in 2.0 (or any other version).  I may make it available as a package for 2.0 at least, and may even backport it as a package for 1.2.3.  If someone (or multiple people) wants to sponsor it, I might be more likely to consider backporting it to 1.2.3.

That is because nfs support is not built into pfSense.  It constitutes a significant security risk for a service which shouldn't be running on a firewall.

@jdwilliams: @Topell: Why do you need to bounce the box every night? Just to try and keep things running smooth… Its for a user whos 300 miles away and they have some slowness issues after squid has been runing for a few days and the webcon give a 500 error at random. Do you normally work with Windows?

Oh, different problem.  If you want to be able to access OWA from the inside using the external DNS name, you're going to have to make an A record on your internal DNS server pointing to the internal IP address.  (And if you're going to do that, making a zone for the public domain name on your internal DNS server, you'll have to replicate all the other public records or your users won't be able to get to, for example, 'www.companyname.com'. Or just create an internal A record like 'mail' and get a multi-name cert that will work with both the internal and external domain names.

can you name a some torrent clients which allow you to manually enter WAN ip..?? because there are too many available and i have ti try each one indiviually..

Hi again, Just thought I would post that a solution to this issue has been discovered.  It turns out that the default ciphers used in v1.2.3+ versions do not support the 3des-cbc cipher, which is what my SSH client uses. Manually editing /etc/sshd to add this cipher to the list solves my issue : Change the line : $sshconf = "Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc\n"; … to this : $sshconf = "Ciphers 3des-cbc,aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc\n"; I'll post this to the bug tracker as well. Thanks, -- Phob

You might try to get in touch with Thayner and see how the install is going… http://forum.pfsense.org/index.php/topic,23365.0.html

Well I've solved my problem. I tried another NIC and it worked! Somehow the onboard NIC didn't support PPPoE. Although all other functions work like it should. This post can be closed.

This was noticed and fixed shortly after the 1.2.3 release, but since 1.2.x likely won't see any more releases, you can apply the fix manually: https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/0535db81e8f813cea016f1c0c8562b1b0b0d7ea7

johnjces: Some access points have a feature you can enable to do that and pfSense also has a simple checkbox to do it when it acts as the access point (with a wireless network card supporting access point mode in FreeBSD).  Any further discussion of this should probably go in a different thread.