Skip to content

Decision Points

These choices require management input and cannot be resolved by technical analysis alone.

1. Routing Peer Deployment: Hyper-V VM vs pfSense vs Docker

Section titled “1. Routing Peer Deployment: Hyper-V VM vs pfSense vs Docker”

NetBird routing peers provide LAN access at each office site. Four deployment options were evaluated:

OptionBoulderHonoluluVerdict
Hyper-V VM (Ubuntu 24.04)DATA001 or DATA007DATA003 or DATA004Recommended. Native Linux support, systemd auto-restart, Hyper-V snapshots, standard apt update workflow. No upgrade removal risk. 1 vCPU, 1-2 GB RAM, 10 GB disk.
Docker on PortainerExisting Portainer serverExisting Portainer serverViable backup. Recurring nftables bugs documented (GitHub #947, #5391, #5593). “ICMP works but TCP fails” pattern across 3+ years of issues. Requires network_mode: host + NET_ADMIN.
pfSense nativeNetgate 6100 (AMD64)N/A (Palo Alto)Not recommended. Early-adopter package (v0.1.25), not in official pfSense package manager. Custom packages are automatically removed on pfSense upgrades — must reinstall after every upgrade. FreeBSD routing peer may need FakeBSD workaround.
Azure Container (ACI/Apps)Not viableNot viableNeither ACI nor Container Apps supports privileged containers, NET_ADMIN, or /dev/net/tun. Confirmed by Azure documentation.

Note on redundancy: NetBird supports multiple routing peers per site for automatic failover (free feature). However, two VMs on the same network share the same internet connection — if the ISP goes down, both go down. The real resilience comes from having routing peers at both offices — if Boulder internet dies, the Honolulu routing peer and Azure management server still work. A second routing peer per site only protects against Hyper-V host hardware failure, which is a lower-probability event. Start with one per site; add a second later if needed.

Decision needed: Confirm Hyper-V VM approach, or choose pfSense/Docker alternative.

Login expiration controls how often SSO-authenticated users must re-verify their identity.

How it works in plain terms:

  • Users who logged in via Entra ID SSO have a session timer (default: 24 hours)
  • When the timer expires, their WireGuard tunnel disconnects and they see “Login required”
  • They must open NetBird and click “Login” to re-authenticate via Entra ID SSO
  • Setup key peers (routing peers, servers) are completely exempt — they never expire

Configurable range: 1 hour to 180 days, or disabled entirely.

Impact on deprovisioning:

  • When an employee is terminated in Entra ID, their NetBird session expires within the configured period
  • At 24h default: maximum 24 hours of residual access
  • TRMM can immediately uninstall NetBird from the device regardless of login expiration:
    netbird down
    netbird_uninstall.exe /S
  • TRMM bulk operations can mass-uninstall from all endpoints in 15-30 minutes

Recommendation: 24 hours (default). Balances security with user convenience. Shorter for high-security environments. Machines are wiped and reinstalled after user termination, making the deprovisioning gap minimal.

Decision needed: Confirm 24-hour default or choose a different period.

Recommended: Weekend deployment (1 week total including pre-work).

PhaseDurationDetails
Pre-work (Mon-Thu)4 daysAzure VM, DNS, Entra OIDC, TRMM scripts, SSPR, AV exclusions
Friday evening4 hoursInfrastructure deployment + IT self-test
Saturday8 hoursPilot group (8-10 users) + validation of 5 scenarios
Sunday4 hoursFull deployment via TRMM to all ~200 endpoints
MondayMonitoringSupport, catch stragglers, monitor dashboard

Key enabler: GlobalProtect stays running throughout. NetBird is purely additive — failure causes zero user outage. Rollback via TRMM mass uninstall takes 15-30 minutes.

Pilot group: 8-10 users across 5 scenarios (Hawaii remote to Boulder SMB, East Coast RDP, Honolulu cellular, Boulder to Honolulu files, password reset testing).

Decision needed: Confirm weekend deployment or request a longer phased rollout.

4. Whether to Notify Cyber Insurance Broker Proactively

Section titled “4. Whether to Notify Cyber Insurance Broker Proactively”

Migrating from EOSL VPN to ZTNA is a security improvement, but draws attention to EOSL hardware. Consult with broker or legal counsel.

Decommission immediately, retain as emergency fallback for 90 days, or repurpose for non-security role (firewall-only, no VPN).