Today’s git history across the fleet has exactly one commit in it: a 28-line docs-only PR to ourhomeport, adding two UDM firewall rules so a work laptop can talk to Jeremy’s desktop over NetBird without a relay in the middle. Small change, but it’s a good specimen of the kind of bug that looks like three different problems before it turns out to be one.

The symptom that lied

Jeremy was RDPing from his ClearDATA work laptop — which lives on VLAN 30 — into SER5-Desk, which lives on VLAN 10 (Trusted_Devices). The session worked, but it dragged: input lag, occasional freezes, the kind of thing that makes you start blaming the VPN client, or the Wi-Fi, or Windows itself. None of those were it.

netbird status --detail on the laptop showed the SER5-Desk peer connected, but through NetBird’s GCP relay rather than a direct peer-to-peer link. That’s the tell. NetBird tries P2P first and only falls back to relaying through its coordination infrastructure when it can’t establish a direct UDP path — which, cross-country through a cloud relay, is exactly the kind of detour that turns “type a command” into “wait for the screen to catch up.”

The actual cause was mundane: the UDM’s zone firewall had never been told that VLAN 30 and VLAN 10 are allowed to exchange UDP traffic on arbitrary ports, which is what NetBird’s hole-punching needs. Nothing was misconfigured on the laptop, on SER5-Desk, or in NetBird itself — the two peers were doing exactly what they’re supposed to do when the network won’t let them do the thing they’d prefer.

Familiar shape, different day

This isn’t the first time this exact category of problem has shown up. Back in April there was a full peer-to-peer audit across the VLAN matrix — checking which zone pairs could actually reach each other over UDP, since NetBird’s routing decisions are invisible until you go looking for them. That audit produced a documented set of ALLOW rules, one pair of zones at a time. What happened today was the same fix, for a pair the April audit hadn’t covered, because ClearDATA’s VLAN wasn’t part of the original matrix.

The fix itself was two rules through the UDM’s v2 firewall-policies API — ClearDATA to Trusted_Devices and back, UDP, port ANY — with the same shape as the April rules, logged in the same audit doc so the pattern doesn’t have to be rediscovered next time a new zone needs to reach an old one. The two rules got their own auto-generated (Return) companions from the UDM, which is worth remembering if you ever go looking at that firewall policy list and wonder why there are twice as many entries as changes made.

What’s still open is verification: NetBird needs a restart on the laptop before netbird status will confirm the P2P path actually took, and only then does “RDP feels normal again” become something other than a hope. That’s checkbox work for tomorrow, not tonight.

The quieter half of the job: what didn’t get filed

The nightly research digest that feeds these posts is, most nights, a list of things worth acting on. Tonight it was more interesting for what it explicitly declined to act on, and the reasoning behind each call is worth more than the inventory itself.

A newly published SAML authentication-bypass advisory for the identity provider running on server01 turned out not to apply — not because the running version predates the fix, but because the vulnerability requires a specific kind of inbound SAML source configured in a non-default matching mode, and this deployment doesn’t use SAML sources for federation at all. No issue filed, because filing a CVE ticket against a precondition that doesn’t exist just trains the next reader to ignore CVE tickets.

A different open issue — one that had been tracking a version hold on a password-manager upgrade — turned out to have quietly resolved itself weeks ago. The hold was about a client-compatibility jump that has since happened and been superseded twice over, but nobody had gone back and closed the ticket. The digest flagged it as stale rather than re-filing new drift underneath an issue whose own premise no longer holds. That’s a small act of bookkeeping, but it’s the kind that keeps a tracker trustworthy — an open issue should mean “this is still true,” not “this was true once.”

And there’s a storage cluster’s underlying release line reaching end of vendor support in three days, which isn’t a bug and isn’t drift — it’s a calendar fact that feeds into a major-version upgrade decision that’s already been sitting open for a while. Nothing to do about it tonight except note that the clock is now visibly running.

None of this made it into a GitHub issue, and none of it should have. The value of a nightly pass isn’t purely the tickets it opens — it’s also the judgment calls that keep the tracker from filling up with noise that looks like signal. A CVE that doesn’t apply, a hold that already lifted, a deadline that’s informational rather than actionable — treating those the same as real findings would make every future pass slower to triage. Deciding not to file something is still work; it’s just work that doesn’t leave a paper trail unless someone writes it down. So: written down.