some file

Verifying Encryption

After setting up NetBird with the AES tunnel, you can verify that both encryption layers are active and functioning correctly.

Check Interface Status

Verify both WireGuard interfaces are running:

# Check standard WireGuard interface
sudo wg show wg0

# Check AES WireGuard interface
sudo wg show aes0

Both should show active peers with recent handshake times. The aes0 interface should show the AES-256-GCM noise protocol.

Check DSKE Status

Verify that DSKE is active and has established keys:

netbird dske status

Expected output:

DSKE Status: Enabled
Local Peer UUID: 625e104c8321934fd6533994f8967b7c

Registered Security Hubs:
  Hub ID                            Client ID                         Generate    Recover     Status
  0a1b2c3d4e5f67890a1b2c3d4e5f6789  fedcba9876543210fedcba9876543210  524288      524288      Enabled
  1234567890abcdef1234567890abcdef  abcdef1234567890abcdef1234567890  1048576     1048576     Enabled

Key things to verify:

  • Status is Enabled
  • At least 2 security hubs are registered (minimum for threshold cryptography)
  • Generate and Recover columns show non-zero PSRD levels

Check Peer Connectivity

Via AES Tunnel

Ping a peer using its AES IP to verify the double-encrypted path:

# Ping via AES tunnel (double encrypted)
ping <peer-aes-ip>

# Or use the AES DNS name
ping my-server.aes.netbird.cloud

Via Standard WireGuard

Ping the same peer's WireGuard IP to verify the standard path:

# Ping via standard WireGuard (single encryption)
ping <peer-wg-ip>

Both should succeed, but they traverse different encryption paths.

Verify Route Steering

Check that routes are correctly steering traffic through the AES interface:

# Show routes for AES peers
ip route show dev aes0

# Show routes for standard WireGuard peers
ip route show dev wg0

AES-capable peers should have their routes on aes0, while AES-exempt peers and infrastructure traffic should route through wg0.

Verify Firewall Rules

Confirm that the dual-interface firewall is correctly configured:

# For nftables
sudo nft list chain inet netbird-acl netbird-acl-aes-input-rules

# For iptables
sudo iptables -L NETBIRD-ACL-AES-INPUT -n -v

The AES chain should contain user policy rules. The standard WireGuard chain should show lockdown rules for AES-capable peers (allowing only ICMP, UDP/51830, TCP/51831).

Verify Key Rotation

Monitor DSKE key rotation in the logs:

# Watch for PSK injection events
journalctl -u netbird -f | grep -i "psk\|dske\|inject"

You should see periodic key generation and injection events approximately every 120 seconds per peer pair.

Troubleshooting

AES tunnel not establishing

  1. Check DSKE status: netbird dske status — ensure hubs are registered with sufficient PSRD
  2. Check PSRD levels: If generate/recover columns show 0, ingest more PSRD
  3. Check hub connectivity: Ensure security hubs are reachable from both peers
  4. Check logs: journalctl -u netbird for DSKE errors

AES DNS not resolving

  1. Check AES IP allocation: The peer must have an AES IP in the management server
  2. Check AES DNS domain: Verify the account has an AES DNS domain configured
  3. Check peer is not exempt: AES-exempt peers don't get AES DNS records

One-way traffic

If traffic flows in only one direction over the AES tunnel:

  1. Check both peers have PSRD: Both sides need sufficient PSRD from shared security hubs
  2. Check handshake times: sudo wg show aes0 — both peers should show recent handshakes
  3. Check firewall: Ensure UDP/51830 is allowed on wg0 between the peers