@jimp: Do you have the WAN set to "none" or DHCP or some other type? If you have it set to "none" then the message is correct. If it's set to DHCP that should still allow you to configure it even if DHCP doesn't yet have an IP. If you don't want to set DHCP, just put a dummy IP on the interface and switch it before taking it live. Thanks for the input. It is set to DHCP and using only IPv4. IPv6 is set to None. Could that be causing all these issues? I don't think so because when I allow the router to obtain DHCP on IPv4 then the problem is gone. Please test on your end. This is most likely a bug.

No, I have never tried to setup something like that. I'm sure there are people here who have though. Steve

thank you, I do some testing with the 2.1 and I'll know.

I could switch to a 32bit system, but the error doesn't seem to be causing any issues I have been able to detect. I do have a couple of ipsec tunnels to remote offices which I assume the padlock helps with the encryption. However if the error is indicating that the accelerator features is not working, then there isn't much point to it. CPU usages typically never exceeds 1-2% so I may not even need the hardware crypto. Network performance has been impressive with the VIA dual core, with us typically dealing with ~100mbps UP/DOWN. Granted I don't have a huge amount of users, around 30; but being able to do what I need and with a fanless design with tons of processor to spare is pretty neat. I am still running 2.03 and haven't  upgraded to 2.1 yet. Perhaps this will address the fpudna issue. If not, I don't think I am going to worry about it unless there is a pressing reason to. I will report any other HDD issues/errors if they happen. I thank everyone for the help and assistance regarding the matter.

Hi Guys, Thanks, I have actually found that info in documentation. What happens in my situation is that I have 4 public IPs with same IPS gateway. Two public IPs a guarded by pfsense Firewalls and when I go from one network to public IP of other I am reaching webadmin page of that other network like there would be external webadmin access enabled. It is ok however if I check it from completely separate public IP from different IPS. I will check it.

Here is the solution; Step1: stopped squid service Step2 : Find squid.conf file find / -name "squid.conf" Step3 : Should add the following lines in squid.conf file acl bump-bypass dst "ip address" or "/…path.../BumpBypass-IPs.txt" ssl_bump none bump-bypass ssl_bump server-first all Stpe4 : started squid service. Good luck.

The main consideration here is how much traffic you need to firewall. What is your WAN connection speed? If you want to run additional services like web proxy, IDS/IPS or VPN that will increase the hardware requirements. The number of NICs you need deppends on how your network is configured. You will need at least two, for WAN and LAN connections, but more if your internal network has several subnets. Steve

@nothing: Just check "Disable Gateway Monitoring". It's not in your use anyway. Unfortunately it appears that I cannot saturate my upstream completely or these OpenVPN endpoint messages accumulate in the system log, CPU usage peaks and I get a series of check reload status msgs regardless of whether I disable gateway monitoring or disable OpenVPN altogether.  I've even tried to delete and recreate my WAN gateway in case it was a corrupt config. Perhaps a bug as no other significant changes made to my pfsense 2.1 release.

Ok, found the issue. I had the WAN interface set to 192.168.0.150/1 instead of /24. As soon as I changed that, everything started working.

FreeBSD syslogd will to that if you add two -c options on the command line when syslogd is started up.  See: http://www.unix.com/man-page/freebsd/8/syslogd/ for example. My 2.1 is running with that already though: q[2.1-RELEASE][root@pfsense.localdomain]/var/log(14): ps axfw | grep syslogd 62744  ??  Is    0:00.48 /usr/sbin/syslogd -s -c -c -l /var/dhcpd/var/run/log -f /var/etc/syslog.conf

I agree it's sometimes more convenient to bridge interfaces. Depending on your NIC type you may also need this patch: https://forum.pfsense.org/index.php/topic,66908.msg367991.html#msg367991 Steve

Actually, this is still an issue. Applying firewall rules, or almost any update will kill existing connections including my OpenVPN connection to the firewall requiring me to reconnect..