Research Synthesis

SYNTHESIS: NetBird as GlobalProtect Replacement for GSISG

Session: 20260321-0115 Date: 2026-03-21 Input: 5 Round 1 reports + 3 Round 2 correction reports (8 total) Domains Covered: Platform architecture, security/attack surface, AD/identity integration, deployment/operations, cost/compliance/risk, self-hosted feature parity, Boulder ARM64 correction, Azure sizing and GP coexistence

1. Executive Summary

GSISG should replace Palo Alto GlobalProtect on the PA-2020 with self-hosted NetBird on Azure. The PA-2020 reached End of Service Life on April 30, 2020 — it has been unsupported for nearly six years, runs PAN-OS 7.1 at best, and is a sitting target for the massive credential-spraying campaign that has been hitting GlobalProtect portals since December 2025 (1.7 million login attempts in a single 16-hour window, ongoing through at least February 2026). NetBird eliminates the exposed login portal entirely — there is no URL to spray credentials against — and replaces the aging IPsec/SSL stack with formally verified WireGuard encryption. The self-hosted deployment runs on a single Azure B2s VM (~$39/month) with zero license fees and integrates with GSISG’s existing Microsoft Entra ID for SSO and MFA. For the 90% of users who only connect to VPN for password resets, NetBird’s always-on tunnel (setup key, SYSTEM service, starts at boot) provides persistent DC connectivity that makes SSPR password writeback work seamlessly without any user interaction with the VPN client. The migration can be executed in 5 phases over 8 weeks with GlobalProtect running as a live fallback throughout, and the risk-adjusted cost of inaction ($31,000-$166,500/year in expected breach losses) dwarfs the one-time migration cost ($10,000). This is not an incremental security improvement; it is a categorical shift from an exposed, unpatched perimeter appliance to a zero-trust mesh architecture with no public attack surface.

2. Research Findings by Domain

2.1 NetBird Platform Features and Architecture

Key Findings:

