Installing PVE: The First Hurdle

Installing PVE itself is relatively straightforward, similar to installing any Linux distribution:

1. Create Installation Media: Download the PVE ISO image. On my Mac, I used Balena Etcher to write the ISO to a USB drive. My first attempt failed – turns out the old USB drive I grabbed was faulty. A newer drive worked perfectly.
2. Boot from USB: Connect a monitor and keyboard to the N100 box, plug in the USB drive, and boot into the BIOS/UEFI settings (usually by pressing DEL or F2 during startup). Set the USB drive as the primary boot device.
3. PVE Installer: Follow the graphical installer prompts. Key settings during installation:
   • Target Hard Disk: Select the Fanxiang NVMe SSD.
   • Location/Timezone: Set appropriately.
   • Hostname: Set to something memorable, like pve.local.
   • Network Configuration: Crucially, assign a static IP address for PVE’s management interface (e.g., 10.0.0.2), along with the gateway (10.0.0.1 - my eventual router VM’s address) and DNS servers. I chose one of the four physical ports (e.g., enp1s0) for this initial management access.

The installation completed smoothly, and PVE rebooted. I could access the command line directly on the N100, and more importantly, access the web UI from my Mac at https://10.0.0.2:8006. Stage one complete!

The Networking Nightmare: Reconfiguring for VMs

PVE’s default network setup uses one physical port (enp1s0 in my case) solely for its own management. However, to allow my virtual machines (like the router VM) to connect to both the internet (WAN) and my home network (LAN), I needed to create Linux Bridges.

My plan:

• vmbr0: Use a different physical port (e.g., enp2s0) for the WAN connection (connecting to my ISP modem).
• vmbr1: Use the remaining two physical ports (e.g., enp3s0, enp4s0) bridged together for the LAN connection (connecting to my home switch).
• Crucially: Move PVE’s own management interface from the physical port enp1s0 onto the newly created LAN bridge (vmbr1). This way, I could manage PVE from any computer on my home network using the 10.0.0.2 address, freeing up enp1s0 perhaps for other uses.

This reconfiguration is done by editing the /etc/network/interfaces file directly via the PVE console (or SSH). I carefully modified the file, creating the bridge definitions and changing the management interface settings.

I applied the changes (systemctl restart networking or a reboot). And then… disaster.

I could no longer access the PVE web UI at 10.0.0.2. Pings failed. It seemed I had completely locked myself out.

Troubleshooting in the Dark

Panic set in. Had I made a typo in the config file? Did the bridge fail to come up? I had to go back to the “direct connection” method: plug a monitor and keyboard directly into the N100 box.

Logging into the PVE console, I ran ip a to check the network interface status. The output revealed the problem: vmbr1 (my intended LAN bridge and new management interface) had no IP address. My configuration changes hadn’t been applied correctly, or something had gone wrong during the network restart.

Carefully re-examining /etc/network/interfaces line by line, I eventually spotted the error – perhaps a typo, a missing auto vmbr1, or incorrect bridge port settings. I corrected the file using the nano editor (a bit friendlier than vi for quick edits).

After saving the corrected file and restarting the networking service again (systemctl restart networking), I ran ip a one more time. Success! vmbr1 now showed the correct 10.0.0.2 address.

Back on my Mac, I refreshed https://10.0.0.2:8006, and the Proxmox login screen reappeared. Access restored!

This harrowing experience was my first real taste of configuring Linux networking and the importance of meticulousness when editing critical system files. With the PVE host networking finally stable, I was ready for the main event: creating the virtual machine that would become my new home router.

What is a Soft Router?

Unlike traditional “hard” routers with proprietary hardware and software, a soft router is essentially a small, dedicated PC running a specialized router operating system (like OpenWrt, pfSense, OPNsense, or RouterOS). The “x86” refers to the standard PC processor architecture (Intel/AMD), offering significantly more power and flexibility than the ARM or MIPS chips found in most consumer routers.

The Allure of x86

The potential benefits were immense:

• Raw Performance: Capable of handling gigabit+ speeds with complex firewall rules, VPNs, and traffic shaping without breaking a sweat.
• Flexibility: Run virtually any router OS or even standard Linux distributions.
• Expandability: Add more RAM, faster storage, or even specialized network cards.
• Virtualization: This was the game-changer. An x86 platform could potentially run multiple operating systems simultaneously using a hypervisor like Proxmox VE (PVE). I could have my router, a NAS, a media server, and more, all running on one efficient box.

Choosing the Platform: N5105/J4125 vs. N100

My research focused on popular low-power x86 chips commonly used in mini PCs and soft routers:

• Older Generation (Jasper Lake N5105, Celeron J4125): Widely available, often cheaper, proven platforms. Decent performance for routing and light server tasks.
• New Generation (Alder Lake-N N100): Significant performance uplift (especially single-core, crucial for routing), much better integrated graphics (useful for PVE console/light desktop tasks), generally more power-efficient, supports faster DDR5 RAM. Often comes paired with newer Intel i226-V 2.5GbE network controllers, known for better driver support and stability compared to the sometimes-problematic Realtek chips found in cheaper units.

Given the relatively small price difference for new units and the significant performance and efficiency gains, the Intel N100 quickly became the clear winner for future-proofing.

Navigating the Hardware Maze

Choosing the N100 platform opened up a dizzying array of options, mostly from Chinese manufacturers like Beikong (Topton/Kingnovy), CWWK, etc., often sold as barebones systems (no RAM/SSD). Key considerations:

• Ports: How many? What speed? The standard was 4x 2.5GbE Intel i226-V ports, perfect for high-speed LAN and future ISP upgrades. Some offered 2x 2.5GbE + 2x 10GbE SFP+ (fiber) – tempting, but overkill and more expensive for my current needs.
• Cooling: Passive (fanless) is preferred for silent operation, requiring a well-designed chassis.
• RAM/SSD: DDR5 SO-DIMM and NVMe M.2 slots were standard.
• Price: Barebones N100 boxes with 4x 2.5GbE ports were readily available.
• Used Market: While tempting for cost savings, diagnosing potential issues on used hardware felt risky after my R8000 experience.

My Final Choice: Beikong H30W (N100)

After much comparison, I settled on a brand new Beikong H30W N100 barebones unit featuring:

• Intel N100 Processor
• 4x Intel i226-V 2.5GbE ports
• Passive cooling chassis
• DDR5 SO-DIMM slot
• NVMe M.2 slot

To complete the build with maximum cost-effectiveness:

• RAM: I salvaged a compatible 16GB DDR5 stick from an old laptop – a huge saving!
• SSD: I purchased a new, budget-friendly but well-regarded Fanxiang S500 Pro 256GB NVMe SSD. Plenty of space for PVE and multiple VMs.

The Grand Vision: Virtualization

With the hardware assembled, the real excitement began. This N100 wasn’t just going to be a router. It was going to be the heart of my home lab. The plan: install Proxmox VE (PVE) as the bare-metal hypervisor, then create virtual machines for:

1. OpenWrt/iStoreOS: My primary router, firewall, and network manager.
2. OpenMediaVault (OMV): A NAS for file storage and backups.
3. Future Possibilities: Home Assistant, AdGuard Home, a web server, maybe even AI experiments?

This N100 box represented a convergence of all my needs and aspirations. The hardware was ready. Now came the software challenge: installing and taming the Proxmox hypervisor.