So no output on either console? The fans remain off? Generally with a failure to POST like that I would start removing hardware and retesting. So remove the expansion NIC. Remove all but one stick of RAM. Try a different RAM stick.

@stephenw10 Agreed on both counts. The M370 doesn't have an opening in the front of the case for the expansion board. Nor does is have an intermediary board that connects the system board to the expansion board (on a more senior model, it would go into the space outlined in red in the image below): [image: 1772754457566-27c9a86f-4304-4305-a13a-ccbd7eb24e24-m370no.jpg] And yes, the M270 is completely different. Has an embedded processor, and all networking is tied up into some proprietary built-in switch.

@belajasmert said in Netgate 4200 freeze and a possible fix: Switch now in place and as expected the system & DNS resolver logs are really quiet This - the LAN interface events : 19:59:13 DOWN 19:59:19 UP 20:01:20 DOWN 20:01:22 UP 20:01:31 DOWN 20:01:34 UP will also trigger other events, like the restart (!) of processes that use this (LAN) interface : The pfSense WebGUI, (nginx), the resolver (unbound), you found that one already, and more, check the main system log for what happens when an interface goes down and up. The solution : you've found it : use a switch. And you can do even better : the upstream WAN device, an ISP router or modem, pfSense itself, and the downstream LAN switch(es), as these are normally all close to each other, hook them up to the same power strip, and use an UPS.

It cannot on those CPUs. It's a limitation of the SoC as noted by Intel: https://docs.netgate.com/pfsense/en/latest/solutions/netgate-6100/io-ports.html#sfp-ethernet-ports If the module defaults to the required rate it can work which is why some module do even though we don't officially support it. I assume you're trying to have it link at 1G and it's failing to link at 10G?

I wanted to see if I could perform the pfSense installation and the initial boot using just the Realtek 2.5G NICs rather than a USB adapter for the installation and installing the driver package post-install. TL;DR I was able to accomplish this goal! This may help others who are attempting to restore a previous configuration during installation and/or migrating from another device. Attempting to load the previous realtek-re-kmod198 package I created originally didn't work because Netgate Installer v1.1.1 is using FreeBSD 16.0-CURRENT. This meant I needed to build the driver package again for this kernel. Having simplified the instructions in my previous post for realtek-rge-kmod this wasn't too bad, just took some time to execute. I swapped the virtual disk in my FreeBSD 15 VM with the latest FreeBSD 16.0-CURRENT VM image and then proceeded to go through the same steps. The operations differ in the following ways. The git commit used for the FreeBSD-src repo was ba25d53d, which has FreeBSD version 1600004, matching the version used by the installer. This is the commit like last time right before a merge updating to a newer FreeBSD version. The git commit used for the FreeBSD-ports repo was 5a17605e, which is a little after Dec 9th, when the installer kernel was built, and before a merge that updates pkg to a version greater than 2.4.2 (the version used by the installer). I didn't checkout the net/realtek-rge-kmod ports directory this time of course since I wasn't intending to build that package, but you could if you wanted. The Make command to build the driver package is make package OSVERSION=1600004, matching the installer FreeBSD version. Now that you have the necessary packages, here are the steps to use the packages during the pfSense installation. The Netgate installer USB image has an additional ~64MB FAT32 partition to store your previous config.xml file for restoring during the installation. We're going to copy the packages realtek-re-kmod198-198.00.1500029.pkg and realtek-re-kmod198-198.00.1600004.pkg to this partition and extract the later to the directory realtek-re-kmod198-198.00.1600004 within that partition. We won't be installing the package during installation so we'll need to be able to load the kernel module directly. When the installer appears the dialog will show that it failed and give you the option to "Retry". Select this option and when it fails again "Exit" the installer. Use the following commands to load the correct if_re.ko kernel module and kickstart the installer again. Replace X with your drive number, which was 0 in my case. (Ensure you're loading the module from the 1600004 package).mount_msdosfs /dev/daXs3 /mnt kldload /mnt/realtek-re-kmod198-198.00.1600004/boot/modules/if_re.ko umount /mnt echo start > /var/run/installer.daemon exit Proceed with the installation as usual. The network connection was a bit flaky, so I had to repeat some steps once or twice. Not sure if this was related to the NIC/driver within the installer environment or my network in general being a bit flaky at the time. When the installation is finished, exit to the "Shell". Use the following commands to install the realtek-re-kmod198 package within the new installation so the Realtek NICs will be available on first boot. (Make sure to install the 1500029 package).mount -t devfs devfs /mnt/dev mount_msdosfs /dev/daXs3 /mnt/mnt chroot /mnt pkg install --no-repo-update /mnt/realtek-re-kmod198-198.00.1500029.pkg echo 'if_re_load="YES"' >> /boot/loader.conf.local exit exit When pfSense boots for the first time the Realtek interfaces should come up as normal like it would if the NIC was supported out of the box.

