Step 6: Verification & Monitoring

This step verifies the entire deployment is working correctly, establishes monitoring, and configures backups for the management server.

6.1 Verify All Peers Are Connected

Open the NetBird Dashboard at https://netbird.gsisg.com and navigate to the Peers tab.

Check List

Check	How to Verify
Total peer count	Should match deployed machine count (~200 laptops + 4 routing peers)
Routing peers online	gsi-nb-hnl-01, gsi-nb-hnl-02, gsi-nb-bld-01, gsi-nb-bld-02 all show “Connected”
Group assignments	Routing peers in their respective groups; laptops in Company-Laptops
No stale peers	No peers stuck in “Disconnected” state for extended periods

Verify Connection Type

On any connected Windows client, run:

& "C:\Program Files\NetBird\netbird.exe" status --detail

Look for:

• Management: Connected
• Signal: Connected
• Relays: X/X Available
• Connection type: P2P (for same-network peers) or Relayed (for cross-NAT)

On routing peers (Linux):

sudo netbird status --detail

6.2 Test Connectivity Scenarios

Run these tests from a Windows laptop that is not on either office LAN (simulates a remote worker).

Test 1: Domain Controller Ping

# Honolulu DCs
ping 10.100.7.10   # AD0
ping 10.100.7.11   # AD1

# Boulder DCs
ping 10.15.0.10    # AD1
ping 10.15.0.11    # AD2

Note

ICMP (ping) may be blocked by Windows Firewall on the DCs. If ping fails but other services work, the issue is the DC firewall, not NetBird.

Test 2: DNS Resolution

nslookup gsisg.local 10.100.7.10
nslookup gsisg.local 10.15.0.10

Test 3: SMB File Share Access

# Honolulu file server
net use \\10.100.7.15\ShareName /user:GSISG\username
dir \\10.100.7.15\ShareName

# Or use UNC path in File Explorer

Test 4: RDP to a Server

mstsc /v:10.100.7.15

Or use Remote Desktop Connection to connect to a server IP through the NetBird tunnel.

Test 5: SAGE Application (Honolulu)

Verify the SAGE application is accessible at 10.100.7.40 from a remote machine. The specific test depends on SAGE’s client requirements (TCP port, thick client, etc.).

Test 6: Site-to-Site

From a machine on the Boulder LAN (or the Boulder routing peer):

ping 10.100.7.10   # Honolulu AD0

From a machine on the Honolulu LAN (or the Honolulu routing peer):

ping 10.15.0.10    # Boulder AD1

Test 7: SSPR Password Reset Flow

If using Azure AD Self-Service Password Reset with password writeback to on-prem AD:

1. From a remote laptop connected via NetBird, navigate to https://aka.ms/sspr
2. Complete a password reset
3. Verify the new password works for on-prem AD authentication (sign out and back in, or test with net use)

6.3 Dashboard Health Check

Review these Dashboard sections:

Section	What to Check
Peers	All expected peers connected, correct group assignments
Network Routes	Both routes active, routing peers healthy
Access Control	All 6 policies present, Default policy deleted
Setup Keys	Keys show correct usage counts
Activity	Recent activity shows peer connections and policy evaluations

6.4 Configure Zabbix Monitoring

Monitor the Azure management VM and routing peers with Zabbix (Zabbix server at 10.15.0.34).

Azure VM Monitoring

Install the Zabbix agent on vm-netbird-mgmt-01:

# On the Azure VM
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.0+ubuntu24.04_all.deb
sudo dpkg -i zabbix-release_latest_7.0+ubuntu24.04_all.deb
sudo apt update
sudo apt install -y zabbix-agent2

# Configure
sudo sed -i "s/Server=127.0.0.1/Server=10.15.0.34/" /etc/zabbix/zabbix_agent2.conf
sudo sed -i "s/ServerActive=127.0.0.1/ServerActive=10.15.0.34/" /etc/zabbix/zabbix_agent2.conf
sudo sed -i "s/Hostname=Zabbix server/Hostname=vm-netbird-mgmt-01/" /etc/zabbix/zabbix_agent2.conf

sudo systemctl enable --now zabbix-agent2

Note

The Zabbix agent on the Azure VM communicates with the Zabbix server through the NetBird tunnel (via the Boulder routing peer). NetBird must be installed on the Azure VM as well, or the Zabbix agent must connect over the public internet. For monitoring the management server itself, consider using Azure Monitor or an external monitoring solution that does not depend on NetBird being operational.

Key Metrics to Monitor

Metric	Threshold	Alert
Docker container status	Any container not running	Critical
Disk usage on /var/lib/docker	> 80%	Warning
CPU usage	> 90% sustained 5 min	Warning
Memory usage	> 85%	Warning
TLS certificate expiry	< 14 days	Warning
Process netbird on routing peers	Not running	Critical

Custom Zabbix Checks for Routing Peers

Install Zabbix agent on each routing peer VM and add a UserParameter to check NetBird status:

/etc/zabbix/zabbix_agent2.d/netbird.conf

UserParameter=netbird.status,netbird status 2>&1 | grep -c "Management: Connected"

