SD-WAN: Paying Enterprise Prices for VPNs and a Python Script

Let's talk about SD-WAN, the networking industry's latest attempt to sell you something you already have under a shiny new acronym. Software-Defined Wide Area Network sounds revolutionary, doesn't it? It promises dynamic path selection, application-aware routing, centralized management, and seamless failover between multiple internet connections. Vendors will tell you it's transforming enterprise networking, replacing MPLS with intelligent internet-based connectivity. Here's what SD-WAN actually is: it's a bunch of VPN tunnels (usually IPSec or sometimes WireGuard if the vendor is modern) with some automation scripts that measure latency and packet loss, then adjust routing policies accordingly. That's it. You're paying $50,000-$500,000+ for hardware appliances and annual licensing fees for functionality you could build yourself in a weekend with strongSwan or WireGuard, some Python or Bash scripts, and basic networking knowledge. The SD-WAN market is worth billions because vendors convinced enterprises that managing multiple VPN tunnels and doing path selection is impossible without proprietary hardware and expensive support contracts. Spoiler alert: it's not.

Let's dissect what SD-WAN actually does, why it's massively overpriced, how you can build it yourself, and why traditional WAN architecture with proper routing protocols might be better anyway.

What SD-WAN Claims to Do

The SD-WAN pitch goes something like this:

Problem: MPLS circuits are expensive. You pay $1,000-$5,000 per month for a 10-100 Mbps connection, and provisioning takes weeks or months. Your branch offices could have two cheap internet connections (cable and DSL, or fiber and 4G) for a fraction of the cost and ten times the bandwidth. But how do you securely connect branch offices over the public internet with reliable failover and optimal path selection?

SD-WAN Solution: Deploy SD-WAN appliances at each site (or virtual appliances in the cloud). These create encrypted tunnels between sites over any available transport (internet connections, MPLS, LTE, whatever). The appliances continuously measure path quality (latency, jitter, packet loss) and intelligently route traffic over the best available path. If one path fails or degrades, traffic seamlessly switches to another path. All of this is managed from a centralized controller that pushes configuration and policies.

The benefits they claim:

• Lower cost (internet is cheaper than MPLS)
• Higher bandwidth (broadband is faster than MPLS)
• Faster deployment (internet circuits provision in days, not months)
• Application-aware routing (prioritize VoIP over best path, send backup traffic over cheap path)
• Centralized management (configure 100 sites from one console)
• Zero-touch provisioning (ship appliances pre-configured, they call home and configure themselves)

This sounds great until you realize you're describing basic VPN functionality plus some automation that any competent network engineer can build.

What SD-WAN Actually Is

Strip away the marketing and here's SD-WAN:

Component 1: VPN Tunnels

SD-WAN appliances create encrypted tunnels between sites. Usually IPSec, sometimes vendor-proprietary protocols, occasionally modern stuff like WireGuard (rare, but Tailscale is pushing this).

This is literally what VPNs have done since the 1990s. strongSwan, OpenVPN, WireGuard, and countless other open-source and commercial VPN solutions create encrypted tunnels. Nothing new here.

Component 2: Multiple Tunnels Per Site Pair

Instead of one tunnel between Site A and Site B, SD-WAN creates multiple tunnels using different underlay paths (one over the primary internet connection, one over the backup connection, maybe one over LTE). This provides redundancy and multiple paths for traffic engineering.

Cool, except you can trivially configure multiple IPSec tunnels or WireGuard interfaces. I can set up three WireGuard tunnels between two sites in about 10 minutes. The configuration is maybe 50 lines total.

Component 3: Path Monitoring

SD-WAN appliances send probes (usually ICMP or UDP) across each tunnel to measure latency, jitter, and packet loss. They maintain statistics about path quality.

This is literally ping and basic statistics. You can write this in 20 lines of Python:

python

import subprocess
import time

while True:
    result = subprocess.run(['ping', '-c', '10', 'remote-ip'], 
                          capture_output=True, text=True)
    # Parse output for latency and loss
    # Update statistics
    time.sleep(30)

