I'm still holding out against Tailscale. I've met the team (their CTO is a nice person), but the mission of 5L Labs is Privacy, not Conveniently Private. So we soldier on. The ask was small: give our research intern VPN access from an iPhone and a laptop to our three sites. Two evenings later, my AI assistant had forced me to understand things about WireGuard I'd been waaaay too lazy to learn. As in "wow, that's an interesting way to do it" is not the same as "the way the AI suggested to do it worked out of the box."

The win 🎉: WireGuard configs can finally live in source control. The private keys stay in Vault and get loaded at runtime, all with one line:

PostUp = wg set %i private-key /etc/wireguard/wg0.key

No secrets in the repo, a .conf that's safe to read, and nothing to scrub before a commit.

Running Home Assistant in a rootless Podman container on a SD Card is a miserable slog when you try to use Bluetooth. --userns=keep-id will require a chown on every file to boot the container - madness on a SD Card (can be upwards of 20 minutes or more on first boot). Failure to do this correctly earns you the error:

DBus authentication error; make sure the DBus socket is available and the user has the correct permissions: authentication failed: REJECTED: ['EXTERNAL']

Rather than code up a side-car, I found yichenshen/dbus-auth-proxy (our patched version: 5L-Labs/dbus-auth-proxy), a small subuid->uid dbus auth proxy someone wrote that can be chained to the standard dbus proxy (which apparently no one wants to touch with a barge pole).

AI has assisted the detailed write-up. Thanks to Shen Yichen for the original code, which I asked my assistant for some bugfixes / made work with quadlets.

I usually under-estimate how long it will take to "Maintain" my extended home network. Six hours later and an AI Assist later, I have a workaround but not a super awesome understanding of what got strict between Kernel 6.12 and 6.18. I wrote this up briefly so others might find it on Google.

As a reminder, we had one Bookworm Raspberry Pi acting as a WireGuard IPv4 forwarder sending traffic across the planet. After upgrading to Trixie, tcp connectivity stopped working but ping went through. None of the usual suspects helped - AI was generally useless.

So what the heck changed?

With the cold and the early darkness, it's time for more TV than less. With that in mind, I needed to fix a few things that "broke" over the last few months. This entry is a technical "brain dump" to document the NetworkManager and WireGuard configurations required to maintain a private, multi-site network.

For exactly zero-users (or maybe just me and my family),​

Wyze integrates and resells IoT cameras and devices for low capital cost, but they have been under increasing pressure to generate monthly recurring revenue. This shift has led to more aggressive cloud-only features and forced firmware updates.

Transitioning away from Wyze's cloud-dependent firmware toward local-only protocols is a major step in building a private home. The goal is to eliminate the need for external servers for live feeds and motion alerts, ensuring that my data stays under my roof.

This post defines the architecture of a private home network that spans multiple locations. By using Site-to-Site VPNs (specifically WireGuard) and rigorous packet inspection with Wireshark, I can ensure that sensitive IoT traffic remains entirely within my controlled environment.