diff --git a/public/docs-static/img/manage/networks/netbird-network-routes.png b/public/docs-static/img/manage/networks/netbird-network-routes.png deleted file mode 100644 index 1997d620..00000000 Binary files a/public/docs-static/img/manage/networks/netbird-network-routes.png and /dev/null differ diff --git a/public/docs-static/img/manage/networks/networks-overview.png b/public/docs-static/img/manage/networks/networks-overview.png new file mode 100644 index 00000000..af40b580 Binary files /dev/null and b/public/docs-static/img/manage/networks/networks-overview.png differ diff --git a/public/docs-static/img/manage/networks/through-or-to-the-routing-peer.png b/public/docs-static/img/manage/networks/through-or-to-the-routing-peer.png new file mode 100644 index 00000000..e289da15 Binary files /dev/null and b/public/docs-static/img/manage/networks/through-or-to-the-routing-peer.png differ diff --git a/src/pages/manage/networks/how-routing-peers-work.mdx b/src/pages/manage/networks/how-routing-peers-work.mdx index b6d98164..5aec95f2 100644 --- a/src/pages/manage/networks/how-routing-peers-work.mdx +++ b/src/pages/manage/networks/how-routing-peers-work.mdx @@ -37,7 +37,7 @@ NetBird offers two ways to configure routing peers. Both are actively maintained ## Mental model: how traffic flows

- Routing peer bridging NetBird overlay to a private network + Three NetBird peers on the overlay network connect through a WireGuard tunnel to a routing peer in a private network. Access policies on the routing peer allow a database on TCP 5432, a web app on TCP 443, and an RDP workstation on TCP/UDP 3389; a printer with no policy is unreachable.

The walkthrough below describes the **Linux kernel-mode** path, where forwarding and firewalling happen in the kernel via `nftables` / `iptables`. On other platforms, NetBird performs the same logical steps in a userspace filter, but the implementation differs. @@ -172,6 +172,10 @@ This is the subtlest part of the model and the source of most policy mistakes. - **Forward chain.** Packets routed *through* the peer to backend resources. Network resource policies (Networks) and ACL Groups (Routes) apply here. - **Input chain.** Packets destined to the routing peer's own IP. [Peer-to-peer policies](/manage/access-control/manage-network-access) apply here. +

+ Two paths compared. Through the routing peer: a network resource policy, evaluated in the forward chain, lets a client reach a web app behind the routing peer on TCP 443. To the routing peer: a peer-to-peer policy, evaluated in the input chain, lets a client reach SSH on the routing peer's NetBird IP on TCP 22. +

+ If users need to reach both the resources behind a routing peer **and** services running on the routing peer itself (Pi-hole, monitoring, jump-host SSH), you need one policy of each kind. **Example.** A routing peer fronts the `10.10.0.0/16` office network and also runs Grafana on TCP/3000 plus SSH on TCP/22. To let the `Engineers` group reach both, create two policies: diff --git a/src/pages/manage/networks/index.mdx b/src/pages/manage/networks/index.mdx index 67bd6894..4ec8f9c3 100644 --- a/src/pages/manage/networks/index.mdx +++ b/src/pages/manage/networks/index.mdx @@ -21,10 +21,10 @@ Throughout this page, a capitalized **Network** means the configuration object y If you remember one thing, remember this: **a NetBird Network is a map of part of your infrastructure, drawn onto your overlay network.** The **resources** are the destinations, the **access policies** are the gatekeepers that decide who may pass, and the **routing peers** are the roads that carry traffic to each destination.

- A NetBird client reaching resources on a private network through a routing peer + Three NetBird peers on the overlay network connect through a WireGuard tunnel to a routing peer in a private network. Access policies on the routing peer allow a database on TCP 5432, a web app on TCP 443, and an RDP workstation on TCP/UDP 3389; a printer with no policy is unreachable.

-*Left to right: a peer in a source group clears an access policy, reaches the routing peer, and connects to a resource behind it.* +*Left to right: peers reach the routing peer through a WireGuard tunnel, and access policies on the routing peer decide which resources behind it each peer can reach. The printer has no policy, so nothing reaches it.* ## The four building blocks @@ -90,7 +90,7 @@ A network resource policy grants access to the network **behind** the routing pe Here is the whole path, end to end: 1. Your client encrypts the packet and sends it through the tunnel to the routing peer. -2. The routing peer forwards it onto the local network toward the resource. +2. The routing peer decrypts the packet and forwards it onto the local network toward the resource. 3. By default the routing peer **masquerades** the traffic, rewriting the source to its own LAN IP, so the destination network needs no awareness of NetBird. 4. Replies follow the reverse path. The connection is stateful, so return traffic needs no extra policy. @@ -100,13 +100,9 @@ One subtlety causes most policy mistakes. A network resource policy permits traf If a resource stays unreachable even though the policy looks right, [Troubleshooting resource connectivity](/help/troubleshooting-resource-connectivity) helps you find which layer is dropping the traffic. -``` -THROUGH the routing peer → forward chain → network resource policy - your client ──tunnel──► routing peer ──────► resource behind it - -TO the routing peer → input chain → peer-to-peer policy - your client ──tunnel──► routing peer (its own SSH, dashboard, …) -``` +

+ Two paths compared. Through the routing peer: a network resource policy, evaluated in the forward chain, lets a client reach a web app behind the routing peer on TCP 443. To the routing peer: a peer-to-peer policy, evaluated in the input chain, lets a client reach SSH on the routing peer's NetBird IP on TCP 22. +

For the full kernel-level traffic walkthrough, host requirements (IP forwarding, container capabilities), masquerade internals, and the forward-vs-input-chain rule in depth, see [How Routing Peers Work](/manage/networks/how-routing-peers-work). diff --git a/src/pages/use-cases/security/implement-zero-trust.mdx b/src/pages/use-cases/security/implement-zero-trust.mdx index bc5abbc4..cf79bf28 100644 --- a/src/pages/use-cases/security/implement-zero-trust.mdx +++ b/src/pages/use-cases/security/implement-zero-trust.mdx @@ -515,7 +515,7 @@ A routing peer is a NetBird peer that: - Is selected as a routing peer in a [Network](/manage/networks) or [Network Route](/manage/network-routes) configuration

- high-level-dia + Three NetBird peers on the overlay network connect through a WireGuard tunnel to a routing peer in a private network. Access policies on the routing peer allow a database on TCP 5432, a web app on TCP 443, and an RDP workstation on TCP/UDP 3389; a printer with no policy is unreachable.

### 5.2 Direction of traffic with routing peers