Or use existing tools like SmokePing, which has been doing this since 2005.

Component 4: Dynamic Routing

Based on path quality metrics, SD-WAN appliances adjust routing to prefer better paths. VoIP traffic goes over the low-latency path, bulk transfers go over the high-bandwidth path, everything fails over if a path goes down.

This is policy-based routing (PBR) combined with metric-driven route preference. Linux (and BSD, and any real router OS) has supported this for 20+ years. You can do this with iproute2, iptables/nftables for marking traffic, and some scripts to update routes based on your monitoring data.

For example, marking VoIP traffic and routing it via a specific interface:

bash

# Mark VoIP traffic
iptables -t mangle -A PREROUTING -p udp --dport 5060:5080 -j MARK --set-mark 1

# Route marked traffic via low-latency interface
ip rule add fwmark 1 table 100
ip route add default via [gateway-for-tunnel1] dev wg0 table 100

When your monitoring script detects that tunnel1 latency is bad, update the routes. Done. This is routing 101.

Component 5: Centralized Management

SD-WAN vendors provide a web interface where you configure policies once and they push to all sites. You define applications, paths, policies, and it propagates automatically.

This is configuration management. Ansible, Salt, Puppet, Chef, or even bash scripts with SSH and rsync can do this. You write your configuration templates, define your sites in a database or YAML file, and push configs. Entire industries run on this stuff.

Component 6: Zero-Touch Provisioning

Ship an appliance to a branch office, plug it in, it calls home to the controller, downloads its config, and establishes tunnels. Non-technical staff can deploy.

This is DHCP, a config server, and bootstrap configuration. Cloud-init does this for VMs. You can build this with a simple HTTP server and shell scripts:

bash

# On boot, device fetches config
curl https://config-server/api/device/$(get_serial_number) > /etc/mywan/config
configure_system_from_config
establish_tunnels

Every IoT device, cloud VM, and modern Linux system does zero-touch provisioning. It's not revolutionary, it's expected.

The Reality: You're Paying for Automation You Can Build

Here's what you're actually buying with SD-WAN:

1. VPN software (open source equivalents are free and probably better)
2. Path monitoring scripts (write it in 50 lines of code or use existing tools)
3. Policy-based routing (built into every modern OS)
4. Config management (Ansible is free)
5. A web GUI (every network admin can SSH and edit configs, or build a simple web interface)

The SD-WAN appliance is a Linux box (or BSD, or custom OS built on Linux) running VPN software, monitoring scripts, and routing daemons. The controller is a web application with a database. The "magic" is orchestration software written in Python, Go, or Java that glues these standard components together.

You're paying enterprise prices (hardware + licensing + support) for what is fundamentally someone else's integration work around standard open-source components. The vendors don't have secret cryptographic algorithms or revolutionary networking protocols. They're running VPNs and scripts, wrapped in a pretty GUI, with professional support.

For small businesses, maybe the support and simplicity are worth it. For enterprises with actual network engineering staff, you're wasting money.

Building Your Own SD-WAN: A Weekend Project

Let's build basic SD-WAN functionality ourselves:

Step 1: Set Up VPN Tunnels

Using WireGuard (modern, fast, simple):

bash

# On each site, install WireGuard
apt-get install wireguard

# Generate keys
wg genkey | tee privatekey | wg pubkey > publickey

# Configure tunnel (wg0.conf)
[Interface]
PrivateKey = <private-key>
Address = 10.0.1.1/24
ListenPort = 51820

[Peer]
PublicKey = <remote-public-key>
AllowedIPs = 10.0.2.0/24
Endpoint = remote-ip:51820
PersistentKeepalive = 25

# Bring up interface
wg-quick up wg0

Repeat for each tunnel. You now have encrypted connectivity. This took 10 minutes.

Using strongSwan (if you need IPSec compatibility):

bash

# Install strongSwan
apt-get install strongswan

# Configure /etc/ipsec.conf and /etc/ipsec.secrets
# Bring up tunnels
ipsec up tunnel1