NetBird v0.66.4 (March 11, 2026) is a mature open-source WireGuard mesh VPN: 23,700+ GitHub stars, 131+ contributors, 306+ releases, backed by the German Federal Ministry of Education and Research.
Since v0.62, the deployment is radically simplified: a single netbird-server container combines management, signal, relay, and STUN. Only 3-4 containers total are needed (server, dashboard, Traefik, optional DB).
Official minimum: 1 vCPU / 2 GB RAM for the management plane; the 100-peer limit bug (#1824) was fixed.
Split DNS, network routes, Networks (newer resource-based routing), and custom DNS zones (v0.63+) are all production features.
Built-in reverse proxy (v0.65+, beta) could eventually replace Cloudflare Tunnels for authenticated service exposure.
pfSense packages are NOT in the official pfSense package manager but are available via manual install. As of v0.1.25 (March 15, 2026), official packages ship for both x86_64 and aarch64, bundling NetBird client v0.66.4 and GUI package v0.2.2.
WireGuard tunnels survive management server outages (data plane is independent). Known issue: clients sometimes fail to auto-reconnect after prolonged outages.
NAT traversal uses ICE/STUN with QUIC relay (WebSocket fallback over TCP 443). Estimated >90% direct P2P in favorable conditions.

Confidence: HIGH. Sourced from official NetBird documentation, GitHub releases, and community reports.

Sources: docs.netbird.io (selfhosted-quickstart, scaling, networks, DNS, network-routes), github.com/netbirdio/netbird (releases, issues #1824, #5492), netbird.io/pricing, community comparison articles.

Gaps: Enterprise license pricing is not public. Management server HA requires an enterprise license. Exact resource consumption benchmarks at scale do not exist from the vendor.

2.2 Security Posture: GlobalProtect Attack Surface vs. NetBird

Key Findings:

The PA-2020 reached End-of-Sale April 30, 2015 and End-of-Service-Life April 30, 2020. Maximum PAN-OS: 7.1 (itself EOL June 30, 2020). No security updates of any kind are available.
The PA-2020’s TLS configuration is deprecated: TLS 1.0/1.1 enabled, 3DES ciphers, no forward secrecy, unsafe legacy renegotiation (CVE-2009-3555).
A massive credential-spraying campaign has been targeting GlobalProtect portals since December 2025: 1.7 million login attempts on December 11, 2025 alone (10,000+ source IPs). A February 2026 wave used 8,575 IPs across three coordinated waves. The campaign is assessed as ongoing.
While the most severe recent PAN-OS CVEs (CVE-2024-3400 CVSS 10.0, CVE-2024-0012 CVSS 9.3) require PAN-OS 10.2+, the PA-2020’s real vulnerability is that PAN-OS 7.1 has received zero patches for 6 years. Unknown vulnerabilities will never be fixed.
NetBird has NO exposed login portal. Authentication is delegated to the IdP (Entra ID) via OIDC. Peer connections use WireGuard cryptokey routing — either you have a valid cryptographic identity or the connection is silently dropped.
WireGuard has undergone extensive formal verification (Tamarin, CryptoVerif, ProVerif, SAPIC+/TAMARIN) — a rarity for VPN protocols. Its codebase is ~4,000 lines vs. ~100,000+ for IPsec/OpenSSL.
NetBird’s CVE history is minimal: CVE-2025-10678 (default credentials in install script, self-hosted only, fixed v0.57.0) and CVE-2024-41260 (static IV in audit events, required DB access, fixed v0.29.1). Neither affected the WireGuard data plane.
NetBird supports optional Rosenpass post-quantum key exchange (since v0.25.4) using Classic McEliece + ML-KEM, providing hybrid classical/quantum security. Status: experimental, desktop only.

Confidence: HIGH to VERY HIGH. Sourced from NVD, GreyNoise, BleepingComputer, ELLIO, Palo Alto Security Advisories, WireGuard formal verification papers, NetBird Trust Center.

Sources: GreyNoise credential campaign blog, BleepingComputer password spraying article, ELLIO GlobalProtect analysis, Palo Alto EoL pages, NVD (CVE-2024-3400, CVE-2024-0012, CVE-2024-9474), wireguard.com/formal-verification, cert.pl CVE-2025-10678, trust.netbird.io.

Gaps: PAN-OS 7.1 vulnerability exposure is inherently unknowable — researchers no longer test against it. Credential-spraying campaign status post-February 2026 is inferred, not directly confirmed.

2.3 AD Integration, Identity, SSPR, and Cached Credentials

Key Findings:

NetBird integrates with Microsoft Entra ID via OIDC App Registration (permissions: User.Read.All, Group.Read.All). Self-hosted uses JWT group sync (groups from the ID token, created/assigned at login); cloud uses background IdP-Sync (polls Microsoft Graph API continuously).
SSPR with password writeback requires Entra ID P1 (or M365 Business Premium). The writeback flow uses 2048-bit RSA + 256-bit AES-GCM encryption over TLS via Azure Service Bus relay. No inbound firewall rules are needed.
The cached credential problem is well-documented by Microsoft: hybrid AD-joined devices require DC line-of-sight after SSPR to update cached credentials. Without it, the user cannot log in with the new password.
NetBird solves this via a machine-level always-on tunnel using setup keys: the Windows service starts at boot under the SYSTEM account, establishes the WireGuard tunnel before any user logs in, and provides DC connectivity at the login screen. This is confirmed working by community testing (GitHub #1661).
True pre-logon user authentication (PLAP/credential provider) is NOT supported — this is an open feature request (#2809, #4207). The setup key approach authenticates the machine, not the user, which is sufficient for the SSPR use case but means any user on the device gets tunnel access.
Required ports through the tunnel: DNS (53), Kerberos (88, 464), LDAP (389, 636), SMB (445), RPC (135, 49152-65535), NTP (123), Global Catalog (3268, 3269).
Role-based access control is fully supported: general users can be restricted to DC-only access while engineers get full LAN access via NetBird policies synced from Entra ID groups.

Confidence: HIGH. Sourced from Microsoft Learn, NetBird documentation, GitHub issues, Microsoft TechCommunity.

Sources: Microsoft Learn (SSPR writeback, SSPR licensing, cached credentials FAQ), docs.netbird.io (idp-sync, posture-checks, access-control), GitHub #1661, #2809, #4207.

Gaps: Exact IdP sync interval for self-hosted is undocumented. Self-hosted JWT sync shows group GUIDs by default rather than display names. Automatic deprovisioning does not exist in self-hosted.

2.4 Deployment Strategy, TacticalRMM, and Operations

Key Findings:

Windows MSI silent deployment is well-supported: msiexec /i netbird.msi /qn /norestart SETUP_KEY=<KEY> MANAGEMENT_URL=<URL>. The MSI installs a Windows service that auto-starts at boot.
TacticalRMM deploys NetBird via PowerShell scripts executed as SYSTEM (ideal for MSI installs). Bulk Script or Automation Policy are the recommended mechanisms. A detailed deployment script template was produced. Chocolatey (choco install netbird -y) is also available.
Multi-site routing works automatically: each routing peer advertises its subnet, and clients route to the correct site via longest-prefix match. No user intervention needed.
NetBird can replace IPsec site-to-site tunnels using bidirectional network routes with masquerade disabled (for source IP transparency) or enabled (for simplicity).
On-premises detection uses Posture Checks (Peer Network Range): when a client is on the office subnet, the route to the routing peer is blocked so traffic stays on the local LAN.
Auto-update exists for Windows/macOS (v0.61.0+) but has known bugs: settings reset after update (#5128), no server version pinning (#5236). TacticalRMM can serve as a more controlled update mechanism.
GlobalProtect and NetBird CAN coexist but with a known issue (#5077): GP triggers NetBird’s network monitor to restart the WireGuard interface. Workaround: --network-monitor=false. Fix (PR #5156) is open but not merged.
REST API provides peer status (connected, last_seen, OS, version) but NOT bandwidth/transfer stats. CLI netbird status -d provides handshake times and transfer data. No native Zabbix template exists.

Confidence: HIGH. Sourced from NetBird docs, TacticalRMM docs, GitHub issues/PRs, community guides.

Sources: docs.netbird.io (Windows install, pfSense install, network-routes, auto-update, posture-checks, peers API), TacticalRMM docs (install_agent, scripting, howitallworks), GitHub #5077, #5155, #5156, #5128, #5236, #1229.

Gaps: GlobalProtect coexistence fix (PR #5156) merge timeline is unknown. Auto-update settings-reset bug (#5128) is open. MANAGEMENT_URL MSI property may not work in older versions.

2.5 Cost, Compliance, and Risk

Key Findings:

Self-hosted NetBird is genuinely free for unlimited users/machines with zero license fees. The only cost is Azure infrastructure.
PA-2020 replacement cost (staying with Palo Alto): $10,000-$27,000 Year 1 for PA-1420/PA-3220 + subscriptions + support; $76,000-$94,000 over 5 years.
Self-hosted NetBird on Azure: ~$10,000 Year 1 (including migration labor); ~$26,000 over 5 years. Savings: ~69% vs. new PA hardware over 5 years.
If GSISG already has M365 Business Premium or M365 E3, Entra ID P1 is included at no additional cost. Standalone P1 is $6/user/month if needed.
Compliance: Neither GlobalProtect nor NetBird has inherent compliance advantages. WireGuard encryption + Entra ID MFA + access logging satisfies SOC 2, CMMC Level 1-2, and applicable state privacy laws (Colorado Privacy Act in effect; Hawaii has no comprehensive privacy law yet).
Insurance: Companies using self-managed VPNs are 11x more likely to experience ransomware (At-Bay data). 58% of ransomware claims start with VPN/firewall compromise (Coalition). Running EOSL hardware is an underwriting red flag that may increase premiums or result in claim denial.
Risk-adjusted cost of staying on PA-2020: $31,000-$166,500/year in expected losses from credential compromise, ransomware, data breach, and insurance claim denial.

Confidence: MEDIUM-HIGH for TCO (some labor estimates assumed), HIGH for compliance and insurance findings.

Sources: netbird.io/pricing, cloudprice.net (Azure VM pricing), microsoft.com (Entra ID pricing), samexpert.com (Entra licensing guide), At-Bay ransomware data, Coalition Cyber Threat Index 2025, Zscaler 2025 VPN Risk Report, stambaughness.com (CMMC for AEC firms).

Gaps: GSISG’s exact M365 licensing tier is unknown (determines if Entra ID P1 is already included). PA-2020 subscription status is unconfirmed. Current cyber insurance policy exclusions are unknown. NetBird enterprise license pricing is not public.

2.6 Self-Hosted Feature Parity (Round 2 Correction)

Key Findings:

Self-hosted NetBird is NOT feature-equivalent to the cloud version. Eight specific capabilities are lost:
1. IdP-Sync (background provisioning) — cloud Team+ only. Self-hosted uses JWT group sync at login.
2. SCIM provisioning — requires enterprise license for self-hosted.
3. Peer approval — cloud Business+ only.
4. Traffic events logging — cloud Business+ only.
5. Audit & traffic events streaming (SIEM) — cloud Business+ only.
6. MDM & EDR integration (posture checks) — cloud Business+ only.
7. Device posture checks — cloud Business+ only.
8. User invites (email) — cloud Team+ only.
Round 1 INCORRECTLY listed Device Posture Checks, Traffic Events Logging, and Audit Events Streaming as available in self-hosted. They are cloud-only.
JWT group sync (self-hosted) shows group GUIDs instead of display names and has a 200-group-per-token limit. More critically, it does not automatically deprovision users — disabled Entra users cannot re-authenticate but existing sessions persist until expiry.
Local user management (v0.62+) with embedded Dex IdP provides fallback/admin access alongside Entra ID OIDC.
AGPLv3 license on server components (since v0.53.0) has ZERO implications for internal organizational use. The client remains BSD-3. AGPL obligations trigger only when offering modified server code as a service to external users.

Confidence: VERY HIGH. Sourced from netbird.io/pricing, official self-hosted vs. cloud comparison, AGPL announcement, and detailed documentation review.

Sources: netbird.io/pricing, docs.netbird.io (self-hosted-vs-cloud, identity-providers, local users, plans-and-billing), netbird.io/knowledge-hub (AGPL announcement, v0.62 local users), GitHub #2073, #5335.

Gaps: Whether traffic events logging and SIEM streaming are available via the self-hosted enterprise license (as opposed to cloud-only) is not explicitly confirmed.

2.7 Boulder ARM64 Correction (Round 2)

Key Findings:

The Netgate 6100 is NOT ARM64. It uses an Intel Atom C3558 (AMD64/x86_64). The ARM64 blocker identified in Round 1 does not exist.
Official NetBird pfSense packages (v0.1.25, March 15, 2026) now provide both x86_64 and aarch64 builds with client v0.66.4 and GUI package v0.2.2. The Round 1 documentation referencing v0.55.1 (AMD64 only) was outdated.
NetBird can be installed directly on the Netgate 6100 pfSense using official x86_64 packages. No workaround, no Linux VM, no OPNsense migration is needed.
ARM64 Netgate models (SG-1100, SG-2100, SG-3100) DO exist but are not what Boulder uses.
A Linux VM routing peer on Hyper-V (DATA001 or DATA007) remains a valid fallback if GSISG prefers not to install third-party packages on the production firewall.

Confidence: DEFINITIVE. Sourced from Netgate official product page, Netgate manual PDF, GitHub API enumeration of release assets.

Sources: shop.netgate.com (6100 product page), docs.netgate.com (6100 manual PDF), github.com/netbirdio/pfsense-netbird/releases, freshports.org/security/netbird.

Gaps: Exact pfSense Plus version running on Boulder’s Netgate 6100 should be confirmed before package installation.

2.8 Azure Sizing and GP Coexistence (Round 2)

Key Findings:

B2s (2 vCPU / 4 GB) is the correct VM size, not B1ms. The extra $15/month eliminates risk for mass reconnection events, relay spikes, and future growth to 250 peers.
SQLite is adequate for 100-150 peers; PostgreSQL is overkill. The real bottleneck is events.db bloat, mitigated by periodic cleanup.
Embedded relay is sufficient: ~5-15% of connections will be relayed, generating <15 Mbps peak. A separate relay server adds $15-30/month with no benefit at this scale.
Total Azure cost: ~$39/month pay-as-you-go or ~$28/month with 1-year reserved instance. Bandwidth is effectively free (2-6 GB/month, within Azure’s 100 GB free tier).
GP coexistence issue (#5077) is caused by NetBird’s network monitor detecting GP’s virtual adapter route changes, not by actual routing conflicts. The routes (100.64.0.0/10 overlay vs. corporate subnets) do not overlap.
PR #5155 was closed without merging. PR #5156 remains open and unmerged as of March 2026. --network-monitor=false is the only workaround.
Side effects of --network-monitor=false are manageable: Wi-Fi network switches may take 25+ seconds to reconnect (WireGuard keepalive timeout) instead of instant re-detection.

Confidence: HIGH. Sourced from GitHub issues #5077/#5155/#5156/#4488/#1473, Azure pricing databases, community deployment reports.

Sources: GitHub #5077, #5155, #5156, #4488, #1473, cloudprice.net (B2s pricing), Azure bandwidth pricing page, HN NetBird discussion, carlpearson.net (self-hosting guide), Cloudron forum.

Gaps: PR #5156 merge timeline is unknown. GP full-tunnel vs. split-tunnel mode at GSISG is unconfirmed.

3. Cross-Domain Synthesis

3.1 ARM64 Correction — Deployment Blocker Eliminated

Round 1 (deployment-operations report) identified the Netgate 6100 at Boulder as ARM64, calling it a “critical blocker” requiring workarounds (unofficial community packages, Linux VM behind pfSense, or bypassing pfSense entirely). Round 2 definitively corrected this: the Netgate 6100 uses an Intel Atom C3558 (AMD64). Furthermore, even the ARM64 concern was doubly obsolete because official aarch64 pfSense packages now exist (v0.1.25, March 2026).

Practical impact: Boulder deployment is straightforward — install x86_64 packages directly on pfSense in ~15 minutes. No additional infrastructure, no additional cost, no Hyper-V VM coordination needed.

Additionally, the Round 2 research discovered that the pfSense packages are far more current than Round 1 reported (v0.66.4 vs v0.55.1), and now include aarch64 builds. The 11-version lag cited in Round 1 no longer applies.

3.2 Self-Hosted Feature Parity — What Is Actually Lost and Does It Matter for GSISG?

Round 1 (cost-compliance report) listed several cloud-only features as available in self-hosted, creating a misleading picture. Round 2 corrected this, revealing that device posture checks, traffic events logging, SIEM streaming, and EDR integration are all cloud-only (Business+ plan).

For GSISG’s specific situation, the impact assessment is:

Lost Feature	Impact for GSISG	Why
IdP-Sync (background)	MEDIUM	Manual offboarding needed; JWT sync works at login. Manageable at 100 users with a documented checklist.
Device posture checks	LOW	No evidence GSISG uses CrowdStrike/SentinelOne or needs OS version enforcement.
Traffic events / SIEM	LOW	No evidence GSISG has a SIEM or needs connection-level audit trails.
Peer approval	LOW	Setup key distribution + expiration provides equivalent enrollment control.
SCIM	LOW	100 users is manageable without fully automated provisioning.
Audit event streaming	LOW	Management server logs accessible via API and dashboard; manual aggregation is sufficient.
MDM/EDR integration	LOW	Enforce compliance through Intune separately if needed.
User email invites	LOW	Share setup keys or login URL directly.

The most significant operational gap is deprovisioning: when an employee is terminated in Entra ID, their NetBird sessions persist until session expiry. This requires a documented offboarding checklist (disable in Entra ID + manually remove from NetBird dashboard). Setting login expiration to 24 hours limits the window of exposure.

3.3 The SSPR + NetBird Always-On + Cached Credentials Chain

This is the most important cross-domain finding, synthesizing the AD integration, deployment, and platform reports. It addresses the ~90% of users who only connect to VPN for password resets.

The complete technical chain:

NetBird tunnel is already UP — installed with a setup key, the Windows service runs under SYSTEM and starts at boot, providing DC connectivity before any user logs in. The user never interacts with the VPN client.
User resets password via SSPR portal (passwordreset.microsoftonline.com) from any browser, completing MFA via Entra ID.
Password writeback sends the new password to on-prem AD via Azure Service Bus relay, encrypted with 2048-bit RSA + AES-256-GCM. Entra Connect applies it to the AD DS forest.
User locks workstation (Win+L), then unlocks with the NEW password.
Windows validates the new password by sending it through the NetBird tunnel to the DC on Kerberos port 88.
DC issues new TGT and Windows updates the local cached credential hash.
Done. User is logged in with new password. No IT support ticket, no manual VPN connection.

Protocols/ports required through the tunnel: DNS (53), Kerberos (88, 464), LDAP (389), NTP (123), SMB (445), RPC (135, 49152-65535), Global Catalog (3268, 3269).

Edge cases handled:

User logs in with OLD cached password first: Lock -> Unlock with NEW password still updates the cache.
Machine offline >30 days: Computer account password does NOT expire (Microsoft confirmed: client initiates change, bails out if DC unreachable).
CachedLogonsCount = 0: DC connectivity required at every login; NetBird always-on tunnel becomes critical for all logins, not just password resets.
Kerberos time skew: NTP (port 123) through the tunnel prevents clock drift beyond the 5-minute tolerance.
AD replication lag: New password may fail briefly on non-primary DCs. Resolves within minutes.

The VPN becomes invisible infrastructure. For the ~90% of users who only needed GlobalProtect for password resets, they will never see or interact with NetBird. The tunnel runs silently, the password reset works via the web, and cached credentials update automatically through the tunnel.

3.4 Cost Analysis Reconciliation

Round 1 produced conflicting Azure cost estimates. Round 2 resolved them:

Component	R1 (Cost Report)	R1 (Platform Report)	R2 (Corrected)
VM size	B1ms ($15/mo)	B2s ($30/mo)	B2s ($30/mo)
Relay	Embedded	Separate B1ms ($15-30/mo)	Embedded
Database	Not specified	Azure PostgreSQL ($25/mo)	SQLite (free)
Total Azure	~$30/mo	~$70-85/mo	~$39/mo

The corrected 5-year TCO comparison:

Option	Year 1	Year 5	5-Year Savings vs PA-1420
Keep PA-2020 (direct cost only)	$7,200	$36,000	—
Keep PA-2020 (risk-adjusted, low end)	$38,200	$191,000	—
Replace with PA-1420	$22,200	$85,000	Baseline
Self-hosted NetBird (P1 included)	~$10,000	~$26,000	~69%
NetBird Cloud (Team plan)	$12,300	$43,500	~49%

Year 1 difference between B1ms and B2s VMs: ~$180/year. This is negligible relative to the risk mitigation value.

3.5 Security Posture Improvement Quantified

The security improvement is categorical, not incremental. When the security, cost, and insurance research are read together:

Vector	PA-2020 (Current)	NetBird (Proposed)
Exposed login portal	YES (vpn.gsisg.com)	NONE
Credential spraying surface	Active target in ongoing campaign	Architecturally impossible
Encryption	TLS 1.0/1.1 + 3DES (broken)	WireGuard ChaCha20-Poly1305 (formally verified)
Forward secrecy	No	Built-in (ephemeral keys per handshake)
CVE patch cadence	Zero (EOSL, no patches since 2020)	2-3 releases/week
Formal verification	None	5+ independent analyses
Authentication model	Username/password to exposed portal	OIDC + WireGuard cryptokey routing
MFA	Likely unavailable on PAN-OS 7.1	Enforced by Entra ID Conditional Access
Zero Trust	Perimeter-based (VPN zone = trusted)	Identity-based, per-resource policies
Cyber insurance impact	Negative (EOSL, 11x ransomware risk)	Neutral to positive (ZTNA, current patching)

4. Critical Corrections from Round 2

These corrections are essential for credibility. Round 1 contained factual errors that would have led to wrong decisions if uncorrected.

#	Round 1 Claim	Round 2 Correction	Impact
1	”Netgate 6100 uses ARM64 (aarch64) architecture”	WRONG. Netgate 6100 uses Intel Atom C3558 (AMD64/x86_64). Verified from Netgate product page and manual.	Eliminates the biggest identified deployment blocker. Direct pfSense installation is possible.
2	”Official NetBird pfSense ARM64 support: NOT AVAILABLE”	OUTDATED. Official aarch64 packages exist since at least March 2026 (v0.1.25).	Even for actual ARM64 devices, the blocker no longer exists.
3	”NetBird pfSense client version: 0.55.1, GUI package: v0.1.0”	OUTDATED. Current versions: client v0.66.4, GUI v0.2.2. Six releases in March 2026 alone.	The 11-version lag cited in Round 1 no longer applies. Packages are current.
4	”Self-hosted includes Device Posture Checks, Traffic Events Logging, Audit Events Streaming” (cost-compliance table)	WRONG. All three are cloud-only (Business+ plan). The self-hosted vs cloud comparison page explicitly lists these as cloud-only.	Self-hosted feature set is more limited than Round 1 suggested. Affects compliance assessment.
5	”Azure B1ms (~$15/mo) is sufficient for 100+ peers”	Risky. B2s ($30/mo) is the correct recommendation. B1ms works for management plane only but is CPU-constrained during relay spikes and mass reconnection events.	Cost estimate increases by ~$15/month but eliminates operational risk.
6	”Separate relay server(s) needed on B1ms/B2s ($15-30/mo each)“	UNNECESSARY. Embedded relay handles <15% relayed connections at this scale. Only ~1-3 connections will be relayed simultaneously.	Eliminates $180-360/year in unnecessary infrastructure.
7	”PostgreSQL recommended for 100+ peers”	OVERKILL. SQLite is adequate for 100-150 peers with periodic events.db cleanup. PostgreSQL threshold is ~300+ peers or 100+ policies.	Eliminates ~$150-300/year in unnecessary managed DB costs.
8	”Community workaround needed: unofficial ARM package at nhdIT/pfsense-netbird”	SUPERSEDED. Official packages now cover both architectures. The nhdIT fork is no longer needed.	Eliminates reliance on unsupported community fork.

5. Unresolved Questions

Requiring GSISG Input (Cannot Be Resolved by Research)

GSISG’s exact Microsoft 365 licensing tier. Determines whether Entra ID P1 is already included (M365 Business Premium or E3 = yes, included at no extra cost) or requires separate purchase ($6/user/month = $7,200/year for 100 users). This is the single largest variable in the cost analysis.
Current GlobalProtect tunnel mode (split-tunnel vs. full-tunnel). Affects coexistence strategy during migration. Split-tunnel is straightforward; full-tunnel requires adding NetBird management server IP to GP’s exclusion list to avoid double encapsulation.
Exact PAN-OS version running on vpn.gsisg.com. Research confirms max is 7.1 but actual could be older (6.x), which would be even worse.
Current cyber insurance policy specifics. EOSL exclusions and VPN-related coverage limitations need review.
Whether GSISG holds DoD/federal contracts requiring CMMC compliance. Affects documentation requirements for the migration.
pfSense Plus version running on Boulder’s Netgate 6100. Should be confirmed before package installation to ensure FreeBSD ABI compatibility.
What Honolulu uses as its firewall/routing device. Round 1 mentions pfSense at both sites but does not specify the Honolulu hardware model.

Requiring Further Investigation or Monitoring

PR #5156 merge timeline. Determines when --network-monitor=false workaround can be removed. Can be monitored passively by watching NetBird releases.
NetBird enterprise license pricing. Needed only if GSISG decides SCIM or management HA is required. Contact sales@netbird.io.
SSPR at the Windows login screen with NetBird tunnel routing. The SSPR “Reset Password” link uses a temporary defaultuser1 account that needs internet access on port 443. If NetBird is split-tunnel (default), this should work. Needs validation in pilot phase.
Multi-site DC affinity. With DCs at both Honolulu and Boulder, how NetBird routing peer configuration interacts with AD Sites and Services / SRV record-based DC selection has not been validated. Windows should automatically select the nearest DC via SRV record weights.
Exact IdP JWT group sync interval on self-hosted. Documented only as “regular intervals.” Needs empirical testing in pilot phase.

6. Final Deliverable: Executive Proposal with Technical Implementation Plan

A. Recommended Architecture

                          INTERNET
                             |
                    Azure West US 2
              +----------------------------+
              |  NetBird Management Server  |
              |  Standard_B2s (2 vCPU/4 GB) |
              |  Ubuntu 24.04 LTS           |
              |  Docker Compose:            |
              |   - netbird-server          |
              |     (mgmt+signal+relay+STUN)|
              |   - dashboard (nginx)       |
              |   - traefik (TLS)           |
              |  SQLite (default DB)         |
              |  Public IP: static          |
              +----------------------------+
                     |              |
            WireGuard P2P    WireGuard P2P
                     |              |
       +-------------+    +-------------+
       |  HONOLULU    |    |   BOULDER    |
       |  Routing Peer|    |  Routing Peer|
       |  (pfSense or |    | Netgate 6100 |
       |   Linux VM)  |    |  (pfSense)   |
       | 10.100.7.0/24|    | 10.15.0.0/24 |
       +------+-------+    +------+-------+
              |                    |
     +--------+--------+  +-------+--------+
     | DCs, file shares,|  | DCs, file shares,|
     | CAD/GIS/SAGE     |  | CAD/GIS/SAGE     |
     | servers          |  | servers           |
     +------------------+  +------------------+
              |                    |
     Endpoints (NetBird client, setup key, always-on)

Management Server:

VM: Azure Standard_B2s (2 vCPU, 4 GB RAM) in West US 2
OS: Ubuntu 24.04 LTS
Deployment: Docker Compose with 3 containers (netbird-server, dashboard, traefik)
Database: SQLite (default; migrate to PostgreSQL only if >300 peers or events.db bloat)
Relay: Embedded in netbird-server (sufficient for <15% relayed connections)
DNS: Public domain pointing to the VM’s static IP (e.g., netbird.gsisg.com)
TLS: Automatic via Traefik + Let’s Encrypt

Routing Peers:

Honolulu: Install NetBird on the site firewall (pfSense) or a dedicated Linux VM on the LAN. Register with a reusable, non-expiring setup key. Advertise network route 10.100.7.0/24.
Boulder: Install NetBird directly on the Netgate 6100 (pfSense) using official x86_64 packages (netbird-0.66.4-x86_64.pkg + pfSense-pkg-NetBird-0.2.2-x86_64.pkg). Register with a reusable, non-expiring setup key. Advertise network route 10.15.0.0/24. Configure Outbound NAT with a static port rule for improved NAT traversal.
Fallback for Boulder: Linux VM on Hyper-V (DATA001 or DATA007), 1 vCPU / 512 MB RAM / 8 GB disk, static IP 10.15.0.20.

Client Deployment:

Tool: TacticalRMM PowerShell script (Bulk Script or Automation Policy)
Installer: NetBird MSI, silent install with SETUP_KEY and MANAGEMENT_URL properties
Service: Windows service under SYSTEM account, auto-starts at boot (always-on)
Migration flag: --network-monitor=false while GlobalProtect is co-installed
Setup keys: Reusable key per office/group, with reasonable expiration (e.g., 90 days)

Identity:

Method: Entra ID as external OIDC provider on self-hosted NetBird (v0.62+ embedded Dex IdP)
SSO: Users authenticate via Microsoft button on NetBird login page
MFA: Enforced by Entra ID Conditional Access policies
Group sync: JWT group sync at login (groups from ID token groups claim)
Local admin accounts: 2-3 break-glass local accounts for emergency access
Offboarding: Manual removal from NetBird dashboard when employee is terminated in Entra ID (documented procedure required)

Password Reset Flow:

SSPR enabled with password writeback (requires Entra ID P1 or M365 Business Premium)
NetBird setup-key tunnel provides DC connectivity at boot (before user login)
User resets password via SSPR portal, then locks + unlocks workstation with new password
Windows validates new password against DC through NetBird tunnel, updates cached credentials
No IT support ticket, no manual VPN connection — fully self-service

B. Revised Cost Analysis

Self-Hosted NetBird on Azure (Recommended)

Cost Category	Monthly	Year 1	Year 3	Year 5
Azure B2s VM (1-yr reserved)	$19.13	$229.56	$688.68	$1,147.80
OS Disk (P4 32 GB Premium SSD)	$5.28	$63.36	$190.08	$316.80
Public Static IP	$3.65	$43.80	$131.40	$219.00
Bandwidth (egress, within free tier)	$0.00	$0.00	$0.00	$0.00
NetBird license	$0.00	$0.00	$0.00	$0.00
Entra ID P1 (if not already included)	$0 - $600	$0 - $7,200	$0 - $21,600	$0 - $36,000
Migration labor (80 hrs @ $75/hr)	—	$6,000	$6,000	$6,000
Ongoing IT labor (4 hrs/mo @ $75/hr)	$300	$3,600	$10,800	$18,000
Total (P1 included in M365)	~$328	~$9,937	~$17,810	~$25,684
Total (P1 standalone purchase)	~$928	~$17,137	~$39,410	~$61,684

Comparison Summary

Option	Year 1	Year 5	5-Year Savings vs PA-1420
Keep PA-2020 (direct cost only)	$7,200	$36,000	—
Keep PA-2020 (risk-adjusted, low end)	$38,200	$191,000	—
Replace with PA-1420	$22,200	$85,000	Baseline
Self-hosted NetBird (P1 included)	$9,937	$25,684	70% savings
NetBird Cloud Team plan	$12,300	$43,500	49% savings

Risk-Adjusted Cost of Inaction

Risk	Annual Probability	Impact Range	Expected Annual Loss
Credential compromise via spraying	15-25%	$50K-$150K	$7,500-$37,500
Ransomware via VPN exploitation	5-10%	$200K-$500K	$10,000-$50,000
Data breach (client/project data)	3-5%	$100K-$300K	$3,000-$15,000
Insurance claim denial (EOSL)	10-20%	$100K-$300K	$10,000-$60,000
Total expected annual loss			$31,000-$166,500

Every month of delay adds $2,600-$13,900 in expected risk exposure.

C. Migration Plan

Phase 1: Infrastructure Setup (Week 1-2)

Provision Azure B2s VM in West US 2 with Ubuntu 24.04 LTS
Deploy NetBird server via Docker Compose (management + signal + relay + dashboard + traefik)
Configure DNS (e.g., netbird.gsisg.com -> Azure VM public IP)
Register Entra ID App Registration with User.Read.All and Group.Read.All permissions
Add Entra ID as external OIDC provider in NetBird dashboard
Enable JWT group sync; pre-create groups matching Entra ID group names
Create local break-glass admin accounts (2-3)
Create setup keys: one reusable key for routing peers (no expiration), one reusable key per office for endpoints (90-day expiration)
Deploy routing peer at Honolulu site
Deploy routing peer at Boulder site (install x86_64 packages on Netgate 6100)
Configure network routes: 10.100.7.0/24 (Honolulu) and 10.15.0.0/24 (Boulder)
Configure split DNS: match domains for AD domain -> internal DC IPs
Create access control policies: General Users -> DCs only; Engineers -> Full LAN
Remove or modify the default full-mesh policy

Success Criteria:

Management dashboard accessible via HTTPS
Entra ID SSO login works for admin
Both routing peers show “Connected” in dashboard
Routing peers advertise correct subnets
DNS resolution for AD domain works through tunnel

Phase 2: Pilot Group (Week 2-3)

Select 5 pilot users (mix of IT staff, one power user, one general user)
Install NetBird via TacticalRMM with --network-monitor=false flag
GlobalProtect remains installed and active on all pilot machines
Verify NetBird overlay connectivity (peer-to-peer pings on 100.x addresses)
Verify access to DC (Kerberos, LDAP, DNS) through NetBird tunnel
Test SSPR password reset flow end-to-end on one pilot machine
Test access to file shares, internal applications via NetBird routes
Test GP + NetBird coexistence stability over 5 business days
Disconnect GP on one pilot machine; verify all resources accessible via NetBird alone
Test rollback: re-enable GP, verify it works as before

Success Criteria:

All 5 pilot peers stable for 5+ days
SSPR + cached credential update works without IT intervention
No GP session disruptions (—network-monitor=false working)
All critical applications accessible via NetBird routes
Rollback to GP verified functional

Phase 3: Office Expansion (Week 3-5)

Deploy NetBird to all office-based users (~80-90) via TacticalRMM in waves:
- Wave 1: Honolulu office (~30-40 users)
- Wave 2: Boulder office (~20-30 users)
Configure on-premises detection posture check (block NetBird routes when on office subnet)
Communicate to users: “NetBird is your new VPN. If you have issues, GlobalProtect still works.”
Monitor dashboard daily for connection issues, relay percentage
Helpdesk team briefed; per-team “VPN champions” designated

Success Criteria:

All office users connected and stable for 2+ weeks
Help desk ticket volume manageable
On-premises detection working (no hairpin traffic)
Policy enforcement verified (general users cannot access non-DC resources)

Phase 4: Remote and Field Workers (Week 5-7)

Deploy NetBird to remote/home workers (~20-30 users)
Deploy to field/cellular workers (~5-10 users) — last wave due to higher relay likelihood
Monitor relay usage; confirm embedded relay handles load
Test with all users on NetBird for 2+ weeks

Success Criteria:

All users connected
Relay usage <15% of active connections
Field workers on cellular experiencing acceptable performance
No capacity issues on B2s VM

Phase 5: GlobalProtect Decommission (Week 7-10+)

Disable GP auto-connect on all endpoints (do NOT uninstall yet)
If PR #5156 has merged into a release, remove --network-monitor=false; otherwise keep it
Monitor for 2 weeks with GP disabled but installed
Uninstall GlobalProtect from all endpoints via TacticalRMM
Remove --network-monitor=false flag if still set (GP is gone, no trigger)
Back up PA-2020 configuration
Power down PA-2020 but retain for 30 days before formal decommission
Notify cyber insurance broker of migration to ZTNA
After 30 days with no issues, formally decommission PA-2020

GlobalProtect Coexistence Strategy (Phases 1-4):

Both VPNs coexist with --network-monitor=false on all NetBird clients
Routes do not conflict: GP handles corporate subnets, NetBird handles 100.64.0.0/10 overlay
If GP is in full-tunnel mode, add NetBird management server IP to GP’s split-tunnel exclusion list
DNS: NetBird uses match-domain DNS for AD domain; GP/system handles everything else

Rollback Procedures:

Phase	Rollback Action	Time to Recovery
Phase 1 (infra)	Delete Azure VM; routing peers removed automatically	<1 hour
Phase 2 (pilot)	`netbird down` + uninstall MSI on 5 machines; GP still works	<30 minutes
Phase 3 (office)	Bulk TacticalRMM script: `netbird down` + uninstall; GP still works	<2 hours
Phase 4 (remote)	Same as Phase 3	<2 hours
Phase 5 (post-GP)	Re-install GlobalProtect, power on PA-2020, restore config	<4 hours

D. Risk Register

#	Risk	Likelihood	Impact	Mitigation
1	GP coexistence issue (#5077/#5156) — GP triggers NetBird WireGuard restart, killing active TCP sessions	HIGH (confirmed bug)	MEDIUM (session drops)	Deploy with `--network-monitor=false` on all clients during migration. Side effects (slower Wi-Fi reconnection) are manageable. Remove flag after GP is fully uninstalled.
2	Management server downtime — single point of failure (no HA in free tier)	LOW (Azure SLA 99.9%)	MEDIUM (no new connections; existing tunnels survive)	Docker restart: unless-stopped. Monitoring via Uptime Kuma/Prometheus. Regular SQLite backups. Blast radius limited to control plane; data plane is unaffected.
3	Entra ID OIDC misconfiguration — users locked out of VPN	MEDIUM (first-time setup)	HIGH (all users unable to authenticate)	Test with pilot group first. Create local break-glass admin accounts. Document exact App Registration settings. Configure Conditional Access to allow NetBird.
4	Self-hosted deprovisioning gap — terminated employee retains access	MEDIUM (process-dependent)	HIGH (unauthorized access)	Document offboarding checklist: disable in Entra ID + remove from NetBird dashboard. Set login expiration to 24 hours.
5	Client auto-reconnection failure — peers stay offline after outages	MEDIUM (known GitHub issue)	LOW (manual `netbird up` resolves)	Setup key mode auto-starts at boot. TacticalRMM can run remediation scripts.
6	pfSense package incompatibility on Boulder Netgate 6100	LOW (actively maintained packages)	MEDIUM (Boulder routing peer down)	Test in maintenance window. Have Linux VM fallback ready. Package v0.1.25 released March 15, 2026.
7	PA-2020 breach BEFORE migration completes — credential spraying succeeds	MEDIUM (active campaign)	CRITICAL ($50K-$500K+)	Accelerate Phase 1-2 timeline. Restrict PA-2020 to known source IPs if possible. Enable any available rate limiting on PAN-OS 7.1.
8	User resistance / help desk overload	HIGH (change management)	MEDIUM (productivity loss)	Step-by-step guides. 3-minute video walkthrough. Per-team VPN champions. Dedicated help desk queue for 2 weeks.
9	Self-hosted feature limitations (no SIEM, no posture checks, no auto-deprovision)	CERTAIN (by design)	LOW for GSISG	Accept limitations. Upgrade to Cloud Team ($500/mo) or Enterprise license if requirements change.
10	PA-2020 EOL — risk of NOT migrating	CERTAIN (already 6 years past EOL)	CRITICAL	No patches, no support, active targeting, 11x ransomware risk, potential insurance claim denial. Risk of inaction exceeds risk of migration.

E. Decision Points Requiring Human Judgment

These choices cannot be made from research alone — they require GSISG leadership input:

Self-hosted free vs. Cloud Team plan ($500/mo) vs. Self-hosted Enterprise license (custom pricing). Self-hosted free is recommended for cost and data sovereignty. Cloud Team adds automatic deprovisioning and managed HA. Enterprise self-hosted adds SCIM and HA without giving up data sovereignty. GSISG must assess whether the deprovisioning gap and single management server are acceptable tradeoffs for $6,000/year savings.
Routing peer deployment: pfSense direct vs. Linux VM. Direct pfSense installation is simpler, cheaper, and technically sound. However, GSISG may have a policy against installing third-party packages on production firewalls. This is an operational preference decision.
Entra ID P1 licensing. If GSISG does not already have M365 Business Premium or E3, adding P1 standalone adds $7,200/year for 100 users. Confirm current licensing before finalizing the budget.
Login expiration policy. Configurable from 1 hour to 180 days, or disabled entirely. Shorter = more secure + faster deprovisioning. Longer = less user friction. Recommendation: 24-48 hours. GSISG IT should set this based on risk tolerance.
Masquerade on/off for site-to-site routing. Masquerade ON is simpler (no static routes needed on pfSense). Masquerade OFF preserves source IPs in server logs (needed for some compliance postures). GSISG should decide based on audit requirements.
Timeline urgency. 8-week plan is safe but conservative. Given the active credential-spraying campaign against GlobalProtect portals, GSISG may want to accelerate Phases 1-2 to 1 week. Every month of delay carries $2,600-$13,900 in expected risk.
Cyber insurance notification timing. Proactive notification may reduce premiums but draws attention to the EOSL status. GSISG should consult their broker or legal counsel on timing.
Long-term identity strategy. The cached credential problem disappears entirely with Azure AD Joined devices (no on-prem AD dependency). This requires migrating from GPO to Intune — a major project but the ultimate solution. GSISG should decide whether to plan this longer-term migration or maintain the hybrid AD-joined model.

This synthesis was produced from 8 research reports (5 Round 1, 3 Round 2) totaling approximately 35,000 words of primary research across 100+ sources and 80+ tool invocations. All findings are traceable to their source reports. No new research was conducted for this synthesis.