Yup I'd be amazed if it was anything but soemthing worn and/or blocked in the cooling system.

Hmm, I'm not aware of that specifically. Only that the modules will generally run at their 'native speeds only because the rate cannot be set. For most dual speed modules that means 10G but some will select 1G and run fine. The actual restriction as noted by Intel is shown here: https://docs.netgate.com/pfsense/en/latest/solutions/netgate-6100/io-ports.html#sfp-ethernet-ports

In answering my own question, I discovered that the continuous # symbols was not a rebuild and so I restarted and checked the bios. I changed from Legacy/UEFI to UEFI and the system restarted without a hitch! A+ pfSense!!!

For future readers: problem solved. For more information, see this post: https://forum.netgate.com/topic/200073/verification-needed-disabling-bypasses-on-cloudgenix-ion-3000/5

OK, complete and total replication. Ran the routine on two more ION 3000 devices, verified the disablement of bypasses by bridging all eight ports on the expansion board into a single network, connecting multiple devices to those ports, and accessing one device from another, including making the remotely accessed device access the Internet. Found a small refinement: you can actually install pfSense on the device (no need to resort to installing on another device), as long as you remember to use the right settings. Anyway, here's the refined procedure: One. Turn off the device (completely, as in, disconnect the power cable) and open up the case (there are four screws holding the top in place, one on each side and two in the back; once you remove the screws, the top slides off). Two. Disconnect the SATA SSD and remove the CF card. Three. Reposition a jumper on the expansion board and do some OpenWrt magic. For details on this step, see my post on the OpenWrt forum: https://forum.openwrt.org/t/report-openwrt-on-cloudgenix-ion-3000/246014 Briefly, you prepare a bootable device with OpenWrt (I used a CF card, but there's no reason you can't use a USB stick), boot the device from it, install three additional packages, make a slight edit to /boot/grub/grub.cfg to configure the disablement of bypasses, reboot the device (which should disable the bypasses), let the boot sequence run, then shut the device down. Four. Remove OpenWrt media, reconnect the SATA SSD, connect a USB stick with pfSense installer, and install pfSense. Remember the settings: UFS file system, entire drive, MS-DOS partitions (the layout suggested by the installer should work). Once the install is complete, shut the device down, disconnect the installer media, and boot the device. It should boot from the SSD, and bypasses should be disabled, so you can assign interfaces and as usual. Remember, the port map is weird: = Expansion board = ====== Onboard controllers ====== igb6 igb7 igb8 igb9 igb10 igb11 igb12 igb13 igb0 igb1 igb2 igb3 igb4 igb5 so by default, the rightmost onboard port (igb1) will be LAN and the one to the left of it (igb0), WAN. Five. To get the little LCD screen working, install lcdproc and configure it to use parallel port (/dev/lpt0) with 2x20 screen size and the Watchguard Firebox with SDEC driver.

@stephenw10 Thanks again. I just need it to install pfsense. I will be using a HDMI computer monitor. Then the webgui will take over.

@stephenw10 Thank you...that worked. [image: 1770652615230-e81450eb-1851-4a69-9496-5861e970441e-image.png]

@stephenw10 said in Watchguard Firebox M400/M500: We should move this to the other thread I think it's a good idea. The expansion module recommendations I made are relevant to M470 / M570 / M670, but not to M400 / M500.

@stephenw10 Whoops! Should be Xeon E-2174G (4c/8t 3.8/4.7GHz)

@stephenw10 It could be a combination of a bad patch cable AND a faulty igc3 port on the 6100. After swapping cables and ports, igc0 sees the LAN and igc1 sees the ISP/WAN. However, switching the working cable from icg1 to igc3, no link is detected. @patient0 my WAN connection is pure DHCP. I'll open a ticket with Netgate. Thanks, Tim

@Waqar.UK the X550 is supported well, yes.

It would need to include something additionally there. The NVM firmware is not part of the BIOS. It does look like there is a utility that will run in FreeBSD that can update it though.

Nice.

@stephenw10 - This is nice. Thank you very much. We will do the upgrade tonight.