Slightly more config than WireGuard but still straightforward.

Step 2: Path Monitoring

python

#!/usr/bin/env python3
import subprocess
import json
import time

TUNNELS = {
    'wg0': '10.0.1.1',
    'wg1': '10.0.2.1',
    'wg2': '10.0.3.1'
}

def ping_tunnel(tunnel_ip):
    result = subprocess.run(
        ['ping', '-c', '5', '-W', '1', tunnel_ip],
        capture_output=True, text=True
    )
    # Parse ping output for latency and loss
    # Return metrics
    pass

def update_path_metrics():
    metrics = {}
    for tunnel, ip in TUNNELS.items():
        metrics[tunnel] = ping_tunnel(ip)
    
    # Save metrics to file
    with open('/var/lib/wan-metrics.json', 'w') as f:
        json.dump(metrics, f)

if __name__ == '__main__':
    while True:
        update_path_metrics()
        time.sleep(30)

Run this in the background. You now have path monitoring. This took 30 minutes to write and test.

Step 3: Dynamic Routing

bash

#!/bin/bash
# Read metrics
METRICS=$(cat /var/lib/wan-metrics.json)

# Determine best tunnel based on latency
BEST_TUNNEL=$(echo $METRICS | jq -r 'to_entries | min_by(.value.latency) | .key')

# Update default route
ip route replace default dev $BEST_TUNNEL

# Classify traffic by application
# VoIP always uses lowest latency
iptables -t mangle -A PREROUTING -p udp --dport 5060:5080 -j MARK --set-mark 1
ip rule add fwmark 1 table 100
ip route add default dev wg0 table 100  # Assuming wg0 is low-latency path

# Bulk traffic uses highest bandwidth path
iptables -t mangle -A PREROUTING -m conntrack --ctstate NEW -j MARK --set-mark 2
ip rule add fwmark 2 table 200
ip route add default dev wg1 table 200

Run this periodically (cron every minute, or triggered by your monitoring script). You now have dynamic path selection. This took 20 minutes.

Step 4: Centralized Management

yaml

# sites.yaml
sites:
  - name: branch1
    location: New York
    tunnels:
      - interface: wg0
        remote_ip: 198.51.100.10
        remote_pubkey: abc123...
      - interface: wg1
        remote_ip: 203.0.113.10
        remote_pubkey: def456...
  - name: branch2
    location: Chicago
    tunnels:
      - interface: wg0
        remote_ip: 198.51.100.20
        remote_pubkey: xyz789...

bash

# deploy.sh
#!/bin/bash
for site in $(yq eval '.sites[].name' sites.yaml); do
  # Generate configs from templates
  generate_config $site
  
  # Push to site via SSH
  scp config.tar.gz $site:/etc/mywan/
  ssh $site 'cd /etc/mywan && tar xzf config.tar.gz && systemctl restart mywan'
done

You now have centralized config management. This took 1-2 hours to write a decent template system.

Step 5: Web GUI (Optional)

If you really want a GUI, use Flask or Django:

python

from flask import Flask, render_template, request
import yaml

app = Flask(__name__)

@app.route('/')
def dashboard():
    metrics = load_metrics()
    return render_template('dashboard.html', metrics=metrics)

@app.route('/configure', methods=['GET', 'POST'])
def configure():
    if request.method == 'POST':
        update_site_config(request.form)
        deploy_configs()
    return render_template('configure.html')

Add some HTML templates and you have a web interface. This took 4-6 hours.

Total Time Investment

• Initial setup and learning: 8-16 hours
• Tunnel configuration: 2-4 hours
• Monitoring scripts: 2-4 hours
• Routing automation: 2-4 hours
• Config management: 4-8 hours
• Web GUI (optional): 4-8 hours

Total: 20-44 hours of engineering time, depending on complexity and polish.

