IPsec remains the foundation of site-to-site connectivity in most enterprise networks, but running it in isolation is no longer enough. This article extends our earlier deep dive into IPsec tunnel architecture by showing how SD-WAN and ZTNA (zero trust network access) reshape what a mature, optimized security perimeter looks like in 2026.
Executive Summary
- IPsec is not being replaced — it’s being orchestrated. SD-WAN treats IPsec tunnels as intelligent, policy-driven paths rather than static links.
- ZTNA shifts trust from the network layer to the identity layer, replacing broad VPN access with per-application micro-tunnels.
- Firewall policy order matters: on most platforms, policy matching happens on the original source IP, before SNAT is applied.
- A mature architecture runs all three together — IPsec for site-to-site backbone traffic, SD-WAN for path intelligence, and ZTNA for remote user and legacy application access.
Understanding IPsec Tunnel Optimization in a Zero Trust Era
Optimizing an IPsec deployment today means recognizing that the tunnel itself is only one layer of a much larger security stack. The encryption and NAT traversal mechanics stay the same — what changes is how traffic gets routed into the tunnel and who is allowed to use it.
Where IPsec Still Fits in Modern Architecture
Site-to-site connectivity between a headquarters and a branch, or between an enterprise and a hosting provider, still relies on IPsec as the encrypted transport layer. Database replication, Active Directory traffic, and bulk internal application traffic all continue to run through classic Phase 1 / Phase 2 tunnels.
What has changed is that this tunnel is rarely the only path out of a network anymore. It typically sits alongside internet breakouts, SaaS traffic, and identity-brokered application access.
The Shift from Network-Level to Identity-Level Trust
Traditional VPN and IPsec-based remote access grant network-level trust — once connected, a user can reach an entire subnet. Zero trust network access (ZTNA) inverts this model by granting access to a single application, at a single IP and port, rather than a network segment.
This distinction is the core of why enterprises are layering ZTNA alongside — not instead of — their existing IPsec infrastructure.
SD-WAN and IPsec Tunnels Working Together
A common misconception is that SD-WAN replaces IPsec. In production Fortinet, Cisco, and similar deployments, SD-WAN sits on top of IPsec: the tunnel provides the encrypted path, and SD-WAN decides intelligently which tunnel or ISP link to use for a given application.
SD-WAN Zones, Rules, and Firewall Policy Order
An SD-WAN zone typically groups multiple physical WAN interfaces and IPsec VPN interfaces into one logical construct. SD-WAN rules then apply policy-based routing on top — for example, directing LDAPS traffic from a specific application server preferentially over one IPsec tunnel rather than another.
Firewall policy is still mandatory alongside the SD-WAN rule. The SD-WAN rule decides the path; the firewall policy decides whether the traffic is permitted at all. On most platforms, policy matching occurs on the packet’s original source IP, before SNAT is applied — SNAT is only applied once the policy has already accepted the session.
# Example (sanitized) order of operations for LAN-to-Internet traffic
1. Packet arrives on source interface (LAN VLAN)
2. Routing lookup selects destination interface (WAN or SD-WAN)
3. Firewall policy match uses ORIGINAL source IP (e.g. 192.168.x.x)
4. If accepted, SNAT is applied (IP pool or outgoing interface IP)
5. Packet is forwarded to WAN
NAT Decisions Inside vs Outside the Tunnel
Whether NAT is enabled or disabled on a policy depends entirely on where the traffic is headed. Traffic leaving toward the public internet is typically source-NATed to hide internal addressing. Traffic entering an IPsec tunnel toward a partner or provider network is usually left un-NATed, so the receiving side can filter policy based on the true originating IP rather than a tunnel-local address.
The diagram below shows how SD-WAN zones and IPsec tunnels combine into a single logical routing decision layer sitting between the internal network and the internet.
ZTNA as the Evolution Beyond Site-to-Site IPsec
While IPsec and SD-WAN handle site-to-site and branch connectivity, remote users and individual applications increasingly move to zero trust network access instead of traditional VPN.
Zero Trust Network Access ZTNA Explained
Zero trust network access (ZTNA) provides access to one specific application, identified by an IP and port, rather than an entire VLAN. A user authenticates through an identity provider, receives a signed token, and is brokered directly to that single application — never gaining visibility into the rest of the network.
This is a fundamental departure from legacy VPN, where a firewall rule such as “VPN subnet to LAN, allow” created broad lateral-movement risk. With ZTNA, the equivalent firewall posture is closer to “no inbound rule at all.”
App Connector Architecture Without Inbound Rules
ZTNA platforms — offered by vendors including Cloudflare, Zscaler, and others — typically use a lightweight connector installed inside the network. This connector makes only outbound TLS 443 connections to the ZTNA/SSE cloud; no inbound port is ever opened on the firewall.
For legacy applications that only speak protocols like LDAP over port 636, the connector brokers that traffic internally, so the legacy system never has to be exposed across a VPN or the public internet directly.
# Example (sanitized) firewall policy set for a ZTNA connector
# Only outbound HTTPS is required — no inbound rule exists
Policy 1: App-Connector -> SSE-Cloud | TCP 443 | ALLOW + NAT
Policy 2: App-Connector -> Internal-App | TCP 8069 | ALLOW, no NAT
Policy 3: Legacy-App -> Managed-AD | TCP 636 | ALLOW, no NAT
Policy 4: Deny-All-Inbound | any | DENY + LOG
The workflow below traces a remote user’s request from authentication through to reaching an internal application — entirely without an inbound firewall rule.
Choosing ZTNA Solutions and SSE Platforms for Enterprise Rollouts
Selecting among available ZTNA solutions depends on existing vendor investment, the number of legacy applications still requiring network-level protocols, and whether the organization wants a standalone ZTNA product or a broader SSE (Security Service Edge) platform.
ZTNA Solutions Comparison Criteria
When evaluating ztna solutions such as those from Fortinet, Sophos, Zscaler, or Cloudflare, the key differentiators are usually connector deployment complexity, native integration with the existing identity provider, and whether the platform bundles SSE capabilities like a secure web gateway and CASB alongside the ZTNA broker itself.
Fortinet ZTNA integrates tightly with existing FortiGate deployments already running IPsec and SD-WAN, which reduces operational overhead for teams already standardized on that platform. Cloud-native providers like Zscaler and Cloudflare instead route traffic entirely through their own global edge, which can simplify multi-site rollouts but shifts more of the trust boundary to a third party.
Combining SSE, SD-WAN, and IPsec in One Strategy
SSE platforms typically combine a secure web gateway, cloud access security broker, firewall-as-a-service, and ZTNA broker into a single cloud-delivered policy plane. In a hybrid architecture, SSE governs user-to-app and user-to-internet traffic, while SD-WAN and IPsec continue to govern site-to-site and application-to-application traffic on the internal network.
The lifecycle below shows how these layers are typically rolled out in sequence, building outward from an existing IPsec foundation.
Operational Best Practices for Hybrid IPsec ZTNA Deployments
Running IPsec, SD-WAN, and ZTNA together requires clear boundaries between what each layer is responsible for, so troubleshooting doesn’t collapse into guesswork.
- Keep NAT disabled on IPsec tunnel policies so the far side firewall can filter on true source IPs rather than tunnel-local addresses.
- Treat the internal firewall as a segmentation and east-west inspection layer, not the sole perimeter — ZTNA and SSE now share that responsibility.
- Default every policy set to deny-all with logging, both on internal VLANs and on any ZTNA connector segment.
- Document which applications remain on legacy protocols (LDAP, RDP, SMB) requiring a connector, versus which have been migrated to SAML or OIDC directly.
Advanced FAQ
What is SD-WAN and how does it relate to IPsec?
SD-WAN is an intelligent routing layer that decides which link — including IPsec tunnels — traffic should use, based on application, performance, or policy. It orchestrates existing IPsec tunnels rather than replacing them.
What is ZTNA, in plain terms?
Zero trust network access (ZTNA) grants a user access to one specific application rather than an entire network segment, based on verified identity and device posture rather than network location.
Do ZTNA solutions eliminate the need for firewalls?
No. Firewalls remain essential for east-west segmentation, egress filtering, and inspecting traffic between internal VLANs — ZTNA changes how remote users reach applications, not the need for internal segmentation.
Should legacy applications move straight to ZTNA?
Applications that only support LDAP, RDP, or SMB typically stay behind an app connector rather than being directly exposed, since ZTNA brokers access to them without requiring a protocol rewrite.
Is Cisco SD-WAN comparable to Fortinet’s approach?
Both treat IPsec tunnels as SD-WAN members and apply policy-based path selection on top, though implementation details around zone configuration and licensing differ by vendor.
Discover more from Solide Info | The Engineer’s Authority on Cyber Defense
Subscribe to get the latest posts sent to your email.
