CloudGenix ION 3000 (also marketed as Palo Alto ION 3000) is an SD-WAN router:
It is also a rebranded Lanner FW-7573 with a locked BIOS and a set of bypasses: there are two pairs on the system board and four pairs on the Lanner NCS2-IGM806A expansion board. (Incidentally, a bypass-free version of the expansion board exists; the model number is NCS2-IGM806B, and it is a drop-in replacement for the NCS2-IGM806A. I have made this replacement in the past, and it has worked like a charm.) Lately, these devices began to appear on eBay at ridiculous prices, so I snagged one for an all-in cost of USD 48.
The device runs on an embedded Intel Atom C2758 processor (eight cores, 2.40 GHz) with 8 GB RAM and a 240 GB SATA SSD. There’s also a CF card holder, which I really wanted to use for this experiment (in the factory setup, there’s a 16 GB CF card in it, but I wanted to use a much smaller 1 GB card just to see what happens). There are six Ethernet controllers on the system board (four Intel i354 and two Intel i210) and eight on the expansion board (all eight are Intel i350).
Here’s a streamlined version of what I did and what you can do now that I’ve retraced my steps enough times. 
First, download the squashfs (non-EFI) version of OpenWrt and expand the image onto a CF card using the software of your choice (I used Rufus on a Windows machine).
Next, with the device powered off completely (meaning, with the power cable physically disconnected), remove the screws holding the top cover in place (two screws in the back and one on each side for a total of four), and the top cover should be able to slide off, exposing the internals. Disconnect two cables (data and power) connecting the SSD to the system board (the SSD is located in a holder in the front left corner of the device). If you intend to remove the SSD from the device, you can do so now or later.
Next, locate and reposition a jumper on the expansion board as shown below:
The expansion board is located on the right of the device. If you are in front of the device, the jumper in its factory position connects two pins that are closest to you. Reposition the jumper so that it connects two pins that are farthest from you. Said another way, move the jumper from the 1-2 position into the 2-3 position.
Now you can install the CF card into its holder (it is located in the front of the device, next to the SSD holder), close the lid, connect the power cable, and turn the device on.
The order of port detection should be as follows:
=== Expansion board ===
==== Onboard controllers ==== eth10 eth11 eth12 eth13
eth0 eth1 eth2 eth3 eth4 eth5 eth6 eth7 eth8 eth9
Generally, at this point, the onboard bypasses should be disabled, so you should be able to use the device in its default mode (eth0 is LAN, eth1 is WAN). However, if you find this is not the case, connect to the device using the console (115200 bps) and edit /etc/config/network to use eth4 and eth5 as LAN and WAN in a combination of your choice (those two controllers do not have bypasses on them). After you edit the configuration file, run service network restart or simply reboot the device to make the new settings active.
Next, we are going to disable the bypasses, all of them. The ION 3000 has third-generation bypasses, which are controlled from software. So let’s get that software:
opkg update && opkg install kmod-i2c-i801 kmod-i2c-smbus kmod-itco-wdt
To disable the bypasses, we will need to add a line to /boot/grub/grub.cfg:
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 --rtscts=off
terminal_input console serial; terminal_output console serial
set default="0"
set timeout="5"
set root='(hd0,msdos1)'
set nmi_watchdog=0 # <-- This is the added line
menuentry "OpenWrt" {
linux /boot/vmlinuz root=/dev/sda2 rootwait console=tty1 console=ttyS0,115200n8 noinitrd
}
menuentry "OpenWrt (failsafe)" {
linux /boot/vmlinuz failsafe=true root=/dev/sda2 rootwait console=tty1 console=ttyS0,115200n8 noinitrd
}
Now, while you’re still configuring grub, you can edit the root option in each menuentry as shown above (by default, root is set to the root partition’s UUID).
Once you save /boot/grub/grub.cfg, you want to make sure it persists across upgrades. To do that, open /etc/sysupgrade.conf and add this line to the end of it:
/boot/grub/grub.cfg
These two little hacks working together will help make sure that (a) bypasses remain disabled, (b) disablement persists across upgrades, and (c) if root partition’s UUID changes for any reason, the device can still boot.
The next part is entirely optional, but I wanted to try it. The CF card I used for this experiment had the capacity of 1 GB, which, conveniently, is the maximum size of OpenWrt image you can get from the default build server. So I decided to expand the root partition to 800 MB (I could probably do a little more, but I decided to go with a number that’s both round and a multiple of 8):
opkg update && opkg install owut luci-app-attendedsysupgrade
uci set attendedsysupgrade.owut=owut
uci set attendedsysupgrade.owut.rootfs_size=800
uci commit
owut upgrade --force
These commands instructed the device to go online and request a new firmware with the root partition size of 800 MB. After the firmware was built, the device installed it and rebooted.
Why not 1000 or 1024? First, you need to leave room for the boot partition (currently, 16 MB, but it may grow in the future). Second, when the device manufacturer says 1 GB, they often mean one billion bytes.
Here’s the layout of the SD card post-reboot:
root@ION3000:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 789.8M 0 loop /overlay
sda 8:0 0 973.5M 0 disk
├─sda1 8:1 0 16M 0 part /boot
│ /boot
└─sda2 8:2 0 800M 0 part /rom
At this point, all 14 Ethernet ports should be operational.
If you’d rather use a SATA SSD, I believe you would be able to do it just as I did with a CF card. Locked BIOS should not present a problem as long as there is only one storage device on the system. If you do see a problem (the device can’t find a bootable drive), try ext4-based firmware.
The only part that remains problematic is the little LCD screen. It’s on all the time and there’s no output. It should be possible to control it using lcdproc, but for some reason, the version of lcdproc distributed with OpenWrt does not include the applicable driver, sdeclcd. There used to be a workaround for it (someone had a compiled sdeclcd.so available for download), but it doesn’t seem to work anymore (whether this is because that driver was compiled for 32-bit systems or because it is now too old, I don’t know). If anyone has ideas for fixing it, I’m all ears.