WiFi isn't the problem. It’s portable, easy to set up, minimal physical work. None of that changed. What changed is what I needed of my network. I am building a system that requires a static gateway now, that needs better backhaul and WiFi won’t cut it.
TL;DR: Replaced the WiFi backhaul with a fibre run, same subnet structure underneath, with some tests.
I started on WiFi because it fit the phase I was in. Early on, Tunneld was running behind Zrok to share and access resources, self-hosting my own control plane. It had Mullvad built in as a VPN for the downstream devices, hand crafted DHCPCD + Dnsmasq and dnscrypt-proxy with a Hagezi block list, which was great, but still dodging captive portals to connect to access points where they existed, which isn't as easy on a custom gateway. Uptime wasn't the priority. Flexibility was. I was still all over the place, not sticking to a side, and with WiFi being a first-class citizen as the initial choice for a portable gateway, it was the elephant in the room when it comes to network issues.
The goal now is downstream machine/resource sharing that's reachable by other people over the internet (I am well aware of Tailscale, Netbird, Pangolin etc there is more to expand on the why in time), and that needs something that's just there online, consistent all the time. Keep in mind there was already a lot to manage before any of that: Zrok going through major releases, updates to the control plane, all the services on the VPSs that I self hosted with the deps I had running, managing dependencies, too many moving parts when the actual goal was giving purpose to dormant silicon in a drawer.
There was a cost side to this too. Mullvad, Zrok, a handful of systemd services (time sunk), and a WiFi link that needed babysitting, VPS instances. Cutting more out simplified more than just the network and optimized more of what was left.
// THE GEAR
There wasn't much to add to the network to get it working. I could have gone with Cat6e again, but I needed something thinner, that scales with bandwidth on the cable side which I can leverage later on, with a higher theoretical ceiling than copper over the distance I'm catering for.
What showed up
The SFP modules work in a pair, each side operating on a different wavelength of light over the same BiDi connection. That's what lets one LC-to-LC simplex cable handle the whole run instead of needing two, a more manageable setup on the hardware side.
the two transceivers - one per end, opposite wavelengths
The two media converters need their own separate power, which is the only real downside to the run right now, another power brick (x2). Down the line I'll swap the barrel jacks out for USB-C and run everything off the same power source.
Media converters at each end of the run between main router and where I need it
What went in:
// SAME SUBNET, NEW LINK
The only thing that changed is the link out to the gateway.
Before, there was a wireless link from my personal subnet and with this change, the network stays the same, just with a physical link to the new subnet. That comes with the side effect of fewer moving parts to manage on the software side, and more resources freed up on the hardware from removing code, less liability in code. The result, a healthy link.
At some point, running tunnels through Zrok over systemd, managing limits on the resources per share, connecting to the self-hosted control-plane, I could get around 15-20 tunnels running on a 1GB memory device. Past that, most of the limits would've meant a higher spend on hardware, in a market that already doesn't make that spend worth it currently.
// THE RUN
The home router still does its normal job, WiFi for the household.
The home router is the same one that came with the internet from the ISP originally, not the best, but the Huawei WiFi AX3 was more than enough. Keep in mind, the household is mostly wireless devices that need a basic connection. The new run also means the other part of the house where my gateway will be, has its own router, the TP-Link MR600, and it can now act somewhat as a “mesh” AP for those devices for better coverage.
Main router direct link to Media converter that will have a fibre run to the other location
The fibre itself gets laid and run through the ceiling. The outdoor-rated cable was always going to be the right call, especially with the concern of a critter chewing through it. For me, protection is key and I won’t need to make visually appealing fibre bends which is not the recommended thing to do even if the cables generally got better over time.
Both ends live
// WHAT IT ACTUALLY CHANGED
Left to right contains the line I get on fibre vs what I used to when paying for a 500/200 line
I ran the same test across wired to the router, wired through the new fibre link, and the old WiFi setup. Wired and fibre both land close to the line's rated speed. Anywhere WiFi's in the mix, download drops and upload drops harder, the old Tunneld gateway's WiFi topped out at 30.6 up against the router's 162 wired. Every run showed 0% packet loss, so it's not drops in packets that I'm solving, it's loss and issues causing bandwidth limits, resulting in a saturated line.
The numbers between straight WiFi vs Fibre direct line and everything in between.
Keep in mind, in general, this isn't a flaw on WiFi's side, it's expected. It was never meant to be used the way I ended up using it (after moving gradually away from wireless first). My use case changing was always going to force this change eventually, regardless of whether access to those resources or machines became a common need or not.
// WHERE IT LANDED
Gateway, switch, sitting on the Mac Mini, router alongside
The result ends up pretty much the same as if I'd plugged directly into the main router (success). The goal here was bandwidth, connection uptime, and not battling WiFi configs and fallbacks with hard to debug issues on the hardware.
This won't improve bandwidth between devices on the subnet, but it’s noticeable when accessing machines on the subnet from a remote location. That's where most of the use cases come from, accessing machines and resources and better consistency for services running on devices I expect to have real uptime. On a device laying around, that is the gateway that owns the network, a router, and not some agent installed on a device on my network.
This opens the door to a lot, custom implementations at lower levels, L3/L4 like Tailscale or Netbird. But it owns the network, so you get access to reach for and build on top of L1/L2 as well, along with higher abstraction levels.
That clears the concerns and bottlenecks at the physical layer. I'll still have limits on the cable, media converter, and SFP connectors, and ceilings on the routers and switches I'm running. That's fine for my use case right now, while I'm focused solely on the gateway.
// WHAT'S NEXT
Physical layer's sorted. Next time: DNS, the setup I run on my local subnet, and a few quick wins worth considering too.