Cost: $0 for software (all open source), your time (sunk cost, you're already paying engineers), commodity hardware (any x86 server or even Raspberry Pi for small sites).

Compare this to SD-WAN: $10,000-$50,000 per site for appliances, $5,000-$20,000 annual licensing per site, vendor lock-in, proprietary protocols, and you're still running VPNs and scripts under the hood.

The Traditional WAN Alternative: Do It Right

Here's another perspective: maybe you don't need SD-WAN or DIY SD-WAN. Maybe you need proper WAN architecture.

Option 1: MPLS with Proper Redundancy

Yes, MPLS is more expensive per megabit than internet. But it's predictable, has SLAs, and doesn't traverse the chaotic public internet. For enterprises that actually need reliability, MPLS from a tier-1 carrier with redundant connections and proper routing (BGP multihoming, diverse paths) might be the right answer.

SD-WAN tries to make cheap internet connections behave like MPLS. Sometimes it's better to just buy MPLS.

Option 2: BGP with Multiple Transits

Get your own ASN and IP space (not hard for organizations with legitimate need). Multihome to multiple transit providers with BGP. Now you have:

• Automatic failover (BGP withdraws routes on failure)
• Path diversity (traffic routes through different providers)
• Policy control (BGP communities, AS-path prepending for traffic engineering)
• Industry-standard protocols (every router speaks BGP)

This is how the internet backbones work. It's proven, scalable, and doesn't require proprietary appliances.

Option 3: Hybrid Approach

Use MPLS for core connectivity between major sites. Use site-to-site VPNs (strongSwan, WireGuard) over internet for branch offices. Use BGP or OSPF to propagate routes. Let proper routing protocols handle failover.

This separates concerns: critical sites get reliable connectivity, branch offices get cheap connectivity, routing protocols handle the rest.

Why SD-WAN Vendors Exist

If building SD-WAN is so easy, why is it a multi-billion dollar market?

Reason 1: Fear, Uncertainty, and Doubt (FUD)

Vendors convince enterprises that networking is too hard, too risky to do yourself. "What if something breaks? What if your scripts have bugs? What if you can't scale?"

This is nonsense. Open source software runs the internet. Google, Amazon, Facebook, and every major tech company build their own networking solutions. They're not buying SD-WAN appliances.

Reason 2: Risk-Averse IT Management

IT managers are often evaluated on uptime, not cost efficiency. Buying a vendor solution provides someone to blame when things break. "We went with [Big Vendor], they have 24/7 support, we did our due diligence."

Building your own means taking responsibility. If your scripts break something, it's your fault. This is a cultural problem, not a technical one.

Reason 3: Lack of In-House Expertise

Some organizations lack network engineering talent. They have generalist IT staff who can manage Windows servers and answer helpdesk tickets, but don't know how to configure VPNs or policy-based routing.

For these organizations, buying an SD-WAN solution makes sense. But that's an admission that you're paying for someone else's expertise, not that SD-WAN is technically superior.

Reason 4: Time to Market

Building your own solution takes time. Deploying an SD-WAN vendor's solution can happen faster, especially if you're doing 50+ sites simultaneously.

This is a valid reason for vendors to exist. But it's a convenience tax, not a technology premium.

Reason 5: Support and Warranty

Vendors provide support contracts, guaranteed response times, and warranty replacements. If an appliance dies, they ship a replacement overnight.

This has value, but you're paying 10-20x the cost of the hardware for this service. Buying spare hardware and maintaining your own inventory is almost always cheaper.

The Vendor Lock-In Trap

Here's what happens when you deploy SD-WAN:

Year 1: You buy appliances and initial licensing. Everything works great. You're happy you didn't have to build it yourself.

Year 3: Licensing renewal comes up. The price has increased 20%. You negotiate, get it down to 10% increase. You pay because ripping out the system would be expensive.

Year 5: Your vendor gets acquired by a private equity firm. Prices increase 50%. Support quality decreases. You're now locked in because migrating 100+ sites to a different solution is a multi-year project.

Year 7: You realize you're paying $500,000 annually for licensing on top of your hardware costs, and your solution is just running VPNs and routing software that hasn't fundamentally changed since you deployed it.

This is the vendor lock-in cycle. It's why open-source solutions are appealing. You're never locked in. You can migrate, modify, or replace components incrementally.

The "It's Just a Python Script" Reality

Let's be honest about what's inside these SD-WAN appliances:

Most vendors build on Linux or BSD. They use standard VPN implementations (strongSwan, OpenVPN, or custom IPSec stacks). They use standard routing (BIRD, Quagga/FRR, or custom implementations of BGP/OSPF). The "secret sauce" is orchestration software that glues these together.

That orchestration software? It's mostly Python or Go. It reads metrics from the system, applies policy rules, and updates routing tables. The web interface is probably React or Vue.js talking to a REST API, with a PostgreSQL or MongoDB database backend.

You're paying enterprise prices for someone else's Python script.

Don't get me wrong, writing good orchestration software is work. But it's not magic. It's not patentable algorithms or revolutionary networking. It's integration code that you could write (or contract someone to write for you) for a fraction of what you'll pay in licensing fees over 5 years.

When SD-WAN Makes Sense

To be fair, SD-WAN isn't always a terrible choice:

Small businesses without IT staff: If you have 10-20 sites and no network engineers, buying an SD-WAN solution with professional support might be the right choice. The alternative is paying consultants $200/hour to maintain your custom solution.

Rapid deployment at scale: If you need to deploy 100+ sites in 6 months and don't have time to build a system, SD-WAN vendors can execute faster.

Regulated environments: Some industries have compliance requirements that favor buying "certified" solutions from established vendors. Building your own might not satisfy auditors.

Organizations that genuinely lack expertise: If your IT team doesn't know networking and can't learn, buying a solution makes sense. But this is an indictment of your hiring, not a vindication of SD-WAN.

For everyone else, especially organizations with competent network engineering teams, SD-WAN is overpriced automation that you can build better and cheaper yourself.

The Open Source SD-WAN Projects

If you want SD-WAN functionality but not vendor lock-in, several open-source projects exist:

VeloCloud (now VMware): Used to be independent, now corporate, but initially proved SD-WAN could work.

OpenWRT with VPN packages: For small sites, OpenWRT on commodity routers can do basic SD-WAN functionality.

StrongSwan with scripting: Full IPSec implementation, scriptable, free.

WireGuard with Tailscale/Netmaker/Netbird: Modern take on mesh VPNs with orchestration.

ZeroTier: Overlay network that creates virtual LANs over the internet. Close to SD-WAN functionality.

Nebula (by Slack): Open-source overlay network with mesh routing and certificate-based auth.

These aren't complete SD-WAN solutions, but they provide the building blocks. Combined with your own automation, they're competitive with commercial SD-WAN.

Conclusion: Take Control of Your Network

SD-WAN is a solution looking for a problem that competent network engineering already solved. VPNs have existed for 30 years. Policy-based routing has existed for 25 years. Path monitoring is trivial. Configuration management is a solved problem. What SD-WAN vendors sell is packaging and marketing.

For organizations with network engineering expertise, building your own "SD-WAN" is not only feasible but often superior:

• Complete control (no vendor lock-in)
• Customizable to your exact needs (not one-size-fits-all)
• Transparent (you know exactly what's running)
• Maintainable (you're not dependent on vendor support)
• Cost-effective (pay once for engineering, not annually for licensing)

For organizations without that expertise, buying SD-WAN might make sense, but understand what you're buying: convenience and support, not revolutionary technology.

The next time a vendor pitches you SD-WAN, ask yourself: "Could I build this with WireGuard and a weekend?" The answer is usually yes. And if it's yes, you should probably build it instead of paying six figures annually for someone else's integration work.

Network engineering is a skill. If you have it, use it. Don't outsource what you can do better yourself. Your CFO will thank you when you're not paying $500,000 in annual licensing fees for functionality you could have built for $50,000 once.

SD-WAN is VPNs plus automation plus marketing. The VPNs are open source, the automation is straightforward, and the marketing is expensive. Choose wisely.