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 000000000..6c9eb2bcc 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 000000000..043039b5f 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 000000000..e208203b7 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 000000000..0c6c8811a 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 000000000..a29f60500 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 000000000..d26d5906a 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 ca2747f06..62b175079 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 ff57d847a..1c6a1615c 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 664a51ddc..1bc55aeb8 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 cff296aa6..9a813d6d5 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 43b215544..1bba84b57 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 6c9ef2f70..2ce3d2238 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