here is an update. I can now ping out. - however, the ip is 70.177.0.29 the static ip for the wan. when i try Virtual ip, i get nothing. - I cant use the lan, as i have voip phones on there, that requrie an ipsec connection to a remote switch, and they need a public ip address. - So i thought i try a dmz, or use the opt2 as the cidr block. thanks,

http://snapshots.pfsense.org/

I'd read that for the LEDs and Thermal Sensors, but not for the reset button.  Oh well.

@Stewart: I was actually able to fix the problem, I think.  Instead of resizing partitions, we are able to increase the size of the RAM drives.  While this may result in the loss of virus definitions and such on a reboot, it only takes about 4 minutes to be fully operational. Ok, that would work too.

Seems you have to use /sbin/reboot as mentioned below to reboot FYI - it should /sbin/tunefs -t enable /, not /sbin/tunefs -t / as mentioned below. @spid: @dstephens80: Charlie, I will give v2.2 a try and let you know how it goes.  As far as dmesg, I can provide nothing as the system will not boot with AHCI enabled.  it will not detect any GEOM devices, but it will boot fine if I remove the ahci_load="YES" from /boot/loader.conf.local. Did you convert fstab to ufslabel before adding ahci_load="YES" ? Run the following script to do it: /usr/local/sbin/ufslabels.sh then if it boots correctly go in single user mode and enable TRIM with: /sbin/tunefs -t / reboot with: /sbin/reboot and after a reboot check if it's enabled with: tunefs -p /

Log into your server, try to ping something external. Note the actual error given if it fails. Try to connect to the server from some external address, check the server logs to see if those requests are arriving. Steve

The default firewall configuration is to block everything on the WAN so you won't be able to connect from the WAN side. To connect to the webgui you should connect a computer to the LAN interface. pfSense will, by default, be running a DHCP server on LAN so it should give you an address in the 192.168.1.X subnet. Your LAN NIC is an older 10/100 Realtek type so it won't have autoMDX. Depending on what you connect to it you might need a switch or a cross-over cable to connect. You would know right away though because you'd see no link lights on the NICs. Steve

Jason: It turns out that, no, the SATA-DOM isn't operating on pin 7 power and needs the power cable to run on the Supermicro motherboard. Everyone: By Jove, I did it!  I used the iso of a cloning program called "Clonezilla" via IPMI's virtual media utility to copy the content of my old USB drive to my new SATA-DOM.  Thanks to all for your help–in particular to Stephen.

Steve, i will have a look.. i have a feeling it is just reporting it wrong because it appears to be working but I will have a look in the logs..

My box has 1 GB, /temp and /var set to 60 and 80MB, respectively.

@Jason: Do you have the appropriate Outbound NAT rules setup for the second connection? That was it. Thank you. Couldn't see the forest for the trees.

In which case the pfSense box must be connected directly to the WAN connections so it has to go in front of the UTM device. Did you find out what that is yet? Steve

Speaking of Virtualbox, don't upgrade to 4.3.14 as it's horribly broken.  Anyone running any kind of AV solution on Windows is having a problem either starting VB or starting any of their VMs.  Rolling back to 4.3.12 fixes the problem.

Yes, it's much easier to apply rules to an interface especially if the clients you're trying to filter are using DHCP and hence may change IP address. This also offers real separation between the two internal networks, much better security. If you're adding further networks you may want that on a futher separate interface. You can always add rules to allow the network to talk to one another but you can't segregate them later if they're all the same network segment. I have no idea what sort of distances you're operating over here but often in this sort of situation using VLANs and appropriate managed switches can makes things easier or at least allow you to do things with only the existing cabling that wouldn't otherwise be possible. Normally I would suggest getting brave and trying one of your routers with OpenWRT and using that for VLANs but neither of yours appears compatible.  :( DHCP should not be a problem since devices behind pfSense will only see the pfSense DHCP servers. Only the pfSense WAN interface will see the Microtik DHCP server. Keeping things simple is key for an easy life here, minimise the number of devices you have. What will the Microtik router actually be doing in this setup? Steve

Make sure the VM type and container match. If it's a 64-bit VM setup, use the amd64 version of pfSense. It's possible your config was pointed to the wrong architecture for the firmware update and switched itself. Set it back to amd64 and run an update for 2.1.4 and see if it stabilizes.

Nope I'd say you have 1GB. Due to the way NanoBSD works you have two boot slices each 443MB and config slice, 50MB. It's usually written next to the platform type on the dashboard: Platform nanobsd (1g) Not sure about 1.2.3 though. My 1g image shows nearly identical to yours: [2.1.4-RELEASE][root@pfsense.fire.box]/root(1): df Filesystem        1K-blocks  Used Avail Capacity  Mounted on /dev/ufs/pfsense1    453327 325815 91246    78%    / devfs                    1      1    0  100%    /dev /dev/ufs/cf          50527  8373 38112    18%    /cf /dev/md0              39406    750 35504    2%    /tmp /dev/md1              79086  27712 45048    38%    /var devfs                    1      1    0  100%    /var/dhcpd/dev You should be able to upgrade directly to 2.1.4. Make sure you've backed up your config file first though. I would probably remove any packages and reinstall them afterwards unless you have some very complex setup. Steve

Ah, this is you? https://redmine.pfsense.org/issues/3755 Slightly different then. Note that Chris does not say 'don't ever edit the config file manually'. What he says is, if you do edit the file make sure the result is a valid config. That's not necessarily that easy because there are no definitions of how the file should be (that I've ever seen!)  ;). Make sure you test the config somewhere unimportant. Use the code included in pfSense to import older config files to the newer file definitions in newer versions. What hardware specific settings are you referring to? Just the NIC names? In your case I would probably have restored the old file onto the new hardware and re-assigned the interfaces at first boot. You do seem to have a point about the config parser though, if it knows there is an error why does it allow it to be imported? Steve