Surface the existing /manage/reverse-proxy/troubleshooting page in the
Troubleshooting section: add it to the Connectivity sidebar group, and
move its hub chip from the Self-hosted card to Connectivity & networking
so the hub and sidebar agree.
The page covers reaching services exposed through routing peers, which
is a connectivity concern rather than self-hosted control-plane infra.
No new page and no duplicated content: both are pointers to the one
existing page.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
New /help/recording-a-har-file how-to under Troubleshooting > Report a
bug, covering HAR capture in Chrome, Edge, Firefox, and Safari with the
"preserve log" gotcha and a security warning about tokens in HAR files.
Nest Community/NetBird Support under the Report a bug "Overview" item so
the new page reads as a sibling of the reporting cluster rather than a
fourth flat peer. Cross-link the HAR page from the two support pages and
the Report bugs overview, next to the existing debug-bundle mention.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Document the community.ansible_netbird collection for managing NetBird
resources (users, groups, setup keys, policies, networks, DNS, posture
checks) declaratively via the REST API. Adds a new Infrastructure as
Code subsection under Self-Host NetBird with room for future entries.
Cross-links from the Automated Setup PAT bootstrap page since the
collection is the natural next step after obtaining the first token.
* docs: add routing peer sizing guide
Add a Sizing Routing Peers page under Networks covering the four-step
sizing method, a per-peer capacity table, the tuning levers that matter,
and how to scale out by sharding load across identical Networks.
Cross-link it from How Routing Peers Work (HA note + related tile) and
the Networks overview, and add it to the docs navigation.
* docs: refine wording in routing peer sizing guide
Generalize the Acme example to remote users, correct the encrypt/decrypt
framing and reach the local network rather than the datacenter, use
'routing peer' instead of 'gateway', and rename the recap to Summary.
* docs: tighten and correct HA behavior in routing peer sizing guide
Correct the high-availability description: a single Network does not
balance load across its peers — different metrics give failover (one
peer carries all), equal metrics give latency-based nearest-peer
selection, which splits traffic by geography but never evenly. Shard
into more Networks to split load deterministically.
Also collapse redundant restatements, drop the secondary worked
example (the capacity table covers it), and slim the commodity-hardware
guidance.
* docs: add 1- and 2-vCPU rows to the routing peer capacity table
Extend the capacity table down to 1 and 2 vCPUs, drop the 'or more' from
the interface column, and adjust the methodology note so the interface
column reads uniformly as the minimum NIC to pair with each size.
* docs: add userspace WireGuard table and when-to-use cases
Add a userspace-mode capacity table showing wireguard-go does not scale
across cores (download plateaus ~6.8 Gbps, only ~4-5 cores used), and
the cases where a routing peer runs userspace: missing/broken/conflicting
kernel module, no TUN device (netstack, incl. rootless Docker), non-Linux
peers, and forcing userspace to capture policy IDs and blocked traffic
events. Name the exact benchmark CPU (Xeon Platinum 8375C).
* docs: replace 'sharding' with plain wording in sizing guide
Rename the Scaling out heading and reword the body, description, and
recap to talk about splitting load across more Networks instead of
sharding. Update the in-page anchor link to match the new heading.
* docs: clarify download/upload direction bullets in sizing guide
Lead each direction bullet with Download:/Upload: and say the routing
peer encrypts/decrypts, tying the pulling/pushing distinction to the
capacity table's column names.
* docs: replace 'shard' with plain wording in HA note
* docs: add jumbo frames section to routing peer sizing guide
* docs: align jumbo upload figure with capacity table, mark 16-vCPU line-rate as projection
* docs: use consistent numerals for MTU byte sizes
Adds the how-to under the reorganized /use-cases/remote-access group
(stacked on the Use Cases reorg). Walks through the decision ladder for
two sites sharing one internal IP, ending with the per-site TCP proxy
pattern on each routing peer.
* docs: consolidate scenario guides under /use-cases with redirects
Move 11 pages: feature-nested use cases from manage/networks,
manage/network-routes, manage/reverse-proxy, and the Kubernetes
integration into /use-cases/remote-access, /use-cases/cloud, and
/use-cases/security; the site-to-site decision page becomes
/use-cases/remote-access; the MikroTik guide becomes an install
guide at /get-started/install/mikrotik.
Add one redirect per moved page and flatten existing redirect
chains so every legacy URL resolves in a single hop. The
deprecated Routes site-to-site recipe stays put.
* docs: rebuild sidebar navigation for use-cases reorg
Remove the four nested Use Cases sublists from Manage NetBird;
keep the deprecated Routes recipe as a direct 'Site-to-Site
(legacy)' link. Rebuild USE CASES with Remote Access, Cloud &
Kubernetes, Security groups and a flat Homelab link. Add MikroTik
to Get Started > Platforms.
* docs: rebuild use-case index pages and refresh feature landing links
Turn /use-cases into an "I want to..." scenario finder. Retitle
the site-to-site decision page to Remote Access and point its
links at the new sibling URLs. Add the Kubernetes service and
private-proxy guides to the cloud and security indexes, refresh
the homelab landing links, and update the Networks, Routes,
Reverse Proxy, and Kubernetes landing pages to the new use-case
URLs.
* docs: update internal links to new use-case URLs
Point cross-links across the docs at the consolidated
/use-cases URLs. Links to the deprecated Routes site-to-site
recipe and all image paths under public/docs-static are left
unchanged.
* docs: shorten sidebar label to Site-to-Site
* docs: move Kubernetes into its own Use Cases section
Pull the entire Kubernetes integration out of Manage > Integrations
into a dedicated Kubernetes group under Use Cases at /use-cases/
kubernetes, and move the two Kubernetes cloud guides there too.
Rename the Cloud group (was 'Cloud & Kubernetes'); Integrations
keeps the MDM deployment pages. Add redirects for every moved page
and flatten existing chains.
* docs: drop 'NetBird on' prefix from cloud sidebar labels
* docs: alphabetize Remote Access use cases in sidebar
* ❯ add mikrotik to install index
* docs: fix duplicated word in remote-access link label on TV install pages
---------
Co-authored-by: Brandon Hopkins <brandon@techhut.tv>
* Add OpenWRT install steps
* Add images
* Fixes and caveats
* minor fixes
* docs: call it "the NetBird client", not "the NetBird client (agent)"
---------
Co-authored-by: Jack Carter <128555021+SunsetDrifter@users.noreply.github.com>
Document running a BYOP proxy in private mode with no public inbound
ports by disabling proxy ACME, issuing the wildcard TLS certificate
externally over DNS-01, and serving it as a static certificate that the
proxy hot-reloads on renewal.
Adds the page under reverse-proxy/use-cases with a new Use Cases nav
group, plus cross-links from the Bring Your Own Proxy page (port-443
prerequisite + TLS table) and the Reverse Proxy overview (static cert
mode).
* docs: add Highly Available Routing Peers use-case page (Kubernetes operator)
Add a standalone use-case page under a new Use Cases group in the Kubernetes
nav, covering how to run the operator's routing peers in HA: NetworkRouter
workloadOverride.replicas (default 3), the auto-created PodDisruptionBudget
(maxUnavailable: 1), equal-metric automatic failover, and spreading replicas
across failure domains via workloadOverride.podTemplate. Models least-privilege
(named destination group + access policy) rather than the All group.
* docs: add topology diagrams to HA routing peers page
Two SVG topology diagrams: replicas on a single node (single point of
failure) and replicas spread one-per-node via topologySpreadConstraints.
Embedded in Step 1 and the failure-domains section.
* docs: correct HA scheduling framing; drop single-node diagram
kube-scheduler spreads a Deployment's replicas across nodes by default
(best-effort, via built-in PodTopologySpread defaults). The earlier text/
diagram wrongly implied replicas co-locate by default. Reframe: multi-node
spread is the default; topologySpreadConstraints turns it into a guarantee
(or spans zones). Remove the single-node diagram (non-HA case, out of scope).
* docs: add Friendly DNS names appendix to HA routing peers page
Document exposing a service under a cleaner name via a CNAME in a custom
zone pointing at the operator's <service>.<namespace>.<zone> record (verified
end-to-end). Placed as an appendix for now; can move to a shared location later.
* docs: use ScheduleAnyway in spread example; note DoNotSchedule rollout deadlock
Multi-node verification: default scheduling already spreads replicas one-per-node;
the operator merges workloadOverride.podTemplate.topologySpreadConstraints into the
Deployment. DoNotSchedule with replicas == schedulable nodes deadlocks rolling updates
(surge pod can't place). Switch the example to ScheduleAnyway (verified clean rollout)
and document DoNotSchedule + the node-count/maxSurge caveat for a hard guarantee.
* docs: clarify custom-zone records are per-name (no whole-domain shadowing)
Verified on the lab: a NetBird custom zone serves only the records you add; other
names under the domain fall through to upstream DNS. Reusing a real internal domain
for friendly names is safe except for exact-name collisions.
* docs: expand into full 'Route to a Kubernetes service' how-to
Restructure the HA use-case page into an end-to-end guide covering the whole
journey: create the custom DNS zone, groups, and access policy (dashboard) ->
deploy HA routing peers (NetworkRouter, replicas:3) -> expose a Service
(NetworkResource) -> verify + failover. Generic, human-readable example names
(k8s.company.internal, kubernetes-clients/-services, network 'kubernetes',
nginx). Keeps the failure-domains diagram + ScheduleAnyway/DoNotSchedule note
and the friendly-DNS appendix. Adds <img> slots for 5 dashboard/terminal
screenshots (to be supplied). Renames the page + nav entry to
route-to-a-kubernetes-service; old slug removed.
* docs: add dashboard/terminal screenshots to the K8s how-to
Four screenshots (DNS zone, access policy, the kubernetes network with HA +
3 routing peers, kubectl pods-across-nodes). Drop the groups screenshot and
renumber the <img> refs to match.
* docs: swap in cleaner pods-across-nodes screenshot for Step 5
* docs: make node-spread central to the HA guide
Node-spread is the point of an HA guide, not a tail-end section. Move the
topology diagram up to 'What you'll achieve', fold the node-spread story into
Step 3 (deploy HA routing peers) - leading with the verified fact that the
scheduler spreads replicas across nodes by default (HA out of the box), with
topologySpreadConstraints as optional hardening - and drop the orphaned
'Spread across failure domains' section.
* docs: clarify the custom zone is created empty (operator fills the record)
Step 1 showed the auto-created A record without saying you don't enter it.
Note that you create only the zone (no hostname/IP/TTL by hand) and the
operator adds <service>.<namespace>.<zone> -> ClusterIP (5-min TTL) in Step 4.
* docs: replace Excalidraw topology with a custom dark-mode SVG
Hand-authored dark-background topology diagram (NetBird overlay -> routing
peers one-per-node -> Service) that matches the dark docs theme, replacing the
light Excalidraw-derived SVG. Removes the orphaned ha-routing-peers-spread-nodes.svg.
* docs: add CNAME dialog screenshot to the friendly-DNS appendix
Show the Add DNS Record dialog (CNAME 'app' -> nginx.default.k8s.company.internal)
and align the example hostname to 'app' to match.
* docs: drop maxSurge:0 workaround (not configurable via the operator)
The operator's workloadOverride only exposes annotations, labels, podTemplate,
and replicas — there is no hook for the Deployment's strategy.rollingUpdate.maxSurge.
Keep the achievable workaround (more schedulable nodes than replicas).
* docs: drop manual topology spread guidance (operator handles it by default)
* Restructure Troubleshooting into a hub with per-area pages
- Add a Troubleshooting hub (/help/troubleshooting) with icon/chip cards and a "Still stuck?" CTA
- Split NetBird Client troubleshooting into an overview + per-OS pages (Linux, Windows, macOS, Android, iOS)
- Split Self-hosted troubleshooting into an overview + per-area pages (installation, IdP, dashboard, certificates, connectivity, database)
- Split "Report bugs and issues" into Community Support and NetBird Support pages
- Add Troubleshooting resource connectivity and a NetBird Cloud pending-approval page
- Add DNS troubleshooting Issue 8 (Windows NRPT rule blocked by a lingering GPO)
- Cross-reference the new pages from networks, DNS, and reverse-proxy docs; update nav
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Address review: client terminology, dead props, labels, cross-links
- Use "client" instead of "agent" across the client troubleshooting pages (headings, prose, anchors)
- Remove unused source: props from the Troubleshooting hub tiles
- Relabel the "NetBird Cloud" grouping to "Cloud & identity" (SSO/provisioning also apply to self-hosted)
- Add a Tiles title on the report-bug landing; add reverse-proxy -> resource-connectivity cross-link
- Fix comma splices introduced by the em-dash cleanup in relayed-connections
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Add client-side hash redirect for moved self-hosted anchors
Old deep links like /selfhosted/troubleshooting#debugging-turn-connections now
forward to the per-area page, since next.config redirects can't act on the URL fragment.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Apply docs-skill review: conventions + reshape area pages
- "open source" (no hyphen), expand NRPT on first use, descriptive alt text + captions on TURN images
- Fix inherited "Netbird" casing in the client glossary
- Reshape the six self-hosted area pages to Symptom -> likely causes (ordered) -> Fix -> Confirm, preserving anchored headings
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Fix two typos in client glossary (CodeRabbit)
- "nunning" -> "running" in the glossary
- possessive "it's" -> "its" in the routing-table sentence
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: fix two broken links in troubleshooting pages
- database: point the "upgrade path" link at /selfhosted/maintenance/upgrade;
selfhosted-quickstart has no #upgrade anchor so the old link landed at page top
- client: add HashRedirect so old #net-bird-agent-status deep links forward to
the renamed #net-bird-client-status section on the same page
* docs: address review follow-ups (deep-link redirects + client casing)
- self-hosted troubleshooting: extend the HashRedirect map with the per-issue
(###-level) anchors from the old single page, so old deep links land on the
exact sub-section of the new area page rather than just the page top
- client glossary: lowercase "NetBird client" in the peer-a/peer-b entries
(house convention) and fix "linux" -> "Linux"
* docs: review polish — fix image class + first-use acronym glosses
- connectivity: fix bad CSS class imagewrapper-nig -> imagewrapper on the
TURN-test screenshot (the typo'd class matched no style and broke zoom)
- gloss acronyms on first use: GPO (DNS Issue 8), IdP/SSO (identity-provider),
ACME (certificates), CORS (dashboard)
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: Jack Carter <128555021+SunsetDrifter@users.noreply.github.com>
The /selfhosted/environment-variables reference page had no inbound
links and was only reachable by direct URL or search. Add it under
Maintenance, after Configuration Files.
* docs: add routing-peer self-access and Active Directory guides
New use-case guides: reaching a service on a routing peer's own LAN IP
(route + peer-to-peer policy + NB_ENABLE_LOCAL_FORWARDING) and an
end-to-end Active Directory / Windows file shares guide over NetBird.
Clarify domain-resource DNS: with Routing Peer DNS Resolution on, the
routing peer answers the client's A/AAAA lookups (a domain resource
matches the exact name; use a wildcard for hostnames under a domain),
but AD still needs a nameserver group for the SRV/DC-locator records.
Add navigation entries, overlay-vs-LAN-IP notes, and ICMP/ping
troubleshooting guidance.
* docs: fix WireGuard anchor slug and sharpen local-forwarding caution
The #why-wireguard-with-netbird anchor doesn't resolve — the heading
slugifies to #why-wire-guard-with-net-bird (decamelized). Fix it in the
networks intro and the netbird-vs-traditional-vpn self-link.
Clarify the NB_ENABLE_LOCAL_FORWARDING caution: with it on, any permitted
peer can reach services bound to the routing peer's own addresses,
including 127.0.0.1, at the peer's NetBird IP.
* docs: polish routing-peer and Active Directory guides
- Correct the DC policy note: TCP/UDP need separate policies because a
policy carries one protocol, not because of a first-rule limitation
- Make internal-dns-servers the canonical A/AAAA-vs-SRV explanation;
collapse the three duplicates to one-line pointers
- Trim emphatic bold to enumerated requirements, ports, and flags
- Reduce em-dash density and clarify the routing-peer SSH-management
and HA cautions in the AD guide
* docs: make Active Directory guide clearer for junior admins
- Rewrite the Verify section to explain why (test as the signed-in
domain user, port 445 vs ping, name vs IP) instead of assuming
ICMP/Kerberos/NTLM knowledge
- Clarify the SSH-management and HA cautions in Step 3
- Note Get-DfsnFolderTarget needs the DFS Management tools (RSAT),
not just any domain-joined machine
- Reduce em-dash density throughout
* docs: Routing Peer DNS Resolution applies to all domain resources, not just wildcards
* docs: refine Active Directory guide and nameserver terminology
- Step 3 DC ports as a Port/Protocol/Needed-for table; promote 123
(time sync) and 464 (kpasswd) into the baseline
- DFS step: derive each target server's FQDN for the domain resource
- order the agent-placement and reachability shapes consistently
(dedicated routing peer first)
- drop the niche SSH-wedge caution and the premature masquerade note
- tie the ping/ICMP caveat to the port-scoped policies
- use "Nameserver" + "match domain" (the UI term) instead of
"nameserver group" across the AD, internal-DNS, and reach-services pages
* docs: scope the local-forwarding caution — loopback exposure is netstack-only
Reaching the routing peer's own 127.0.0.1-bound services via its NetBird IP
only happens on netstack-mode peers; on userspace-TUN (Windows/macOS) it does
not (verified), and Linux kernel mode is a no-op. The general "exposes own
addresses" caution stands; drop the over-broad 127.0.0.1/localhost specifics.
* docs: trim DC-through-routing-peer section to the DNS-only reason and reorder AD subsections
Drop the setup-flavored framing from 'Reaching a Domain Controller
through a routing peer' (it lives on the AD use-case page), keeping the
DNS reference fact: A/AAAA resolves on the routing peer but SRV/DC-locator
records don't, so AD still needs a nameserver to the DC. Heading text is
unchanged so the existing anchor still resolves. Reorder the AD & Domain
Controllers subsections to lead with the recommended case (reach the DC
through a separate routing peer), then the discouraged DC-as-routing-peer
path, then its WireGuard port-conflict troubleshooting.
* docs: drop redundant cross-link from AD Step 4 nameserver note
The note already explains why a domain resource doesn't remove the
nameserver requirement (SRV/DC-locator records). The trailing link to the
DNS page's 'Reaching a Domain Controller through a routing peer' section
just repeated that fact and linked back here, bouncing the reader. Step 4
already links to Internal DNS Servers for the general setup.
* docs: restructure AD routing-peer guidance — least-privilege tiers, DC route/policy split, de-loop cross-links
Active Directory & Windows File Shares:
- Add a TL;DR linking to a new 'The four settings' checklist at the bottom.
- Split Step 3 into Step 3 (route the DC) and Step 4 (allow the AD ports);
DNS becomes Step 5. Keeps the route distinct from the access policies.
- Step 2: break each routing-peer case into sub-bullets of what's needed;
point the self-access case to Reach Services on the Routing Peer.
- Step 3: present /32 or apex domain as the granular default and the
*.corp.example.com wildcard as the least-privilege opt-in — and spell out
the wildcard's one-policy-scope cost (uniform ports across the whole domain).
Reach Services on the Routing Peer:
- Tighten the setup steps; concrete DNS-nameserver instruction for AD/DFS;
state the Linux kernel-mode default for NB_ENABLE_LOCAL_FORWARDING.
- 'recipe' -> 'setup' throughout.
Internal DNS Servers:
- Clarify nameserver vs plain share: A/AAAA via the routing peer needs no
nameserver; AD needs one for SRV records and because the resolver won't
fall back. Distribute the nameserver to the routing peer's group *and*
client groups that resolve directly; only when the peer can't resolve on
its own. Reorder AD subsections; fix the overbroad distribution note.
How Routing Peers Work / cross-links:
- Remove redundant/circular cross-links across the four pages (the
HRPW -> Internal DNS -> Active Directory -> HRPW loop).
* docs: use "NetBird client"/"clientless" wording in AD and self-access guides
Replace 'the agent'/'agentless' with the preferred 'NetBird client'/'clientless' terms, and add the missing blank line before the Step 2 heading.
* docs: lower altitude of routing-peer/AD guides for junior admins
- Unify the overlay address as 'NetBird IP' and the local one as 'LAN IP' across the routing-peer/DNS pages; add a 2-line two-address primer to the two crux pages.
- Replace the dense userspace/netstack/kernel forwarding sentence with a platform table framed to the self-access case, plus a netstack-override footnote.
- Demote the wildcard policy-scope trade-off in the AD guide to a Note, keeping the granular-first nudge in the main flow.
- Split the 'Reaching a DC through a routing peer' paragraph into what-it-needs / why-a-domain-resource-isn't-enough bullets.
- De-duplicate the self-access section: it now owns the mental model and points to the use-case page for the concrete setup.
* docs: clarify the forwarding section for junior admins
- Disambiguate NB_ENABLE_LOCAL_FORWARDING from the IP-forwarding sysctl by naming the setting explicitly before the table.
- Split local forwarding into its own '### Local forwarding' subheading, distinct from '### IP forwarding'; repoint the #local-forwarding cross-link.
- Drop the netstack-specific override footnote — edge-case reference material that doesn't help the target reader (the row already names the correct flag).
* docs: apply review feedback to routing-peer/AD guides
- AD Step 4: list the AD ports per TCP/UDP access control policy instead of a dense one-rule-per-policy sentence; add 123 to the four-settings recap.
- De-duplicate the route+policy+local-forwarding triad within how-routing-peers-work (Local forwarding now points to the canonical statement); render the LAN-IP requirements as a sub-list.
- Plain-language rewrite of why a domain resource isn't enough for AD DNS.
- Qualify Global Catalog 3268/3269 to multi-domain forests; state the default branch in AD Step 1.
- Fix the Networks Tiles description to say 'NetBird client', not 'agent'.
- Add DNS troubleshooting Issue 7 for the AD symptom (login/DFS fails but file-by-IP works), cross-linked to the AD guide and the DC section.
* docs: recast AD "four settings" as an explicit NetBird config checklist
Rename the summary to 'What you configure in NetBird' and list the discrete NetBird objects: routing peer, a route (resource) to the file server and to the DC, separate access control policies for each, and a DNS nameserver. Keep the full AD port set in Step 4 only; update the TL;DR link to the new (decamelized) anchor.
* docs: clarify the self-access setup steps
- Identify NB_ENABLE_LOCAL_FORWARDING as an environment variable and link the Client Environment Variables reference.
- Front-load the platform on step 3 (Windows/macOS need the flag; Linux kernel forwarding doesn't, only netstack) and soften the 'all three required' framing accordingly.
- Explain that steps 1 and 3 exist only because clients reach the file server at its LAN IP; reaching a peer at its NetBird IP needs only the policy.
* docs: rename Network Routes to Routes, deprecate, and relocate Browser Client Architecture
- Rename the docs sidebar entry "Network Routes" to "Routes" and the page H1
- Add a deprecation note to the Routes page: all use cases except exit nodes
have moved to Networks; reconcile the body framing accordingly
- Move Browser Client Architecture under Peers > Browser Client
(/manage/peers/browser-client/architecture), nest the nav, add a redirect,
and update cross-links
- Shrink the site-to-site Architecture diagram boxes to fit their content
* docs: rename Routes nav 'Concept' link to 'Overview'
* docs: add Troubleshooting relayed connections teaching page
Adds a help-section teaching doc that walks junior admins from
'Connection type: Relayed' to a fixed P2P connection (or a justified
stop): mental model, the four players (NAT/Signal/STUN/Relay), ICE
candidate reading, an elimination-based decision flow, a port-forwarding
escape hatch, a worked walkthrough, and when relay is the right answer.
Moves the troubleshooting-oriented sections (Checking Your Connection
Type, Tips for Improving P2P Success) out of Understanding NAT and
Connectivity, leaving it purely conceptual with pointers to the new
page. Adds sidebar entry and a pointer from troubleshooting-client.
* fix: correct nftables example for STUN outbound rule
The STUN service runs on UDP 80/443/3478/5555, but the example rule
allowed TCP/443. Also note that nftables resolves hostnames at
ruleset-load time only, which matters for a dynamic geo-distributed
endpoint pool.
Create a standalone User Roles reference covering all six roles (Owner,
Admin, Network Admin, Billing Admin, Auditor, User) with a permission
matrix aligned to the current dashboard, per-role sections, API/token
notes, and role-assignment steps.
Reduce the role section on the Add Users page to a pointer (keeping the
existing anchor), repoint inbound links from delete-account,
control-center, and msp-portal, add the page to the Team sidebar, and
refresh the role screenshots.
* docs: rewrite Networks page as a teaching guide
Rework /manage/networks from a reference-style concept page into a
structured teaching guide: mental model, the four building blocks
(Network, Resource, Access policy, Routing peer), how a packet reaches
a resource, and an end-to-end walkthrough for reaching two internal
apps with Zero Trust access by default.
- Add a production checklist (HA, monitoring, masquerade, internal DNS,
routing-peer access) and a clear "Networks or Network Routes?" split:
Networks now covers every remote-access scenario except exit nodes.
- Add worked-example and resource-list screenshots.
- how-routing-peers-work: point site-to-site at Networks, describe
Routing Peer DNS Resolution as on by default, and restore the
0.59.x domain-resolution compatibility note.
- Rename the sidebar entry from "Concept" to "Overview".
* image organization into /networks dir
* fix embedded images in networks/index.mdx
* docs: note no inbound ports and Linux-only masquerade on Networks page
---------
Co-authored-by: TechHutTV <brandon@techhut.tv>
* docs: add Networks site-to-site use-case guide
Add a canonical site-to-site guide built on Networks/Resources/Policies,
which is the recommended and actively developed approach. Reposition the
legacy Network Routes site-to-site Note to point at the new page and scope
Network Routes to the wide-open, no-policy case only. Add the new page to
the docs sidebar under Networks > Use Cases.
* docs: fix Resource fields, policy heading, and prerequisites in Networks site-to-site
- Remove non-existent 'Type: Subnet' field; describe Resource Groups under
Additional Options to match the actual UI
- Rename Step 4 to 'Create access control policies'
- Trim prerequisites (drop account line and device examples)
* docs: clarify Masquerade requirement and Linux-only SNAT for site-to-site
* Add Support Matrix section under Get More Help
Adds /help/support-matrix with an overview, NetBird client (split into
per-OS pages following the get-started/install layout), Kubernetes
operator, Terraform provider, and self-hosted sub-sections.
Linux/Windows/macOS pages pre-fill OS version cutoffs derived from the
Go toolchain's minimum OS requirements at each NetBird release's Go
version (sourced from go.mod at release tags). Each derived page carries
a Warning callout marking the values as inferences pending team
confirmation. Mobile/TV pages and the other component pages remain TBD
placeholders.
* Rework Linux support page around client modes
Drops the per-distro TBD table and consolidates the description with the
Warning callout. Splits Linux support by client mode: userspace follows
the Go toolchain's minimum OS requirements; kernel mode depends on the
host's iptables/nftables features. Notes Ubuntu 20.04 as the
end-to-end test floor.
* Add full Linux e2e test matrix to support page
Replaces the single Ubuntu 20.04 floor reference with the full set of
distributions covered by the NetBird team's end-to-end tests: Ubuntu
20.04/22.04/24.04, Debian 12, Rocky Linux 9, and Fedora 41. Ubuntu
20.04 remains called out as the oldest tested release.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
* docs: add Masquerade configuration page
Documents persistent return-route setup on the destination host when
masquerade is disabled on a routing peer. Covers Netplan, systemd-networkd,
NetworkManager, ifupdown, and RHEL legacy network-scripts, plus verification
and a security note. Resolves the previously dangling "Related" tile in
how-routing-peers-work.mdx.
* docs: clarify masquerade page and trim persistent recipes
- Netplan: show as a fragment with addresses/default route context so readers
don't paste it as a standalone file
- systemd-networkd: note the drop-in needs a matching .network file and
point at networkctl status to find it
- Test section: add ping/curl reachability examples
- Verify section: call out that proto/onlink/metric fields are normal
- Remove NetworkManager, ifupdown, and RHEL legacy sections
* docs: clarify netplan section when /etc/netplan is empty
Lead with the common case (cloud-init / installer yaml already exists),
and call out the placeholders in the example. Add a fallback path for
the rare case where /etc/netplan/ is empty.
* docs: comment <IFACE> placeholder in netplan example
* docs: clarify <IFACE> is the destination's LAN interface
* docs: comment <PEER_LAN_IP> placeholder in netplan example
* docs: tighten <PEER_LAN_IP> comment to 'local IP on this subnet'
* docs: make 'pick one' explicit for the persistent-config methods
Replace the weak one-liner with a bold "pick one" callout and a
two-bullet decision criterion (ls /etc/netplan/) so readers don't
mistake the two H3 sections for sequential steps.
* docs: add 'Find your account's NetBird range' to the masquerade page
Mirror the section already on the site-to-vpn page so readers learn to
use their account's /16 block rather than pinning the whole /10. Same
prose and netbird status recipe; trailing line adapted to reference
100.64.0.0/10 (the placeholder used elsewhere on this page).
* docs: remove 'Related' Tiles block from masquerade page
* docs: align security warning with the recommended /16 range
* docs: restore cross-link from advanced-configuration to masquerade
* docs: drop ping from the test-route example
ping would fail for ACL reasons (not routing reasons) on policies
scoped to specific TCP ports, misdirecting troubleshooting. Use curl or
nc against an allowed port instead.
* docs: apply review findings to masquerade page and legacy warning
masquerade.mdx
- add "Disable masquerade on the routing peer" section (dashboard +
API path), so the page actually documents the toggle, not just
the prerequisite
- "What changes when masquerade is off": say the route lives on the
destination host (or its gateway for multi-hop)
- forward-ref "Find your account's NetBird range" from the inputs
list to remove the substitute-then-rewind loop
- ip route del: include via <PEER_LAN_IP> so the test takedown is
unambiguous
- netplan prose: spell out that you append to the existing routes:
list, not add a second routes: key (YAML rejects that)
- verify output: use 192.168.1.10 for the routing peer so it stops
colliding with the 192.168.1.50 used as the destination's own IP
in the netplan example
- add an end-to-end verification step (curl + tcpdump) so a reader
confirms source IPs are actually preserved, not just that a route
exists in the table
advanced-configuration.mdx
- rewrite the contradictory Warning so it scopes correctly to legacy
Network Routes (which match peer NetBird IPs only) and points
readers to the Networks path when they want policy-layer ACLs
with masquerade off
* docs: promote the /16 substitution reminder to a Note callout
* docs: clearer wording for the /16 substitution Note
The Networks and Network Routes "By Scenario" / "By Resource Type" /
"By Configuration" subgroups had grown into reskinned walkthroughs of
flows already on the concept pages. Collapse to what's actually
distinct, flatten the survivors up one level, fold unique nuggets
into the concept pages.
Networks:
- Delete the "By Resource Type" trio (Multiple IP Resources, Domain
Resources, Wildcard Domains) and Remote Worker Access — all rehashes
of /manage/networks. Fold the wildcard-vs-base-domain gotcha and the
shared-policy pattern into the concept page.
- Delete the Use Cases overview; fold the VPN-to-Site framing into the
concept page.
- Flatten access-home-devices and cloud-to-on-premise up out of
/by-scenario/.
Network Routes:
- Consolidate site-to-site-{home,office,cloud} into one
/manage/network-routes/use-cases/site-to-site page covering the
shared walkthrough plus AWS/GCP/Azure routing-peer requirements.
- Move exit-nodes, access-control, overlapping-routes, and
advanced-configuration up out of /by-{scenario,configuration}/.
- Trim advanced-configuration (301 → 144 lines), dropping masquerade
basics, ACL setup, site-to-site flow, and HA repetition duplicated
elsewhere. Keep the masquerade trade-off matrix, Networks-vs-Routes
comparison, troubleshooting, and debug commands.
- Delete the Use Cases overview.
Permanent redirects added for every removed URL. Inbound references
updated across introduction, ipv6, homelab, cloud, security,
site-to-site overview, android-tv/tvOS install pages, and the concept
pages.
The Settings group header auto-navigates to its first child's href on
expand. The first child was "Allow SSH" pointing to /client/allow-ssh,
which redirects to /manage/peers/ssh, pulling the user out of the Client
section. Reorder so real /client/ pages come first; the two redirect
entries (Allow SSH, Enable Lazy Connections) stay discoverable at the
bottom of the group.
* docs: add Site-to-VPN scenario guide
New dedicated guide for letting clientless devices on a local network
initiate connections to NetBird peers (the reverse of VPN-to-Site).
Covers static-route and DNAT options, DNS resolution via dnsmasq, and
explains why the target peer always observes the routing peer's NetBird
IP as the source.
- Add src/pages/manage/network-routes/use-cases/by-scenario/site-to-vpn.mdx
- Wire it into NavigationDocs.jsx
- Update the site-to-site overview table row to point at the new page
- Replace the stub Site-to-VPN subsection in site-to-site-office.mdx
with a pointer to the new guide
* docs(site-to-vpn): correct source-IP section, add firewall and interface notes
- Source IP Behavior: remove the option that suggested emptying the
destination peer's policies. That doesn't preserve source IP; it just
tears down the wireguard pairing. Replace with an honest "not possible
with legacy Network Routes."
- Step 3: call out that hosts with FORWARD-DROP firewalls (UFW, firewalld)
need an explicit ACCEPT rule between the site interface and wt0.
- Option B: prefix the DNAT step with `ip -br addr` so customers find the
right site-facing interface instead of assuming eth0.
- Step 1: use "Name" for the setup key field instead of the route-only
"Network Identifier".
* docs(site-to-vpn): tighten prereqs, firewall step, and source-IP wording
- Drop generic prereqs (account, routing peer hardware, target peer)
- Reduce Step 3 to the host-firewall FORWARD rule
- Label Networks-feature Site-to-VPN as 'not possible' rather than limited
- Rename topology arrow to 'NetBird Overlay'
- Clarify masquerade lives on the routing peer in troubleshooting
* docs(site-to-vpn): switch primary path to Networks; document outbound SNAT requirement
Verified in the lab that Networks supports Site-to-VPN with the same
shape as Network Routes (Resource + Routing Peer + peer-group policy).
The differentiating factor is not the feature but the routing peer
platform: NetBird's masquerade flag does not install a working outbound
SNAT on non-Linux peers or in userspace mode, so the user must configure
it explicitly on the routing peer or upstream firewall.
Doc changes:
- Lead with Networks; Network Routes is now framed as an equivalent
alternative rather than the only option
- New Step 3 dedicated to the outbound SNAT (Linux iptables, pfSense /
OPNsense, MikroTik examples)
- New section "Outbound SNAT requirement" explaining why the destination
peer's access control rejects unrewritten site IPs and where the
dashboard masquerade flag is and isn't sufficient
- Up-front Warning calls out the platform requirement so customers don't
silently misconfigure
- Troubleshooting entry updated to point at SNAT counters and tcpdump
- Updated Source IP Behavior section to reflect that the behavior is the
same on both Networks and Network Routes
Parent page changes:
- /use-cases/site-to-site: Scenario Support table now shows Site-to-VPN
as Yes on both Networks and Network Routes; "Which Scenario Do I Need"
row points at both implementations
* docs(site-to-vpn): make static route the only Step 6 path; move DNAT to appendix
The static-route approach is the canonical setup; the per-service DNAT
option is a fallback for sites where routing changes aren't possible.
Treat it that way in the doc to keep the main flow linear.
- Step 6 now describes only the static-route approach (former Option A)
- Add a one-line pointer at the end of Step 6 to the appendix for sites
where the route can't be set
- Move the DNAT instructions to a new appendix at the bottom of the page
- Simplify Test Connectivity to a single curl
- Trim the Option-A/Option-B framing from the Troubleshooting "Connection
times out" entry
* docs(site-to-vpn): drop Source IP Behavior section
The "Outbound SNAT requirement" section already covers why the source IP
ends up as the routing peer's NetBird IP; a separate Source IP Behavior
section was repeating the same point and adding a speculative paragraph
about future Networks support. Drop both, plus the up-front Warning that
pointed at the removed section.
* docs(site-to-vpn): drop the Networks-vs-Network-Routes note
The guide is written around Networks; the side-note suggesting Network
Routes as an alternative path adds noise without value. The Step 4 inline
note keeps the Network Routes equivalent for anyone who needs it.
* docs(site-to-vpn): drop the inline Network Routes equivalent note
The guide is Networks-only now. Pointing readers at Network Routes mid-flow
just creates two paths to maintain without serving the reader who's
following the steps in front of them.
* docs(site-to-vpn): move page under Networks → Use Cases
The page describes a Networks-based setup; living under Network Routes
mis-categorised it.
- git mv to /manage/networks/use-cases/site-to-vpn.mdx (as a direct
child of Use Cases, not under By Scenario)
- Navigation: remove entry from Network Routes → By Scenario, add under
Networks → Use Cases
- Redirect old URL (/manage/network-routes/use-cases/by-scenario/site-to-vpn)
to new URL, permanent
- Update in-tree links in use-cases/site-to-site/index.mdx and
network-routes/use-cases/by-scenario/site-to-site-office.mdx
* docs(site-to-site): drop Network Routes mentions for Site-to-VPN
The Site-to-VPN guide is Networks-only; the overview page shouldn't
still be listing Network Routes alongside it.
* docs(site-to-vpn): trust NetBird's automatic SNAT on Linux kernel mode
On Linux in kernel mode, NetBird installs the SNAT itself when masquerade
is enabled on the routing peer — the user does not need a manual iptables
rule. Reframe Step 3 around this:
- Linux: enable ip_forward only; NetBird does the SNAT
- Non-Linux (pfSense / OPNsense / MikroTik / Windows / macOS / userspace):
configure manual outbound SNAT on the routing peer or upstream firewall
- Tighten the "Outbound SNAT requirement" appendix accordingly
- Move the explicit Linux iptables MASQUERADE rule into a troubleshooting
fallback for the case where NetBird's automatic SNAT doesn't fire
* docs(site-to-vpn): drop sysctl ip_forward instruction on Linux
NetBird handles IP forwarding itself on Linux; the manual sysctl was
unnecessary noise. Keep the host-firewall FORWARD-ACCEPT note since
UFW/firewalld setups still need it.
* docs(site-to-vpn): route the account's /16, not the entire /10 CGNAT range
NetBird assigns each account one /16 block out of 100.64.0.0/10 (chosen
randomly, customisable). Routing the whole /10 sends unrelated CGNAT
addresses through the routing peer; the correct target is the account's
own /16.
Step 6 now:
- Explains the /16-per-account model with the 64-block context
- Shows how to read the account's /16 from `netbird status` on any peer
- Switches the Linux / Windows / DHCP-option-121 examples to a concrete
/16 example (100.121.0.0/16) with a note to substitute your own
* docs(site-to-vpn): clarify when the target peer uses a setup key
Setup keys are for service / appliance peers; user peers (laptops,
workstations) enroll through SSO and inherit groups from existing
assignments. Reword the target-peer instruction to reflect that
distinction.
* docs(site-to-vpn): rename target peer to overlay-peer / overlay-peers
The previous backup-collector / backup-collectors naming carried
scenario-specific framing into the step examples. Use the generic
overlay-peer / overlay-peers throughout to keep the guide universal.
* chore: add trailing commas in Kubernetes nav entries
* Revert "chore: add trailing commas in Kubernetes nav entries"
This reverts commit d11b7eb7d0.
* docs(event-streaming): add Wazuh integration guide
Documents how to wire NetBird's Generic HTTP event-streaming integration
to a self-hosted Wazuh manager: NetBird-side configuration, KQL queries
for audit and traffic events in the Wazuh dashboard, and a schema
reference for both event shapes via the receiver wrapper.
Adds the page to the Stream Activity Events sidebar and the
event-streaming index.
* docs(event-streaming): replace Wazuh Generic HTTP screenshot
New page covering how to pre-populate default.json so NetBird peers
register with the right settings on first start in IaC, Docker, and
Kubernetes deployments. Documents file location across OSes, common
keys (with guidance to leave PrivateKey empty and treat PreSharedKey
as optional), runtime setup-key injection with worked Docker and
Kubernetes ConfigMap + Secret examples, backup hazards around the
embedded WireGuard private key, and how to verify registration via
netbird status --check startup, --json, and GET /api/peers.
Includes a callout that this workflow is for unattended workloads
only -- end-user devices should still enroll via the SSO flow so
Zero Trust can re-verify the user identity.
Linked from Manage NetBird -> Peers, right after Setup Keys.
* docs: add How Routing Peers Work concept page
Add a feature-agnostic primer covering the routing peer mental model:
traffic flow through forward vs input chains, host requirements (IP
forwarding on Linux/Windows, container caps, cloud settings), HA modes
(primary/failover and equal-metric latency switching), masquerade,
access control, DNS routing, exit nodes, and common pitfalls. Surface
it in the sidebar under Networks and cross-link from both the Networks
and Network Routes concept pages.
* docs(routing-peers): apply review feedback
- Clarify mental-model walkthrough describes the Linux kernel-mode path
- Expand OS list to Linux/Windows/macOS/FreeBSD/Android/tvOS/Docker
- Correct container IP-forwarding guidance: set sysctl on the host
- Reframe Windows NB_ENABLE_LOCAL_FORWARDING as opt-in for exposing
services on the routing peer's local addresses, off by default
- Soften failover wording to avoid implying tunnel rebuild; scope
reset claim to established TCP connections, drop "typically"
- Add masquerade-off caveats: Linux only, breaks HA
- Drop unfounded ACL-Groups-require-masquerade Warning
- Drop misplaced internal-DNS-resolver link from DNS section intro
- Rename Wildcard domains section to Routing Peer DNS Resolution
- Drop container/host IP-forwarding pitfall (not a real-world failure)
- Rephrase exit-node ICMP pitfall: clients can't connect at all
* docs(routing-peers): add example for forward vs input chain policies
A concrete scenario (office subnet behind the peer + Grafana on
TCP/3000 + SSH on TCP/22) showing the two policies needed: a network
resource policy on the forward chain and a peer-to-peer policy on
the input chain.
Adds a new API guide covering the cross-tenant `?account=<tenant_id>`
query parameter that scopes calls to a specific tenant under an MSP
account. Includes setup steps for picking a user and generating a PAT,
how to retrieve tenant IDs via the MSP listing endpoint, read/write
examples, and auditing/security guidance.
Cross-references added from the Authentication guide, the MSP Portal
page, and the public-api token-creation page so the new guide is
discoverable from each entry point an MSP user is likely to hit.
