Okay - everything is working again  ;) This is what i did with the SDcard: root# dd if=/dev/random of=/dev/disk4 bs=16k dd: /dev/disk4: end of device 242017+0 records in 242016+1 records out 3965194240 bytes transferred in 1900.317391 secs (2086596 bytes/sec) root# dd if=/dev/null of=/dev/disk4 bs=16k 0+0 records in 0+0 records out 0 bytes transferred in 0.000020 secs (0 bytes/sec) root# dd if=/dev/zero of=/dev/disk4 bs=16k dd: /dev/disk4: end of device 242017+0 records in 242016+1 records out 3965194240 bytes transferred in 1885.583163 secs (2102901 bytes/sec) root# gzcat pfSense-2.1.5-RELEASE-2g-amd64-nanobsd.img.gz |dd of=/dev/disk4 bs=16k 121458+1 records in 121458+1 records out 1989969408 bytes transferred in 944.297691 secs (2107354 bytes/sec) And after that it works as expected. Bye, thanks for every hint eweri

If you didn't enable UPnP or set port forwards in pfsense there's nothing to do at the client.  I'm just telling you my experience with rate-limiting bittorrent clients.  Only you know how your network is configured.

I would try the 2.2-BETA - http://snapshots.pfsense.org/ It uses FreeBSD 10.1 and a whole bunch of different/newer stuff, so here's hoping the "38%" installation issue no longer happens. As far as I have been trying stuff, the latest 2.2-BETA (and what is expected to be a 2.2-RC real soon now) is good to go.

If you configure pfSense with only one interface, WAN, it will allow administrative access on that interface via a default firewall rule. If you add a second interface, LAN, access to the web gui switches to that and the firewall rule on WAN is removed. If you need to access it via the WAN add a firewall rule to the WAN allowing it before adding the LAN interface. I'm unsure why you couldn't connect on LAN. If you add both WAN and LAN interfaces at the initial setup in the console dhcp is enabled by default. You can still do that from the console menu at any time using option 2, 'set interface ip addresses'. Steve

Others have also asked for a master admin console for working with many instances, but the pfSense has said that this is something for the future, maybe.

UPDATE:  SOLVED First I tried updating the bios (build 9/8/2014), which involves booting TinyCore Linux on a  thumb drive, which I did with no trouble. (Still using Win32DiskImager) I was still unable to boot pfSense on a thumb drive. Then I tired writing the same pfSense image  to a new thumb drive using 'dd' on MacOS.  That finally worked. So the combination of my 5 year old desktop, its USB plumbing, Win32DiskImager, and certain memory sticks results in unbootable media.

Serial consoles are fairly standard on most all routing gear. It's a reliable and simple way to gain out-of-band access in gear that doesn't have more advanced capabilities (e.g. IPMI). There is a reason it is still around while other things have died off. USB to serial adapters are cheap, so are null modem cables/adapters, and both are extremely useful for configuring lots of different network gear. They should be a part of anyone's standard toolset. Two inexpensive options here: http://store.netgate.com/Cable/CB-FTDI.aspx http://store.netgate.com/Cable/NM9FF.aspx

Also could be a broken package that modifies fbegin.inc like the old widescreen package.

What are the exact steps taken, inputs given, etc? I create GEOM mirrors all the time and have never seen that error.

