Security, Segmentation, and SASE Integration

1. Built-in Security

A defining feature of EdgeConnect (formerly Silver Peak Unity EdgeConnect) is that security is not a separate appliance bolted onto the WAN edge — it ships inside every appliance. Each device includes an integrated stateful, zone-based firewall and a segment-based fabric that together provide both macro-segmentation (VRF-like isolation across the WAN) and micro-segmentation (fine-grained zone-to-zone policy).

Zone-based stateful firewall

A stateful firewall tracks the state of each session rather than inspecting packets in isolation. It follows the TCP handshake (SYN, SYN-ACK, ACK), watches TCP flags, and maintains pseudo-sessions for connectionless UDP flows. Because the firewall knows a session is established, return traffic is permitted automatically — you write policy only in the initiating direction, and the reply path opens itself.

EdgeConnect's firewall is zone-based rather than merely interface-based. A zone groups interfaces or VLANs that share a common trust level (such as Corp_LAN, Guest, IoT, WAN, DC, or Internet), then writes policy between zones. Every interface is assigned to a zone (its security anchor) and a segment (its routing context). Rules can match source/destination IP, subnet, VLAN, port, protocol (L3/L4), and recognized applications (L7). Available actions are allow, deny, or send to service — the last redirecting traffic to an external NGFW or cloud SWG.

The usual default posture is deny by default, allow by exception between zones. The biggest operational benefit is that policies become topology-independent: a single Guest → Internet rule applies identically across every branch, regardless of local IP addressing.

Routing segmentation as micro-segmentation

The coarse layer is the segment, which behaves like a VRF instance: its own routing table, its own overlays, and its own policy context. Typical segments are Corp, Guest, IoT, PCI, OT, and Voice. Traffic in one segment does not reach another by default — the macro boundary that guarantees "Guest can never reach Corp or PCI across the WAN."

The fine layer is the zone, which lives inside exactly one segment. Micro-segmentation divides the network into small, individually-policed compartments via zone-to-zone rules so a breach cannot spread laterally:

When two segments must talk, you keep them separate and route the controlled traffic through an explicit inter-segment gateway with a narrow rule. A typical branch interface map:

Identity and role-based segmentation

EdgeConnect extends segmentation with identity by aligning on a shared IdP — Azure AD, Okta, or Aruba ClearPass — so policy can be written in terms of users and roles rather than IP addresses. A "Contractor" can land in the Guest segment while a "Finance" user lands in a PCI-adjacent zone. Device posture (from MDM/EDR) feeds the same inputs, so an out-of-compliance laptop receives a more restrictive role regardless of where it plugs in.

It is worth being honest about scope. The built-in firewall is excellent for L3–L7 policy, segmentation, and breakout control. For deep threat prevention — full IDS/IPS, advanced DLP, sandboxing — EdgeConnect hands traffic off to a dedicated NGFW or cloud security service.

2. Service Chaining and Breakout

The old WAN security model hauled every internet-bound packet back across the WAN to a data-center firewall stack — adding latency, consuming expensive transport, and bottlenecking at the DC. EdgeConnect breaks that pattern with local internet breakout secured by service chaining: the appliance sends selected traffic directly from the branch over an encrypted tunnel to a provider's nearest POP, which inspects it and forwards it on.

Cloud security service chaining

Service chaining steers a flow through one or more security services on its way to its destination. Instead of User → LAN → EdgeConnect → Internet, the path becomes User → LAN → EdgeConnect → IPsec tunnel → cloud SWG → Internet. The cloud service — a Zscaler, Netskope, or Check Point POP — performs URL filtering, threat inspection, CASB, and DLP that the branch appliance does not.

The decision of which traffic to chain is driven by First-Packet iQ: EdgeConnect classifies an application on the very first packet using destination IP/port, domain or TLS SNI, URL category, behavioral heuristics, and a continuously updated database. The first SYN is enough for the policy engine to pick a path and commit the entire flow.

