I've come across this problem once. I had left the network cables plugged in and it just hung on 38%. Only figured it out when I backtracked to what I had done before and what I was doing now and realized that the network cables being unplugged/plugged in were the only difference.

You don't want the memstick version. That acts exactly like the install CD, it will run live but won't remember any changes.
Use the NanoBSD version.

Steve

bump. Do you want to use squid cache on a separate disk (msata) ? If so im also looking for the answer.
im running the enbedded version on a SD card but would like to use my msata disk for cache. Does anyone know how to achieve this?

Noting the version of Firmware for the Raid Controller between the 2 systems.

The working system was running Perc 6i Integrated with firmware 6.3.3-0002
The non working system was running Perc 6/i Integrated with firmware 6.3.0-0001 and 6.3.1-0003

However when i tried to find 6.3.3-0002 for a Perc6i on Dells Support site under PowerEdge 1950, i could not find it. I then searched Dells site specifically for Perc 6i firmware, and found the proper version 6.3.3-0002 (note NOT for a PERC 6E, but PERC 6i).

Booted to a live CentOS disk, upgraded the firmware and viola, success!

Below is the link to the proper firmware:

http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=F96NR

This can be marked as Solved.  I see that many people out there find this same issue, and i hope they find this.

Thanks.  Flashing a spare 4 GB Transcend 300x CF to the 2.1.5-RELEASE worked fine.  I imported the configuration I had saved before I started, and I was off and running.  Two mistakes I made that slowed me down were 1) to forget to expand the image before flashing it, and 2) to flash the upgrade version, when I should have flashed the full install.  As a backup during this process, I kept the original Kingston 4 GB 133x CF that shipped with my unit.

Just as an example figure an Atom D510 will push ~50Mbps of VPN traffic. That's software only.

Steve

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