Homelab Rebuild Part 3: Sliding the Firewall In

The awkward part Link to heading

The hardware from part 2 was sitting on the desk. The network kept running. And that’s exactly the uncomfortable spot: the uplink isn’t my hobby project, it’s the way to the internet. If I break it, it’s broken.

So the task wasn’t “set up OPNsense”, it was “set up OPNsense without hours of downtime in between”.

Prepare before it counts Link to heading

The first step had nothing to do with the network: the firewall got assembled in my room, hooked up to the workstation, and fully configured. LAN on 10.0.1.1, DHCP set up, base rules in place, everything clicked through.

Sounds trivial, but it’s the actual trick. When the box finally went onto the line, the rest was a matter of minutes — instead of an hour of first-time setup with a dead uplink behind me.

While I was at it, I moved to 10.0.1.0/24 rather than staying on 192.168.1.0/24. Not because one is better, but because I wanted multiple networks later and 10.0.<VLAN>.0/24 numbers cleanly. VLAN 30 becomes 10.0.30.0/24, VLAN 41 becomes 10.0.41.0/24. When I see an address, I know immediately where it belongs.

The MAC trap Link to heading

One detail I knew about in advance, and which would easily have cost me an evening: my provider remembers the MAC address on the line. Plug in a device with a different one and in the worst case it takes hours before you get an address again.

So I set the R4’s MAC on the OPNsense WAN interface. From the other side’s point of view, nothing had changed at all.

This is the kind of problem you can’t debug while it’s happening — you can only wait it out. So check how your own provider handles this beforehand.

The switchover: double NAT as a bridge Link to heading

Now the actual move. The obvious approach would have been to rebuild the R4 completely and then wire everything together. That would have meant both devices in an unfinished state at the same time.

Instead I took an intermediate step:

• Fibre out of the R4, into the OPNsense (the SFP module simply moved over)
• OPNsense to the R4 over the DAC cable
• The R4 stayed a router, unchanged — it just got an address from the new network on its WAN port, 10.0.1.2
• Behind it, everything carried on in 192.168.1.x as before

That’s double NAT, and normally you don’t want it: two translations in series, inbound connections get complicated, troubleshooting gets murky.

As a transitional state it’s exactly right. Twenty minutes later I was back online, every device in the flat kept working unchanged, and from that point on I had a functioning firewall I could work on at my own pace. The WAN link came up over DHCP on the first try, incidentally, once the SFP module had moved.

From there it stopped being one big rebuild and became a lot of small steps: routing off the R4, DHCP off the R4, DNS off the R4 — handed over to the OPNsense piece by piece. After each step I could check whether things still worked. And if they didn’t, I knew exactly which step it was.

What went wrong: the VLAN MAC Link to heading

And then came the VLAN.

I’d set up a static DHCP reservation on the OPNsense for the R4: this MAC gets 10.0.1.2. Neat, the way you’re supposed to.

Then I started setting up VLANs. And afterwards I couldn’t reach the R4. Not over SSH, not over LuCI, not at all. My assumption: I’d wrecked the config.

I hadn’t. A VLAN interface gets its own MAC address. So the R4 was no longer announcing itself with the MAC my reservation was tied to, but with a new one — and got a completely different address out of the DHCP pool. The device had been reachable the whole time. Just not where I was looking.

That cost me two SD card reinstalls that day before I understood what was happening.

The lesson is unspectacular, but it’s saved me a lot since: when a device disappears after a network change, the first place to look isn’t the device’s config, it’s the firewall’s DHCP leases. If it’s sitting there with a new address, nothing is broken — it just moved.

And static reservations hang off MAC addresses. Anything that creates a new MAC — VLANs, bridges, virtual interfaces — breaks them.

The safety net Link to heading

After the second reflash I got into the habit of laying down a way back before every network change on the R4. A timer saves the running config, waits 90 seconds, and restores it unless I cancel first:

cp /etc/config/network /etc/config/network.failsafe
setsid sh -c 'sleep 90; cp /etc/config/network.failsafe /etc/config/network; /etc/init.d/network restart' >/dev/null 2>&1 </dev/null &

Then make the change and test. If it works, kill the timer:

pkill -f "sleep 90"

If it doesn’t, you do nothing — ninety seconds later the old state is back.

Two details that cost me time: disown doesn’t exist in OpenWrt’s BusyBox shell, and you don’t need it — setsid is enough. And if you rebuild this on an OPNsense, watch out: the root shell there is csh, not bash. Constructs like 2>/dev/null before a pipe behave differently and get you “Ambiguous output redirect”. Either use csh syntax or put a bash -c '...' in front.

On top of that, the R4 has had its own recovery interface ever since, on an otherwise unused port, with a fixed address and independent of the bridge. That never gets touched, not even “just quickly”. That’s the whole point of it.

Afterwards: the IPTV problem Link to heading

The network had barely settled when I noticed the TV had stopped working. My provider delivers its TV service over multicast, and multicast doesn’t just cross a firewall.

The fix comes in two parts. On the OPNsense, an IGMP proxy handles joining the multicast groups and passes the stream into the internal network. On the R4, udpxy turns that into HTTP unicast — which I need because Wi-Fi devices are supposed to receive the stream too, and multicast over Wi-Fi is an unpleasant business.

The bug that held me up longest sat in an unremarkable spot: the IGMP proxy’s upstream configuration has an “Allowed Subnets” field that defaults to 0.0.0.0/32. Nothing gets through with that. It wants the network the provider sends its streams from.

Where things stand Link to heading

The OPNsense routes, the R4 is a switch and access point, the double NAT is history. TV works, telephony works, and for the first time there’s a place in the network where I can actually enforce rules.

What’s still missing is all the interesting parts: the VLANs, the automatic assignment, the internal CA. But those need somewhere for services to run first — which is what the next part is about.

Part of a series about rebuilding my home network. As of August 2026. Questions, corrections and your own experiences are welcome in the comments.