I would ditto what everyone else is saying. Using a router on a stick should work out pretty good assuming you have a managed gigabit switch laying around. I also have Fios and put my PfSense in the DMZ of the Fios provided router and everything seems to work well (Site to site vpn's, xbox live, plex, …) and I never have to touch the Fios router. I also turned the Wi-Fi off on the Verizon router and use Ubiquiti AP's works well.

I figured out how to get this to update…. 1. I changed the branch to "Legacy stable version (Security/Errata only 2.3.x)"     The web GUI could then detect updates.  However updating via the web GUI did not work. 2. I logged in via SSA and got the console menu.  I tried an update via the console menu (option 13     in my case).  This worked! *** Welcome to pfSense 2.3.4-RELEASE-p1 (amd64 full-install) on fw1 *** WAN (wan)      -> igb0      -> v4: nnn.nnn.nnn.nnn/nn LAN (lan)      -> igb1      -> v4: xxx.xxx.xxx.xxx/xx 0) Logout (SSH only)                  9) pfTop 1) Assign Interfaces                10) Filter Logs 2) Set interface(s) IP address      11) Restart webConfigurator 3) Reset webConfigurator password    12) PHP shell + pfSense tools 4) Reset to factory defaults        13) Update from console 5) Reboot system                    14) Disable Secure Shell (sshd) 6) Halt system                      15) Restore recent configuration 7) Ping host                        16) Restart PHP-FPM 8) Shell Enter an option: 13 >>> Updating repositories metadata... Updating pfSense-core repository catalogue... pfSense-core repository is up to date. Updating pfSense repository catalogue... pfSense repository is up to date. All repositories are up to date. >>> Unlocking package pfSense-kernel-pfSense... done. The following 80 package(s) will be affected (of 0 checked): New packages to be INSTALLED:         python2: 2_3 [pfSense]         readline: 7.0.3 [pfSense]         oniguruma6: 6.4.0 [pfSense]         pecl-rrd1: 1.1.3 [pfSense]   .   .   . Number of packages to be upgraded: 2 [1/2] Upgrading pfSense-rc from 2.3.4_1 to 2.3.5_1... [1/2] Extracting pfSense-rc-2.3.5_1: .... done [2/2] Upgrading pfSense-kernel-pfSense from 2.3.4_1 to 2.3.5_1... [2/2] Extracting pfSense-kernel-pfSense-2.3.5_1: .......... done ===> Keeping a copy of current kernel in /boot/kernel.old Upgrade is complete.  Rebooting in 10 seconds. >>> Locking package pfSense-kernel-pfSense... done. Still not sure why updates via the GUI don't work, but at least the system updated.  We're now at 2.3.5-RELEASE-p1.  ??Updates via the console from now on??

I was thinking MAC address. :)

I too got the dreaded “System update failed!” message back when I tried upgrading one of my pfSense 2.3.4 boxes to 2.4.0, and I got it again today when I tried upgrading another 2.3.4 box to 2.4.2. I'm really surprised it still has this problem in 2.4.2, and even more surprised that none of the pfSense upgrade documentation mentions this problem. Here's what I had to do both times: SSH into your pfSense machine and run the following three commands as root: pkg-static install -f pkg mv /usr/local/etc/pkg.conf /usr/local/etc/pkg.conf.old pfSense-upgrade -d Detail: When you run “pkg-static install -f pkg” you’ll see the following: Updating pfSense-core repository catalogue… pfSense-core repository is up to date. Updating pfSense repository catalogue... pfSense repository is up to date. All repositories are up to date. Checking integrity... done (0 conflicting) The following 1 package(s) will be affected (of 0 checked): Installed packages to be REINSTALLED: pkg-1.10.1_1 [pfSense] Number of packages to be reinstalled: 1 After you select “y” and it upgrades the “pkg” package it will tell you the following: You may need to manually remove /usr/local/etc/pkg.conf if it is no longer needed. Instead, I renamed it to pkg.conf.old, just in case. After you run “pfSense-upgrade -d” to complete the upgrade it will automatically reboot. The reboot will take longer than normal because it will continue upgrading packages after it boots. Eventually, though, the Web interface will load again and you'll see the new Web GUI design. Hope that helps someone. –Dan

What is your host's IP address? What kind of networking did you use for the VM? e.g. NAT or bridged etc Do you have any VLANs setup? Why are you using /29 for your LAN and not just plain /24?

Ok so not everything…. but I am obligated to post and update. There was still some issues to be worked out: I redid pfsense from scratch again this time to a 10.1.1.0/24 subnet Testing  direct to pc from pfsense works I go live and change over all those manual IPs. I note that some devices could get dhcp, while others could and the usual reset ip and reboot devices still wont work, even updated LAN drivers. At some point I decide to reset the Netgear managed switch (GS724T v2)- all of a sudden the down devices all got IP addresses . WTAF?? It would appear that the secondary culprit was the switch. So subtly messing with dhcp messages between pfsense and my PC! At least this is my home lab and not some live work environment. I'd be out of a job by now.

I would be on-site for that then.

pfsense 2.4.2p1 with ZFS on Hyper-v starts without any error after powerloss. Continue testing…

" currently populated by a double-wide video card" Router doesn't even need a video card ;)

Ah, OK so the two networks will be isolated in VMWare? That should be possible. You will be double NATing though pfSense I imagine unless you have multiple public IPs from your provider. What is not working? Steve

Devices like the SG-1000 without 'console' => not for me. Btw : I'm wrong, the 'doc' says all you need is a USB key …. https://www.netgate.com/docs/pfsense/sg-1000/reinstall-pfsense.html

See also : https://forum.pfsense.org/index.php?topic=141404.msg772258#msg772258 As always : Don't use the yellow port. Give it a static IP - point it's gateway to pfSEnse LAN Stop DHCP. If possible, set it to AP only mode. Done.

I am definitely avoiding any of the Cxxxx CPU's now when I am doing hardware selection.  If this same bug happened on Intel's server or desktop CPU's, yes it will definitely be a big deal.  Just look at AMD's ryzen issue, and that only effected very edge cases. I wonder if I actually received the same hardware as what I sent in. On one of my other SG-2440 replacements, I got someone else's system w/ a different serial # and config. Granted that system had no functional issues after a config reset.  May be it was luck to have gotten someone else's box??

@internetservices: Solution: disable 'Monitor M-Wait' in bios Could be under Features tab > CPU Configuration I cant seem to find this feature in my bios http://asrock.com/mb/Intel/J3455-ITX/ Any suggestions?

Are you able to press the key during that count time and perform a run recovery? You will need the sg-3100 arm firmware found at the gold member`s page and a pendrive. You can find the procedure to perform this recovery at: https://www.netgate.com/docs Hope it helps you. Edit: You will have to configure everything again if you do the procedure above ok? All configuration will be lost !!

Ive got several boxes that are working fine..  Try pressing your F-5 key..