• General, unknown, or risky web → Zscaler SWG for inspection.
• Social media, webmail, file sharing → Netskope for CASB and DLP.
• Internal / private applications → SD-WAN overlay straight to the data center, bypassing the SWG.

Automated tunnels to third-party SSE

1. Define the cloud security service in Orchestrator — choose provider (Zscaler ZIA, Netskope, Check Point), set region/POP preferences, configure global IKE/IPsec settings.
2. API- or template-based automation — for native integrations, Orchestrator calls provider APIs to create VPN endpoints, register each branch's egress IP, and bind sub-locations to POPs (Netskope typically uses per-region templates).
3. Per-site automatic tunnel instantiation — one or two IPsec tunnels per POP (primary + backup) are built, parameters pushed, and the appliance brings tunnels up and reports health.
4. Continuous monitoring and failover — Orchestrator tracks per-tunnel SLA (latency/loss/jitter) and fails over/back per policy.

Common pitfalls follow directly: IKE/IPsec proposal mismatches (v1 vs v2, lifetimes, DPD timers) are the classic "tunnel DOWN" cause; NAT public-IP mismatches trip up NAT'd sites because the external address must match the provider portal; and MTU/fragmentation issues require MSS clamping or a lowered tunnel MTU.

Local breakout with security enforcement

Business Intent Overlays (BIOs) decide where and how traffic flows (path, SLA, whether to service-insert), while the firewall decides whether it is allowed and between which zones. A niche or brand-new app classified "unknown" still needs somewhere to go — a fallback rule sends all unknown internet traffic to the SWG so nothing escapes inspection by accident.

3. The SASE Picture

SSE (Security Service Edge) is the cloud-delivered security portion of the model, bundling at minimum SWG (URL filtering and web threat protection), CASB (SaaS visibility, control, DLP), ZTNA (app-level secure access replacing broad VPNs), and FWaaS (L3–L7 firewall in the cloud), frequently plus DLP and remote browser isolation. Crucially, SSE does not include SD-WAN; it assumes traffic somehow arrives at its POPs.

SASE (Secure Access Service Edge) is the convergence of WAN networking and cloud security into a single, identity-driven, centrally managed, globally distributed service:

SASE = SD-WAN (WAN edge) + SSE (cloud security) + unified, cloud-delivered control.

EdgeConnect is the networking half: it performs local breakout, builds IPsec/GRE tunnels to security POPs, applies application-aware steering, and monitors path health. EdgeConnect decides what goes where and how; the SSE platform enforces what is allowed and inspects for threats.

Aruba EdgeConnect SASE / unified SASE

HPE Aruba assembled the security half through acquisition: it bought Axis Security and rebranded/expanded it as Aruba SSE, delivering ZTNA, SWG/FWaaS, CASB, and cloud-delivered DLP. Pairing EdgeConnect (SD-WAN) with Aruba SSE gives a single-vendor SASE offering. The branch flow: a user hits EdgeConnect; EdgeConnect classifies by application, user/group, destination, and risk; private apps go over the SD-WAN overlay while internet/SaaS/ZTNA traffic goes over IPsec/GRE to Aruba SSE POPs; the POP applies ZTNA/SWG/CASB/DLP and forwards on. Remote users run an SSE client to the nearest POP and get the same stack — no backhauling.

Partnerships: Zscaler, Netskope, Check Point, Palo Alto

Single-vendor is not the only path. EdgeConnect's openness supports multi-vendor, best-of-breed SASE by integrating natively with major SSE providers — valuable for enterprises already running Zscaler or Netskope. The trade-off:

A common migration arc is pragmatic: Phase 1 deploys EdgeConnect while keeping existing SSE; Phase 2 moves more traffic to SSE and retires on-prem appliances; Phase 3 optionally consolidates onto one SSE and sunsets legacy VPN/firewalls. Across all of these, aligning EdgeConnect and the SSE layer on the same IdP (Azure AD, Okta) and feeding device posture lets policy be written about users and roles rather than brittle IP addresses.