After installing the version 2.2.6 the problem has gone! Thank you for the great product! Happy new year, yarick123

I have tested both again, in both combinations, now instead of using CF cards, I'm using equal SSDs, Kingston S200/30GB. No changes in the results. Both devices present higher temperature and lower performance on 64 bit, than on 32 bit.

Note that in 2.3 the factory defaults processing will automagically select from a range of physical interface combinations when first booting, avoiding the need to do interface assignment on the console for hardware like Alix, APU and SG-series devices… https://github.com/pfsense/pfsense/commit/b49e6c0113f107f5a9ff61fe8e8798de8cca0953 That should be working now in 2.3-ALPHA images.

^ that. Try a different serial speed (like 9600)

Just a FYI. I was trying to connect using one of my failover IPs on my dedi server from online.net. anyway, I manage to get it sorted. I knew what to do (almost)  I had to add a route, but didnt realise that the last bit was important, I kept trying dev eth0  when I should have been using -iface em0  once I added the route correctly, pfsense connected to internet. Thank you for providing this software.. Once my testing is done, If I keep pfsense, I`ll think about getting a gold sub. Del

There are relatively few changes between 2.2.5 and 2.2.6, so reinstalling packages in that scenario would have been more a precautionary step than anything else. If everything seems to be working, I'd leave well alone.

I wanted to update this post to reflect a method to correct this should anyone else run into a similar issue. I visited over at the QNAP forums and posted a similar message to a thread which already talked about running pfSense in a VM. mbender71 over at QNAP forums had a similar issue. Here is what was done; EXCELLENT question as I fought this battle a number of times. The issue is that pfSense is not able to get an IP address via DHCP and I believe it has something to do with the MAC address of the pfSense VM versus the MAC address of the physical adapter on the NAS. I found only one solution and here is how it goes : attach a desktop/laptop to your cable modem (that's in bridge mode already) and get that working. For me I used my MacBook Pro with a thunderbolt to ethernet adapter. The point of this exercise is to get your ISP to recognize the MAC address behind your cable modem and lock it in (my ISP only allows one DHCP at a time). PLEASE make sure though that you have your firewall turned on your desktop/laptop and perform this operation quick. Leaving a computer jacked to the net directly is dangerous! once you've confirmed your ISP has given you your IP address (i.e. you get get to the net) go ahead and disconnect your computer (for safety reasons). what you have now is a very special MAC address. Record the MAC address of the adapter you just used to connect your desktop/laptop to your cable modem since that is "golden" with your ISP. open the configuration of your pfSense VM in Virtual Station and begin to edit. What you need to edit is the MAC address of the virtual adapter that you will be using for the WAN in your pfSense VM. Copy the registered MAC you just found in the previous step into the configuration for the adapter you'll be using in the pfSense VM. For the record, I use the Virtual Ethernet IO (vmnet) for both of my pfSense network adapters. connect your cable modem to the designated virtual switch that you have your pfSense WAN network adapter configured to (the virtual switch for the WAN connection SHOULD BE configured as EXTERNAL ONLY). fire up your pfSense VM and open the console to watch it boot up. It might ask to configure the WAN/LAN in the CLI, but this time pfSense won't hang while it's initializing the WAN as it SHOULD receive its IP during the DHCP portion of it initialization. NUTSHELL -> Take a working MAC address that was connected to the cable modem and copy that MAC address (spoofing) in the pfSense network adapter that is being used to connect to your cable modem (WAN). This is what has worked for me and it's pretty solid. Only once have I had to repeat this crappy procedure when my ISP had a major outage for about 6 hours. I DO hope this works for you as I've had one other instance where a local friend had the same problem and after giving this solution it worked for him. Good luck! Thanks, Michael Hope this helps anyone else in a case where they are unable to get their WAN to detect.

@RonpfS: I disable Suricata, pfBlockerNG and FW Rules using pfBlockerNG before doing an upgrade. Yes - I probably should have done that too but I'd had no problems with another pfSense upgrade at work earlier and I just hit the upgrade button at home without thinking.  The NanoBSD system has less resources and has given me occasional glitches like this in the past - caveat emptor.

Which provider BTW? TM Unifi (Malaysia) Great. It works. Assigned as suggested and added Rules as follow: Action : Pass Interface : WAN TCP/IP : IPv4 Protocol : TCP Source : any Destination : any

Configured Pfsense router as DMZ , working perfect  , i noticed issues with double nating is issue with VPN and portforwarding  . but since my ISP NAT again i cant use VPN or other , (previous ISP used to provided public IP dynamically , but current provide high speed by 172.30.x.x private ip range which is NATed , so no issue with double NATing thank you

After the Upgrade to 2.2.6 i have the same Problem, but this is strange because I never used the Traffic Shaper. There were error(s) loading the rules: /tmp/rules.debug:52: errors in queue definition - The line in question reads [52]:  queue qInternet on re2 bandwidth 150000Kb hfsc (  ecn  , linkshare 150000Kb  , upperlimit 150000Kb  )  {  qACK,  qP2P,  qVoIP  } There were error(s) loading the rules: /tmp/rules.debug:52: errors in queue definition - The line in question reads [52]:  queue qInternet on re0 bandwidth 150000Kb hfsc (  ecn  , linkshare 150000Kb  , upperlimit 150000Kb  )  {  qACK,  qP2P,  qVoIP  } Because this Error occur i am back again on v2.2.5.

Ok my issues are now fixed. I thought it was the network card/s but ISP fixed phone line as it was playing up and now works again. I just find it strange that when connected to the modem direct I got normal speed but as soon as I added the Pfsense box in the speed dropped I dunno what the go is with that but its all good again. Thanks for the help.

just re-assign and use the auto-detect features in the menu (as stated by @robi)

@phil.davis: Note for reference: https://forum.pfsense.org/index.php?topic=87364.msg583303#msg583303 No luck with the FW-525B on latest pfSense 2.3-ALPHA that follows FreeBSD 10 development. It seems that the problem will be solved in FreeBSD 11: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199495

@cmb: That's confirmed fixed in the newer lighttpd in 2.2.6, so likely the next update will work for you there. Thanks cmb, I can confirm that in the 2.2.6 release the upload of the release file through the webgui works fine! While the 2.2.5 release gives the reported problem. So we can put this issue on solved: workaround on 2.2.5 through ssh - option 13. solved in 2.2.6

@skysurf76: One of these days you're going to to make an update that actually installs on my Neocore (Edit: Its Neoware, not Neocore) CA22 successfully when I auto update it and I am going to poop.  Until that time, I would just like to say that you all should reconsider careers in the janitorial sciences because you sure as hell can't program. Dear Skysmurf76, the "devs" did a great job with the update, it ran hasslefree on various sites and also my side, the noobish side of "se known galaxy". Concerning your janitorial wishes, well, you must have your experiences in that field; at least, in some sort of basement, but let's not carry on this, shall we? @skysurf76: I have to go now to finish completely wiping my box and reinstalling…...again...... for like the 4th time in 5 years....which makes me wonder why you even have auto-update as an option if its so unreliable. For the last 5 Years? Well, if others are able and you are not, what does you tell this? @skysurf76: Hey, at least what you're charging is the correct price. :) Price, yap. Go, get a sonicwall (they castrate your bandwith by firmware, but they charge you the correct price), go, get a Juniper, or Cisco, they deliver to you with a door and charge you also the correct price. Go, get a Walmartwall, for 0.99$, they are the best. Sorry, from one Noob to another: Post the logs, post the errors, help might come. Post no logs, troll, be unpolite: no help, no mercy with no remorse. Happy new year, soon.

@cmb: Sure there isn't something else different between? All 2.2.x versions use the exact same lcdproc package, which is generally the only thing that would have any impact on the LCD. The only OS change between 2.2.5 and 2.2.6 was a minor openssl update which likely doesn't impact lcdproc at all. Nothing else changed that could have any impact. Nothing in the LCD package has changed. After installing 2.2.5 I installed the same LCD package I used on 2.2.6 and no funky characters. After installing 2.2.6 and using the same LCD package tested on 2.2.5 I get some funky characters on only a couple of the screens. This is more of I would like to find out what the cause is then my LCD does not work. It is just a couple characters on only 2 of the screens so it is more of an annoyance. The date shows as 2015 and after a couple of seconds it turns into what looks like 2017. I know the LCDPROC is the main piece for what shows on the LCD, but I do not know why when using the same LCDPROC on 2.2.5 the LCD is fine, when installing 2.2.6 and then using the same LCDPROC the funky characters appear.

Ideally, if something can't get working within some reasonable timeout, it should fail with a clear message.

Removed the patch, upgraded to 2.2.6, did the patch again (with the updated url for 2.2.6) and everything still works.

@bluepr0: Interesting! It will be helpful for a newbie like me. Thanks a lot for sharing! I hope that helps beginners friends :)