* fix: replace invalid <p> wrapping Button with <div>
The Button component renders a <div> in its primary variant. HTML
disallows block elements inside <p>, so browsers auto-close the <p>
during parsing and React 19 reports a hydration mismatch. The
float="center" attribute was non-functional, so rendering is unchanged.
* chore: gitignore .playwright-mcp run artifacts
* OPNsense checkbox "Show community plugins"
OPNsense requires a new checkbox "Show community plugins" to be checked, before you can find the netbird plugin.
Tested on OPNsense 26.1.8_5
* docs: tighten OPNsense community plugins instruction
---------
Co-authored-by: Jack Carter <128555021+SunsetDrifter@users.noreply.github.com>
* 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>
---------
* Update BYOP documentation to reflect "Clusters" terminology and add shared vs account cluster details.
* Update BYOP DNS documentation and replace modal images
* Update Linux installation instructions for NetBird on Fedora Silverblue and Universal Blue. Added Homebrew and Distrobox installation methods, including necessary commands and SELinux configuration notes. Updated Distrobox container image version from Debian 12 to 13.
* Some adjustments to homebrew docs
* removed leading space on the \``bash` opening fence
---------
Co-authored-by: TechHutTV <brandon@techhut.tv>
* 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 agent already enables ip_forward inside the container's own network
namespace when it has NET_ADMIN, so the blanket claim that a container
cannot do this on its own is misleading. The preceding paragraph
already covers the fallback case when the agent cannot modify sysctl.
* docs: rewrite Site-to-VPN SNAT requirement to always be manual
The dashboard Masquerade flag does not cover the Site-to-VPN direction on
any route — the marking rules NetBird installs are only wired up when a
policy targets the resource, and the documented flow uses a peer-to-peer
policy. The old guidance ("on Linux kernel mode, no manual SNAT needed")
was wrong, so manual SNAT is now framed as required on every routing peer
regardless of OS or WireGuard mode.
Also adds an nftables example alongside the iptables one, drops the
"(If applicable)" qualifier from the Step 3 heading, fixes the four
in-page anchor links that were already 404ing against the old heading,
and reframes the Step 4 masquerade-flag note plus the Outbound SNAT
requirement and Troubleshooting sections to match.
Verified end-to-end in a kernel-mode Linux lab: with the documented setup
(masquerade=true, peer-to-peer policy only, no manual SNAT) curl from a
clientless device to the overlay peer's NetBird IP times out; adding
either the iptables or the nftables rule from the new Step 3 makes it
return HTTP 200.
* docs: make Step 3 SNAT examples persistent
The previous version showed runtime iptables/nft commands with
persistence as a trailing comment. Replace with two equivalent
fully-persistent options: iptables-persistent (recommended) and a
dedicated systemd-unit + /etc/nftables.d/ file for nftables-native
setups.
Explicitly call out why /etc/nftables.conf is not the right persistence
target — its default starts with "flush ruleset", which wipes the
iptables-nft chains NetBird installs.
Both options verified end-to-end in a lab: rule applied, curl succeeds;
rule removed (simulating reboot), curl fails; reload via
netfilter-persistent / systemctl restart, curl succeeds again.
* docs: drop nftables-only option from Step 3
iptables-persistent works on every Linux NetBird supports — whether the
underlying backend is iptables-legacy or iptables-nft — so a separate
nftables variant with its own systemd unit was strictly more complexity
for the same outcome. Keep the iptables-persistent block as the single
Linux instruction.
* docs: drop UFW/firewalld FORWARD caveat from Step 3
The note was scoped to a minority of routing peers (those running UFW or
firewalld with default-DROP on FORWARD), and the persistence guidance
was too vague to be actionable. The symptom — packets reaching the
routing peer but not the target — is already covered by the
Troubleshooting section, which is enough of a lead for affected users.
* docs: drop standalone Outbound SNAT requirement section
The section's three takeaways — ACL ipset rejects routed-CIDR sources,
SNAT rewrites the source to a known NetBird IP, dashboard Masquerade
flag doesn't cover this direction — are already covered inline in Step
3 and the Step 4 masquerade note. Fold the one unique bit (the ipset
mechanic) into Step 3's opening sentence and drop the standalone
section plus the three "see Outbound SNAT requirement" backreferences
that pointed at it.
* docs: use ss -tan in Test Connectivity verification
The previous command (ss -tnp | grep :8080) filters by process and
misses TIME-WAIT sockets, which are kernel-owned. After a fast curl the
TCP connection closes before ss runs, so the user only ever sees the
LISTEN socket — no indication of the source IP. ss -tan lists all
states, so the TIME-WAIT entry showing the routing peer's NetBird IP as
the remote address is reliably visible for ~60 s.
Verified end-to-end in a kernel-mode Linux lab.
* docs: make Linux static route in Step 6 persistent
Replace the runtime "ip route add" + persistence-as-a-comment with two
fully-persistent options: a netplan drop-in (Ubuntu Server default) and
an nmcli equivalent (RHEL / Fedora / desktop). The netplan YAML was
validated against netplan generate. Also annotate the Windows command
to highlight that "-p" is what makes it persistent.
* docs: drop unverified pfSense/OPNsense and MikroTik examples
Neither platform ships a first-class NetBird routing-peer setup, and we
have no way to verify the SNAT commands in those sections work as
written. Replace with a single "Other platforms" paragraph that points
back to the general principle (any SNAT that rewrites the site-CIDR
source on egress from wt0 is sufficient) without claiming to give
verified instructions. Also tighten the Prerequisites line that
referenced "per-platform SNAT syntax" that no longer exists.
* docs: rewrite DNS NXDOMAIN troubleshooting entry
The previous entry referenced a "127.0.0.1-co-located NetBird resolver"
that doesn't exist — the doc's own DNS section explicitly notes that
the NetBird daemon binds its resolver on the peer's own NetBird IP,
not on 127.0.0.1. The "binding loopback causes it to refuse forwarding"
explanation was therefore exactly backwards.
Replace with a dig-based isolation flow that distinguishes the three
real failure modes (timeout = dnsmasq not reachable on the site IP;
SERVFAIL = forward to NetBird resolver failed; NXDOMAIN = wrong FQDN).
Diagnostic flow verified end-to-end in a lab — valid hostnames return
NOERROR with an answer record, unknown ones return status: NXDOMAIN as
described.
Matches the dashboard rename. The setting moves DNS resolution for
routed domains from the client to the routing peer; wildcard routing
is one consequence rather than the primary purpose, so the canonical
section now leads with that framing.
Heading anchor changes from #enable-dns-wildcard-routing to
#enable-routing-peer-dns-resolution. Keeps an invisible legacy anchor
on both pages so external bookmarks still scroll to the section.
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.
Delete /about-netbird/other (Google Summer of Code 2022 project
ideas) and add a 301 redirect to /introduction. The page was
orphaned — not linked from navigation, contained broken internal
links, and had no modern equivalent.
* 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
* ci: validate PRs with build and MDX heading linter
Adds a pull_request workflow running npm run lint:mdx, npm run build,
and npm run lint so heading-hierarchy bugs and broken builds get caught
before merge rather than after.
The new linter (scripts/lint-mdx-headings.mjs) enforces that the first
heading is h1 and that heading levels never jump by more than one. Also
fixes three existing pages that had no h1 title — two were using a
legacy export const title pattern, one was missing a title entirely.
* ci: use npm install since lockfile is gitignored
package-lock.json is in .gitignore, so npm ci and setup-node's npm
cache both fail on a fresh CI checkout. Match the Dockerfile pattern
(npm install, no cache) instead.
* ci: drop ESLint step; project config is broken
`npm run lint` fails with 'Converting circular structure to JSON'
under ESLint 9.x — the repo has no .eslintrc or eslint.config file,
so the legacy resolver hits the React plugin's circular reference.
This is pre-existing (build_n_push.yml never ran lint, so it stayed
hidden); fixing it needs flat-config migration and is out of scope.
Drop the step until that lands.
* docs: rewrite traffic events logging Limitations section
The previous matrix mixed several inaccurate claims about feature
availability across WireGuard modes. Replace it with the actual
constraint — policy IDs and blocked events are only reported when
the destination/routing peer is in userspace mode — plus the
command Linux operators use to force userspace mode.
Collapse the two duplicated inline notes in the Correlating events
section into short pointers to Limitations so the constraint and
command live in one canonical place.
* Update src/pages/manage/activity/traffic-events-logging.mdx
Co-authored-by: Viktor Liu <17948409+lixmal@users.noreply.github.com>
---------
Co-authored-by: Viktor Liu <17948409+lixmal@users.noreply.github.com>
* Add script to generate sitemap.xml and update related configurations
* chore: add robots.txt referencing sitemap.xml
---------
Co-authored-by: Jack Carter <128555021+SunsetDrifter@users.noreply.github.com>
The page jumped from h1 directly to h3, leaving no h2 heading and
breaking the docs build. Promote both NetworkRouter and NetworkResource
sections to h2 so the hierarchy is contiguous.
House style writes "Zero Trust" / "zero trust" without a hyphen
in prose. Sweep all hyphenated prose occurrences under `src/pages/`
to match.
URL slugs (e.g. `/use-cases/security/implement-zero-trust`) and
external links (CrowdStrike press release / blog URLs that include
`zero-trust` as a path segment) are intentionally preserved.
Earlier docs asserted that policies using `ALL`, `ICMP`, or portless
`TCP`/`UDP` must be bidirectional. Data-plane testing on NetBird
0.59.10 shows the engine honors the direction flag for every
protocol — peer-d's iptables only installs the destination-side
`ACCEPT` rule, so reverse-initiated traffic is dropped at the source
even when the policy uses `ALL` or `ICMP`. The greyed-out direction
toggle in the dashboard is a UX guardrail, not an enforcement gap.
- manage-network-access.mdx: rewrite the Policies overview and
Multiple Mesh Networks paragraphs; drop the outdated `Note`
callout; trim Creating Policies guidance.
- access-control/index.mdx: rewrite Protocol-Specific Behavior;
drop the "Always Bidirectional (regardless of UI setting)" list.
- implement-zero-trust.mdx: soften TCP/UDP+ports framing.
- troubleshooting-client.mdx: drop "always true for the protocol
`ALL`" clause from the bidirectional-rule bullet.
Network-resource (routing peer) policies remain genuinely
unidirectional — that statement preserved.
* fix(api-template): repair Go brace and collapse summary whitespace
The ApiTemplate accidentally emitted `{` instead of `}` for the closing
brace after the early-return error check in the Go example, leaving every
generated Go snippet syntactically invalid. The summary description was
also rendered raw, so multi-line OpenAPI descriptions broke the MDX
parser when the closing tag landed inside a JSX paragraph.
Fix the template at the source and regenerate the affected resource
pages so the API docs build cleanly again.
* chore: ignore generator tsbuildinfo
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(routing-peers): apply outstanding review feedback
- Drop the unverified Cloud-specific settings subsection (AWS/GCP/Azure
bullets) and the related AWS source/destination pitfall bullet
- Spell out "high availability" in the Masquerade note for clarity
* docs(routing-peers): expand inbound cross-links to How Routing Peers Work
Surface the routing peer primer from 11 high-leverage pages so readers
landing in a configuration or scenario guide can find the mental model
without having to backtrack through the sidebar.
- Index pages (manage/networks, manage/network-routes): move the
cross-link from the page top into the Routing Peer(s) subsection,
where it sits adjacent to existing routing-peer guidance
- exit-nodes scenario: cross-link inside the Routing Peer subsection,
anchored at #exit-node-mode
- internal-dns-servers: cross-link under Domain Resources and Routing
Peer DNS, anchored at #routing-peer-dns-resolution
- Procedural and comparison pages (access-control, by-scenario VPN-to-Site
guides, site-to-site overview, Kubernetes operator, routing peers in
Kubernetes): cross-link near the page top with section-specific anchors
* docs(routing-peers): spell out HA across the primer and cross-link notes
- Index-page cross-link notes (manage/networks, manage/network-routes):
expand "HA" to "high availability" in the bullet list
- Primer page: spell out the three remaining HA references in the High
availability section and Common pitfalls; use "highly available peers"
as the adjective form
* 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.
* docs: refresh CLAUDE.md for Next.js 16 toolchain and API sidebar
- Note Node.js >=20.9 requirement (Next 16 fails the build below this)
- Update dev/build descriptions to mention gen:edit-routes; add start
and gen:edit-routes to the common commands list
- Document the second sidebar file (NavigationAPI.jsx) alongside
NavigationDocs.jsx so the API sidebar is discoverable
* docs: add Security boundaries section to CLAUDE.md
Calls out four posture items relevant to AI-assisted contributions:
the repo is public, .env is committed and must hold placeholders only,
npm run gen pulls upstream main without pinning, and CLAUDE.md itself
is authoritative input to AI sessions and should be reviewed accordingly.
* Documented gen:last-updated and generated src/lib/ files
---------
Co-authored-by: TechHutTV <brandon@techhut.tv>
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.
Add the embedded IdP sync pages (Microsoft Entra ID API/SCIM, Google
Workspace, JumpCloud, Keycloak) under SELF-HOST NETBIRD so users can
discover them from the navigation instead of relying on direct links.
Regroup the Authentication subsection by purpose: Local Users, Identity
Provider Connectors (wraps Self-hosted and Managed IdPs), and Provision
Users & Groups.
* docs(macos): add CLI-only binary install and MDM deployment guide
Document the previously undocumented binary-only install path for macOS
using USE_BIN_INSTALL and SKIP_UI_APP flags. Add a new guide for
building custom CLI-only .pkg packages for MDM fleet deployment,
covering pkgbuild workflow, pre/postinstall scripts, setup key
enrollment, and update strategies.
* docs(macos): add warnings about unsigned binaries in tarballs
The darwin tarballs from GitHub releases contain unsigned binaries —
only the official .pkg goes through the sign pipeline. Add warnings
to both the install page and MDM guide, and document the full signing
workflow: codesign for the binary, pkgbuild --sign for the package,
and optional notarization via notarytool.
