If you're on nanobsd, you could set the boot slice to the alternate and reboot, and it would be back to normal (but with your config, of course). That's under Diagnostics > NanoBSD Power loss normally isn't an issue with embedded, as the device is read-only most of the time. Even so, it's rare that a file gets corrupted.

The newest release version of pfSense is 1.2.3-release which is what you should be using in production. Adding something like iBlocklist is a feature coming in 2.0 which is currently in Beta.  It's not quite ready for production, but its getting very close.

The updated ones may have carried over files from the older version, but should have updated all core files. The update kernels are built separately from the ones that go onto the ISOs. The firewall logs are also updated by the Dashboard package, you may have installed that in some or all of the boxes.

Key words from your post are: @rwalker: I.e. segment A - 10.10.10.x has 3 servers, server 1 is requesting from server 2 & 3 which are in a cluster. Correct approach would be: to access this cluster Server1 should use 10.10.10.y IP assigned to serv2&3 cluster. If you still want Public IP then probably you should try NAT reflection.

Hardware: My connection is 5500/720. I run squid, freeswitch, and do lots of traffic shaping, with voip and torrents on the LAN. A 500 MHz Geode is more than enough hardware for this. I could handle 3 times the speed comfortably. Bandwidth: The more the better, obviously, but when I worked for a wISP a couple years back I observed that we were able to oversell our bandwidth about 30x without too much trouble. In other words, we could sell 1000/300 to 90 clients on a 3000/1000 connection before our pipe really started to max out. Using that math, I would estimate that you could provide 1000/1000 to roughly 60 clients on a 2/2 mpbs pipe before performance would start to suffer at the client's end.

Try another location - before you spend time chasing red herrings you need to be able to narrow down the issues. As for VPN - try this about setting up site to site with OpenVPN.  Before you do that though, do check that it is happening from more than just your office.

Some computer on your net is not configured with static IP and can not receive IP through DHCP, so it picks up some 169.254.x.x IP and then sends arp requests. pfSense's kernel receiving this arp requests understands that according to its config it is impossible to have this IP on this interface and reacts with the message in log. Do tcpdump, find out mac of this computer, find computer and fix it.

Thank you

Thankx for the reply, yes i have 4 ip's. Only using one now. I will try nattting a second ip to the second interface.

What does this mean please? @bangsters: when the server using this ip communicates with the outside, it reflects the main firewall IP and not the virtual IP What does``` pfctl -sn

Yes, I need to do some fact-finding before I can understand better.  Which probably means I need to get pfsense running in the first place replacing my router anyways :) ! I'll report back findings/progress when I've got it together (might take some time). Thanks wallabybob and everyone for your help.

Well usually you dont have to reset the webGUI. Normally you know how access to the GUI is allowed and just access it. In most setups i have i allow access to the webGUI only via VPN (even if you are on the LAN side).

I found it!. I configured it a few weeks ago and it worked perfect. this morning I remembered that the default gateway on the 192.168.20.0 net is 192.168.20.254 while the PFsense ip is 192.168.20.1. this is where I made the mistake. When I tested the setup I had a static route facing 192.168.20.1 then I told to myself I will just add a static route on the existing firewall 192.168.20.254 and it will redirect the traffic. I rebooted the server a few time and the local route was deleted. So it's very interesting why the firewall 192.168.20.254 has created the mess. But I'm not going to investigate this.  I will replace it to Pfsense as well, and I hope that it will be ok. Many Thanks David,

Thank you! Will look into it!