What OS was running on the Asus when you tested? Its just before rack servers with quad ports existed I had some of these quad port intel nics in windows servers 2003 and either the MS drivers coming from the windows update or Intel drivers would not work properly, although I think it was the MS drivers which didnt work properly from memory. So even though your Asus might have appeared to have worked, not all features on the card may have worked. FWIW.

@heper: i wouldn't know why there would be a difference between up or downstream on your VM. are you seeing a difference in CPU usage between up or downstream ? are you sure you don't have limiters / shaping configured on pfsense? No limiters, no CPU difference, I put my AC66u router back in place and have the same upload restriction…  I think its an issue with Verizon.. sorry to jump the gun.  Always speed test before and after!

There are not any known issues with logging on 2.1.5, but it's possible something has corrupted your log files. rm /var/log/*.log and then reboot, it should start working again.

As per Stephen, you need to unzip the gz file , use 7zip to unzip the archive and then write the unzipped image to usb or cd see here https://doc.pfsense.org/index.php/Writing_Disk_Images. I had to do a lot of hula hooping before I managed to install pfsense on my alix box  ;D. The documentation on the pfsense site is awesome take some time and go through it, it is really helpful. Cheers!

Have a read at this https://doc.pfsense.org/index.php/Boot_Troubleshooting I had the same problem with my mSata drive. I had to re-install pfsense and I had to uncheck the "packet mode option during boot block" option when I installed it. After that it worked for me. Cheers!

Finally was able to install it on the msata, didn't do anything different this time. I had to install it a few time before I figured I had to install it with packet mode during boot option unchecked , otherwise it would just hang at boot time. Thank you for all your help Stephen. Cheers!

There is no such file /etc/inc.inc What pfSense distribution are you using? Please check the error message you posted - it must be some other file.

Actual RAM. The X-Core uses SDRAM, it's old.  ;) It's also really quite fussy about what DIMMs you can use. There are a number of posts about it in that very long thread and I've also put a few known examples in the docs: https://doc.pfsense.org/index.php/PfSense_on_Watchguard_Firebox#Further_Enhancements You can run it with the standard 256MB but that really is the minium requirement for pfSense. You shouldn't exepect to be able to run any hungry packages. The two X-Core boxes I've had both ran fine with 256MB, I never had lack of memory problems, but I only ran them in default configuration. Steve

looks easy enough. just setup a VM with both nics in place. (use a 1 for WAN, the other for the vlan trunk to managed switch) be sure to setup your virtual networking correctly, to allow the use of ALL vlans (4095=allow ALL vlans in esxi) http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004252 install the pfsense with the wan / lan / vlans / … add all the firewall rules etc etc, put a limiter on the guest vlan If you want more info, just ask If you want someone to do this for you  ---> check out the "bounty" section of the forum or get a commercial support contract by ESF

Yes since you shouldn't ever get traffic from private IPs on the WAN unless, as you say, it's behind some other NAT. Even then you can can leave it on and it won't block outgoing traffic, or replys to that traffic, only unsolicited traffic from the private subnet. If you aren't using NAT and have a routed network with public IPs internally you might also use it there. Steve

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