OpenVPN built into each phone is attractive for one or two isolated remote phones, but once several phones are at the same remote location, I strongly prefer the GL.iNet/WireGuard router approach we’ve been using.
Yealink supports OpenVPN directly on its phones. The big advantage is that you need no separate VPN router at the remote site. A phone can be placed on essentially any Internet connection, establish its tunnel back to the PBX network, and then behave much more like an internal phone.
The disadvantages become more apparent as you scale it. Each phone becomes an individual VPN endpoint. That means individual certificates/configuration, VPN troubleshooting, tunnel status, potentially separate addressing, and another configuration layer on every handset.
Compare that with what we’ve done with the MT3600:
OpenVPN in every phone
PH #1 ─ OpenVPN ─┐
PH #2 ─ OpenVPN ─┼── Internet → PBX
PH #3 ─ OpenVPN ─┘
versus:
WireGuard in one remote router
PH #1 ─┐
PH #2 ─┼─ MT3600 ── WireGuard ── Internet → PBX
PH #3 ─┘
The second architecture has some major operational advantages. The phones themselves don’t need to know that a VPN exists. They just receive ordinary LAN addresses such as 192.168.8.x and talk to the PBX. You configure and troubleshoot one tunnel instead of three, five or ten tunnels. You can also use phones that don’t have OpenVPN support at all—which is exactly what allowed a wired T46G to participate alongside the T54W.
And yes, WireGuard generally has substantially less computational/protocol overhead than OpenVPN. WireGuard was specifically designed to be small and fast, with a much simpler protocol and implementation.
For voice traffic, though, I wouldn’t exaggerate the bandwidth aspect. A few SIP calls consume so little bandwidth that the difference between OpenVPN and WireGuard isn’t likely to determine whether the call sounds good. Where WireGuard has the bigger advantage for this application is simplicity, latency consistency and processing load on small embedded devices.
There’s one potentially useful OpenVPN advantage: it is extremely mature and flexible, and it can operate in environments where WireGuard’s UDP-only nature may occasionally be problematic. OpenVPN can be configured in ways that traverse restrictive networks more readily, including TCP configurations. WireGuard deliberately remains much simpler and UDP-based.
There’s another benefit of the MT3600 approach that is particularly important: it separates telephony configuration from network/VPN configuration. The IP phone can contains nothing unusual—PBX address, extension credentials, codecs, buttons, etc. If you replace that phone tomorrow, you don’t have to recreate the VPN infrastructure on the replacement. Plug another phone into the 192.168.8.x network and the VPN path already exists.
And because that remote LAN is effectively routed toward the PBX through WireGuard, you can do other things with it besides SIP. Management interfaces, provisioning, paging or other PBX-related services can travel across that same path. With per-phone OpenVPN, you’ve essentially built several little independent VPN islands.
For this type of setup, the architecture I would choose is:
PBX site ← WireGuard → GL-MT3600 ← ordinary IP phones
rather than putting a VPN client into every handset.
The native phone OpenVPN capability is still quite useful, though. It would be an interesting experiment to configure one phone with OpenVPN and compare it directly with the same phone behind the MT3600/WireGuard tunnel—registration behavior, call establishment, audio latency and tunnel recovery after deliberately interrupting its Internet connection.
Phone System 
