The Nano variant uses md(4) rather than tmpfs as a ram drive. You could use that. [2.2-RC][root@xtm5.localdomain]/root: mount -p /dev/ufs/pfsense0 / ufs ro,sync,noatime 1 1 devfs /dev devfs rw 0 0 /dev/ufs/cf /cf ufs ro,sync,noatime 1 1 /dev/md0 /tmp ufs rw 2 2 /dev/md1 /var ufs rw 2 2 devfs /var/dhcpd/dev devfs rw 0 0 You can move /tmp onto a ram disk on a full install using the options in System: Advanced: Miscellaneous: Edit: Although..https://forums.freebsd.org/threads/tmpfs-dev-shm-md-questions.45210/#post-256239 Steve

I may question how the 8 hour graph can get results like 0.12% in a 1min average,  but when I ran a ping myself and upped the sampling rate, I would get similar numbers. I wonder if it does some kind of weighted sliding window for the average percentage. The main thing is the numbers seem trustworthy, so I'm happy. Maybe I just to look at the code. I've never done that before.

Leave it unchecked to kill the states. That's almost certainly the behaviour you want. Steve

Hi, Did you ever get an answer to this? FYI, I had the same question … all when green when you actually add the Pool to a Virtual Server (until then, no checks it seems -> stays red).

If all the internet traffic is going through one device I can't see it making much of a difference.  The only reason I'd run it at each branch is to protect them from each other.  I'd rather maintain just the one at the WAN if possible.

No official releases are affected. It would affect the 2.2-RC snapshots but the fix is already in current snapshots (note they report 10.1-RELEASE-p1 now).

Ah ha! That makes sense.  I always wondered why it sometimes seems to work as expected and other times not.  Thanks for that!

Thanks for the reply. A reboot of the box brought things back to normal. The polling option was already disabled in the UI after the reboot. Maybe the system locked up before the change was saved to the config file?

That is highly unlikely to work as they are compiled for very different versions of FreeBSD. In theory someone could compile apinger on a builder made to create pfSense 2.1.x images (FreeBSD 8.3 base) and then copy that over, but we have not tested that.

@phil.davis: Try this to generate the list of FaceBook IPs: https://forum.pfsense.org/index.php/topic,69860.msg383922.html#msg383922 Then use the Alias as destination in a pass rule on LAN and direct that traffic to the VPN gateway. That's … brilliant. I can use this for so many other sites it would be nice to anonymize too. Thanks!

Thanks for your help everybody. This was a compound issue, and it looks like everything has been explained now. I appreciate the help.

Sounds like something got botched on install.  Maybe you accidentally put in a bad setting.  I'd reinstall again and start from fresh. Much easier than trouble shooting a broken install. BTW - I'm also running similar CPU as you, also broadcom on the WAN with 4 gigabit intel PCIe NICs for LAN.  It should work no problem. This ugly pfsense for some reason is the most reliable one for me.  Seems to never glitch at all.  Its my personal use box in Maryland.

Because traffic is allowed out of an interface by default, without a firewall rule. Thus there is no rule capturing the traffic to log it. It requires a rule on LAN because it's going in on that interface and hence is logged (assuming you've enabled logging on whatever rule you have there). You should see that traffic arriving over the IPSec tunnel is logged on the IPSec interface and not the LAN. The only exception to this are the floating rules which can operate both in and out. Steve

@heper: this is a freebsd 8.x problem … working around it, is not hard. once installed you can turn your cores back on. imho, nobody will bother to fix ancient bsd releases. you could try the pf 2.2 beta on freebsd10.1, perhaps they've fixed it there. ;D

Hello, I find the problem. Other users ask me to change the GUI to Portuguese. And some settings don't work in Portuguese. I set GUI to English and it works again. Thanks.

Helps when you read instructions! Its up now :) http://en.community.dell.com/support-forums/network-switches/f/866/t/19445142

Ok so I revisited my code after giving it a rest for a few days and made some progress on my original idea of creating an Alias called "Whitelist" and then programatically updating that list by pushing the config.xml file from the server, updating the Whitelist Alias, then pulling the config.xml file back to the firewall and reloading the config…. The issue I ran into was  that running rm/tmp/config.cache would not apply the changes… Today I found that if you run both rm/tmp/config.cache and then /etc/rc.filter_configure it will apply the rule! Two questions… 1. Are there any unforeseen issues with running the /etc/rc.filter_configure script… it looks like it is pretty straight forward.. and I did not see anything obvious… 2. Is there any way to preflight the config.xml BEFORE is run the commands to reload it? Like you can with Apache? I am running all kinds of safety checks in my script that updates the config.xml.. but I want to be as safe as I can be… For anyone interested here are more details… I am running coldfusion on a box that is open to all Ip address on the WAN. 1. I have a page on that server that requires the agent to authenticate to. 2. The coldfusion script looks at the users IP and determines if it is a new one. 3. If it is a new one it updates a database for that users profile and sets a flag that tells a scheduled task (cron job) that a new IP needs to be added to the whitelist. 4. The scheduled task runs every five minutes and looks for the update flag… if it sees it it runs… Here is what it does…. Gets the new IP whitelist from the server… uses putty to run a .sh script on the firewall that FTPs the config to the coldfusion server (all done inside the LAN) Replaces the previous whitelist with the new whitelist uses putty to run a .sh script on the firewall to ftp the config.xml file back to the firewall server runs a .sh script to reload the config..