@wallabybob: @onlineph: I purchased new board, and as expected I got a ROOT MOUNT ERROR when attaching my HDD SATA (previously attached to the P4). At the root mount error report type a question mark, tap the Enter key then post a screen shot or screen dump. The root mount error occurs when the hard drive has a different device (e.g. was /dev/ad4 now /dev/ad2). The problem is relatively straightforward to fix PROVIDED the system recognises the hard drive. I posted this question expecting that anytime my old board would gonna broke down (although I have tried already transferring my hdd to a new hardware environment) the silly part is, its the other way around, my HH broke down, 5 minutes preparing to back up its pfsense settings, now I lost that setting. sigh!

No problem. Its also easy enough to put any of these on USB/Memstick/whatever with UNetbootin in ubuntu, which is an application that cost 1 Billion dollars… (kidding - Its free)

pfSense 2.2 will be based on FreeBSD 10.x, so there will be a large leap in driver support there. Once we ship out 2.1 (hopefully soon) we'll start working more on that.

Use the Netgate firmware for the 7535 from here (It's not the 7541 but it's nearly identical, close enough): http://www.netgate.com/firmware/2.0.1-RELEASE-rebrand/ Or if you have another FreeBSD or pfSense unit around, you can adjust the image file or disk manually… http://doc.pfsense.org/index.php/Embedded_install_on_Netgate_Hamakua

If it was a missing beep binary it would never beep, not just start/stop. Check your console, I suspect something is causing the boot to never fully complete.

I like to do this also - have an offline backup system ready to go in places where I have spare hardware. (With CARP or any solution with multiple boxes powered up together, all the hardware can be killed by the 1 lightning strike…). You can restore the config, then it is good to get it to load all the packages when it first boots, so it is ready to go when needed. In practice, I find I need to plug it in as the real pfSense during some after hours period, let it boot up, download the packages it wants and start up. Actually, you can then leave it in place as the production unit and keep the previous production unit as the disaster backup hardware. If your WAN uses DHCP, then you can plug the backup unit into some other internet connection, and it will get DHCP on WAN and download packages... But if it has a static IP set on WAN in the config, then the only way to get it to download packages is to plug it in as the real production unit. (Otherwise you have to change the config to make it connect on some other WAN, and then make sure you correctly reverse the changes you made so that the backup unit really is an identical config to the production unit.)

2.1 Has some ease-of-use improvements. First is with a Wizard after you assign your NICs on the console.  Wish there was a wizard for rules and port forwarding for morons like myself.

I believe so, I tried it by setting a firewall rules as follows: allow all traffic on interface IPSEC from remote IP > internal LAN allow all traffic on interface INTERNAL LAN from remote IP > internal LAN I didn't reset states though. I did read a post later on that suggested allowing traffic on your EXTERNAL interface from remote EXTERNAL IP but my thinking is that once the VPN tunnel is established the traffic would appear to come from the remote IP network addresses rather than EXTERNAL IP address? Drac

Got It, Thank you

Thanks for the reply.  I had set my Virtual IP addresses as lfAlias rather than CARP (not 100% sure what the difference is). I noticed from your post that your external virtual IP's are each pointing to a different internal machine, whereas in my scenario I had set one virtual IP to NAT to 4 different internal IP's with some on different subnets.  In the end I disabled the NAT 1:1 mappings and just used NAT port forwards and this seems to be working fine now. Regards Drac

Thanks for the help, you two. Resetting states seems to have done the trick.

So I will have to re-configure the packages, if needed. Not really an issue in the particular situation, but for other installations. Best Kostas

If you can find deals on thin clients with proper spec, that is an option.  I found some that were better priced than the Alix boards I've used.  These were also new. See this post.  I have 2 of them with upgraded disks of 4 GB, and run offices which averages 5 GB-10GB daily using Squid, Snort, etc. http://forum.pfsense.org/index.php/topic,64393.0.html

Automatic or manual upgrade? If manual, what is the name of the file you are attempting to use in the upgrade?

@Reiner030: mmh, I try to cut/clean the video I made of it with our last firewall switch… Gateway just crashed because of TRAP 12 bug…. The good thing: I found in crashdump the console output while re-installing package ;) <118> <118> <118> <118> <118> <118> <118>done. <118> Starting package iperf... <118> <118> <118> <118> <118> <118> <118>done. <118> Starting package OpenBGPD... <118> <118> <118> <118> <118> <118> <118>done. <118> Starting package pfBlocker... <118> <118> <118> <118> <118> <118> <118>done. <118> Starting package Cron... <118> <118> <118> <118> <118> <118> <118>done. <118> Starting package bacula-client... <118> <118> <118> <118> <118> <118> <118>done. <118> Starting package System Patches... <118> <118> <118> <118> <118><118> <118> <118>done. <118>Bootup complete

The rl message may or may not be related, hard to say really. If you have to try it again, jump right to a 2.1 snapshot.

http://doc.pfsense.org/index.php/Upgrade_Guide#Upgrading_CARP http://doc.pfsense.org/index.php/Redundant_Firewalls_Upgrade_Guide

There is nothing wrong with running a completely virtualised test setup. @uberwebguru reading back through this thread it seems quite clear that you have somehow managed to connect the pfSense LAN interface to a physical(bridged) NIC an that is connected to your network. Hence both pfSense and your Netgear router are both trying to be the network router. In a fully virtual setup as you're describing only the pfSense WAN interface should be connected to a real NIC. Inside virtual box the pfSense LAN interface is connected to your other VMs via a virtual switch. Since both pfSense and the Netgear router are using 192.168.1.* for their LAN interface you will have to change one of them. I suggest changing the pfSense LAN. Steve