Yep, but couldn't understand which process was the one doing I/O. I'm not a *nix expert… but the forum and the many "good news" rang a bell https://forum.pfsense.org/index.php?topic=95837.msg533449#msg533449 mount -o nosync / SOLVED! PS: now removed the "sync" option out of /etc/fstab and rebooted, looks ok.

The only reason to have a default gateway in the netgear is so the netgear device itself can route to the internet.  You might or might not be able to even set a default gateway on the LAN side of that device. The wireless clients should have the IP address of pfSense as their default gateway either from DHCP or static.  The Netgear simply bridges the wireless clients with the wired network.  The netgear/AP is not a layer 3 hop.  You are putting wireless and wired clients on the same segment.

You're redirecting it somewhere else. There are suggested workarounds to get in here: https://doc.pfsense.org/index.php/Locked_out_of_the_WebGUI

How do you know you have internet access?  I suppose you can ping IP addresses on the internet? Could be a DNS problem.  If you can load PFSense in your browser, then I don't see how this is a totally "browser" issue.  It seems odd that it would be a PFSense issue that not a single browser would display a web page for you.  Unless it's a rules problem… Can you ping by domain name?

If it works fine that was the issue then, your DNS doesn't like the pings! You can lower the number of pings or just use a different server to ping.

So, great, previous crash fixed, ran the "reinstall all packages" routine to test, but now I get this crash: Crash report begins.  Anonymous machine information: amd64 10.1-RELEASE-p13 FreeBSD 10.1-RELEASE-p13 #0 c77d1b2(releng/10.1)-dirty: Tue Jun 23 17:00:47 CDT 2015    root@pfs22-amd64-builder:/usr/obj.amd64/usr/pfSensesrc/src/sys/pfSense_SMP.10 Crash report details: PHP Errors: [29-Jun-2015 12:35:33 Etc/UTC] PHP Fatal error:  require_once(): Failed opening required '/usr/local/pkg/shellcmd.inc' (include_path='.:/etc/inc:/usr/local/www:/usr/local/captiveportal:/usr/local/pkg') in /etc/inc/filter.inc on line 3852 Another thing that would be useful: if version updates wouldn't mess with the crontab file: after each update I have to re-add the 'MAILTO=""' line in order not to get swamped with notification e-mails; even better if we'd get notifications e-mails when there are package and/or OS updates ready. But those are different issues…

Hello Guys, I have an emulex OCE11102-NT which works well on freebsd 10.1. I get the oce driver from there and add it to pfsense which see my two 10Gbe ports. However, I can't make any vlan working with. It works well on pfsense but not directly on PFsense 2.2.2. I ran some tests with Emulex, it seems the VLAN tag received by the network card is not correct. Any idea of what's going on ? Thank you

i'm such a fool….sorry... it was MY failure - used a wrong netmask on wan interface... thx for your attention phil...

remove all manually created gateways … dhcp on wan does it for you.

@Derelict: Inherited a network and you're not a network guy, huh.  Must not be very important to TPTB that their network actually work. Artecs, don't worry. You don't need to be a network guy to setup pfSense but it helps if you are willing to learn what you do need to know. VLANs are far easier to conceptualize if you understand why they exist. To expand on robi's comments… You have 5 LANs. In the old days, you would need 5 physical ethernet interfaces in your firewall to service them. VLANs enable you to collapse 5 physical networks into just 1 physical network so that only 1 physical interface is required to service them all. This cuts down on cabling and hardware and can make remote moves and changes much easier. VLANs do this by tagging packets with the label that you assigned to them so that they can be identified and separated later. If you have a physical cable plugged into a pfSense ethernet interface that is running one or more tagged VLANs, the other end of the cable should be plugged into a tagged port on a VLAN switch. It is usual to make this port a member of each VLAN that it is servicing. If you have a physical cable plugged into a pfSense ethernet interface that is not declared as a VLAN, the other end of the cable should be plugged into an UNtagged port on a VLAN switch. This port only needs to be a member of the one LAN that it services. Alternatively you could just use a regular Non-VLAN capable switch or even a hub! I hope this helps.

Did the 1st major upgrade one some of the heavier ones in production running about 20 VIP's and shitload of aliases and VLAN's. No issues at all. Everything checked and running with no errors WSE. Very smooth.

I have PM'd you update URL that appears to work. I will get the default URL updated tomorrow for others. Steve

@Abhishek: Wan Speed ?  5Mbps With a WAN speed of 5Mbps and a LAN speed of 1000Mbps there is going to be a lot of buffering either in hardware or in the protocol stack for packets that pass between these networks. A long, long time ago, when 10Mbps LAN speeds were common, Cisco routers had the equivalent processing power of a 16Mhz intel 386sx. It really doesn't need a powerful CPU to move packets in and out of a slow speed network. What will take CPU is packet inspection. An intel E5800 with 2x 64-bit 3.2Ghz cores and 800Mhz bus will be idling most of the time running pfSense. Snort will give it more work to do but it will depend on the rules you select. This is a powerful machine for pfSense.

The previous issue of coming from 2.1.X with a different FreeBSD base version doesn't apply here. The reboot binary would run in 2.2.2 or 2.2.3. The only thing that might cause that would be coming from 32bit except that you say you didn't and also it wouldn't reboot manually without actually pressing the power button. We haven't seen any other reports of this yet in 2.2.3. Steve

The "issue" is that restoring newer config on older versions is neither supported, nor suggested. You can take older configuration and restore it on newer versions which will be handled by the configuration upgrade code. Not the other way round.