CONCEPT Cited by 1 source
Router peer¶
A router peer is a distinguished role in Netbird's WireGuard mesh: a peer that is permitted to accept traffic from other peers and egress it to destination resources, rather than being merely a terminal endpoint for its own traffic. The canonical source-of-definition wiki instance is Yelp's 2025-04-15 Zero Trust Access post.
Definition (verbatim)¶
"All members of the mesh are peers but router peers serve the special role of being able to accept and egress traffic from other peers. Clients intrinsically have a one to many relationship with router peers they are permitted to use." (Source: sources/2025-04-15-yelp-journey-to-zero-trust-access)
Why the one-to-many binding matters¶
The HA property of a WireGuard mesh with router peers comes from clients being simultaneously connected to multiple router peers they are permitted to use. Concrete consequence measured at Yelp:
"This allows for maintenance or service interruption on one router peer without causing a user to reconnect to the network or experience noticeable degradation. Our testing with Netbird showed that a router peer that was actively handling traffic for a given peer could suddenly halt operation, and the client would experience a sub 2 second connectivity interruption while their traffic was rerouted to another host." (Source: sources/2025-04-15-yelp-journey-to-zero-trust-access)
The <2s interval is the reroute window, not a reconnect window: the client peer doesn't have to tear down its WireGuard session with the dead router peer and rebuild it with a new one — because it already had the new one as a configured peer. It just starts routing packets to a different permitted egress.
Contrast with a classical hub-and-spoke VPN concentrator: a client has one tunnel, to one concentrator; when the concentrator fails, the client must reestablish the tunnel with a different concentrator — and session state (authentication, routing tables, MFA proof) is rebuilt in the process. Router-peer topology collapses that reestablishment into an in-protocol reroute.
Policy boundary¶
Router peers are not implicitly reachable by every client peer — "Clients intrinsically have a one to many relationship with router peers they are permitted to use." The permission matrix is the zero-trust access control surface. Who- can-egress-via-which-router-peer is enforced at the control plane rather than by network-segment perimeter policy. This is the mesh's contribution to zero-trust authorization: access is a per-peer decision, not a per-subnet decision.
Seen in¶
- sources/2025-04-15-yelp-journey-to-zero-trust-access — canonical source-of-definition instance; Yelp's ZTA migration; <2s measured failover.
Related¶
- systems/netbird — the system that names + exposes this role.
- concepts/wireguard-mesh-topology — the broader topology in which router peers are distinguished.
- systems/wireguard — the protocol substrate.
- concepts/zero-trust-authorization — the permission model that gates which clients can use which router peers.