Harmony SASE Technical View

[WiliRGasparetto]

Architecture, adoption phases, and failure points (Control Plane vs Data Plane)

Thesis

Harmony SASE is not “a VPN in the cloud.” It is a SASE platform with a global PoP/Region mesh acting as policy enforcement points for two primary planes:

• Internet Access (SWG) for web/SaaS

• Private Access (ZTNA) for private applications (on-prem / cloud)

The operational differentiator is a centralized governance and policy model, combined with site-to-cloud connectivity (tunnels) and routed interconnectivity (when required).

1) Mental model: Control Plane vs Data Plane

Control Plane (management/policy)

• Policies, objects, users, and rules are managed in the Infinity Portal (Harmony SASE Admin Portal).

• Examples:

  • Internet Access Policy (SWG)

  • Data Loss Prevention (DLP)

  • Private Access rules

  • Directory integrations (AD / Azure AD / SCIM) and automation APIs

Data Plane (traffic)

• Remote users, branches, and workloads establish connectivity to the PoP/Region mesh.

• Traffic is routed to:

  • Internet Access (SWG): secure access to web/SaaS

  • Private Access (ZTNA): secure access to private applications (on-prem or cloud)

Traffic flows (text diagram)

• Remote Users (Agent / on-device) → Harmony SASE PoP → Web/SaaS

• Remote Users / BYOD (Agentless) → Harmony SASE PoP → Private Apps (DC/Cloud)

• Offices / DC / Cloud workloads (IPsec/WireGuard/OpenVPN) → Harmony SASE PoP → Interconnectivity / routing (when applicable)

Critical note: “Full mesh” refers to any-to-any connectivity via the SASE backbone, but site-to-site interconnectivity requires explicit routing — it is not automatic.

2) Architecture: components and responsibilities

2.1 PoPs/Regions and Cloud Gateways

• Harmony SASE operates through globally distributed PoPs.

• The PoP is the policy enforcement point for Internet Access and Private Access.

• Region selection directly impacts latency, user experience, and resiliency.

2.2 Network connectivity (site-to-cloud tunnels)

Three tunnel types are supported to connect sites/resources into the mesh:

• IPsec Site-to-Site VPN

• WireGuard Connector

• OpenVPN

Interconnectivity (site ↔ site)

• To interconnect sites through the SASE mesh, you must configure routes in the Route Table, including:

  • each site’s subnets, and

  • the mesh subnet (e.g., 10.255.0.0/16)

• Operational caution:

  • In policy-based environments, interconnectivity may require multiple Phase II SAs and not all routers support this model; route-based IPsec is recommended for interconnectivity use cases.

WireGuard Connector (common pitfall)

• By default, the WireGuard Connector is installed in accessor mode, which does not allow resource-to-resource traffic without specific configuration/re-installation.
  This is a classic root cause of “tunnel is up, but no lateral traffic.”

2.3 Internet Access (SWG) + Threat Prevention

• The typical design is to start with Internet Access Policy and, when needed, define bypass rules for critical applications—especially apps with certificate pinning.

• Important: enforcement of Threat Prevention / DLP / inspection can impact performance and compatibility; rollout should be controlled, with baselines and monitoring.

2.4 Private Access (ZTNA) + Agentless

• Secure access to private applications (e.g., SSH, RDP, Web, Database) via agent or agentless portal.

• Enables onboarding for BYOD and third parties without requiring agent deployment/management in specific scenarios.

•  

2.5 Data Loss Prevention (DLP)

• Integrated DLP module with policies scoped by members/groups and management of Data Types / Data Groups.

• Integration with Microsoft Purview Sensitivity Labels for data governance.

•  

2.6 Agent governance (anti-tampering / uninstall control)

• Ability to protect uninstallation with a code (“Uninstall is Protected”), reducing control evasion and posture/enforcement drift.

•  

3) Threat/Failure scenarios (real-world failures)

1. Tunnel UP, no traffic (site ↔ site)

   • Almost always missing explicit routes in the Route Table for remote subnets + the mesh subnet.

2. WireGuard Connector with no lateral traffic

   • Default accessor mode blocks resource-to-resource unless reconfigured.

3. Application breaks after inspection (SSL / SWG)

   • Most commonly certificate pinning → requires a bypass rule.

4. Data exfiltration via SaaS/AI

   • Without DLP or correct group/risk scoping, sensitive data escapes via uploads/web apps.

5. Operations without governance

   • Lack of logging/telemetry and metrics turns troubleshooting into trial-and-error and MTTR spikes.

   •  

4) Architecture options (trade-offs)

Option A — Traditional VPN + NGFW/Proxy

Pros

• Fast initial deployment

• Operational familiarity

Cons

• Expanded attack surface (network exposure)

• Low per-application granularity

• Fragmented governance and observability

• Harder to enforce identity-driven Zero Trust

•  

Option B — Point ZTNA + separate SWG

Pros

• Reduces exposure with application-level access

• Good incremental evolution path

Cons

• Multiple consoles and policy stacks

• More complex integrations/troubleshooting

• Hard to unify logs and governance

Option C — Harmony SASE (Internet Access + Private Access + Tunnels + Interconnectivity)

Pros

• Centralized policy/governance model

• PoPs/Regions as global enforcement points

• ZTNA/agentless + DLP + Threat Prevention under unified governance

• Support for IPsec/WireGuard/OpenVPN

Cons

• Interconnectivity requires explicit routing design (route-based recommended)

• Controlled rollout required (bypass/pinning/tuning)

• Subnet planning needed to avoid overlaps

[the_rock]

Another great write up!

[israelfds95]

Very good 💯