OpenVPN vs NetBird: Side-by-Side Comparison

The Fundamental Difference

OpenVPN on the Boulder pfSense is a hub-and-spoke architecture. Every remote user tunnels into Boulder, regardless of where they are or what they need to reach. If the resource is in Honolulu, traffic crosses the Pacific to Boulder and then crosses the Pacific again to reach Honolulu.

NetBird is a peer-to-peer mesh. Users connect directly to the routing peer at the site hosting the resource. Traffic takes the shortest path.

OpenVPN on Boulder pfSense: Hub-and-Spoke

graph LR
    MD[Maryland Worker] -->|VPN| BPF[Boulder pfSense]
    HI[Hawaii Worker] -->|VPN| BPF
    CA[California Worker] -->|VPN| BPF
    BPF --> BLAN[Boulder LAN]
    BPF -->|site-to-site| HLAN[Honolulu LAN]

    style BPF fill:#d32f2f,color:#fff
    style HLAN fill:#fff3e0
    style BLAN fill:#e8f5e9

ALL traffic funnels through one device in Boulder. Hawaii workers accessing Honolulu resources cross the Pacific twice.

NetBird: Peer-to-Peer Mesh

graph LR
    MD[Maryland Worker] -->|WireGuard| BRP[Boulder Routing Peer]
    HI[Hawaii Worker] -->|WireGuard| HRP[Honolulu Routing Peer]
    CA1[California Worker] -->|WireGuard| HRP
    CA2[California Worker] -->|WireGuard| BRP
    BRP --> BLAN[Boulder LAN]
    HRP --> HLAN[Honolulu LAN]

    style BRP fill:#2e7d32,color:#fff
    style HRP fill:#2e7d32,color:#fff
    style HLAN fill:#e8f5e9
    style BLAN fill:#e8f5e9

Each site has its own routing peer. Users connect to whichever site hosts the resource they need.

Performance: Netgate 6100 OpenVPN vs WireGuard

Metric	OpenVPN (no DCO)	OpenVPN (DCO+QAT)	WireGuard
Aggregate throughput	80-270 Mbps	~400-700 Mbps (limited independent data)	909 Mbps (tested on same CPU)
Processing model	Single-threaded	Multi-threaded	Multi-threaded, kernel-space
Per-user at 200 connections	7-13 Mbps	~20-35 Mbps	45+ Mbps
Reconnection after network change	3-10 seconds	3-10 seconds	0.2-0.8 seconds

Source: Netgate forums and official Netgate blog benchmarks on C3558 / SG-5100 hardware.

Scenario Comparisons

graph LR
    subgraph OpenVPN
        A1[Maryland] -->|30-50ms| A2[Boulder pfSense] --> A3[Boulder LAN]
    end
    subgraph NetBird
        B1[Maryland] -->|30-50ms| B2[Boulder Routing Peer] --> B3[Boulder LAN]
    end

	OpenVPN	NetBird
Path	Maryland -> Boulder pfSense -> Boulder LAN	Maryland -> Boulder routing peer -> Boulder LAN
RTT	~65-85ms	~62-82ms

Verdict: Similar. The destination is Boulder, so both paths are direct. OpenVPN works fine here.

graph LR
    subgraph OpenVPN
        A1[Hawaii] -->|60-80ms| A2[Boulder pfSense] --> A3[Boulder LAN]
    end
    subgraph NetBird
        B1[Hawaii] -->|60-80ms| B2[Boulder Routing Peer] --> B3[Boulder LAN]
    end

	OpenVPN	NetBird
Path	Hawaii -> Pacific -> Boulder pfSense -> Boulder LAN	Hawaii -> Pacific -> Boulder routing peer -> Boulder LAN
RTT	~125-165ms	~122-162ms

Verdict: Similar. Both cross the Pacific once. The cross-ocean hop is unavoidable for Boulder resources.

Scenario C: Hawaii Worker to Honolulu Sage Server

This is the scenario that kills the OpenVPN-on-Boulder argument.

Hawaii worker to Honolulu Sage — OpenVPN crosses the Pacific twice, NetBird stays local

graph LR
    subgraph OpenVPN - 245-325ms RTT
        A1[Hawaii] -->|60-80ms| A2[Boulder pfSense] -->|60-80ms| A3[Honolulu LAN]
    end
    subgraph NetBird - 7-18ms RTT
        B1[Hawaii] -->|3-9ms| B2[Honolulu Routing Peer] --> B3[Honolulu LAN]
    end

    style A2 fill:#d32f2f,color:#fff
    style B2 fill:#2e7d32,color:#fff

	OpenVPN	NetBird
