Its working because your IPs are connected to the same network..  So does not matter what interface pfsense sends traffic from be its lan or its wan it can still talk to your actual physical gateway. So if you look at its routing table - what does its show as primary route to 172.16.1.1 which I assume is your actual physical gateway off your network.  What interface is it using? Here is your problem - a client connected to lan side of pfsense can directly talk to 172.16.1.1 - there is no reason for it to talk to pfsense IP - unless you tell it too.  Because your lan side is bridged to the same physical interface as your wan interface. Why in the world would you setup such a pointless setup?

Thank you very much it worked

There isn't much you could do for that short of tossing more CPU at it. The IPsec status code might need some optimization, it does have to go over and over the entire status output a few times to build things up, so as the number of tunnels increases, the GUI status will be slower. I'm not sure if there is a more efficient way to build the status output though, it's been a few years since I looked at that code.

It could be that the format of a config section changed, something may be converted to/from an array, settings could move, variable names could change, etc, etc. Lots of different reasons. There is a configuration upgrade process that makes changes to the config as needed. It only happens when necessary. The config format didn't change from 2.0 through 2.0.3, but it's already changed from 2.1 to 2.1.1.

@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.