Skip to content

ADR 0023 — Cloud SDWAN On-Ramp Endpoint Service

  • Status: Accepted (formalized 2026-05-12 with v3.7.0 — bench-side scaffolds shipping in v3.7.0; cloud sprint ongoing)
  • Date: 2026-05-10
  • Deciders: TLSStress.Art project
  • Targets: v5.x bench-side scaffolds + parallel cloud-side sprint (~3-6 months)
  • Patent claim family: claim #15

Context

MÓDULO SDWAN/CoR-N.Art (vyos-vpn-remote-{1..10}) tests SDWAN tunnel behavior end-to-end. The remote endpoint is currently the bench's own synthetic VPN remote, in local mode.

Real-world SDWAN tests need a distributed cloud endpoint the bench can dial out to over IPSec — multi-PoP, multi-region, with iperf3 / H2 / H3 / DNS / NTP / QUIC services available at each PoP.

Two motivations: 1. Realism — testing through a real public Internet path is the only way to validate latency / loss / jitter under SDWAN encap 2. K6-vs-iperf3 open question — the SDWAN test framework needs a definitive iperf3 server endpoint (per discuss_vpn_ipsec_simulation.md open Q on baseline measurement tool)

Decision

Build TLSStress.Art Cloud Endpoint Service as a standalone IaaS offering reachable from the bench via IPSec. Bench's MÓDULO SDWAN/CoR-N.Art adds a remote-endpoint=cloud mode that dials out to the nearest PoP.

Architecture

Bench (customer DC)                    TLSStress.Art Cloud
┌──────────────────────┐               ┌────────────────────────────┐
│  MÓDULO SDWAN/CoR-N  │  IPSec tunnel │  Cloud Endpoint Service    │
│  remote-endpoint=    │◄─────────────►│  ├ StrongSwan (multi-tenant)│
│   cloud-pop-sao01    │  over public  │  ├ iperf3 fleet (per-PoP)  │
│                      │  Internet     │  ├ control plane API        │
└──────────────────────┘               │  ├ multi-PoP deploy         │
                                       │  └ Stripe metering          │
                                       └────────────────────────────┘
                                       PoPs: SAO01 GRU01 BSB01 IAD01
                                             FRA01 AMS01 SIN01 SYD01

Service tiers

Tier Tests/month PoPs Throughput cap Price model
Free 1 / 5min 1 (nearest) 50 Mbps $0
Pro 100/month 4 (region) 500 Mbps $X/test
Team+ 1000/month all 8 5 Gbps $Y/test
Enterprise unlimited dedicated PoP 25 Gbps quote

Stripe metering per IPSec session-second.

Bench integration (3 PRs in Phase 1)

  1. PR-18 — bench dashboard ↔ Cloud Endpoint Service control plane (IPSec session creation, PoP selection, credentials fetch)
  2. PR-19 — MÓDULO SDWAN/CoR-N.Art adds remote-endpoint=cloud mode + iperf3 client integration
  3. PR-20 — air-gap "self-hosted endpoint" container (operators can stand up their own private endpoint on customer infra when SaaS path unavailable)

Cloud-side stack (separate repo)

Repository: tlsstress-art/cloud-endpoint-service. Separate sprint ~3-6 months, parallel to bench Phase 1. Includes: - StrongSwan multi-tenant configuration generator - iperf3 fleet management (one process per tenant per PoP) - Control plane REST API (POST /sessions, GET /pops, etc.) - Multi-PoP deploy automation (Terraform + Ansible per CSP) - Stripe webhook + usage tracking

Consequences

Pros

  • Realistic SDWAN testing through actual Internet paths
  • SaaS revenue stream (recurring vs one-time bench license)
  • Resolves K6-vs-iperf3 open question (iperf3 standardized as baseline tool for SDWAN tests)
  • Multi-PoP geographic differentiator vs competitors

Cons / risks

  • Operating cost: 8 PoPs × StrongSwan + iperf3 + monitoring = $XYZ/mo
  • Compliance: tenant data crossing public Internet — must encrypt IPSec end-to-end + meet SOC 2 controls
  • Air-gap fallback (PR-20 self-hosted endpoint) splits codebase

Compatibility

  • Existing bench deployments: local mode still default; cloud mode is opt-in
  • Free tier requires Internet — air-gap operators use PR-20 self-hosted

References

  • Memory: discuss_cloud_endpoint_span_2026_05_10.md
  • Memory: discuss_vpn_ipsec_simulation.md (K6-vs-iperf3 baseline Q)
  • Code: PR-18/19/20 scaffolds (Wave 4 Phase 1, future)
  • Patent claim: #15