SD-WAN Overlay Without Provider Encryption¶

Overview¶

Some organizations operate under a policy that prohibits the network provider from encrypting their data in transit. The customer retains sole control of its own cryptography (encrypting at the application layer, or with their own appliances) and does not want a third party holding keys or terminating encryption on their behalf. In short: the customer owns the security (overlay), and the provider owns the transport (underlay) only.

For these deployments, RansNet can build the SD-WAN overlay with no provider encryption using one of two protocols:

VXLAN — a peer-to-peer clear-text overlay, ideal for Layer-2 extension and private/static-IP underlays.
SSL VPN (OpenVPN) in no-encryption mode — a client-server clear-text overlay that, unlike VXLAN, works when branches are behind NAT or have dynamic IPs.

Either way, the overlay still benefits from the full set of SD-WAN capabilities — multi-WAN failover, dynamic routing, traffic steering, and QoS.

Skipping provider encryption also brings a performance benefit: when the customer already encrypts end-to-end, a second overlay encryption layer is redundant. Running the overlay clear-text produces better tunnel throughput.

Security responsibility

A clear-text overlay does not encrypt traffic — the payload travels unencrypted inside the tunnel encapsulation. This design is only appropriate when one of the following is true:

The underlay is a private circuit (MPLS or leased line) that is not exposed to untrusted third parties, or
The customer encrypts traffic end-to-end themselves (e.g., application-layer TLS/mTLS or separate appliances).

When to Use¶

Condition	Why an unencrypted overlay fits
Provider-side encryption prohibited by policy/regulation	The overlay transports traffic without the provider applying encryption
Customer performs its own end-to-end encryption	Avoids redundant double encryption and key custody by the provider
Private MPLS / leased-line underlay	The transport is already isolated; provider encryption is unnecessary
Need L2 extension or L3 routed transport	Both protocols support either mode

Choosing the Overlay Protocol¶

The deciding factor is usually how the remote sites are addressed. VXLAN requires both tunnel endpoints to be static and routable; SSL VPN's client-server model tolerates dynamic and NAT'd branches.

	VXLAN	SSL VPN (OpenVPN), clear-text
Model	Peer-to-peer / multipoint VTEP	Client–server
Remote behind NAT / dynamic IP	❌ Not supported	✅ Supported (branch initiates to the server)
Hub / server address	Static, routable	Static, routable IP or FQDN
L2 / L3	Both — bridge (L2) or route (L3)	Both — tap (L2) or tun (L3)
Transport	UDP/4789	UDP (preferred) or TCP (firewall-restrictive sites)
Overhead	Lowest	Slightly higher (OpenVPN framing)
Best for	Private MPLS/leased-line underlay; L2 extension; lowest overhead	Branches on the public Internet with dynamic/NAT'd IPs

Requirements¶

RansNet gateway (CMG/HSG) and branch routers (UA/HSA/XE), provisioned in mfusion
A suitable underlay between sites, depending on the chosen overlay:
- VXLAN — a routable underlay where both endpoints are static and reachable (MPLS, leased line, or static-IP WAN)
- SSL VPN — any underlay, including the public Internet with NAT'd or dynamic-IP branches (only the server needs a fixed IP/FQDN)
Agreement that traffic is not encrypted by RansNet on this overlay

Option A — VXLAN Overlay¶

VXLAN encapsulates traffic in UDP (port 4789) and forms a peer-to-peer overlay between VXLAN Tunnel Endpoints (VTEPs). It can provide either Layer 2 (bridged) or Layer 3 (routed) connectivity. For protocol background, see VPN Protocols — VXLAN.

VTEP Addressing¶

Because a clear-text overlay has no peer-identity or NAT-traversal mechanism, both VTEP endpoints must be real, routable, stable addresses on the shared underlay.

Endpoint	Addressing requirement
Hub (gateway)	Static, routable VTEP address — every branch is configured with `remote <hub-ip>`.
Remote — private MPLS / leased line	Carrier-assigned site IP is fixed and routable (effectively static, no NAT). The clean, supported case.
Remote — routable but dynamic	The hub can learn the branch source via data-plane MAC learning, but it is non-deterministic and hard to firewall. Static strongly recommended.
Remote — behind NAT / dynamic public IP	Not supported with VXLAN — use Option B (SSL VPN) instead.

Layer 2 Mode (Bridged Overlay)¶

In Layer 2 mode, the VXLAN tunnel is bridged to the LAN interface so all sites share a single broadcast domain and subnet — identical to the Layer-2 SD-WAN (Hub and Spoke) design, but without the IPsec encryption layer.

Configuration via mfusion — Follow the Layer-2 SD-WAN guide, with one difference: when adding the SD-WAN VPN instance, select no encryption (clear-text VXLAN) instead of IPsec or WireGuard. mfusion compiles the VXLAN + bridge configuration and pushes it to each branch.

CLI reference (auto-generated by mfusion; no ipsec blocks — this is what makes the overlay clear-text. VTEP addresses use underlay-routable IPs):

Gateway (hub):

!
interface vxlan1
 description "VXLAN overlay (no encryption)"
 vx-local 10.10.0.1
 enable
 bridge-group 1
!
interface vlan 0 1
 enable
 bridge-group 1
!
interface bridge br1
 description "VXLAN L2 overlay bridge"
 enable
 ip address 10.0.0.1/24
!

Branch (spoke):

!
interface vxlan1
 description "VXLAN overlay (no encryption)"
 vx-local 10.10.0.3 remote 10.10.0.1
 enable
 bridge-group 1
!
interface vlan 1 1
 enable
 bridge-group 1
