Deployment & Operations

deployment-operations — Round 1 Research Report

Session: 20260321-0115 Domain: Deployment Strategy, TacticalRMM, Multi-Site Operations, and Migration Date: 2026-03-21 Tools Used: mcp__claude_ai_Tavily__tavily_search, WebSearch, mcp__exa_websearch__web_search_exa, WebFetch

Executive Summary

This report answers 10 critical operational questions about deploying NetBird across GSISG’s two-site infrastructure (Honolulu 10.100.7.0/24, Boulder 10.15.0.0/24) using TacticalRMM for endpoint deployment. Key findings:

Windows MSI silent deployment is well-supported with SETUP_KEY and MANAGEMENT_URL MSI properties, plus /qn /norestart flags. The MSI installs a Windows service that auto-starts.
TacticalRMM can deploy NetBird via PowerShell scripts run against bulk agents. Scripts execute as SYSTEM, which is ideal for MSI installation. The recommended approach is a PowerShell script via Bulk Script or Automation Policy.
pfSense NetBird is NOT in the package manager — manual .pkg install required. Official packages are AMD64 only; the Netgate 6100 (ARM64) requires an unofficial community package.
Multi-site routing works automatically — each routing peer advertises its local subnet, and remote clients route to the correct site based on destination IP via longest-prefix match.
NetBird CAN replace IPsec site-to-site tunnels using bidirectional network routes with masquerade disabled.
On-premises detection is solved via Posture Checks (Peer Network Range) — not a native “trusted network” feature, but an effective workaround that blocks routes when a client is on the office subnet.
Auto-update exists (v0.61.0+) for Windows and macOS with central control, but has known bugs (settings reset after update).
GlobalProtect and NetBird CAN coexist but with a known issue: GlobalProtect triggers NetBird’s network monitor to restart the WireGuard interface. A fix (PR #5155) is in progress; workaround: --network-monitor=false.
Windows Firewall conflicts are manageable but EDR/AV products (CrowdStrike, Symantec, etc.) may need NetBird process exceptions. NetBird auto-creates firewall rules.
REST API provides peer status (connected, last_seen, OS, version, groups) but NOT bandwidth/transfer stats via API. CLI netbird status -d shows handshake times and transfer data. No native Zabbix template exists.

Answers to Mission Questions

Q1: Windows MSI Silent Deployment

Confidence: HIGH | Sources: NetBird Docs, Acronis Integration Guide, Chocolatey Package, ManageEngine

MSI Properties Available

Property	Purpose	Example
`SETUP_KEY`	Pre-authenticates the peer with a setup key	`SETUP_KEY=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX`
`MANAGEMENT_URL`	Points to management server (for self-hosted or NetBird Cloud)	`MANAGEMENT_URL=https://api.netbird.io:443`

These are the only two documented MSI custom properties. Standard MSI properties (/qn, /norestart, /Lv) also apply.

Silent Install Command

msiexec.exe /i "netbird_installer_0.66.4_windows_amd64.msi" /qn /norestart SETUP_KEY=<KEY> MANAGEMENT_URL=https://api.netbird.io:443

Or using the EXE installer with /S flag:

netbird_installer_0.66.4_windows_amd64.exe /S

Service Behavior

YES, the MSI installs a Windows service (the NetBird daemon)
YES, the service auto-starts. It runs as a background/system-wide daemon independent from the GUI application
The service starts on boot by default. Users can disable this with netbird up --disable-auto-connect or by setting "DisableAutoConnect": true in the config file at C:\ProgramData\NetBird\
Install path: C:\Program Files\NetBird

Two-Step Deployment Pattern

If SETUP_KEY is passed as an MSI property, the installer handles registration. If not, a post-install step is required:

& "C:\Program Files\NetBird\netbird.exe" up --setup-key <KEY> --management-url <URL>

Gotchas

The MSI property MANAGEMENT_URL was a feature request (GitHub #2171, #4788) — verify it works with your target version. Earlier versions required post-install CLI configuration.
The MSI does not surface errors well in silent mode; use /Lv <logfile> for verbose logging.
The installer requires Administrator privileges.

Q2: TacticalRMM Deployment Approach

Confidence: HIGH | Sources: TacticalRMM Docs (install_agent, scripting, howitallworks)

How TacticalRMM Executes Scripts

The TacticalRMM agent runs under the SYSTEM security context
Scripts are transferred via NATS, saved to a temp file in C:\ProgramData\TacticalRMM, executed, output captured, and temp file removed
Supported languages: PowerShell, Windows Batch, Python, Nushell, Deno

Recommended Deployment Approach: PowerShell Script via Bulk Script

Step 1: Create the deployment script in TacticalRMM Settings > Scripts Manager:

# NetBird Silent Deployment via TacticalRMM
param(
    [string]$SetupKey = "YOUR_SETUP_KEY_HERE",
    [string]$ManagementUrl = "https://api.netbird.io:443"
)

$InstallerUrl = "https://github.com/netbirdio/netbird/releases/latest/download/netbird_installer_0.66.4_windows_amd64.msi"
$InstallerPath = "$env:TEMP\netbird_installer.msi"
$LogFile = "$env:TEMP\netbird_install.log"

# Check if already installed
if (Test-Path "C:\Program Files\NetBird\netbird.exe") {
    Write-Host "NetBird already installed"
    & "C:\Program Files\NetBird\netbird.exe" version
    exit 0
}

# Download
Invoke-WebRequest -Uri $InstallerUrl -OutFile $InstallerPath -UseBasicParsing

# Install silently
$MsiArgs = @("/i", $InstallerPath, "/qn", "/norestart", "/Lv", $LogFile)
if ($SetupKey) { $MsiArgs += "SETUP_KEY=$SetupKey" }
if ($ManagementUrl) { $MsiArgs += "MANAGEMENT_URL=$ManagementUrl" }

$proc = Start-Process "msiexec.exe" -ArgumentList $MsiArgs -Wait -PassThru
if ($proc.ExitCode -ne 0) {
    Write-Error "Installation failed with exit code $($proc.ExitCode)"
    if (Test-Path $LogFile) { Get-Content $LogFile -Tail 50 }
    exit 1
}

# Verify
Start-Sleep -Seconds 5
if (Test-Path "C:\Program Files\NetBird\netbird.exe") {
    Write-Host "NetBird installed successfully"
    & "C:\Program Files\NetBird\netbird.exe" status
} else {
    Write-Error "Installation verification failed"
    exit 1
}

# Cleanup
Remove-Item $InstallerPath -Force -ErrorAction SilentlyContinue

Step 2: Deploy via Tools > Bulk Script or create an Automation Policy:

Bulk Script: Select Client/Site/All agents, choose the script, run as “Fire and Forget” or “Wait for Output”
Automation Policy: Attach the script as an Automated Task to run once or on schedule

SYSTEM vs User Context Gotchas

Concern	Detail
SYSTEM is perfect for MSI installs	MSI installations require admin privileges, SYSTEM has them
GUI won’t be visible to logged-in user	The daemon service installs fine, but the UI tray app won’t launch automatically for the user session
RunAsUser for post-install	If you need to launch the NetBird UI for users, use TacticalRMM’s “RunAsUser” option for a separate script
AV interference	TacticalRMM docs warn that AV may quarantine downloaded installers. Consider adding Defender exclusions first
Script execution policy	TacticalRMM handles execution policy internally; no need to set it manually

Alternative Approaches

Chocolatey: choco install netbird -y — available on Chocolatey Community repo (version 0.66.1 as of writing). Can be deployed via TacticalRMM’s built-in Chocolatey integration.
Software Deployment feature: TacticalRMM has built-in Chocolatey support under the agent’s Software tab, but custom MSI deployment via script gives more control over setup keys.

Q3: pfSense NetBird Package Installation

Confidence: HIGH | Sources: NetBird pfSense Docs, NetBird Forum, Netgate Forum, GitHub Issues

Package Status: NOT in pfSense Package Manager

The NetBird documentation explicitly states: “This installation is intended for early adopters while the pfSense package is under review and not yet available in the pfSense package manager.”

Current Package Versions (from docs)

Package	Version	Architecture
NetBird client	0.55.1	AMD64 only
pfSense GUI package	NetBird-0.1.0	AMD64 only

Note: These versions lag significantly behind the latest client (0.66.x). Check GitHub releases for newer pfSense-specific builds.

Installation Process (Manual)

# 1. SSH into pfSense
ssh admin@<pfsense-ip>

# 2. Download NetBird client package
fetch https://github.com/netbirdio/netbird/releases/download/v0.55.1/netbird-0.55.1.pkg

# 3. Download pfSense GUI package
fetch https://github.com/netbirdio/pfsense-netbird/releases/download/v0.1.0/pfSense-pkg-NetBird-0.1.0.pkg

# 4. Install both packages
pkg add -f netbird-0.55.1.pkg
pkg add -f pfSense-pkg-NetBird-0.1.0.pkg

# 5. Verify: VPN > NetBird should appear in pfSense menu

Post-Install Configuration

Navigate to VPN > NetBird in pfSense GUI
Enter Management URL and Setup Key
Click Save to authenticate
Assign the wt0 interface: Interfaces > Assignments > select wt0(wt0) > Add
Enable the interface (rename to e.g., NETBIRD)
Create firewall rules on the NetBird interface to permit traffic
Configure Outbound NAT: Add a Static Port rule for the NetBird interface to improve NAT traversal

The Netgate 6100 ARM64 Problem

This is a critical blocker. The Netgate 6100 uses ARM64 (aarch64) architecture. The official NetBird pfSense packages are AMD64 only.

Aspect	Detail
Official ARM64 support	NOT AVAILABLE
What happens if you try	pfSense GUI shows VPN > NetBird but the service will not start
Community workaround	Unofficial ARM package exists at `github.com/nhdIT/pfsense-netbird` — reported working
Official timeline	No commitment from NetBird team for ARM64 pfSense support
pfSense Plus ARM	pfSense Plus supports ARM64 on Netgate hardware, but CE does not have ARM builds

Recommendation: If the Netgate 6100 is the firewall at either site, consider:

Using the unofficial ARM package (risk: unsupported, may break on pfSense upgrades)
Running NetBird on a separate Linux VM/container behind pfSense as the routing peer instead
Installing NetBird on any Linux server at the site to serve as routing peer, bypassing pfSense entirely

pfSense Version Compatibility

The documentation does not specify CE vs Plus requirements. The package is a FreeBSD .pkg file that should work on both, but:

pfSense CE is AMD64 only
pfSense Plus supports ARM64 on Netgate hardware
FreeBSD ABI changes between major pfSense releases (e.g., FreeBSD 15 to 16) can break packages (seen in pfSense Plus 25.11 upgrade)

Q4: Multi-Site Routing with Routing Peers

Confidence: HIGH | Sources: NetBird Network Routes Docs, VyOS Site-to-Site Article, NetBird Knowledge Hub

How It Works

Yes, destination-based routing works automatically. Here is the exact flow:

Honolulu routing peer advertises 10.100.7.0/24 as a network route
Boulder routing peer advertises 10.15.0.0/24 as a network route
Both routes are distributed to peers in the specified Distribution Groups
A remote user’s NetBird client receives both routes and installs them in the local routing table
When the user accesses 10.100.7.x, traffic routes to the Honolulu routing peer
When the user accesses 10.15.x.x, traffic routes to the Boulder routing peer
This is automatic — standard longest-prefix-match IP routing, no user intervention needed

Route Selection Logic

NetBird selects routing peers based on:

Metric priority (lower = higher priority) for HA setups
Connection type: direct P2P preferred over relayed
Latency: lowest RTT wins (for P2P connections; relayed connections report 0ms latency — known limitation, GitHub #4603)

Configuration per Site

For each site, create a Network Route in the NetBird dashboard:

Network Range: e.g., 10.100.7.0/24
Routing Peer: select the peer at that site
Distribution Groups: select groups containing users who need access
Masquerade: Enable for simplicity (NAT), or disable for source IP transparency
Enable Route: toggle on

Key Detail: Routes Are Independent

Each route operates independently. There is no “site affinity” — routing is purely based on destination IP matching. A user can simultaneously access resources at both sites through their respective routing peers.

Q5: Replacing Existing IPsec Site-to-Site

Confidence: HIGH | Sources: NetBird Site-to-Site Docs, VyOS Article, Network Routes Access Control Docs

Can NetBird Replace IPsec Tunnels?

Yes, explicitly supported. NetBird’s documentation lists “Link branch offices” and “Bridge on-premise data centers” as core site-to-site use cases.

How Cross-Site Routing Works

For site-to-site (both sites’ devices can reach each other without NetBird agents):

Deploy a routing peer at each site (Linux machine, pfSense, or any supported OS)
Create network routes for each site’s subnet:
- Route 1: 10.100.7.0/24 via Honolulu routing peer, distributed to Boulder routing peer
- Route 2: 10.15.0.0/24 via Boulder routing peer, distributed to Honolulu routing peer
Masquerade setting for site-to-site:
- Masquerade OFF is recommended for site-to-site (per VyOS article: “Masquerade is deselected since we’re doing site-to-site routing”)
- When masquerade is off, you must add static routes on each site’s router pointing the remote NetBird subnet back through the local routing peer
- With masquerade ON, it works without static routes but you lose source IP visibility
Configure clientless devices at each site with a static route pointing to the local routing peer for the remote subnet

Static Route Requirements (Masquerade OFF)

On the Honolulu pfSense/router:

# Route to Boulder via local NetBird routing peer
Destination: 10.15.0.0/24
Gateway: <Honolulu routing peer LAN IP>

On the Boulder pfSense/router:

# Route to Honolulu via local NetBird routing peer
Destination: 10.100.7.0/24
Gateway: <Boulder routing peer LAN IP>

Also route the NetBird overlay subnet (default 100.x.0.0/16) through the routing peer if masquerade is off.

Coexistence During Migration

You can run NetBird site-to-site alongside the existing PA IPsec tunnel during migration. Both will install routes; ensure metrics/priorities don’t conflict. Test by adding the NetBird routes with higher metrics initially.

Access Control Caveat

Network Routes bypass ACL rules by default. The docs warn: “Unless configured explicitly, Network Routes ignore Access Control rules. This can lead to unexpected access.” For site-to-site with access control, create policies with masquerade enabled and bidirectional policies.

Q6: On-Premises Detection / Hairpin Traffic

Confidence: HIGH | Sources: NetBird Posture Checks Docs, GitHub Issues #1229, #5278

Native Trusted Network Detection

NetBird does NOT have a built-in “trusted network” auto-disconnect feature. This has been a recurring feature request (GitHub #1229, filed Oct 2023, closed; #5278, filed Feb 2026, still open).

Official Solution: Posture Checks (Peer Network Range)

NetBird provides an effective workaround using Posture Checks:

Create a Posture Check:
- Type: Peer Network Range
- Action: Block
- Network Ranges: 10.100.7.0/24 (Honolulu), 10.15.0.0/24 (Boulder)
Create a Policy:
- Source: user group (e.g., remote-users)
- Destination: routing peer group (e.g., site-routers)
- Attach the posture check
Result: When a client is on 10.100.7.x (physically in Honolulu office), the posture check blocks the route to the routing peer. Traffic uses the local LAN directly. When the user leaves and gets a different IP, routes activate automatically.

What This Does and Does NOT Solve

Scenario	Solved?	Detail
Prevents routing through NetBird when on office LAN	YES	Posture check blocks route distribution
Prevents hairpin traffic for routed subnets	YES	Routes not installed = traffic stays local
Disconnects NetBird entirely when on office LAN	NO	Peer-to-peer connections still establish
Prevents WireGuard tunnel overhead when in office	NO	Tunnel stays up, just routes not applied

Community Workaround: PowerShell Script

For complete disconnection, some organizations deploy a scheduled script:

# Check if on corporate subnet
$firmSubnets = @("10.100.7.0/24", "10.15.0.0/24")
$isInCorporateNetwork = <subnet-check-logic>

if ($isInCorporateNetwork) {
    & "C:\Program Files\NetBird\netbird.exe" down
} else {
    & "C:\Program Files\NetBird\netbird.exe" up
}

This can be deployed as a TacticalRMM Automated Task running every 5-10 minutes or triggered by Windows network change events.

Q7: Client Update Mechanism

Confidence: HIGH | Sources: NetBird Auto-Update Docs, GitHub Issues #832, #1793, #4019, #5128, #5236

Official Auto-Update Feature (v0.61.0+)

Setting	Detail
Minimum client version	v0.61.0
Minimum management server	v0.61.0 (self-hosted)
Supported platforms	Windows and macOS only (Linux NOT supported due to package manager diversity)
Default state	Disabled — must be enabled in dashboard
Configuration location	Settings > Clients in NetBird dashboard

Update Options

Latest stable release: automatically updates to newest version
Pin to specific version: locks all clients to a chosen version
Force updates: auto-installs without user prompt (causes brief connection disruption during restart)

How It Works

Peers receive update settings when connecting to management
Version comparison runs locally on the client
Outdated clients download from official repository
Client restarts to apply changes

Known Issues (as of March 2026)

Issue	Detail	Status
Settings reset after update	Windows/macOS clients forget enabled networks and exit nodes after auto-update (#5128)	Open
No server version pinning	Clients can update beyond the management server version, potentially breaking compatibility (#5236)	Open
Failed downloads don’t retry	Must wait for next client restart	By design
Notifications require UI	If NetBird UI is not running, no update notification shown	By design

TacticalRMM as Update Manager

For Linux endpoints or more control, TacticalRMM can handle updates:

Chocolatey: choco upgrade netbird -y via scheduled TacticalRMM task
PowerShell script: Download latest MSI and reinstall via scheduled Automated Task
Script Check: Create a TacticalRMM check that alerts when netbird version doesn’t match expected version

Q8: Rollback Strategy and GlobalProtect Coexistence

Confidence: MEDIUM-HIGH | Sources: GitHub Issue #5077, #2522, #1923, NetBird Windows Docs, Reddit

Can GlobalProtect and NetBird Coexist?

Yes, but with a known issue requiring a workaround.

Aspect	Detail
Can both be installed simultaneously?	YES
Can both run simultaneously?	YES, with caveats
Known issue	When GP connects, it adds a default route that triggers NetBird’s network monitor to restart the WireGuard interface, killing active TCP sessions (GitHub #5077)
Workaround	`netbird up --network-monitor=false` (disables network change detection)
Fix status	PR #5155 in progress — patches Windows soft interface detection to recognize GP’s “PANGP Virtual Ethernet Adapter Secure”
Affected versions	v0.60.0 through v0.62.1+
Affected platforms	Windows and macOS

WireGuard Port Conflict

NetBird defaults to UDP port 51820, same as standalone WireGuard. If WireGuard is also installed:

netbird up --wireguard-port 51821

Migration Strategy: Phased Rollout

Phase 1 - Install NetBird alongside GP: Both coexist. GP remains primary VPN. NetBird installs with --network-monitor=false flag until fix lands.
Phase 2 - Test NetBird routing: Enable NetBird routes for non-critical resources. GP still handles production traffic.
Phase 3 - Shift traffic: Gradually move users to NetBird routes. GP remains installed as fallback.
Phase 4 - Remove GP: Once stable, uninstall GlobalProtect.

Rollback Procedure

NetBird rollback is straightforward:

# 1. Disconnect NetBird
& "C:\Program Files\NetBird\netbird.exe" down

# 2. Uninstall via MSI (silent)
msiexec.exe /x "netbird_installer_*.msi" /qn /norestart

# 3. Or uninstall via Add/Remove Programs

# 4. Or via Chocolatey
choco uninstall netbird -y

# 5. GlobalProtect continues working -- no changes needed

The uninstall removes:

NetBird service
WireGuard interface (wt0)
Firewall rules added by NetBird
Program files from C:\Program Files\NetBird

Config data persists at C:\ProgramData\NetBird — delete manually if doing a clean removal.

DNS may need manual restoration if NetBird modified resolver settings (documented in NetBird DNS troubleshooting).

Q9: Windows Firewall, AV/EDR, and VPN Client Interactions

Confidence: HIGH | Sources: NetBird Troubleshooting Docs, GitHub Issues #1692, #3531, #4714

Windows Firewall

NetBird automatically creates Windows Firewall rules allowing all incoming traffic on the wt0 interface
This is by design and cannot be disabled without modifying NetBird source (GitHub #1692 is a feature request to prevent this)
Group Policy may override NetBird’s firewall rules — if GPO manages Windows Firewall, you may need to add NetBird rules to GPO

In non-NAT environments (flat office networks), an additional inbound UDP rule may be needed:

New-NetFirewallRule -DisplayName "NetBird P2P" -Direction Inbound -Action Allow -Protocol UDP -LocalPort 49152-65535 -Program "C:\Program Files\Netbird\netbird.exe"

Known AV/EDR Conflicts

Product	Issue	Resolution
Bitdefender MDR	Flags NetBird notification PowerShell script `fyne-NetBird-notify-1.ps1` as suspicious	Whitelist the script
Symantec Endpoint Protection	May block NetBird traffic	Add process exception for `netbird.exe`
CrowdStrike Falcon	May interfere with WireGuard kernel operations	Add exception for NetBird process and `wt0` interface
McAfee	Firewall component may block tunnel traffic	Temporarily disable McAfee firewall to test; add exception
Kaspersky	Similar firewall interference	Add NetBird to trusted applications
ESET	May quarantine NetBird components	Add folder exception for `C:\Program Files\NetBird`

General recommendation: Add C:\Program Files\NetBird\ to AV/EDR exclusion lists before deployment. The troubleshooting docs recommend: “Temporarily disable the third-party firewall component (not the entire product) to test if it’s blocking NetBird, then add exceptions for the NetBird process.”

NetBird EDR Integration (Posture Checks)

NetBird can also leverage EDR for posture enforcement:

Integrates with Huntress EDR, CrowdStrike, and others
Can block peers that don’t have EDR installed/compliant
Checks: Defender policy status, firewall active, AV up-to-date

Other VPN Client Conflicts

VPN	Coexistence	Notes
GlobalProtect	Works with workaround	See Q8; `--network-monitor=false`
NordVPN (WireGuard/NordLynx)	Fails	Both bind to WireGuard; routing conflicts
NordVPN (OpenVPN mode)	Works	Different tunnel technology
WireGuard standalone	Works	Must use different port (`--wireguard-port 51821`)
Tailscale	Problematic	Both manage WireGuard interfaces and DNS; constant log spam from DNS conflicts
OpenVPN	Generally works	Different tunnel technology; tested but may need investigation
Cisco AnyConnect	Not tested/documented	Likely similar to GP issues with route changes

Q10: Monitoring, Alerting, and API Access

Confidence: HIGH | Sources: NetBird Peers API Docs, CLI Docs, Traffic Events Docs, DeepWiki

REST API: Peer Status

Endpoint: GET /api/peers Authentication: Authorization: Token <API_TOKEN>

Available peer fields via API:

Field	Type	Description
`id`	string	Unique peer identifier
`name`	string	Peer hostname
`ip`	string	Assigned NetBird IP
`connected`	boolean	Current connection status
`last_seen`	timestamp	Last time peer was seen
`os`	string	Operating system
`version`	string	NetBird client version
`connection_ip`	string	Public IP of the peer
`hostname`	string	System hostname
`dns_label`	string	DNS label for the peer
`country_code`	string	Geographic location
`city_name`	string	City
`groups`	array	Group memberships
`ssh_enabled`	boolean	SSH access status
`login_expiration_enabled`	boolean	Login expiry setting
`approval_required`	boolean	Approval workflow status
`ui_version`	string	UI client version
`serial_number`	string	Device serial
`accessible_peers_count`	integer	Number of reachable peers

NOT available via API: Bandwidth usage, transfer stats, handshake times, latency.

Additional API Endpoints

Endpoint	Method	Purpose
`/api/peers`	GET	List all peers
`/api/peers/{id}`	GET	Get specific peer
`/api/peers/{id}`	PUT	Update peer settings
`/api/peers/{id}`	DELETE	Remove peer
`/api/peers/{id}/accessible-peers`	GET	List peers this peer can reach

CLI: Detailed Status (Handshake, Transfer)

netbird status -d provides per-peer detail:

Connection status (Connected/Disconnected)
Connection type (P2P/Relayed)
Last WireGuard handshake time
Transfer (bytes received/sent)
Latency (RTT)
Routes in use
Relay server in use

Traffic Events Logging

NetBird supports traffic event logging that can be streamed to a SIEM system:

Who initiated the connection
What resource was accessed
When it happened
Why it was allowed (which policy)

Zabbix Integration

No native Zabbix template exists. Custom integration approach:

Zabbix HTTP Agent items polling GET /api/peers for connected status and last_seen
Zabbix External Script running netbird status -d on the NetBird routing peers for handshake/transfer data
Triggers: Alert on connected=false, last_seen older than threshold, or stale handshake
Discovery: Use API to auto-discover peers and create host entries

Example Zabbix HTTP agent configuration:

URL: https://api.netbird.io/api/peers
Headers: Authorization: Token <TOKEN>
Request type: GET

Parse response with JSONPath preprocessing: $.peers[*].connected

Gaps & Uncertainties

#	Gap	Impact	Mitigation
1	Official NetBird pfSense ARM64 support — no timeline	HIGH for Netgate 6100 sites	Use Linux routing peer VM behind pfSense, or test unofficial ARM package
2	MANAGEMENT_URL MSI property may not work in older versions	MEDIUM	Test with target version; fall back to post-install CLI command
3	GlobalProtect coexistence fix (PR #5155) not merged yet	MEDIUM	Use `--network-monitor=false` workaround during migration
4	Auto-update resets client settings (bug #5128)	MEDIUM	Pin version via dashboard; use TacticalRMM for controlled updates instead
5	Network Routes bypass ACL rules by default	MEDIUM	Use Networks feature (not Network Routes) for ACL-governed access, or create explicit policies
6	No native Zabbix template	LOW	Build custom template using REST API + CLI parsing
7	Trusted network detection is not built-in	LOW	Posture Checks solve 90% of the use case; PowerShell script for the rest
8	Bandwidth/transfer stats not available via API	LOW	Parse CLI output or use traffic events logging for SIEM
9	pfSense package version (0.55.1) significantly lags latest client (0.66.x)	MEDIUM	Check GitHub for newer pfSense packages; may need to build from source

Sources & Tool Usage Log

Primary Documentation

GitHub Issues & PRs

Community & Third-Party

Tool Usage Summary

Tool	Calls	Purpose
mcp__claude_ai_Tavily__tavily_search	9	Primary search for deployment docs, pfSense, routing, site-to-site, TacticalRMM, updates, rollback, masquerade
WebSearch	4	Cross-reference auto-update, GlobalProtect coexistence, firewall/EDR conflicts, monitoring API
mcp__exa_websearch__web_search_exa	2	Deep search for on-premises detection, GlobalProtect coexistence
WebFetch	7	Fetch full documentation pages for auto-update, pfSense install, troubleshooting, API, posture checks, site-to-site, GlobalProtect issue