diff --git a/public/docs-static/img/manage/networks/use-cases/access-home-devices/architecture.png b/public/docs-static/img/manage/networks/use-cases/access-home-devices/architecture.png new file mode 100644 index 00000000..66fe95a6 Binary files /dev/null and b/public/docs-static/img/manage/networks/use-cases/access-home-devices/architecture.png differ diff --git a/public/docs-static/img/manage/networks/use-cases/active-directory/architecture.png b/public/docs-static/img/manage/networks/use-cases/active-directory/architecture.png new file mode 100644 index 00000000..7902e3c5 Binary files /dev/null and b/public/docs-static/img/manage/networks/use-cases/active-directory/architecture.png differ diff --git a/public/docs-static/img/manage/networks/use-cases/cloud-to-on-premise/architecture.png b/public/docs-static/img/manage/networks/use-cases/cloud-to-on-premise/architecture.png new file mode 100644 index 00000000..ab349720 Binary files /dev/null and b/public/docs-static/img/manage/networks/use-cases/cloud-to-on-premise/architecture.png differ diff --git a/public/docs-static/img/manage/networks/use-cases/reach-services-on-the-routing-peer/architecture.png b/public/docs-static/img/manage/networks/use-cases/reach-services-on-the-routing-peer/architecture.png new file mode 100644 index 00000000..0c6c8811 Binary files /dev/null and b/public/docs-static/img/manage/networks/use-cases/reach-services-on-the-routing-peer/architecture.png differ diff --git a/public/docs-static/img/manage/networks/use-cases/site-to-site/architecture.png b/public/docs-static/img/manage/networks/use-cases/site-to-site/architecture.png new file mode 100644 index 00000000..a411ef6d Binary files /dev/null and b/public/docs-static/img/manage/networks/use-cases/site-to-site/architecture.png differ diff --git a/public/docs-static/img/manage/networks/use-cases/site-to-vpn/architecture.png b/public/docs-static/img/manage/networks/use-cases/site-to-vpn/architecture.png new file mode 100644 index 00000000..0b5c1abb Binary files /dev/null and b/public/docs-static/img/manage/networks/use-cases/site-to-vpn/architecture.png differ diff --git a/src/pages/manage/networks/use-cases/access-home-devices.mdx b/src/pages/manage/networks/use-cases/access-home-devices.mdx index ca2747f0..62b17507 100644 --- a/src/pages/manage/networks/use-cases/access-home-devices.mdx +++ b/src/pages/manage/networks/use-cases/access-home-devices.mdx @@ -12,10 +12,9 @@ For the mental model — see [How Routing Peers Work — Mental model](/manage/n After following this guide, you'll be able to access your home NAS, media server, home automation, or any device on your home network from your laptop or phone—anywhere in the world. -``` -Your Laptop ──────► NetBird Tunnel ──────► Routing Peer ──────► Home NAS - (peer) (at home) (no NetBird) -``` +

+ Laptop connects through an encrypted NetBird tunnel to a home routing peer and then to a home NAS +

## Prerequisites diff --git a/src/pages/manage/networks/use-cases/active-directory.mdx b/src/pages/manage/networks/use-cases/active-directory.mdx index ff57d847..1c6a1615 100644 --- a/src/pages/manage/networks/use-cases/active-directory.mdx +++ b/src/pages/manage/networks/use-cases/active-directory.mdx @@ -13,10 +13,9 @@ The core idea: a domain-joined client's everyday actions quietly depend on **two - the **domain controller (DC)**, for DNS, Kerberos authentication, and DFS namespace referrals; - the **file server(s)**, the machines that actually hold the shares. -``` -Remote user ──tunnel──► routing peer ──LAN──► Domain Controller (DNS, Kerberos, DFS referral) - (NetBird) └─────► File server(s) (the SMB/DFS share data) -``` +

+ Remote NetBird user connects through an encrypted tunnel to a routing peer that reaches a domain controller and file servers on the LAN +

## What one mapped drive actually depends on diff --git a/src/pages/manage/networks/use-cases/cloud-to-on-premise.mdx b/src/pages/manage/networks/use-cases/cloud-to-on-premise.mdx index 664a51dd..1bc55aeb 100644 --- a/src/pages/manage/networks/use-cases/cloud-to-on-premise.mdx +++ b/src/pages/manage/networks/use-cases/cloud-to-on-premise.mdx @@ -12,10 +12,9 @@ For the mental model — see [How Routing Peers Work — Mental model](/manage/n After following this guide, your cloud applications will be able to securely access on-premise databases, APIs, and services without exposing them to the public internet. -``` -Cloud VM ────► NetBird Tunnel ────► Routing Peer ────► Database Server -(peer) (on-prem) (no NetBird) -``` +

+ Cloud VM connects through an encrypted NetBird tunnel to an on-premise routing peer and then to a database server +

## Prerequisites diff --git a/src/pages/manage/networks/use-cases/reach-services-on-the-routing-peer.mdx b/src/pages/manage/networks/use-cases/reach-services-on-the-routing-peer.mdx index cff296aa..9a813d6d 100644 --- a/src/pages/manage/networks/use-cases/reach-services-on-the-routing-peer.mdx +++ b/src/pages/manage/networks/use-cases/reach-services-on-the-routing-peer.mdx @@ -8,10 +8,9 @@ Every peer has two addresses: its **NetBird IP** (its `100.x` overlay address, t The NetBird client is installed only on the file server, so the file server *is* the routing peer. Remote users resolve the file server's name (and any DFS paths) to its LAN IP — but that address belongs to the routing peer itself, so traffic to it must be *delivered locally on the peer, not forwarded* to a network behind it. The symptom: DNS resolves, yet SMB connections and pings to the file server fail. -``` -Remote user ──tunnel──► File server = routing peer (its own SMB/DFS share at its LAN IP) - (NetBird) └──► Domain Controller (clientless, on the same LAN) -``` +

+ Remote NetBird user connects through an encrypted tunnel to a file server that is also the routing peer, with a clientless domain controller on the same LAN +

## The setup diff --git a/src/pages/manage/networks/use-cases/site-to-site.mdx b/src/pages/manage/networks/use-cases/site-to-site.mdx index 43b21554..1bba84b5 100644 --- a/src/pages/manage/networks/use-cases/site-to-site.mdx +++ b/src/pages/manage/networks/use-cases/site-to-site.mdx @@ -6,14 +6,9 @@ Site-to-Site connects two networks through routing peers at each end. Neither en ## Architecture -
- -``` -Site A device ──► Routing Peer ──► NetBird Tunnel ──► Routing Peer ──► Site B device - (no NetBird) (peer) (peer) (no NetBird) -``` - -
+

+ Site A device reaches Site B device through routing peers over an encrypted NetBird tunnel +

Networks is the recommended way to build site-to-site. It has per-Resource access control, is Zero Trust by default, and is the actively developed system. diff --git a/src/pages/manage/networks/use-cases/site-to-vpn.mdx b/src/pages/manage/networks/use-cases/site-to-vpn.mdx index 6c9ef2f7..2ce3d223 100644 --- a/src/pages/manage/networks/use-cases/site-to-vpn.mdx +++ b/src/pages/manage/networks/use-cases/site-to-vpn.mdx @@ -17,10 +17,9 @@ reach a NetBird peer by its overlay IP or NetBird DNS name. Typical examples: - An office printer reporting status to a NetBird-connected management application -``` -Clientless Device ──► Routing Peer ──► NetBird Overlay ──► NetBird Peer - (no NetBird) (peer) (peer) -``` +

+ Clientless device reaches a NetBird peer through a routing peer over an encrypted NetBird tunnel +

The routing peer must perform **outbound source NAT** for site traffic