!
interface bridge br1
 description "VXLAN L2 overlay bridge"
 bridge
 enable
!

Key points:

vx-local 10.10.0.1 (hub) and vx-local 10.10.0.3 remote 10.10.0.1 (branch) use the underlay-routable site IPs as VTEP endpoints — replace with your actual MPLS/WAN IPs.
bridge-group 1 places both vxlan1 and the LAN VLAN into the br1 bridge, creating the flat Layer-2 overlay.
No ipsec configuration is present — traffic is carried in clear text inside VXLAN/UDP.
LAN devices across all sites share one subnet (e.g., 10.0.0.0/24); the hub bridge holds the gateway IP 10.0.0.1.

Layer 3 Mode (Routed Overlay)¶

In Layer 3 mode, the VXLAN overlay is a routed transit segment rather than a shared LAN. Each site keeps its own LAN subnet and routes to remote subnets across the overlay. Assign a transit IP directly to the vxlan1 interface at each site — no bridge interface is required.

CLI reference (replace addresses with your own underlay, transit, and LAN subnets):

Gateway (hub) — LAN 10.0.0.0/24, transit 10.254.0.1/24:

!
interface vxlan1
 description "VXLAN L3 overlay (no encryption)"
 vx-local 10.10.0.1
 enable
 ip address 10.254.0.1/24
!
interface vlan 0 1
 description "HQ LAN"
 enable
 ip address 10.0.0.1/24
!
ip route 192.168.3.0/24 10.254.0.3
!

Branch (spoke) — LAN 192.168.3.0/24, transit 10.254.0.3/24:

!
interface vxlan1
 description "VXLAN L3 overlay (no encryption)"
 vx-local 10.10.0.3 remote 10.10.0.1
 enable
 ip address 10.254.0.3/24
!
interface vlan 1 1
 description "Branch LAN"
 enable
 ip address 192.168.3.1/24
!
ip route 10.0.0.0/24 10.254.0.1
!

Key points:

The transit IP is assigned directly to vxlan1 — no bridge interface is used, and the LAN VLAN keeps its own distinct subnet.
The vxlan1 transit subnet (10.254.0.x/24) is shared by all VTEPs across the overlay; this is the next-hop network for inter-site routing.
Static routes direct each remote LAN subnet to the remote site's transit IP. For many sites, advertise these subnets with OSPF/BGP over the overlay instead of static routes.

VXLAN Verification¶

Items to Test	Command	Expected Outcome
VXLAN interface up	`show interface vxlan1`	`Admin State` and `Link State` show `UP`
VTEP peer learned	`show interface vxlan1`	VXLAN Peers table lists the remote VTEP IP (e.g., `dst 10.10.0.1`)
No IPsec present	`show ipsec status`	No peers (confirming the overlay is clear-text by design)
L2 mode — bridge members	`show interface bridge`	`br1` lists both `vxlan1` and the LAN VLAN as members
L2 mode — LAN reachability	From a branch LAN host, `ping 10.0.0.1`	Reply from the hub bridge gateway
L3 mode — transit reachability	`ping 10.254.0.1` (from branch)	Reply across the transit subnet
L3 mode — remote subnet	`ping` a host in the remote LAN	Reply via the route over the overlay

Confirming clear text

Capture the overlay on the WAN: tcpdump interface <wan> port 4789 detail. The VXLAN/UDP packets are visible and the inner payload is not encrypted by the router — any confidentiality comes from the customer's own end-to-end encryption or the private underlay.

Option B — SSL VPN (OpenVPN), Clear-Text¶

When branches sit behind NAT or have dynamic public IPs, VXLAN cannot form a tunnel. SSL VPN (OpenVPN) solves this with a client-server model: only the server (hub) needs a fixed, reachable address — branches connect outbound as clients, so their address can change or be NAT'd.

Running OpenVPN in no-encryption mode carries the data channel in clear text, satisfying the no-provider-encryption requirement while keeping the NAT-friendly client-server behaviour. For protocol background, see VPN Protocols — SSL VPN (OpenVPN).

How It Works¶

Server (hub) — runs on the gateway, reachable at a static public IP or FQDN. Branches initiate to it.
Clients (branches) — connect outbound; may be behind NAT or on dynamic IPs. No inbound reachability or static address required at the branch.
L2 (tap) or L3 (tun) — tap mode bridges Ethernet frames (shared subnet across sites); tun mode carries routed IP packets (separate subnets).
UDP or TCP — UDP is preferred for performance; TCP allows traversal of firewalls that block UDP.
No-encryption mode — the data channel uses no cipher, so the payload is clear text.

Configuration¶

Configure an SSL VPN instance in mfusion (SD-WAN → VPN → Add VPN Instance):

Select SSL VPN (OpenVPN) as the protocol and set encryption to None (clear text).
Choose tap (L2) or tun (L3) to match your connectivity model.
Set the server's reachable IP/FQDN and transport (UDP or TCP).
Assign branch routers to the instance — mfusion compiles and pushes the client configuration to each branch automatically.

Note

The server (hub) still requires a static public IP or FQDN — this is the one fixed endpoint in the design. Everything downstream (the branches) can be dynamic or NAT'd.

SSL VPN Verification¶

Items to Test	Command	Expected Outcome
Tunnel interface up	`show interface tap0` (tap) or the tun interface	Interface shows `UP` with the overlay IP
Branch connected to server	Check VPN status on the gateway	Each branch appears as a connected client
No IPsec present	`show ipsec status`	No peers — confirming the overlay is clear-text
End-to-end reachability	`ping` across the overlay to a remote LAN host	Reply via the tunnel