Since VPN is the underlying infrastructure for SD-WAN connectivity, it's important to understand the foundamental of each protocol.
A virtual private network (VPN) extends a private network across a public network, such as the Internet. It enables a computer or network-enabled device to send and receive data across shared or public networks as if it were directly connected to the private network, while benefiting from the functionality, security and management policies of the private networks. VPNs allow employees to securely access their company's intranet while traveling outside the office. Similarly, VPNs securely connect geographically separated offices of an organization, creating one cohesive network.
Please refer to the respective submenus for details.
WireGuard is a modern, high-performance Layer 3 VPN protocol designed to provide secure encrypted tunneling with minimal configuration complexity. It operates over UDP and uses state-of-the-art cryptographic primitives to ensure strong security while maintaining extremely low overhead.
WireGuard is built into the Linux kernel (since Linux 5.6) and is also available for Windows, macOS, iOS, Android, and BSD systems.
Protocol Architecture
WireGuard operates as a Layer 3 routed VPN. Unlike traditional VPNs that rely on certificates and negotiation frameworks, WireGuard uses:
Static public/private key pairs
Cryptokey routing
UDP-based encrypted transport
Each peer is identified by its public key. Traffic routing is defined by the AllowedIPs parameter, which determines both:
Which traffic is encrypted and sent to the peer
Which source IPs are accepted from that peer
Cryptography Suite
WireGuard uses modern and opinionated cryptographic primitives:
Key Exchange: Curve25519
Encryption: ChaCha20
Authentication: Poly1305
Hashing: BLAKE2s
WireGuard typically outperforms OpenVPN and is comparable or faster than IPsec in many deployments.
Our SSLVPN is based on OpenVPN technology, which utilizes Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL) cryptographic protocols. It uses X.509 certificates and hence asymmetric cryptography to authenticate the counterparty with whom they are communicating, and to exchange a symmetric session key. This session key is then used to encrypt data flowing between the parties. This allows for data/message confidentiality, and message authentication codes for message integrity and as a by-product, message authentication.
mbox SSL VPN has following key characteristics:
primarily runs in client-to-server VPN mode. One mbox acts as a VPN server (head end); one mbox acts as a client (remote end). In this case, remote/client site mbox can support dynamic/DHCP public IP addressing or behind any firewall (without punch a hold on the firewall for inbound access) because the VPN is always initiated from remote(client) site. This is a significant advantage over traditional IPSec or GRE VPN tunnels, which require both sites to have static IP addresses and directly accessible/reachable to each other. And it is extremely scalable, easy to deploy and support.
two mbox gateways form site-to-site VPN (for protected networks) for their protected private networks. Hosts behind mbox gateways can communicate directly, as if they are passing through a private leased line. Dynamic routing protocols (OSPF and BGP) are used to auto learn/advertise routes/networks behind each gateway.
all SSLVPN tunnels can run in either tunnel mode (default) or tap mode (layer 2 tunnel). Note: If you want to run OSPF or bonding/bridging with SSL tunnel, it's a must to run in tap mode.
in either tunnel or tap mode, raw/original traffic is encapsulated and encrypted into a virtual tunnel:
there's a virtual IP assigned to the tunnel interface, for both server and client
by default, no address translation for raw traffic passing through the tunnel, eg. hosts on each side "see" each other's original IP address
by default all traffic is allowed to pass through the tunnel, eg. no firewall filtering inside tunnel
supports both unicast and multicast across the tunnel
SSLVPN tunnel provides data encryption, integration and authentication
RSA certificate for gateway authentication
DH algorithm for generating session keys
SHA-512/MD5-128 for data integrity
DES/3DES/AES-256 for data encryption
Internet Protocol Security (IPsec) is a very complex protocol suite for secure Internet Protocol (IP) communications, by building secure tunnels/sessions to authenticate and encrypt each IP packet passing between two hosts or gateways.
IPsec includes protocols for establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic keys to be used during the session. An IPSec tunnel consists of 3 Security Associations (SA). An SA defines a bundle of algorithms and parameters (such as keys) that is being used to encrypt and authenticate a particular flow in one direction. Therefore, in normal bi-directional traffic, the flows are secured by a pair of security associations.
There're a lot of details we can google about IPSec. In summary, to establish an IPSec tunnel, we configure three sets of policies:
IKE policy (as in IPSec Phase I). This phase basically authenticates peers first then negotiate a bundle of encryption/hashing algorithms to generate session key, which is used by Phase II to encrypt packets. One peer (host or gateway) can be configured with multiple set/combination of policies, and when two peers are initiating a tunnel, they will agree on a matched policy. If no matching policy between two peers, tunnel will not come up. Each IKE policy consists of a combination of either one of these parameters. Supported parameters are listed below:
authentication: pre-shared key or RSA-sig
encryption: 3DES, AES, AES-192, AES-256
hashing: MD5, MD5-128, SHA, SHA-256, SHA-512
version: IKEv1 or IKEv2
ESP policy (as in IPSec Phase II). IPSec can use either Authentication Header (AH) or Encapsulating Security Payload (ESP) to secure data, but AH is rarely used, so mbox will only support ESP. Under ESP, there're also two modes to "carry" the packets: transport mode or tunnel mode. Again, since transport mode is rarely used, mbox will only support tunnel mode. Diagram below illustrates a typical ESP packet. In our configuration, we usually call ESP-policy, which consists of a combination of either one of these options:
encryption: 3DES, AES, AES-192, AES-256
hashing: MD5, MD5-128, SHA, SHA-256, SHA-512
GRE (Generic Routing Encapsulation) is a Layer 3 tunneling protocol defined in RFC 2784 that enables the encapsulation of various network layer protocols inside an IP tunnel. It allows packets from one network to be transported across an intermediate IP network as if they were directly connected. GRE is protocol-agnostic, meaning it can carry IPv4, IPv6, multicast, and even non-IP traffic.
GRE operates by encapsulating the original packet with a new IP header, forming a point-to-point tunnel between two endpoints. Unlike VXLAN, GRE does not use UDP and does not provide segmentation identifiers. It is commonly used for site-to-site connectivity, routing protocol transport (such as OSPF, BGP, or EIGRP), and multicast forwarding across Layer 3 networks.
GRE itself does not provide encryption or authentication. For secure deployments, it is typically combined with IPsec or other encryption mechanisms. Due to its simplicity and low overhead, GRE remains widely used in enterprise networks, SD-WAN overlays, and service provider environments where lightweight tunneling is required.
VXLAN (Virtual Extensible LAN) is a Layer 2 overlay tunneling protocol designed to extend Ethernet networks over Layer 3 infrastructure. It encapsulates Layer 2 Ethernet frames inside UDP packets, allowing geographically dispersed networks to appear as if they are on the same local LAN. VXLAN is standardized under RFC 7348 and is widely used in data centers, cloud environments, and SD-WAN deployments.
VXLAN introduces a 24-bit VXLAN Network Identifier (VNI), which enables up to 16 million isolated Layer 2 segments. This significantly exceeds the scalability limits of traditional VLANs (4,096 IDs). Each VXLAN segment operates independently, making it suitable for multi-tenant environments, network segmentation, and large-scale virtualized infrastructures.
VXLAN operates over UDP (default port 4789), making it compatible with existing IP routing infrastructure and NAT traversal. It is commonly deployed between VXLAN Tunnel Endpoints (VTEPs), which perform encapsulation and decapsulation. VXLAN is often combined with secure transport mechanisms such as IPsec or WireGuard when encryption is required, as VXLAN itself does not provide built-in encryption.