Path	Hawaii -> Pacific -> Boulder -> Pacific -> Honolulu	Hawaii -> Honolulu routing peer -> Honolulu LAN
RTT	245-325ms	7-18ms
Penalty	Traffic crosses the Pacific TWICE	Stays local on Oahu

Verdict: 16-22x worse with OpenVPN. A Hawaii-based worker accessing Sage ERP in the Honolulu office would send every packet across the Pacific Ocean, through Boulder, and back across the Pacific. Sage is a database-heavy, latency-sensitive application. At 245-325ms RTT, it becomes unusable. NetBird routes directly to the Honolulu routing peer at near-LAN latency.

Maryland worker to Honolulu — OpenVPN goes east to reach the west, NetBird goes direct

Scenario D: California Worker to Honolulu Server

graph LR
    subgraph OpenVPN - 175-235ms RTT
        A1[California] -->|25-35ms| A2[Boulder pfSense] -->|60-80ms| A3[Honolulu LAN]
    end
    subgraph NetBird - 102-122ms RTT
        B1[California] -->|50-60ms| B2[Honolulu Routing Peer] --> B3[Honolulu LAN]
    end

    style A2 fill:#d32f2f,color:#fff
    style B2 fill:#2e7d32,color:#fff

	OpenVPN	NetBird
Path	California -> east to Boulder -> west to Honolulu	California -> direct to Honolulu
RTT	175-235ms	102-122ms

Verdict: ~2x latency penalty with OpenVPN. Traffic goes east to come back west — a geographic detour through Colorado to reach Hawaii.

Scenario E: Field Worker on Cellular

	OpenVPN	NetBird
Cell tower handoff	3-10 second reconnect (TLS renegotiation)	200-400ms seamless (cryptokey routing)
TCP sessions	Drop and must re-establish	Survive the transition
Sage ERP on cellular	Session drops on every tower handoff	Uninterrupted
Battery drain (8hr mobile)	~30%	~12%

Verdict: OpenVPN is unusable for field workers on cellular. WireGuard identifies peers by cryptographic key, not IP address. When the device’s IP changes during a cell tower handoff, the tunnel continues without renegotiation. OpenVPN must perform a full TLS handshake on every network change.

The Boulder Single Point of Failure

Boulder outage — OpenVPN loses all 200 users, NetBird only loses Boulder resources

Event	OpenVPN on Boulder pfSense	NetBird
Boulder internet down	ALL 200 users lose VPN to EVERYTHING — both Boulder AND Honolulu resources	Only Boulder resources unreachable. Honolulu routing peer still works.
Boulder pfSense hardware failure	Same — total VPN outage PLUS site-to-site tunnel to Honolulu also breaks	Boulder resources unreachable. All other connectivity unaffected.
Comcast maintenance window	ALL remote access dead during the window	Only Boulder access affected
pfSense CPU overload	OpenVPN pegs one core, ALL 200 sessions degrade simultaneously	Data plane is P2P. No single device carries all VPN load.

With OpenVPN on Boulder pfSense, the Netgate 6100 becomes a convergence point for five functions: office firewall, site-to-site VPN, remote access VPN for 200 users, LDAP auth proxy, and NAT gateway. A single failure takes out all five.

Summary

Dimension	OpenVPN on Boulder pfSense	NetBird
Architecture	Hub-and-spoke	P2P mesh
Hawaii -> Honolulu latency	245-325ms	7-18ms
Boulder SPOF	All 200 users affected	Only Boulder resources
Authentication	PKI + LDAP (~60 config fields)	Entra ID SSO (7 fields)
Deployment to 200 machines	200 unique .ovpn configs	1 universal script
Cellular handoff	3-10 sec drop	200ms seamless
Throughput (200 users)	7-13 Mbps/user	45+ Mbps/user

Recommendation

NetBird is the clear choice. The Hawaii-to-Honolulu hairpin alone — 245-325ms vs 7-18ms, a 16-22x penalty — makes OpenVPN on the Boulder pfSense unacceptable for a company headquartered in Hawaii with its primary servers in Honolulu. Add the single point of failure, the PKI/LDAP complexity for 200 users, and the broken cellular experience for field workers, and the case is decisive.