* docs: add NetBird client compatibility to the operator support matrix
Add a "NetBird client compatibility" section to the Kubernetes operator
support matrix. Each operator release is built and tested against a
specific NetBird release and deploys that exact, digest-pinned client by
default, so a default install runs the supported combination. Document the
current pairing (operator v0.8.0 with NetBird v0.72.4), a table of tested
clients for recent releases, and that overriding routingClientImage is
neither supported nor tested.
Also replace an em dash in the Kubernetes compatibility section with two
plain sentences.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: ask for NetBird client version in operator issue reports
Address CodeRabbit review: the compatibility section makes the client
version part of the supported combination, so the reporting checklist now
asks for the NetBird client version and any routingClientImage override.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* docs: document the fallback when the client cannot manage firewall rules
Add a troubleshooting section for hosts that are missing the netfilter
modules the client's firewall rules depend on, such as the mark match used
for policy routing or ipset. Include the client log excerpt so the error is
findable by search, with timestamps, hostname and peer identifiers removed.
Document what actually happens. The client logs the failure and proceeds
with the userspace packet filter, so NetBird keeps working and keeps
filtering, and on a routing peer the forwarding path moves to userspace as
well. Remedies are ordered from narrowest to broadest, starting with
loading the missing module and the related environment variables before
reaching for --disable-firewall.
Warn that --disable-firewall is not the same as that automatic fallback.
The userspace filter does not take over, so NetBird enforces no access
control on the peer, and the operator has to recreate the restrictions with
the host's own firewall.
Reference the new section from the Synology install page, where these
netfilter match modules can be missing alongside the tun module already
covered there.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: reword the NB_USE_LEGACY_ROUTING line
Address CodeRabbit review: 'ip-rule based routing' was an incorrectly
hyphenated compound modifier. Reword so the sentence describes the fallback
directly and drops the compound modifier.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Branch offices with strict egress policies need stable outbound rules
toward main locations. Documents pinning --wireguard-port per peer plus
a static DNAT at the main site, with the no-inbound trade-off stated
and scoped, and cross-links from Incoming ports and the relayed-
connections troubleshooting note.
* fix: correct ICE candidate field semantics in troubleshooting docs
The ICE candidate (Local/Remote) field shows the selected pair only, so
every relayed connection reads -/- on both peers, even when STUN worked
and srflx candidates were gathered (symmetric NAT case). Lab-verified on
client 0.76.3 against NetBird Cloud.
- relayed-connections: fix the relay/relay sample to -/-; reword the
candidate table (the '-' row named one cause for a symptom with two);
replace the 'weaker side' heuristic, which cannot work when both sides
show '-', with a client-log method that splits the two causes; mark
'relay' as the legacy TURN fallback path
- troubleshooting-client: replace the 0.27.4 status sample with 0.76.3
output (Direct/Routes fields are gone; Relay server address and
Networks exist now) and update the field explanations to match
* docs: show Networks line with routed subnet and exit node in status sample
Verified output: a client's status -d lists the routes a routing peer
serves it under that peer's block (Networks: 0.0.0.0/0, 10.0.0.0/24),
while the trailing summary Networks line stays '-' unless this device
routes something itself. Adds a Networks field explanation.
* docs: accuracy and readability pass on status field docs
- status sample: kernel WireGuard interface implies Linux, so the sample
host is linux/amd64 now
- clearer table cells (candidate pair, not connection; per-row P2P
implications) and untangled the log-reading sentence
- consistent phrasing in the Relay server address and Networks field
explanations
* docs: expand srflx and prflx abbreviations in the candidate table
srflx (server-reflexive) and prflx (peer-reflexive) were used without
ever being expanded anywhere in the help pages.
* docs: mark turn.netbird.io as fallback-only on Ports & Firewalls
Since v0.29.0 (relay integration, #2244) clients relay through
*.relay.netbird.io and contact TURN only when that relay is unreachable
or the remote peer runs an older client. The rule stays recommended as
the last relay path.
* docs: include bare relay.netbird.io in the fallback-only note
Clients bootstrap against relay.netbird.io before being assigned a
regional *.relay.netbird.io host, so both belong in the reference.
* docs: trim the keep-this-rule advice from the fallback note
* docs: call the TURN relay legacy in the fallback note
Matches the 'Legacy fallback' wording in the relayed-connections
candidate table.
* docs: srflx plus failed checks does not skip the firewall steps
A gathered srflx candidate proves STUN discovery only; the failed
connectivity checks can still be a host firewall or a destination-scoped
egress policy, so clear Steps 4-5 on both peers before concluding
symmetric NAT.
Add a decision-flow guide for "NetBird feels slow" that helps a reader
find whether the tunnel, their own connection, a routing peer, or the app
is the real cause, instead of assuming NetBird is at fault.
The page leads with the path traffic takes, a one-minute Quick test that
resolves the two most common causes (a relayed peer, or the local
network), then a Start here checklist that links down to detail sections:
checking the connection with netbird status -d, setting a baseline with
iperf3 in both directions, isolating the slow hop, ruling out packet size
and inspecting firewalls, and separating startup delays from throughput.
Add a reusable PathFlow component that draws the hop-by-hop path as a
labelled icon flow, used for the overview, the routing-peer example, and
the recap. Wire the page into the docs sidebar and the troubleshooting
hub.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* docs: add Quantum Resistance check to client status and make its fields navigable
Two related updates to the NetBird client status troubleshooting section,
prompted by an incident where a peer stayed invisible until Quantum Resistance
was turned off:
- Document the `Quantum resistance` status field as a cause and fix. A peer with
Quantum Resistance enabled only connects to peers that also have it enabled, so
a mismatch can keep a peer from connecting. Cross-link the Quantum-Resistance
doc and its permissive mode.
- Convert the flat peer-field list into per-field h3 subsections (Connection
type, Direct, ICE candidate, Last WireGuard handshake, Quantum resistance,
Transfer status) so each appears in the On this page nav.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: tighten status field descriptions per review
- ICE candidate: describe relay/host as the local and remote ICE candidate
types, and point to Connection type for whether the path is P2P or relayed,
since a host candidate does not by itself mean the remote path is direct.
- Last WireGuard handshake: distinguish an empty value (no handshake yet) from
an old timestamp (a previous connection that is now stale).
- Quantum resistance: call Rosenpass post-quantum key exchange rather than
encryption.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* docs: explain macOS two-resolver-stack DNS behavior and the match-only vs primary nameserver split
Lab-validated against client 0.76.3 (macOS 26, NetBird Cloud):
- DNS troubleshooting: new Issue 5 'dig and host fail, but browsers and
curl work (macOS)' with the scoped-resolver vs resolv.conf explanation,
the language-runtime split table (pure-Go/dnspython/c-ares vs
getaddrinfo), and the Windows nslookup-vs-NRPT analog; renumbered
Issues 5-8 to 6-9; checklist step 6 now says why it prescribes
dscacheutil/Resolve-DnsName
- Internal DNS Servers: primary-vs-match now explains that match-only
leaves resolv.conf untouched on macOS; new warning that emptying a
match group's domains silently drops the search suffix (masked on
domain-joined Windows); split-horizon example gains the
route-everything-internal variant (the OpenVPN migration shape)
- DNS overview: macOS line now distinguishes scoped resolvers from the
primary case, where configd regenerates resolv.conf with NetBird's
resolver
* docs: add dashboard screenshot for the route-all-internal nameserver example
* docs: polish wording in the macOS DNS additions
* docs: promote the route-all-internal example to its own section
* docs: drop the Example prefix from the nameserver scenario headings
* docs: state the public-resolution prerequisite for an internal primary nameserver
* docs: make the direct-resolver check precise
* docs: anchor the scoped-resolver term to scutil output and split the dense solution paragraph
* docs: add corporate firewalls table to Ports & Firewalls
Add a "Corporate firewalls" section covering common enterprise firewall and
SASE products (Palo Alto, Fortinet, Cisco, Check Point, Zscaler, Netskope,
Cloudflare Gateway, Sophos, SonicWall, Barracuda). It explains how NetBird
behaves through a corporate firewall, that it falls back to the TCP/443 relay
when direct peer-to-peer is blocked so peers stay connected, and what to allow
per product, including which TLS inspection feature to exclude the NetBird
domains from.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: refine corporate firewalls section and cross-link from troubleshooting
Address review feedback on the new Corporate firewalls section:
- Distinguish the two firewall failure modes. Blocking outbound UDP falls back
to the TCP/443 relay, but TLS/DPI inspection of the control plane can prevent
connecting at all.
- Correct the STUN vs TURN roles. STUN enables direct connections, while TURN
and the relay service are the fallback, not a way to keep connections direct.
- Make the relay domains explicit in the inspection-bypass guidance, since a
*.netbird.io wildcard does not match the deeper *.relay.netbird.io hosts.
Cross-link the section from the relayed-connections guide (Step 3) and the
troubleshooting hub, since a corporate firewall blocking UDP is a common cause
of relayed connections.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: add Palo Alto source-NAT guidance and surface firewalls at relay escalation
Corporate firewalls: note that some enterprise firewalls apply per-destination
(symmetric) source NAT, which defeats hole punching and forces the relay. Add
the port-preserving fix, with Palo Alto's Persistent Dynamic IP And Port mode in
its row and a general note covering the pattern and UDP session timeouts.
Relayed connections: the symmetric-NAT cause is often a corporate firewall the
operator controls, so reference the Corporate firewalls section at the final
escalation step, and scope the earlier "no firewall tuning will change that"
claim to mobile and cloud NAT where it actually holds.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: address second review pass on corporate firewalls guidance
- Broaden the firewall failure modes beyond UDP blocking and TLS inspection to
include blocked or proxied outbound TCP/443 and strict destination egress,
which break the control plane before any inspection.
- Note that reaching the NetBird service endpoints does not by itself prove a
direct peer path, since a firewall can allow STUN/TURN yet block UDP to peer
addresses. Qualify the relayed-connections conclusion accordingly.
- Match the STUN/TURN fix to the transport that netbird status reports: STUN is
UDP 80/443/3478/5555, TURN is UDP 80/443 plus TCP 443-65535, rather than
applying STUN's UDP ports to TURN.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: drop TURN wording from corporate firewalls guidance
Refer to the outbound relay endpoints as "relay" rather than "STUN/TURN" and
"Relay (TURN)" in the Corporate firewalls section, in line with NetBird's relay
terminology. Endpoint hostnames are unchanged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: replace TURN wording with relay in user-facing docs
TURN is legacy in NetBird, so the user-facing docs now call it the relay
service:
- Ports & Firewalls: rename the "Relay (TURN) service" endpoint and split the
two relay endpoints by transport (UDP/TCP and TCP) to keep them distinct,
and drop TURN from the notes and the JSON-download line.
- Relayed-connections and troubleshooting hub: drop TURN from the status and
rollout wording and the connectivity chip label.
- Zero Trust use case: describe STUN and relay instead of STUN/TURN.
Endpoint hostnames (turn.netbird.io) and the netbird status output are
unchanged. Self-hosted coturn documentation is intentionally left as-is, since
there TURN refers to the actual legacy software.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: scope TURN wording changes to Ports & Firewalls and relayed connections
Revert the TURN wording in the troubleshooting hub chip and the Zero Trust use
case, keeping the TURN-to-relay rename limited to the Ports & Firewalls and
relayed-connections docs for now. The corporate-firewalls cross-link chip in
the hub stays.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: sort the corporate firewalls table alphabetically
Order the firewall and SASE rows alphabetically by product (Barracuda through
Zscaler) so readers can scan for their vendor.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: add pfSense and OPNsense to the corporate firewalls table
Add pfSense and OPNsense rows, each linking to its existing NetBird setup
section for keeping connections direct (Static Port outbound NAT, or
Endpoint-Independent NAT / EIM-NAT beta on pfSense). Broaden the table intro
from "enterprise" firewalls since these are open-source firewalls.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
The NetBird iOS app can now collect a debug bundle from Settings ->
Troubleshoot. Update the iOS troubleshooting page to use it and route
reports to Community Support, or NetBird Support for paying customers.
Also reference the iOS method from the canonical Debug bundle section
and update the iOS card on the client troubleshooting hub.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
The per-browser export steps led each bold browser label with an em
dash. Switch to a colon so each bullet reads as a clean
label-then-instruction, consistent with the other bullet lists in the
docs. Wording is otherwise unchanged.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Document the two failure modes when the NetBird CLI SSO login can't bind
its loopback callback port on Windows: bind forbidden (WSAEACCES, port
inside a Hyper-V/winnat reserved range) and address in use
(WSAEADDRINUSE, a stale process). Note that the redirect port is a
configured, IdP-registered set (default 53000, often 54000), not a
single hardcoded value, and cover cases where AV/EDR or other software
blocks the bind invisibly.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Link the existing "WireGuard port conflict on Domain Controllers"
guidance (on /manage/dns/internal-dns-servers) from two pages a
troubleshooting-hub user could not previously reach it from:
- Windows client troubleshooting: a bullet under Windows DNS scenarios
for the "NetBird won't start on a DC" symptom.
- DNS troubleshooting: a note after the AD/DC issue, disambiguating the
client-running-on-the-DC case.
No content duplicated; both are pointers to the one existing section.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
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>
* 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>
* docs: add persistent-route guidance for clientless devices and align site-to-site on Networks
Step 5 of both site-to-site guides (and the masquerade page) now walk a
first-time admin through persisting a Linux static route end to end:
detect Netplan vs systemd-networkd with `ls /etc/netplan/`, then a clear
Option A / Option B that are framed as alternatives, with the exact
editing mechanics (open in nano, save/exit keys, or a one-paste
systemd-networkd drop-in). Standardize on the `<IFACE>` placeholder with
an `ip -br addr` hint so a literal `eth0` can't silently misconfigure
hosts using predictable interface names.
Update the site-to-site use-case hub to recommend Networks for all
non-exit-node scenarios, rename "Network Routes" to "Routes", and
reconcile the comparison section with the Routes deprecation.
* docs: promote Routes site-to-site recommendation to a deprecation warning
Move the 'use Networks instead' callout above the Architecture section
and make it a Warning, matching the Routes deprecation. Keep the legacy
no-Policy nuance and the Site-to-VPN pointer; rename Network Routes to Routes.
* docs: correct Networks scenario support and mark Routes deprecated
- advanced-configuration: Networks supports all scenarios (VPN-to-Site,
Site-to-VPN, Site-to-Site), not VPN-to-Site only
- how-routing-peers-work: Routes labeled deprecated, not 'still supported'
* docs: import Note explicitly in site-to-site use-case page
Addresses CodeRabbit: <Note> was used without an explicit import from
@/components/mdx, relying on the global MDX provider.
* docs: repoint site-to-site cross-links to Networks
Site-to-site moved to Networks; update the homelab and cloud use-case
tiles/table and the access-home-devices and cloud-to-on-premise Next
Steps links to /manage/networks/use-cases/site-to-site.
* docs: rename Network Routes to Routes in prose and repoint advanced-config links
Bucket A rename (display text only): rename the 'Network Routes' feature
name to 'Routes' across prose, link labels, table cells, alt text, Tiles
names, and code comments. Headings are deliberately left unchanged to
avoid breaking anchors and inbound links; URL paths (/manage/network-routes)
are unchanged. Generic routing-table mentions and the desktop system-tray
UI label are left as-is.
Also repoint the access-home-devices and cloud-to-on-premise 'Advanced
configuration' Next Steps links from the Routes advanced-config page to
/manage/networks/masquerade.
* Update site-to-site documentation for clarity
Removed outdated information about using Routes for site-to-site connections.
* Update src/pages/manage/networks/use-cases/site-to-site.mdx
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
* Update section title from 'Networks vs Network Routes' to 'Networks vs Routes'
---------
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
* 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.
Adds docs for env variables for logging (including the new NB_LOG_DISABLE_ROTATION) and troubleshooting using external logging rotation (describing also new detection behavior).
* 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>
---------
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.
* This PR adds documentation explaining how NetBird interacts with host-based firewalls (Windows Firewall, UFW, iptables) and how to troubleshoot conflicts.
* Fix markdown formatting in troubleshooting-client.mdx
* Add sections for flat networks and routed VLANs without NAT
* Fix typo in UFW conflicts section
* Fix typo in UFW description in troubleshooting guide