Hi Steve, Thank you!  Great catch.  On my first try I downloaded a 1.2.3 nanobsd image in order to match my old configuration file (it wouldn't boot), but on the second, somehow I managed to download the memstick version instead of nanobsd.  I went back and downloaded pfSense-2.1.5-RELEASE-4g-i386-nanobsd-vga.img, installed it, restored my configuration, and I am much much happier. Regards, Rich

I think my 2.1.x versions used swap, but cant say I have noticed 2.2 using swap yet. Perhaps the latest bsd version spots ssd in use and just doesnt use it now?

Different companies offer different amounts. Some ISP give you their unthrottled bandwith throughout the use of an allowance, but anything over the allowance amount and the bandwidth can be throttled back to a lessor amount of their choosing. Others might just disconnect you once your allowance is reached like PAYG mobile phone data plans do. Holiday parks and hotels work much like PAYG mobile data plans, so its a case of either doing as others in your area of business do, or do something different if you fancy it.

Those RRD logs are symptomatic of a system that ran out of RAM at boot time. Only circumstances where I can recall seeing that are systems with 256 MB or less RAM, running nano (so a chunk of the RAM is taken by rw filesystems), and more packages or other services than should be run with minimal RAM.

NICs are named by their driver type. They can't be renamed. There's no way you reinstalled and ended up with different NICs unless you switched hardware in the process. Just re-assign the NICs either manually in the config, or after you restore the config. That's very easy and trouble-free. Where you have complex interface scenarios, like VLANs and lagg and bridging, things can be a bit more complicated. Editing the config manually is definitely the easiest route there. If you do edit the config manually, be careful, and never do a blind mass search and replace. Verify every replacement is actually an interface (granted there will only be 1 instance unless you have a more complex interface scenario). There's a good chance you have certificate or other data that happens to contain, say, "em1", and if you replace every instance of "em1" you'll break things.

Yes.  i217/218 was added to the em driver.  /var/log/dmesg.boot will contain all the boot device sensing logs. 2.2's in beta.  It will, at some point (presumably when there are no more known bugs marked as blocking (or tagged as a known issue)) go to RC1.  Then maybe RC2. Maybe to RC3+.  Then it will go to RELEASE when it is ready.  Church bells will ring across the land. I usually hold off here at home until RC1.  In production I wait until RELEASE and then only if I need a feature/fix.

@KOM: If I'm not mistaken, don't you have to use the Embedded nanoBSD install for those ALIX appliances? I want to see the actual traffic that is going through the pfSense Interfaces, I think that's called RRD? Are you looking for live, realtime data or reports & graphs?  Traffic graph will give you realtime views, while packages like Bandwidthd, RRD Graphs and Darkstat give you historical details. I thought the Embedded Version is for SD Cards because the system is loaded into the RAM instead of writing it on the Card to protect the limited writing cycles of the Card. I'm looking mainly for live and realtime data but reports and graphs are also great.

You'd be better off using the alc(4) driver from 10 stable. Unfortunately it just missed being included in 10.1. https://svnweb.freebsd.org/base/stable/10/sys/dev/alc/ Steve

Perfect, waiting on RC :D Still stable for now, but I can't restart the server, but its not something we do anyway.

With a PPPoE connection the gateway is allowed to be outside the subnet of the interface where as other types, static/DHCP etc, it is not. If you try to define the gateway manually pfSense will complain as you've found. This is not a problem. The fact that your pfSense VM can check for updates proves that it has WAN side connectivity. When using a virtual machine host and bridging interfaces I do not normally expect the host OS to use those interfaces. I can see how it might use the WAN NIC but there seems to be no reason that it should be using the LAN NIC. I would not expect that to have an IP. If you want to pfSense VM to firewall connections to the host as well then the host should not have an IP address on either WAN or LAN. Instead you add a further virtual NIC that the host OS uses to talk to the pfSense VM. VirtualBox has a special interface type for doing that but I have to admit getting that setup right has tripped me up the few times I've used VirtualBox. Steve

Update 2 Some further progress - purely by chance I unchecked "Skip rules when gateway is down" and I have now got back the behavior expected with LAN policy rules being followed. I set this rule so that traffic was NOT sent to the default gateway when the openvpn link is down - this worked fine in 2.1 but the behavior here has changed. Also, I have a dual openvpn setup, that was nicely load balanced - in this latest version only one of the VPN links is ever used with all the connections going out on the one link. I am struggling to take this further without some help.  Will revert to previous VM for now.