Tagged: SDWAN
112 posts · browse all tags
-
CVE-2026-76504 and Cisco's October 2026 Fixes: SD-WAN Manager, NX-OS, APIC and License On-Prem
One exploited Catalyst SD-WAN Manager authentication bypass (CVE-2026-76504, CVSS 9.8, on CISA KEV) and a seven-day-later batch of 14 advisories covering NX-OS, APIC and License On-Prem, including a CVSS 10.0 that is not the one being exploited.
-
Certificate Required, Credentials Not: CVE-2026-93952 and the Second VeloCloud Orchestrator 10.0 of the Summer
Arista's SA 0183 discloses CVE-2026-93952, an actively exploited CVSS 10.0 flaw in on-prem VeloCloud Orchestrator that only bites when Edges authenticate with certificates. Fixes exist for 5.2 and 6.4, not yet 6.1 or 7.0, and July's patched builds are still exposed.
-
Proving the Path Part 1: The Chain, and the Fault We're Chasing
A companion series to Day in the Life of a Packet, framed around diagnosis rather than architecture: one Teams call that stayed choppy long after the dashboards said everything had recovered, and the nine-stage chain I used to prove where the packet actually was.
-
Proving the Path Part 2: Ingress and Session
Before touching SD-WAN or routing, the session table tells you whether the flow you're chasing predates the event you're investigating. For the choppy Teams call, that one field settles more than the dashboard did.
-
Proving the Path Part 3: Policy Route and Routing
The pinned session predates the fault. Before blaming SD-WAN or routing for what's happening now, I need to know what a brand-new flow to the same destination would actually do today, and that's a different question from what the config says on paper.
-
Proving the Path Part 4: SD-WAN Member, SLA, and Rule Selection
The health-check history shows a breach, a failover, and a recovery, all working exactly as designed. Which raises the real question: if SD-WAN did its job correctly, why did the call stay broken?
-
Proving the Path Part 5: Policy/NAT and IPsec
The tunnel the pinned session is using never went down. The policy it matched hasn't changed. Both of those facts are true, and neither of them means the session's path was healthy the whole time it mattered.
-
Proving the Path Part 6: Egress, NPU Offload, and the Verdict
Every stage checked out clean on its own terms. The fix isn't clearing everything and hoping, it's one targeted action once the evidence points at a single cause. Closing the series with the full false-conclusions list and the discipline behind it.
-
Arista VeloCloud Edge HA Part 1: How Failover Actually Works, and CVE-2026-86106
On 9 September 2026 Arista disclosed four VeloCloud Edge and Gateway CVEs in one batch. This one, CVE-2026-86106, lives entirely inside the HA peer channel between two Edges, so Part 1 goes deep on how that channel actually works before explaining the bug in it.
-
Arista VeloCloud Edge HA Part 2: CVE-2026-86107, CVE-2026-86108, CVE-2026-86109, and the Fix
The other three VeloCloud Edge and Gateway CVEs from Arista's 9 September 2026 batch: a VCMP tunnel crash, an OS command injection in the management workflow, and a signature-validation gap in the update mechanism. All three share their fixed releases with Part 1's HA bypass.
-
One CSV Upload From Root: Inside CVE-2026-20245 on Cisco Catalyst SD-WAN Manager
A rogue peering connection, a password changed and quietly changed back, then one crafted CSV file that turned an admin session into root. Mandiant's writeup of CVE-2026-20245 is the missing middle chapter between this site's UAT-8616 post and August's hardening release.
-
SDWSCS Part 13: Monitoring with vManage & vAnalytics
The SDWSCS finale — module 13: operating everything the series deployed. vManage's security and Cloud OnRamp dashboards, the UTD and tunnel health signals worth alerting on, vAnalytics/Cisco SDWAN Analytics for trends and forecasting, and a day-2 runbook.
-
Declare Yourself Trusted: Inside UAT-8616's Three-Year Run Against Cisco Catalyst SD-WAN
Two maximum-severity Cisco Catalyst SD-WAN authentication bypasses, one threat actor, three years of quiet control-plane access. What CVE-2026-20182 and CVE-2026-20127 actually broke, how UAT-8616 used it, and what the fix demands beyond patching.
-
Marking Its Own Homework: Inside Cisco's August 2026 Catalyst SD-WAN Hardening Release
Three months after UAT-8616 forced Cisco's hand on SD-WAN, a different kind of disclosure: an internal security review, five CWE-grouped CVEs up to CVSS 9.9, and an admission that some of the bugs were found by AI models, not people.
-
SDWSCS Part 12: Cloud Interconnect & OnRamp for Colocation
Modules 11–12 of SDWSCS: software-defined cloud interconnect with Megaport and Equinix — virtual routers and private cross-connects provisioned from vManage — and Cloud OnRamp for Colocation: CSP clusters, NFVIS, and vManage-orchestrated VNF service chains.
-
SDWSCS Part 11: Cloud OnRamp Multicloud — AWS, Azure & GCP
Module 10 of SDWSCS: extending the fabric into public cloud with Cloud OnRamp for Multicloud — cloud gateways built from Catalyst 8000Vs, AWS Transit Gateway and Cloud WAN, Azure vWAN, GCP NCC, and the tag-based intent mapping that connects VPCs to service VPNs.
-
SDWSCS Part 10: Cloud OnRamp for SaaS
Module 9 of SDWSCS: Cloud OnRamp for SaaS in deployment detail — vQoE probing and scoring, DIA vs gateway vs client access exits, the Microsoft 365 telemetry integration, Webex/Office/custom app lists, and verifying the path decisions it makes.
-
SDWSCS Part 9: ThousandEyes — Monitoring Cloud Services
Module 8 of SDWSCS: deploying ThousandEyes enterprise agents in app hosting on Catalyst edges, test types and what each proves, the vManage integration, and building Microsoft 365 monitoring that turns 'Teams is slow' into an actionable path diagnosis.
-
SDWSCS Part 8: CASB, DLP & Securing Microsoft 365
Module 7 of SDWSCS: the CASB layer riding on Umbrella SIG — shadow IT discovery, app controls, tenant restrictions for Microsoft 365, data loss prevention, and remote browser isolation. What each control needs from the SDWAN side to work.
-
Route Leaking Between VRFs on FortiGate: What Happens When You Actually Build It
I set out to build the BGP leak-target VRF route-leaking mechanism from my own earlier post, on a real FortiGate 70G. It hit three undocumented platform quirks in a row. The real answer turned out to be a static route over a VDOM-link — no BGP required.
-
SDWSCS Part 7: Umbrella SIG — Deployment & DNS Policies
Module 6 of SDWSCS: Umbrella SIG architecture and deployment — the automatic tunnel workflow from vManage, active/active vs active/backup designs, steering traffic into the SIG, and DNS security policies as the first (and cheapest) enforcement layer.
-
SDWSCS Part 6: SASE — Architecture & Use Cases
Module 5 of SDWSCS: what SASE actually is once the marketing is stripped away — the SSE service stack, how Cisco assembles it from Catalyst SDWAN, Umbrella, Duo and ThousandEyes, and the use cases where cloud-delivered enforcement beats on-box or chained designs.
-
SDWSCS Part 5: Secure DIA & Service Chaining
Module 4 of SDWSCS: assembling the embedded stack into a secure Direct Internet Access design, then service chaining — OMP service routes, control and data policy steering, and the dedicated-security patterns for traffic that must transit a real firewall.
-
SDWSCS Part 4: Content Filtering — URL Filtering & TLS/SSL Decryption
Module 3 of SDWSCS: URL filtering with categories and web reputation, block pages, and the TLS/SSL decryption proxy — CA design choices, the decrypt policy, undecryptable traffic handling, and why decryption is the feature that needs a change-management plan.
-
SDWSCS Part 3: On-Premises Threat Prevention — Firewall, IPS & AMP
Module 2 of SDWSCS: deploying the application-aware enterprise firewall, Snort-based IPS with its three signature sets, and AMP file reputation with Threat Grid sandboxing — plus fail-open vs fail-close and the verification commands for each.
-
SDWSCS Part 2: The SDWAN Security Model & Unified Security Policy
Module 1 of the SDWSCS syllabus: why DIA changed the threat model, the four security deployment patterns, what actually runs on a Catalyst edge (zone-based firewall vs the UTD container), and the unified security policy framework that ties it together.
-
SDWSCS Part 1: Course Overview & Study Roadmap
Kicking off a thirteen-part series on Cisco's SDWSCS syllabus — SDWAN security and cloud solutions. Part 1 explains what the course covers, how it extends ENSDWI, maps all thirteen modules and eleven labs to this series, and sets out a realistic study plan.
-
ENSDWI Part 12: Management, Operations, and Exam Day
Blueprint domain 6.0 — vManage AAA, monitoring and alarms, REST API monitoring, and software image management — then a revision strategy for the whole blueprint and what to expect on exam day. Series finale.
-
Contrail SD-WAN Deep Dive Part 1: Contrail Service Orchestration and the SRX/NFX CPE Model
Before Session Smart Routing, Juniper's enterprise SD-WAN ran on Contrail Service Orchestration — an SDN/NFV control plane repurposed for site connectivity, provisioning SRX firewalls and NFX universal CPE. This post walks the architecture as it actually shipped.
-
Contrail SD-WAN Deep Dive Part 2: E-Hub, P-Hub, and the Anatomy of a Hub-and-Spoke Overlay
Contrail's hub-and-spoke model ran on two hub roles — the customer-owned enterprise hub and the multi-tenant provider hub. Routing, VRF segmentation, and traffic-flow mechanics of both, and why the model got heavy at scale.
-
Contrail SD-WAN Deep Dive Part 3: Why Contrail Lost the Enterprise, and the Pivot to Session Smart
Closing the Contrail arc: a straight comparison against Viptela, VeloCloud, and CloudGenix, what CSO's architecture cost it competitively, and the specific rationale Juniper gave for retiring it in favour of Session Smart Routing.
-
From Contrail to Session Smart: A History of Juniper's SD-WAN Journey
Juniper has shipped two structurally different SD-WAN products under one brand: Contrail Service Orchestration, born out of an SDN/NFV controller, and Session Smart Routing, born out of a 2014 session-border-controller team's bet that tunnels were the wrong abstraction. This is how one became the other.
-
Juniper Session Smart SD-WAN Deep Dive Part 1: 128 Technology and the Tunnel-Free Premise
Session Smart Routing didn't start as a Juniper project — it started as a session border controller team's bet that SD-WAN's entire tunnel-based premise was solving the wrong problem. This post covers 128 Technology's origin and the architectural break it made.
-
Juniper Session Smart SD-WAN Deep Dive Part 2: Secure Vector Routing — Tenants, Services, and Session Metadata
How Secure Vector Routing actually forwards a session: the tenant/service data model, the metadata the ingress router stamps on the first packet, and why that's enough to route symmetrically without a tunnel.
-
Juniper Session Smart SD-WAN Deep Dive Part 3: Session Smart Conductor, Mist, and the Two Control Planes
Session Smart Routers can be managed by an on-premises Conductor or by the Mist cloud. What each control plane actually does, how the multitenant policy model gets distributed, and how to choose between them.
-
Juniper Session Smart SD-WAN Deep Dive Part 4: WAN Assurance, Marvis, and AI-Native Operations
What "AI-native WAN" concretely means on the Mist side of Juniper's SD-WAN stack: WAN Assurance's telemetry model, Marvis's self-driving remediation, and where the AI layer actually earns its keep versus where it's a dashboard feature.
-
Juniper Session Smart SD-WAN Deep Dive Part 5: Zero Trust by Default — the SSR Security Model
Because SVR classifies every session against a tenant and a service before forwarding a single packet, deny-by-default segmentation is a property of the routing engine itself. What that buys, what it doesn't, and how SRX fills the gap.
-
Juniper Session Smart SD-WAN Deep Dive Part 6: Cloud Onramp and Multicloud
Extending Secure Vector Routing into AWS and Azure: virtual SSR instances, cloud regions treated as ordinary sites in the tenant/service model, and how that compares to the tunnel-based cloud onramp patterns already covered on this site.
-
Juniper Session Smart SD-WAN Deep Dive Part 7: The MPLS Cutover Playbook
A practical staged cutover from legacy MPLS to Session Smart Routing — overlay-first coexistence, tenant/service modelling before a single circuit changes, and why SVR's tunnel-free design changes the risk profile of the cutover weekend itself.
-
Juniper Session Smart SD-WAN Deep Dive Part 8: Failure Modes, Scale Limits, and a Five-Way Vendor Comparison
Series finale. What happens to the data plane when Conductor or Mist goes dark, where SSR's scale story sits, and Session Smart Routing lined up against Fortinet, Cisco/Viptela, Arista/VeloCloud, and Palo Alto/Prisma — five philosophies, one underlying question.
-
Palo Alto Prisma SDWAN Deep Dive Part 1: From CloudGenix to App-Defined SASE
Starting an eight-part deep dive into Palo Alto Prisma SDWAN — the fourth control-plane philosophy this site has covered, after Fortinet, Arista/VeloCloud, and Cisco/Viptela. Part 1 covers the CloudGenix lineage, the 2020 acquisition, and what 'app-defined' actually means before we touch a single ION device.
-
Palo Alto Prisma SDWAN Deep Dive Part 2: ION, Strata Cloud Manager, and the Planes
The ION device line from 1000 to 9000, physical and virtual, and Strata Cloud Manager — the cloud-only console that absorbed the old CloudGenix Portal. Part 2 maps Prisma SDWAN onto the planes framework this site has used for Fortinet, Arista, and Cisco, and explains why there's no controller box to rack.
-
Palo Alto Prisma SDWAN Deep Dive Part 3: AppFabric and Path Selection Without a Routing Protocol
How AppFabric actually builds its full-mesh Secure Fabric Links, why circuit categories and labels stand in for TLOCs, and how per-flow path selection works when there's no routing protocol advertising a route in the first place. The mechanics behind Part 1's philosophical claim.
-
Palo Alto Prisma SDWAN Deep Dive Part 4: The Data Plane — App-ID, Adaptive QoS, and Control vs Analytics Mode
What App-ID actually classifies at the packet level, how Adaptive QoS measures real circuit capacity instead of trusting a configured bandwidth number, and the practical operational differences between an ION in Control mode and one still in Analytics.
-
Palo Alto Prisma SDWAN Deep Dive Part 5: Security — Prisma Access, Clean Pipe, and CloudBlades
What the ION's local Zone-Based Firewall actually covers, where the line to Prisma Access gets drawn, and how CloudBlades chains in Zscaler, Netskope, and AWS Transit Gateway without touching the branch device. This is the post where 'app-defined SASE' from Part 1 stops being a tagline.
-
Palo Alto Prisma SDWAN Deep Dive Part 6: Cloud Onramp and Multicloud
Prisma SDWAN treats a VPC or VNet as just another data centre: a pair of virtual IONs joins the fabric, and a CloudBlade automates the cloud-native plumbing around them — Transit VNETs and vWAN Hub association on Azure, Transit Gateway attachment on AWS. How that compares to Cisco's and Fortinet's cloud onramp designs already on this site.
-
Palo Alto Prisma SDWAN Deep Dive Part 7: The MPLS Cutover Playbook
A per-site MPLS-to-Prisma-SDWAN migration playbook built around the Analytics-to-Control progression from Part 3: zero-touch bootstrap, a genuinely evidence-based baseline before anything changes behaviour, a bounded rollback window per site, and a decommission sequence that doesn't ask anyone to trust the fabric on day one.
-
Palo Alto Prisma SDWAN Deep Dive Part 8: Failure Modes, Scale Limits, and a Vendor Comparison Checklist
Series finale. What actually happens when Strata Cloud Manager goes dark, where Prisma SDWAN's scale limits sit, and an honest, direct comparison against Fortinet's collapsed model and Cisco's fully decoupled one — the fourth philosophy, lined up against the three already covered on this site.
-
ENSDWI Part 11: QoS and Application Quality of Experience
Blueprint 5.4 and 5.5: the WAN Edge QoS pipeline — classification, marking, policing, shaping, scheduling, queuing — plus per-tunnel and adaptive QoS, then App-QoE: TCP optimization, DRE, packet duplication, FEC, and AppNav.
-
ENSDWI Part 10: Security — Service Insertion, Embedded, and Cloud-Delivered
Blueprint 5.1–5.3: service insertion with OMP service routes, the embedded security stack — app-aware firewall, Snort IPS, URL filtering, AMP, SSL/TLS proxy, TrustSec — and cloud security integration with Umbrella DNS and SIG tunnels.
-
ENSDWI Part 9: Data Policies, Segmentation, App-Aware Routing, and DIA
Blueprint 4.2–4.5: centralized data policy at the edge, VPN segmentation and per-VPN topologies, application-aware routing with SLA classes and BFD measurements, and direct Internet access with NAT fallback.
-
ENSDWI Part 8: Control Policies
Blueprint 4.1: the centralized policy framework, how control policy is evaluated at vSmart, match/action anatomy, and the canonical topologies — hub-and-spoke, regional mesh, and TLOC preference steering — built entirely by filtering routing information.
-
ENSDWI Part 7: OMP, TLOCs, Routing Protocols, Multicast, and Config Groups
Blueprint 3.3–3.7: configuring OMP and TLOCs, service-side OSPF/BGP/EIGRP and VRRP with their loop-prevention markers, multicast over the overlay, and the configuration-group/feature-profile model that v1.2 added to the exam.
-
ENSDWI Part 6: WAN Edge Deployment — ZTP, Bootstrap, and TLOC Extension
Blueprint 3.1 and 3.2: onboarding edges with ZTP, PnP, and bootstrap; data-centre and regional-hub designs; circuit termination and TLOC extension; dynamic tunnels; and how the underlay and overlay exchange routes.
-
ENSDWI Part 5: Certificates, Device Lists, and Control-Plane Troubleshooting
Blueprint 2.3 and 2.4: the certificate trust model end to end — root CA options, controller CSRs, the WAN Edge authorized serial list — then the systematic control-connection troubleshooting flow behind most ENSDWI exhibit questions.
-
ENSDWI Part 4: Controller Deployment — Cloud, On-Prem, Scale, and Redundancy
Blueprint 2.1 and 2.2: Cisco-hosted vs on-premises controllers, hosting platform requirements, installing the vManage/vBond/vSmart trio, and the scalability and redundancy rules — clustering, affinity, and how many of each you actually need.
-
ENSDWI Part 3: Edge Platforms and Cloud OnRamp
Finishing blueprint domain 1.0: the cEdge and vEdge platform families and how to pick between them, then all four Cloud OnRamp variants — SaaS, IaaS, Colocation, and Multicloud/Interconnect — at the depth the exam actually tests.
-
ENSDWI Part 2: Architecture — Planes, Components, and Multi-Region Fabric
Blueprint domain 1.1: the four planes and their components, OMP's three route types, TLOCs, IPsec vs GRE encapsulation, BFD's dual role, and Multi-Region Fabric — the v1.2 addition that older study material misses entirely.
-
ENSDWI Part 1: Exam Syllabus & Study Roadmap
Kicking off a twelve-part study series for the Cisco 300-415 ENSDWI exam. Part 1 breaks down the v1.2 blueprint domain by domain, maps every topic to a part of this series, and covers exam logistics, lab options, and how to study for a 90-minute concentration exam.
-
Cisco Catalyst SDWAN Deep Dive Part 1: Components, Controllers, and the Four Planes
Starting a ten-part deep dive into Cisco Catalyst SDWAN. Part 1 covers the Viptela lineage, the four controller planes (vManage, vSmart, vBond, WAN Edge), the certificate trust model, and the control-connection bring-up sequence.
-
Cisco Catalyst SDWAN Deep Dive Part 10: Failure Modes, Scale Limits, and a Vendor Comparison
Part 10, the finale: what actually breaks (vBond, vSmart, vManage) and what doesn't when it does, vManage's documented scale ceiling, and a head-to-head of OMP/TLOC against Fortinet ADVPN, Arista DMPO, and VeloCloud.
-
Cisco Catalyst SDWAN Deep Dive Part 2: OMP, the Overlay Management Protocol
Part 2 of the Cisco Catalyst SDWAN series: what OMP actually carries between WAN Edge and vSmart — OMP routes, TLOC routes, and service routes — how best-path selection and multipath differ from BGP, and why the overlay/underlay split is the whole point.
-
Cisco Catalyst SDWAN Deep Dive Part 3: TLOCs, Color, and Centralized Policy
Part 3 of the Cisco Catalyst SDWAN series: what TLOC color actually constrains, how restrict/no-restrict shapes which tunnels can form, and how centralized control policy on vSmart turns that into enforced topology — full mesh, hub-and-spoke, or anything between.
-
Cisco Catalyst SDWAN Deep Dive Part 4: BFD, App-Route SLAs, and cEdge Forwarding
Part 4: how BFD over every data tunnel drives both fast failure detection and continuous SLA measurement, how app-route policy steers on that data, and where cEdge's IOS-XE forwarding pipeline diverges from legacy vEdge.
-
Cisco Catalyst SDWAN Deep Dive Part 5: Topology Walkthroughs — Dual Transport, DIA, and TLOC Extension
Part 5: VPN segmentation (transport vs. service VPNs), a worked dual-MPLS-plus-Internet branch design, direct internet access for local breakout, and TLOC extension for sites with no WAN circuit of their own.
-
Cisco Catalyst SDWAN Deep Dive Part 6: Cloud OnRamp for SaaS and IaaS
Part 6: how Cloud OnRamp for SaaS continuously measures per-app, per-transport path quality to pick the best local breakout, and how Cloud OnRamp for IaaS extends the fabric directly into AWS and Azure as cloud-resident sites.
-
Cisco Catalyst SDWAN Deep Dive Part 7: SIG, Secure Firewall, and Edge Security
Part 7: how DIA traffic gets inspected without a hub backhaul — Cisco Secure Internet Gateway integration, the on-box UTD container on cEdge, and how this converges with the broader SASE shift other vendors are making too.
-
Cisco Catalyst SDWAN Deep Dive Part 8: Automation — vManage API, Terraform, and Ansible
Part 8: why vManage's API-first design means automating Catalyst SDWAN looks nothing like CLI-scraping individual boxes, and where Terraform's declarative model and Ansible's procedural model each fit.
-
Cisco Catalyst SDWAN Deep Dive Part 9: The MPLS-to-SDWAN Cutover Playbook
Part 9: a phased, coexistence-based migration sequence from legacy MPLS to Catalyst SDWAN — pilot sites first, hubs last, explicit rollback triggers, and why ripping MPLS out in one weekend is the wrong instinct.
-
SDWAN Control Plane Showdown: Three Philosophies for Solving the Same Problem
Fortinet collapses control onto the data-plane device. Arista/VeloCloud collocates it on a multi-tenant Gateway. Cisco/Viptela decouples it fully into vSmart and OMP. Three architectures covered on this site, lined up side by side, right before the Cisco series picks up the third one.
-
A Brief History of SDWAN Controllers: Viptela, VeloCloud, CloudGenix, and Why Cisco Runs Two SDWAN Stacks
Three startups solved SDWAN's control-plane problem within a year of each other. Two got bought by exactly the company you'd expect; one brand didn't survive. The acquisition history of Viptela, VeloCloud, and CloudGenix — and why Cisco still runs two unrelated SDWAN stacks today.
-
The Three Planes: Management, Control, and Data — and Why Every SDWAN Argument Comes Back to Them
A vendor-neutral primer on the management, control, and data planes — what each actually does, why management-vs-control is the distinction everyone blurs, and a three-question test you can run against any SDWAN platform regardless of vendor.
-
FortiAnalyzer and FortiMonitor for SDWAN SLA Observability: Watching the Fabric
The operational bookend to the SDWAN design series — how FortiAnalyzer and FortiMonitor turn the performance-SLA assumptions baked into your hub placement and resilience design into something you can actually alert on, trend, and defend with data months later.
-
Migrating from MPLS to SDWAN Without a Bad Weekend: The Cutover Playbook
A phased, dual-running migration plan for moving a branch off MPLS and onto SDWAN — route-map-based preference during transition, what to validate before each cutover step, and the rollback triggers that keep a bad change from becoming an outage.
-
IPsec Deep Dive Part 1: ESP, AH, and How IKE Phase 1 Actually Brings a Tunnel Up
IPsec underpins every Fortinet SDWAN overlay this blog has built, and it's never had its own deep dive. Part 1 fixes that: the SA model, ESP vs AH, tunnel vs transport, and a message-by-message walk through IKEv1 main mode, aggressive mode, and IKEv2.
-
IPsec Deep Dive Part 2: Phase 2, Child SAs, and the Anatomy of an ESP Packet
Phase 1 built a control channel and protected nothing. Part 2 covers the negotiation that actually moves data: quick mode and child SAs, traffic selectors, PFS, rekeying, and anti-replay — then dissects an ESP packet field by field, down to the MTU math.
-
IPsec Deep Dive Part 3: NAT vs IPsec — NAT-T, Port Forwarding, and the Fortinet SDWAN Reality
NAT breaks IPsec three distinct ways — AH's ICV, ESP's missing ports, and IKE's rewritten source port. Part 3 covers each break, how NAT-D detects it and NAT-T's UDP 4500 encapsulation repairs it, when port forwarding is still required, and what it all means for SDWAN spokes behind CPE NAT.
-
Traffic Shaping and QoS Internals on Fortinet SDWAN: Policed, Not Just Routed
Application-aware routing decides which path a flow takes. Shaping decides what happens to it once it's there — shaping profiles, per-IP and per-policy shapers, queue assignment, and how it all interacts with NP7 hardware offload.
-
Zero Trust Meets the Overlay: Converging ZTNA and SDWAN on Fortinet
The capstone to the SDWAN series: how Fortinet's ZTNA tags and access proxy let you fold per-application, identity-aware access control directly into the SDWAN fabric — built on the RADIUS/TACACS AAA backend and the PKI you already stood up for IPsec.
-
Beyond PSK: PKI for Fortinet SDWAN IPsec, Part 1 — The Architecture Decision
FortiManager-as-CA vs. a dedicated external CA for certificate-based IPsec on Fortinet SDWAN: the honest trade-offs, SCEP vs EST, CRL vs OCSP, certificate lifetime philosophy, and why "who is your CA" is the real question hiding inside "switch to certificates."
-
Beyond PSK: PKI for Fortinet SDWAN IPsec, Part 2 — Standing Up the PKI
Standing up a real PKI for Fortinet SDWAN IPsec: offline root, online issuing CA, a certificate role scoped to IPsec end entities, an EST front-end, CRL/OCSP placed where the chicken-and-egg overlay problem can't reach it, and FortiManager's much smaller supporting role.
-
Beyond PSK: PKI for Fortinet SDWAN IPsec, Part 3 — Enrollment, Automation, and the Cutover
Closing the series: solving EST's bootstrap-credential problem on purpose, monitoring certificate renewal at scale before it becomes an outage, and executing the PSK-to-certificate cutover — explicitly diffed against the FMG-as-CA migration path.
-
Cloud On-Ramp Part 1: The Architecture Decision and AWS Transit Gateway
Hub Placement Part 3 said the hub goes where the VPC is. This post answers the question that raises immediately: how does it actually get there? BGP-over-IPsec to AWS Transit Gateway, ASN selection, and mapping on-prem VRFs onto TGW route tables.
-
Cloud On-Ramp Part 2: Azure Virtual WAN and a Dual-Cloud Resilience Design
Azure Virtual WAN looks like AWS Transit Gateway from a distance — a managed hub that attachments plug into. Up close, the BGP mechanics, the route-propagation model, and the failure modes all differ in ways that decide whether a dual-cloud on-ramp actually survives a bad day.
-
Local Internet Breakout in Practice: SDWAN Zones, Rules, and a Multi-VRF Guest Wi-Fi Walkthrough
How SDWAN zones, members, and performance-SLA rules actually decide where a session breaks out — and a full walkthrough of giving Guest Wi-Fi its own VRF, its own zone, and a local internet path that never touches the corporate tunnel.
-
Fortinet SDWAN Hub Placement Part 1: The Traditional Model — Hubs in the DC
Why hubs traditionally sit in the DC, the job they actually do there, how they protect FMG/FAZ, and how BGP on loopback ties it together. Part 1 of a series that goes on to challenge the assumption that the hub belongs in the DC at all.
-
Fortinet SDWAN Hub Placement Part 2: The MSSP Shift — When the Hub Becomes Customer-Centric
What changes when one FMG/FAZ pair manages many customers through ADOMs: the hub stops being "the DC's hub" and becomes a per-customer design decision, with its own routing domain, AS plan, and placement logic.
-
Fortinet SDWAN Hub Placement Part 3: Cloud, SASE, and the Death of "The DC" as the Default
Closing out the hub-placement series: what changes about hub design when the destination is Azure, AWS, or GCP rather than a DC, and what changes again for customers migrating from a DC-centric WAN to a SASE-centric one.
-
From DSCP to Deep Packet Inspection: Why SDWAN Application-Aware Routing Killed Traditional QoS
A deep technical comparison of legacy QoS (DSCP/CoS, static priority queues, box-by-box CLI) against SDWAN Application-Aware Routing — plus a vendor-by-vendor breakdown of how Cisco Catalyst SDWAN, Fortinet, Juniper Mist (128T), and VeloCloud actually identify and steer application traffic.
-
Fortinet SDWAN Jinja Orchestrator — Part 1: The Two Template Engines
Part 1 of three. FortiManager hosts two distinct template engines — classic CLI templates and Jinja CLI templates — and they aren't interchangeable. Thesis: Jinja for shape-varying network plumbing, CLI templates for shape-fixed system config, and a real deployment uses both.
-
Fortinet SDWAN Jinja Orchestrator — Part 2: Anatomy and Patterns
Part 2 of three. We open Fortinet's sdwan-advpn-reference repo and read it end-to-end: the dynamic-bgp-on-lo directory, the four reference Project Templates, the inventory contract that feeds them, and the three Jinja patterns the templates lean on heaviest — loops, ipaddr derivation, and imports.
-
Fortinet SDWAN Jinja Orchestrator — Part 3: PSK to Cert With FMG as CA
Part 3 of three. We take the single-hub PSK example from the reference repo and migrate it to certificate-based IPSec, with FortiManager as the CA. FMG CA setup, per-device enrolment, Project Template flag flip, what changes in the rendered config and what doesn't.
-
Arista (VMware) SDWAN Deep Dive — Part 1: Components, Gateways, and the Three Planes
First post in a five-part deep dive on Arista (VMware) SDWAN. We start with the components — Edges, Cloud Gateways, Partner Gateways, Orchestrator, Controller — and the three planes that bind them. Sets up a UK ISP scenario that the rest of the series will pick apart.
-
Arista (VMware) SDWAN Deep Dive — Part 2: Routing — Overlay, Underlay, BGP, and the Gateway as Route Reflector
Part 2 of five. How prefixes get into the overlay, how the Gateway redistributes them, the three Cloud VPN modes, BGP at the Edge and the Partner Gateway, and the route-selection logic that decides which underlay a flow ends up on.
-
Arista (VMware) SDWAN Deep Dive — Part 3: The Data Plane — VCMP, DMPO, and Per-Flow Steering
Part 3 of five. Wire-level look at VCMP encapsulation, the DMPO measurement loop, Business Policy and per-flow steering, and the on-path remediation (FEC, duplication, jitter buffer) that lets the overlay tolerate underlays that misbehave.
-
Arista (VMware) SDWAN Deep Dive — Part 4: Topology Walkthroughs — MPLS-only meets Internet-only Across Continents
Part 4 of five. The GlobalCo packet-flow walkthroughs — Newcastle to HQ, Bristol to HQ, Chicago to a UK Cloud Gateway (why it fails), and the headline: MPLS-only Chicago talking to Internet-only Shanghai via a Partner Gateway, hop by hop.
-
Arista (VMware) SDWAN Deep Dive — Part 5: Best Practice, Failure Modes, and a Design Checklist
Part 5 of five. Gateway design rules, Partner Gateway sizing, segmentation, security service insertion, MTU, the failure modes that catch teams the first time, and a one-page design checklist for an Arista (VMware) SDWAN rollout.
-
SDWAN Resilience Part 1: Design and Assumptions
A multi-part deep dive into building a resilient Fortinet SDWAN on a real, slightly unfashionable topology — HA FortiManager, dual hubs in active/standby, no DCI, and an independent DCE. Part 1 lays out the topology, the AS plan, and challenges the design choices up front.
-
SDWAN Resilience Part 2: BGP on Loopback
Why we peer BGP on loopbacks instead of tunnel-interface IPs, the FortiOS dynamic-IPsec config that makes it work, the spoke-side reciprocal config, and why hub-to-hub iBGP is the wrong answer in a no-DCI active/standby topology.
-
SDWAN Resilience Part 3: DC to DCE Routing — Static, OSPF, and BGP
The hub FortiGate has to glue the spoke overlay to the data-centre environment that hosts the services. Static, OSPF, and eBGP each work — but only two of them fail correctly when the DCE peering goes down on one DC and not the other.
-
SDWAN Resilience Part 4: BFD and Convergence Tuning
Default BGP timers detect failure in three minutes. That's unacceptable for active/standby SDWAN. This post is the timer-math: DPD vs BFD on tunnels, BFD-for-BGP, holdtime ratios, the Graceful Restart trade-off, and what convergence numbers each combination actually delivers.
-
SDWAN Resilience Part 5: Performance SLAs and Service Steering
BGP and BFD catch every failure that takes a tunnel or session with it. They don't catch the failure where everything looks healthy at the network layer but the application is gone. That's the gap SDWAN Performance SLAs fill — and the place where careful health-check design earns its keep.
-
SDWAN Resilience Part 6: Building It Right — Full DCI and Dual-Active ADVPN
The first five parts defended a topology with real constraints. This final post is the version without those constraints — Fortinet's reference design: full DCI, dual-active ADVPN, iBGP between hubs, symmetric routing, ECMP across both paths. The full shebang.
-
Designing an Arista SDWAN Spoke with Enhanced HA, Dual DIA, and OSPF
Building a resilient Arista (formerly VeloCloud) SDWAN spoke: two Edges in Enhanced HA, two DIA circuits wired the optimal way, a multi-VLAN LAN, OSPF for route exchange, and the caveats that bite in practice.
-
A Day in the Life of a Packet on a 50G FortiGate, Part 3: Routing, Policy Routes, and SDWAN Service Rules
The packet has a session entry and now needs to know where to go. FortiOS resolves that in a strict order: policy routes, then SDWAN service rules, then the FIB. Each layer has its own logic, its own match criteria, and its own diagnostic surface.
-
Configuring RADIUS Admin Auth on FortiGate SDWAN: RBAC and Three User Profiles (Part 2 of 2)
Part 2 of 2 on RADIUS for FortiGate SDWAN. Walks through the FortiOS config end-to-end — RADIUS server entry, group-to-profile mapping via VSA, three worked RBAC examples (senior engineer, NOC operator, compliance auditor), and the verification commands you'll need.
-
NSE5 Part 6: Device-Level Configuration and Templates
Part 6 of the NSE5 study series — covers the FortiManager template engine: provisioning templates, CLI templates, SDWAN, IPsec, and certificate templates, and how they compose into a single per-device install.
-
RADIUS vs TACACS+ on FortiGate SDWAN: Choosing the Right AAA Backend (Part 1 of 2)
Part 1 of 2 on RADIUS for FortiGate SDWAN. Covers the protocol differences vs TACACS+, the RADIUS server options worth knowing (NPS, FortiAuthenticator, FreeRADIUS, ISE, Okta, Duo, Entra), and when each protocol is the right call for FortiOS.
-
FortiOS 7.6.6 SDWAN: VRF1 Transport and Loopback Design
A refined VRF reference design for FortiOS 7.6.6 — transport in VRF 1, separate transport and management loopbacks, complete management-plane pinning, and NPU-VLINK guidance for inter-VRF acceleration.
-
MP-BGP and VRFs on FortiGate SDWAN
A practical reference design using MP-BGP (VPNv4) and VRFs on FortiOS to keep management (VRF20), customer SDWAN (VRF30), and Guest Wi-Fi DIA (VRF99) isolated end-to-end. Includes config, traffic flows, and the gotchas that bite people in production.
-
NSE4 Part 9: Routing & SDWAN
Part 9 of the NSE4 study series — static and policy routing, distance vs priority, RPF, OSPF and BGP basics, and how SDWAN turns a pile of WAN links into a single steered zone with performance SLAs.
-
Route Leaking Between VRFs on FortiGate: Why It's Trickier Than You Think
VRF route leaking is a daily reality in any multi-tenant or shared-services network design. On FortiGate it's harder to find — and harder to get right — than the equivalent on Cisco or Juniper. Here's how to do it, why it's easy to miss, and the practical pitfalls.