Software-defined WAN (SD-WAN)

The request, step by step

1. Classify the traffic at the branch

   Everything at the site enters one edge device, which identifies the application behind each flow. Identification is the weakest link in the chain: it depends on inspection, certificate names or vendor signatures, and it degrades as traffic becomes more opaque.

   • Request: Branch staff to SD-WAN edge device, “ERP, SaaS and web traffic from the branch LAN”
   • Request: Card payment terminal to SD-WAN edge device, “Payment traffic, kept in its own segment”
   • Request: SD-WAN edge device to Path choice, “Classified flow presented for steering”

   Emphasised at this step: SD-WAN edge device.

2. Choose a link for each application

   The edge compares live circuit measurements against the policy it holds and places each flow on a link. The ERP client takes the contracted circuit; SaaS and web traffic exit locally instead of being carried back to the data centre first.

   • Request: Path choice to Contracted circuit, “ERP flows placed on the contracted circuit”
   • Request: Path choice to Local broadband, “SaaS and web exit locally”

   Emphasised at this step: Path choice.

3. Carry one overlay over mixed transport

   Logically there is a single encrypted overlay between the edges. The transport plane underneath it is several unrelated circuits, and the overlay hides which one is in use at any moment from everything above it.

   • Request: Path choice to Data centre edge device, “One encrypted overlay tunnel to the data centre”
   • Request: Path choice to Cloud security service, “Internet-bound traffic steered to inspection”
   • Request: Contracted circuit to Data centre edge device, “Carries the tunnel across the carrier network”
   • Request: Local broadband to Cloud security service, “Carries the tunnel to the security service”

   Emphasised at this step: Data centre edge device.

4. Reach the destinations, with inspection bought separately

   Private traffic arrives at the data centre and reaches its application. Internet and SaaS traffic arrives at a cloud security service that inspects it. The fabric steered that traffic; it did not inspect it, and the service doing so is a different product.

   • Request: Data centre edge device to ERP application, “Reaches the ERP application”
   • Request: ERP application to Order records, “Application reads order records”
   • Request: Cloud security service to Sanctioned SaaS suite, “Inspected SaaS traffic”
   • Request: Cloud security service to Internet destination, “Inspected web traffic”

   Emphasised at this step: Cloud security service.

5. Fail over, then report

   When both circuits degrade, flows move to the cellular standby without changing the overlay or the segment they sit in. Measurements and path changes go back to the orchestrator, which is also the only place the policy itself can be edited.

   • Request: Path choice to Cellular standby, “Failover when both circuits degrade”
   • Request: Cellular standby to Data centre edge device, “Carries the same tunnel over cellular”
   • Telemetry: SD-WAN edge device to SD-WAN orchestrator, “Loss, latency and jitter per circuit”
   • Context: SD-WAN orchestrator to SD-WAN edge device, “Application policy pushed to every edge”
   • Telemetry: SD-WAN orchestrator to Network operations, “Path changes and per-application performance”

   Emphasised at this step: SD-WAN orchestrator.

Attempts shown, and where each one stops

• Compromised device on guest wireless attempts:

  • Attack: Compromised device on guest wireless to Card payment terminal, “Probes the branch LAN for the payment terminal”
  • Attack: Compromised device on guest wireless to Path choice, “Its outbound traffic is steered like any other flow”
  • Terminated here by SD-WAN edge device — “Denied: guest wireless has no route to the payment segment”. The line stops short and takes a bar, not an arrowhead.

Annotations

1. This line is logical, not physical

   Relationship — Request: Path choice to Data centre edge device, “One encrypted overlay tunnel to the data centre”

   Nothing travels along it. It represents a tunnel whose real path is whichever transport-plane link the edge selected, and it exists so that applications and routing above the fabric stop caring which circuit is alive. Hide the transport plane and this line still describes the network correctly.

2. Why nothing terminates this attempt

   Relationship — Attack: Compromised device on guest wireless to Path choice, “Its outbound traffic is steered like any other flow”

   The overlay classifies this flow, encrypts it and gives it a good path, exactly as it would for legitimate traffic. No control in the fabric opens it, so there is no counterpart ending the attempt. Anything that would stop it lives in the separately purchased service further along.

3. The one refusal the fabric can genuinely make

   Relationship — Blocked: Compromised device on guest wireless stopped at SD-WAN edge device, “Denied: guest wireless has no route to the payment segment”

   The bar means the attempt ended here rather than reaching its target. Segment separation is enforced by the edge itself, which is why this refusal is real. Its scope is narrow: it decides which segments may reach each other, not whether the traffic inside a permitted segment is hostile.

4. Central policy, local decision

   Component “Path choice”

   The orchestrator distributes intent, such as which class of application prefers which class of link. The choice for a given flow is made here, from measurements only this device has. That split is why behaviour differs between sites under identical policy.

5. This boundary is somebody else's product

   Boundary “Cloud security service” (third party)

   Converged offerings bundle it, and the bundle is still two services with two policy models. Crossing this boundary is where inspection starts, so an internet exit that does not cross it is uninspected however good the path selection is.

6. Encryption does not promote the carrier

   Boundary “Carrier transport” (untrusted)

   Tunnelling over a circuit stops the carrier reading the payload. It does not make the circuit dependable, private in its metadata, or independent of the other circuit sold by the same provider. The badge stays as it is.

7. A single control plane is a single dependency

   Component “SD-WAN orchestrator”

   Edges normally keep forwarding on their last known policy when this is unreachable, which is the right default and also means no change can be made during the outage. Establish the hold behaviour and the local override in writing before it matters.