Home Lab
A Desktop Lab
Home Grown Router, Part I
Part I of a three part series on building my bespoke network router.
In my Introduction, I laid out the requirements for the edge router I’m building for my home network. It must run all of the services my current router provides, go faster, be serviceable, and allow for future experimentation. In the end, I specified the hardware (Protectli SFF) and software (Proxmox and FreeBSD) that I’d be using.
This article explores setting up a Desktop Lab for prototyping the router. The lab includes the new computer with Proxmox and FreeBSD VMs, a Raspberry Pi as a console terminal, a cellular data modem and a Wireguard app for VPN access. With the lab, I can prototype various configurations and experiment with features required for the final router. The Raspberry Pi serves two purposes: (1) a console terminal into the Protectli via USB—no matter what happens to the network or VMs, I can get into Proxmox through that, and (2) a backdoor (second route) into my network through a cellular modem and a VPN. The backdoor will come in handy if I bork my main router as I now have another path into my network. During prototyping and production, I have to be able to service the network devices while off site.
Machine Setup
Unboxing the Protectli Vault went almost perfectly. One challenge I had was connecting to its console port. We have an all Apple hardware household and the USB to console port cable won’t take connections from Apple hardware. We e-cycled all of our old computer equipment long ago including HDMI screens. I grabbed an unused Raspberry Pi, formatted its SD Card with FreeBSD, tricked the Pi into speaking to my MacBook Pro over ethernet, and then consoled in from the Pi. Keep in mind, this was all to get into the console on the Vault.
After I connected through to the Vault’s console, BIOS setup and Proxmox install from a USB drive was a piece of cake. I made sure to create random complex passwords for the BIOS admin and user accounts and the Proxmox root account knowing I’d probably fail to do it later. A lot of people purchase Protectli Vaults to run Proxmox, so Protectli posted helpful instructions with the steps required to do the installation.
With Proxmox running, I wired my MacBook to one of the Vault’s ethernet ports, brought up a browser, and followed the initial Proxmox configuration steps. After configuration, I navigated to the local storage screen where I found the ISO Images panel and downloaded a stable version of FreeBSD. Proxmox let me enter the Checksum for the downloaded ISOs as a safety and a security check.
Using the FreeBSD ISO I created a new VM running FreeBSD OS and went through that set up process. With a configured instance of FreeBSD running, I took one last step and made a Template out of it. If you examine the above image, you can see I have three templates. That’s because it took me three tries to get the template I liked. I left the others there just because. You can also see there are five VMs running and two shutdown. Between templates and VM cloning, Virtual Machine creation is like eating popcorn—you can have as much as you want.
Redundant Access
Experiment enough with network equipment and you quickly realize you need multiple pathways into it, especially while you’re learning. When working remotely, multiple pathways are even more critical.
Although I had a trip scheduled in the midst of this, I didn’t want to lose a couple of weeks working on the system. More importantly, once the router is operational redundant remote access via a VPN is critical. To address this, I settled on the following: (1) a Raspberry Pi connected to the Protectli’s console port, (2) a new to me 10-port 1Gbps managed switch (VLANs!), (3) a cellular data modem I had been meaning to use for redundant backup but hadn’t got around to it yet, (4) a couple of VMs (Stargate 1 and Stargate 2) running FreeBSD with default routes to my main router and the cellular modem, respectively, (5) a NAS with VPN support, (6) for VPN, Wireguard on the Pi, the two Stargate VMs, and the NAS. The wire diagram at the top of this article contains this structure.
These virtual and real machines each have multiple static addresses for various VLANs. For example, Stargate 1 has static addresses for five VLANs: (1) Engineering 10.3.25.6/24, (2) local to Switch-3 172.20.50.6/24, (3) for cellular modem (to WAN2) 192.168.90.6/24, (4) for simulated cable modem (to WAN1) 10.4.200.6/24, (5) internal to Proxmox 172.20.55.6/24.
The Raspberry Pi has four of these address which all end in .8 instead of .6. Making all of the devices static and each device have their own low # (.6 vs .8) means I can memorize VLAN prefixes and device IDs and then combine them when I want to ssh into them. The Pi doesn’t have a fifth address because that last one in Stargate 1 is internal to and only reachable by PVE and the VMs.
The day before I left, I had a chance to test remoting into this set up. Earlier in the day I had played around with my main firewall configuration and wanted to reset it to the last known good configuration. During the reset, the internet would be down. My wife was still using the network. Rather than wait around, I headed out for some errands and once she left the house, used my phone to connect through the cellular modem via Wireguard (backdoor), rebooted the main firewall (frontdoor) and checked that I still had internal network connectivity via the VPN. I did. Test passed!
While traveling, I have VPNed into my home network, managed a few ongoing jobs (new NAS backups) and retested the connections between all the various devices in the desktop lab.
Final Prototype Configuration
I left before I had a chance to setup the virtual network hardware for the VMs containing the router and DNS/DHCP. Using the VPN I completed those configurations the other night. Now, in Proxmox I have four VMs (router, dnsmasq, two landing pads). Next up, I’ll configure the dnsmasq VM to handle DHCP and DNS. Understand, this is prototyping and probably won’t be the final production configuration.
Soon—Part II: dnsmasq in FreeBSD to serve DHCP addresses and DNS.
