do your lan clients have their gateway set to pfsense ? does your openvpn-client-device have a route for the lan-subnet by the tunnel (the defaultv openvpn client for windows, needs to be run "as administrator' to be able to SET the routes) did you try turning off windows-firewall (for testing). It is known to block pings outside its own subnet.

Same error here with a new install. Any ideas out there?

A lot more info please.  ;) Where is pfSense in this setup? Is it running Squid? Squidguard? What firewall rules do you have? Where are you testing from? What do you see in the firewall logs when the "app" in blocked? Steve

what was the solution here? can someone update?

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