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..1f501ee7 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..2a970ff6 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 @@ -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).