Expected value: 1 (connected). Alert if 0.

6.5 Backup Strategy

What to Back Up

Item	Location	Frequency	Method
Configuration files	VM working directory	After any config change	File copy
NetBird databases	netbird_data Docker volume	Daily	Docker volume copy
Encryption key	config.yaml (server.store.encryptionKey)	Once (store securely)	Password manager / Key Vault
TLS certificates	netbird_traefik_letsencrypt volume	Weekly	Docker volume copy

Backup Script

Create this script on the Azure VM at /opt/netbird-backup.sh:

#!/bin/bash
# NetBird Backup Script
# Run daily via cron: 0 2 * * * /opt/netbird-backup.sh

BACKUP_DIR="/opt/netbird-backups"
DATE=$(date +%Y%m%d-%H%M%S)
DEST="$BACKUP_DIR/$DATE"

mkdir -p "$DEST"

# 1. Copy configuration files
cp ~/docker-compose.yml ~/config.yaml ~/dashboard.env "$DEST/"

# 2. Stop server and copy databases
cd ~/
docker compose stop netbird-server
docker compose cp -a netbird-server:/var/lib/netbird/ "$DEST/data/"
docker compose start netbird-server

# 3. Copy TLS certificates (Traefik Let's Encrypt)
docker run --rm -v netbird_traefik_letsencrypt:/source -v "$DEST":/backup alpine \
  cp -a /source/. /backup/letsencrypt/

# 4. Compress
tar czf "$BACKUP_DIR/netbird-backup-$DATE.tar.gz" -C "$BACKUP_DIR" "$DATE"
rm -rf "$DEST"

# 5. Retain last 30 days of backups
find "$BACKUP_DIR" -name "*.tar.gz" -mtime +30 -delete

echo "Backup completed: $BACKUP_DIR/netbird-backup-$DATE.tar.gz"

chmod +x /opt/netbird-backup.sh
sudo crontab -e
# Add: 0 2 * * * /opt/netbird-backup.sh >> /var/log/netbird-backup.log 2>&1

Off-Site Backup

Copy backups to Azure Blob Storage or another off-site location:

# Install Azure CLI on the VM (if not already installed)
# Then use azcopy or az storage blob upload
az storage blob upload \
  --account-name gsisgstorage \
  --container-name netbird-backups \
  --file /opt/netbird-backups/netbird-backup-$DATE.tar.gz \
  --name "netbird-backup-$DATE.tar.gz"

The Encryption Key Is Critical

The server.store.encryptionKey in config.yaml encrypts setup keys and API tokens in the database. If this key is lost:

• All existing setup keys become undecryptable
• All API tokens become invalid
• You must regenerate everything

Store this key in at least two separate secure locations (e.g., Azure Key Vault + password manager + printed copy in a safe).

Restore Procedure

If you need to rebuild the management server:

1. Provision a new VM with the same specs
2. Install Docker and prerequisites (Step 1.4)
3. Copy the backup files to the new VM
4. Extract: tar xzf netbird-backup-YYYYMMDD-HHMMSS.tar.gz
5. Restore config files to the working directory
6. Restore the data volume:

   docker compose up -d  # Creates volumes
   docker compose stop netbird-server
   docker compose cp -a backup/data/ netbird-server:/var/lib/netbird/
   docker compose start netbird-server

7. Update DNS to point netbird.gsisg.com to the new VM’s IP
8. Verify dashboard access and peer connectivity

6.6 Upgrade Process

To upgrade NetBird to a new version:

1. Read the release notes for breaking changes:

   • Server: https://github.com/netbirdio/netbird/releases
   • Dashboard: https://github.com/netbirdio/dashboard/releases

2. Run a backup (Section 6.5)

3. Pull new images:

   docker compose pull

4. Restart with new images:

   docker compose up -d --force-recreate

5. Verify the Dashboard loads and peers reconnect

Note

The Dashboard displays an update indicator in the sidebar when a new version is available. Check this periodically.

Final Verification Checklist

The complete NetBird deployment is verified when all of the following are true:

Infrastructure

• Azure VM running, Docker healthy, all 3 containers up
• DNS netbird.gsisg.com resolves correctly
• TLS certificate valid (check in browser)
• Entra ID SSO login works
• Local admin break-glass accounts work

Routing

• All 4 routing peers connected (2 per site, including HA)
• Network routes for 10.100.7.0/24 and 10.15.0.0/24 active
• Site-to-site routing works between offices

Access Control

• Default policy deleted
• All 6 custom policies active
• IT Admins can access all resources at both sites
• Engineers can access their respective site resources
• All staff can authenticate against DCs

Clients

• All ~200 machines enrolled and showing in Dashboard
• NetBird service running as Windows service on all endpoints
• No conflicts with GlobalProtect during coexistence
• Users can access file shares, RDP, and applications through NetBird

Operations

• Daily backups configured and tested
• Encryption key stored in at least 2 secure locations
• Zabbix monitoring configured for VM and routing peers
• Client secret expiration date calendared for renewal
• Upgrade process documented and tested