Thanks!  Before we go back, we'll tripple check the changes made for the tunning parameters.  But litterally the only thing that changed was the update from 2.2.3 to 2.2.4.  All the servers are directly connected to the firewall - there are no switches, no OS or driver changes were made to the servers on either side.  It's very odd.  And I did confirm that all test results were with a 1500 byte MTU.  There is no traffic going through this firewall that could vary - it is simply a test platform with connections to two servers out two Chelsio NIC's, so there is no way the "base" level of traffic varried between the tests. AS soon as we double check and can test I'll post again.

I just was saying that I wasn't on ram or nano That I have disk space My 2 pfsenses are not in those cases

@pete: I couldn't wait so updated again.  Update worked fine and all is well again. 2.2.4-RELEASE (amd64) built on Sat Jul 25 19:57:37 CDT 2015 FreeBSD 10.1-RELEASE-p15 Good to hear that… ;)

I made a dumb typo url_port should be url_ports https://github.com/pfsense/pfsense/pull/1794

@nfw I recently bought new hardware (64bit) and when attempted to install pfsense on it i had EXACTLY the same issues you did (bootloop). I tried to troubleshoot it the same way you did but no luck. NanoBSD on a CF card would boot fine but had other issues like not being able to run snort or suricata  and…! Frustrated and a little sad for my misfortune i decided to use it as an extra GNU/Linux-desktop for experimenting. It served well that purpose until this noon when i decided to give the 2.2.4 a go! BINGO!!! installed just fine and is now my new pfs-box! I did Uncheck the 'packet mode' box during bootblock installation but i don't know if that was necessary. I didn't bother reinstalling just to check it. SATA SSD 60gb full partition from Muskin. I am planning to make a new thread about the hardware i used. Very... VERY... Happy with the result Regards!

Dude. You have a corrupt filesystem with missing/screwed /etc/group. Stop "fixing" permissions, do a clean 2.2.4 install and restore config.

Just means you don't have any IPsec config when it's doing the config upgrade. I added a check to skip that part where you don't have IPsec configured, to prevent the noise in that case in future releases. Doesn't hurt anything.

There's a good chance the HAVP package could have filled /tmp there. That's normally only applied in embedded (Nano) installs where running HAVP is not recomended. Increase the size of /tmp if that's the case. Steve

It's your code "hardcoding" it when you select something from dropdown. How's that user-induced?! Users assume the GUI exists for a reason, and have a need to check the settings! Stupidity illustrated: Step 0: [image: gJwcXKB.png] $ grep firmwareurl /cf/conf/config.xml                                 <firmwareurl>https://updates.pfsense.org/_updaters/amd64</firmwareurl> Step 1: Uncheck, Save, as advised above: [image: tqVIDuR.png] $ grep firmwareurl /cf/conf/config.xml $ Good that we spared one line in config.xml! To make it more helpful, there's nothing useful visible in the GUI either. ::) Step 2: Select the (recommended) "Current architecture", watch the "Use an unofficial server for firmware upgrades" getting automagically ticked. Click Save. [image: 5TtKj3o.png] $ grep firmwareurl /cf/conf/config.xml                                 <firmwareurl>https://updates.pfsense.org/_updaters/amd64</firmwareurl> Result: We are back to Step 0. Wash, rinse, repeat.  >:( >:( >:( Bonus: I also see this note there: NOTE: When a custom URL is configured, the system will not verify the image has an official digital signature but cannot see that coded anywhere. Sigh. Tell people what they have set (even by default) in the GUI. Instead of leaving it blank – and leaving the config.xml blank as well.

New option "any" added for peer ID, and config upgrade code added so EAP types have their peer ID changed so it continues to match previous behavior. Rebuilding 2.2.4-RELEASE with that change. You can gitsync RELENG_2_2 now to fix that on your system.

Can you browse this? http://www.msftncsi.com/ncsi.txt What's the output of this? drill dns.msftncsi.com Otherwise, kindly describe "limited connection".

LAN GW: 10.0.0.254 Should not exist.

Waste of time. Use the latest 2.2.4 snapshots; sync mounts with slow drives -> disaster.

Hey thanks for that, i think i will do a re-image of the card when i get chance, as a temp solution i created the dir and scp'd the font over from another pfsense box. Seems to be working at the moment. But as the directory structure wasnt created initially it looks like i may have a semi broken box so i think i definitely need to rebuild.

64 Bit LiveCD Installer ran fine (2.2.3)