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

@stephenw10: It's not the same, you don't get some of the benefits of running Nano. Youc an choose to move /tmp and /var to ramdrives in the advanced options which gets you the limited writes. (mounting -noatime also  :-\ I'd have to check). Ahhh.. I thought there may be more to the nanobsd image. Is there some reason you need more space than the 4G Nano image gives you? Steve Not really, other than the feeling I am using the space I paid for :p.  Guess I will be using the nanobsd image. thanks.

Not necessarily. Do you have a complete list of specs? What exact images are you trying to load? What error is shown? (if any) Some quick Googling seems to show some issues with this model and *BSD. Some workarounds might be: disabling ACPI in the BIOS. Using the F12 boot media selection to specify the boot device which seems to pass more useful info to the OS. Steve

Where are you pinging from? Try pinging from the Diagnostics: Ping: page in the webgui. Try pinging from the pfSense console. Please give the exact error given if the ping fails. Are your public IP, gateway and DNS servers all in the same subnet? Steve

It should be supported by the iwn(4) driver in FreeBSD 10 but that means only in pfSense 2.2 alpha. It will not work in pfSense 2.1.4 (current). Edit: Looks like I was wrong, it will work to some extent in 2.1.4 but it's reported not to work in access point mode. Also the FreeBSD 10 man page reports only station and monitor mode so you could be out of luck if you want to use it as an access point. Steve

Just to add my experience Every fiber service switch I have ever connected to has required me to force the interface settings in pfsense.  The always connect half duplex and sometimes the wrong speed if I leave it to auto-negotiate.  Most likely the settings are 100baseTX / full duplex [image: 2014-07-14_171531.jpg] [image: 2014-07-14_171531.jpg_thumb]

Both vi and ee are available in the shell.

No. The EFM is on a fixed IP range. But yes, existing connection is PPPoE. Good idea on the config file,also on the opening a port. Thanks for the suggestions