May 2026 Firezone Updates and Releases | Firezone Devlog
May brought Client-to-Client connections closer to production readiness, made connected devices visible from the desktop clients, hardened local IPC on Windows and Linux, and opened audit logs through the REST API.
Client-to-Client Traffic Enforcement
Static device pools let a client act as a Resource, which means the receiving client—not a Gateway—has to enforce the policy. Connlib now compiles each pool's traffic filters on the receiving peer and keeps conntrack-style state so return traffic is allowed without accidentally granting the destination device access back to the initiator.1
Filter changes also propagate to already-connected pool members.2 If an administrator tightens a pool's filters, newly forbidden traffic is rejected immediately instead of continuing until the connection is rebuilt.
See Connected Devices from the Client
The Windows and Linux system trays now include a Devices submenu that shows peers connected through device-pool Resources.3 Each entry includes the client ID and its pools, while large lists are capped in the menu with a total count so the tray remains usable.
This makes Client-to-Client activity visible without requiring an administrator to inspect the portal and provides a quick way to copy the tunnel address or peer identifier while troubleshooting.
Stronger Local IPC Boundaries
On Windows, Firezone now ships a signed sparse MSIX inside the existing MSI.4 The package gives the GUI a kernel-tracked identity that can be used to restrict access to its named pipes to the installed, signed Firezone binary. Follow-up changes applied that identity to the pipe ACLs and rejected cross-user GUI connections.5
Linux received a similar defense using SO_PEERPIDFD.6 On kernels 6.5 and newer, the tunnel daemon resolves the executable on the other end of its Unix socket without a PID-reuse race and only accepts the installed Firezone GUI.
Audit Logs via REST API
Change logs are now available from the REST API with filters for time range, actor ID, and actor email.7 Client and Gateway sessions were added to the audit trail as well,8 preserving a record even when the underlying token and session rows are later cleaned up.
More Resilient Portal DNS
Some networks block UDP/53 or run DNS forwarders that return unusable responses. When a portal lookup fails over UDP, connlib now retries it over TCP unless the resolver returned a definitive NXDOMAIN.9 That gives clients another path to reach the portal on networks with broken UDP DNS handling.