WireGuard, IPsec and SD-WAN do not sit at the same level. WireGuard and IPsec protect traffic in tunnels. SD-WAN describes a managed site networking service over one or more underlying connections; encryption can use different technologies. For multiple business sites, the choice therefore starts with applications, circuits, responsibilities and failure scenarios, rather than a product name.
A fictional business has a head office and three branches. ERP and telephony use central services, Microsoft 365 accesses the internet as directly as possible, and a maintenance company needs only restricted service access. The DAXS article on OPNsense maintenance covers the firewall update process; this article addresses site topology and the operating decision behind it. A second internet connection at each site is a separate issue that the name SD-WAN alone does not resolve.
Four checks before choosing a protocol
First, record each site’s applications, destination networks, measured peak load, latency requirements, public reachability and circuit outages. Overlapping private address ranges complicate routing and access rules regardless of the tunnelling protocol. Then decide whether branches communicate only with head office or also directly with each other; hub-and-spoke requires fewer tunnel relationships but can make head office a bottleneck. Finally, assign responsibility for operations, key maintenance, monitoring and a tested recovery path.
| Approach | Suitable when … | Checks and limitations |
|---|---|---|
| WireGuard | A few clearly defined peers and networks have manageable key maintenance | Test AllowedIPs, routes, firewall rules, NAT and reachability for each peer in practice; the protocol does not provide automatic central operations |
| IPsec with IKEv2 | Existing devices or peers require standardised IPsec tunnels | Validate cross-vendor profiles, certificates, rekeying, NAT-T and failover on the actual device pair |
| SD-WAN service | Multiple circuits, many sites or application-specific paths need central control and support | Assess underlay, edge devices, policy, measurement points, management access, SLA and failure path both contractually and technically |
A small network can run very well with WireGuard or IPsec if someone is responsible for configuration and incidents. An SD-WAN offering can bundle this operational work and control paths, but introduces its own platform, licence, support and dependency costs. Whether it provides better availability depends on genuinely independent circuits and tested switching.
WireGuard: clear peers, clear networks
WireGuard associates public keys with allowed IP ranges. In a site connection, these ranges must match the routing table and firewall rules; a working handshake alone does not prove that ERP or telephony is reachable. A keepalive may be needed when a peer is behind NAT. The OPNsense documentation shows specific peer, routing and firewall checks for two sites, as well as possible MTU/MSS issues. With four sites, configuration and key maintenance grow, especially if direct site-to-site paths are required. WireGuard alone does not add automatic policy management, service monitoring or an SLA.
IPsec/IKEv2: standardisation still needs validation
IPsec protects packets at the network layer; IKEv2 negotiates security associations and keys. This can make sense with heterogeneous firewalls or existing partner requirements. Compatibility still requires work: encryption suites, certificates, network selectors, rekeying and NAT traversal must match on both sides. RFC 7296 describes UDP encapsulation for IPsec with NAT, for example. The pilot therefore checks tunnel establishment, extended runtime, key changes and reconnection after a circuit interruption. A successful ping is not functional acceptance here either.
SD-WAN: distinguish overlay, underlay and contract
MEF 70.2 defines SD-WAN as a service with agreed attributes and explicitly distinguishes it from the underlying connectivity services. In this example, rules such as “ERP over path A, switching to B on a measured failure” or “telephony only with suitable latency” could be requirements; their actual availability depends on the provider’s product, measurement and contracted services. If a branch has only one physical internet connection, central control cannot configure away its failure. Likewise, a second circuit offers little help if both use the same route, power supply or edge device.
An offer should therefore be assessed separately for edge hardware, management location, circuits, central policy, security boundaries, logging, firmware maintenance, support hours, data path and exit scenario. “Managed” is an advantage only when escalation, measurement data and responsibility for incidents are defined.
A failure test tells you more than a datasheet
Head office and one branch jointly test four cases: loss of the primary path, an edge device failure, an invalid key or certificate, and an application that fails despite an active tunnel. Measure detection, switching, reconnection, application impact and restoration of the normal path. ERP and telephony may have different acceptable interruptions. The test record states actual times rather than a blanket promise of high availability.
The cost decision includes devices and spares, tunnel and policy setup, circuit charges, additional genuine redundancy, licences or service fees, monitoring and internal on-call effort. A self-managed WireGuard tunnel may have no separate protocol licence fees, but still incurs operating and connectivity costs. An IPsec tunnel on existing devices may look inexpensive, provided maintenance and vendor approval are included. An SD-WAN service can reduce work across many sites, but must be compared against the same service scope. Without measurements and quotations, a ranking in euros would be invented.
DAXS can work with your business to translate the four sites, applications and failure scenarios into a topology ready for acceptance testing and compare suitable operating options. The starting points for a discussion with DAXS are the site network plan, connectivity contracts and previous incident history.
Sources: WireGuard: Quick Start; OPNsense: WireGuard Site-to-Site; IETF RFC 7296: IKEv2; Mplify/MEF 70.2: SD-WAN Service Attributes.
