Table of contents

Getting Started

I had to set up PXE booting in my home lab to ease the burden of adding new metals. My existing Ignite WiFi Gateway (Gen 3) from Rogers doesn’t support PXE booting, so it was clear I needed to find a routing solution that did. I had run into reasons to switch in the past, but I delayed making the switch until I reached a roadblock. This was just one of many issues I had encountered with the router, including no option to disable DHCP, no custom DNS, etc. However, this was the tiebreaker.

Choosing a Router + Firewall

Fast-forward a couple of days later, I settled for OPNsense. I deliberated running within a VM or bare metal. Finally, I settled for the latter primarily because this is a critical piece of my network. I wanted to perform independent upgrades for it without thinking of other services that might be sharing the underlying hardware.

I got a Protectli Vault FW4B, a 4-Port Mini PC with an Intel Quad Core, 8GB RAM, and a 120GB mSATA SSD from eBay for $214. I settled for the following setup:

Stripped-down topology of the network. Devices within the network have intentionally been excluded.

Stripped-down topology of the network. Devices within the network have intentionally been excluded.

Re-using Ignite WiFi Gateway

Although the Ignite router no longer met my routing capability needs, it did have a good WiFi range that was well-suited to my apartment's layout, so I wanted to stick with it instead of getting something else.

Sadly, the Ignite Wifi gateway is known to only work well with other routers if you run them in bridge mode. Running in bridge mode for this router model disables the router's wireless capabilities, which I didn’t want. I did lots of digging around on the Rogers community forum but didn’t find much. I eventually got things working, but not after a couple of roadblocks, which I tried documenting below:

Preserving IPs

<aside> <img src="/icons/light-bulb_yellow.svg" alt="/icons/light-bulb_yellow.svg" width="40px" /> The configurations below can also be performed via shell.

</aside>

Before making these changes, devices and metals within my network were all within the 10.0.0.1/24 subnet. I still wanted to maintain these since there was already automation in place, which I didn’t want to break or need to modify. However, OPN sense, by default, issues DHCP assignments within the 192.168.0.1/24 subnet.

The first step was configuring the LAN and DHCP assignment to the 10.0.0.1/24 subnet (see screenshots below). After making these changes, the admin UI will now be accessible via 10.1 (or whatever address you configured as the gateway).

The LAN interface is configured to run within the 10.0/24 subnet, with 10.1 as the gateway.

The LAN interface is configured to run within the 10.0/24 subnet, with 10.1 as the gateway.

DHCP assignment configuration

DHCP assignment configuration