Beyond VPNs: Leveraging Secure Access Service Edge (SASE) for Remote Workforces

What SASE actually is, where it earns its money, and where a mesh VPN is the smarter buy

17-05-2025

Beyond VPNs: Leveraging Secure Access Service Edge (SASE) for Remote Workforces

Contents

The clearest sign your remote-access VPN has outgrown its design is the tromboning. A salesperson in the same city as your cloud provider opens their laptop, connects to a SaaS app that lives twenty miles away, and their traffic first flies several hundred miles to the corporate VPN concentrator, gets inspected, then flies several hundred miles back out to the cloud. Round trip: a thousand miles to reach something next door. Everyone blames “the internet being slow.” The internet is fine. The architecture is the problem. That hairpin is the original sin of the concentrator VPN model, and it is the specific thing Secure Access Service Edge — SASE, pronounced “sassy”, a Gartner coinage from 2019 — was invented to fix. The pitch is simple even if the acronym soup is not: stop dragging every packet back to a central box for inspection, and instead push the inspection out to points of presence near the user. The user connects to the nearest edge, gets inspected there, and goes straight to wherever they were headed. No thousand-mile detour. <h2 id="why-the-old-model-breaks">Why the old model breaks</h2><div class="ad-unit ad-in-article" aria-label="Advertisement"> Advertisement <ins class="adsbygoogle" style="display:block;text-align:center" data-ad-client="ca-pub-3726833845844946" data-ad-slot="3291553914" data-ad-format="auto" data-full-width-responsive="true"></ins> <script>(adsbygoogle = window.adsbygoogle || []).push({});</script> </div> The traditional setup made perfect sense in 2005. Everything that mattered lived inside the corporate perimeter — file servers, the intranet, the line-of-business app — so you built a wall, put a VPN gateway in it, and let remote users tunnel inside. Once inside, they were trusted. The model is sometimes called “castle and moat,” and the implicit rule is that the network boundary equals the trust boundary. Three things broke that. First, the apps left the building: they are SaaS now, sitting in someone else’s cloud, so funnelling traffic into your perimeter just to send it back out to the internet is pure overhead. Second, the users left the building: hybrid work means the “remote” case is now the normal case, and a concentrator sized for 10% of staff on a snowy day melts when 90% connect daily. Third, “inside equals trusted” turned out to be a catastrophic assumption — one phished laptop on the VPN had lateral run of the whole network. The industry’s answer to that last point is zero trust: never trust based on network location, always verify identity and device posture per request. SASE is, in large part, the delivery vehicle for zero trust to a distributed workforce. <h2 id="whats-actually-in-the-box">What’s actually in the box</h2> SASE is not one product; it is a bundle of functions delivered as a cloud service from a provider’s global edge. Strip the marketing and there are two halves. The networking half is SD-WAN — software-defined wide-area networking that steers traffic intelligently across whatever links you have, picking paths by latency and health rather than dumb static routes. The security half is where the acronyms breed, but they reduce to a few real jobs: <ul> <li>ZTNA (Zero Trust Network Access) — the VPN replacement. Instead of putting a user on the network, it grants access to specific applications after verifying identity and device, so a compromised laptop can reach the one app it was authorised for and nothing else.</li> <li>SWG (Secure Web Gateway) — filters outbound web traffic, blocks known-bad destinations, enforces acceptable-use policy.</li> <li>CASB (Cloud Access Security Broker) — sits between users and SaaS apps to enforce policy and spot risky data movement.</li> <li>FWaaS (Firewall as a Service) — firewalling delivered from the cloud edge rather than a box in a rack.</li> </ul> The whole point of selling them together is that one identity-and-policy engine drives all of them, and the inspection happens at an edge node near the user instead of at one central chokepoint. The session-per-application, verify-every-time model is conceptually the same trust posture you would build between internal services with <a href="/story/mtls-mutual-tls-between-services-without-a-service-mesh/">mutual TLS</a> — SASE just applies it to humans and their devices at the network edge. <h2 id="a-worked-example-ztna-versus-the-old-way">A worked example: ZTNA versus the old way</h2><div class="ad-unit ad-in-article" aria-label="Advertisement"> Advertisement <ins class="adsbygoogle" style="display:block;text-align:center" data-ad-client="ca-pub-3726833845844946" data-ad-slot="3291553914" data-ad-format="auto" data-full-width-responsive="true"></ins> <script>(adsbygoogle = window.adsbygoogle || []).push({});</script> </div> The difference is easiest to see in access policy. The old firewall rule that lets a VPN subnet reach an internal app looks like this — coarse, network-based, and blind to who is actually connecting: <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"># old-world: anyone on the VPN subnet can reach the finance app on its port allow src 10.8.0.0/24 -> dst 10.0.5.20:443 # the finance app </code></pre></td></tr></table> </div> </div>A ZTNA policy expresses the same intent in terms of identity, device, and a single named application, with no network exposure at all: <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-yaml" data-lang="yaml"># zero-trust intent: who, on what device, to which app — never "the network" policy: name: finance-app-access application: finance-portal # one app, not a subnet allow: identity_group: finance-team # verified via your IdP / SSO device_posture: managed: true disk_encryption: required os_patch_level: current mfa: required default: deny </code></pre></td></tr></table> </div> </div>Nobody is ever “on the network.” A user authenticates, their device posture is checked, and they get a brokered connection to one application. Lateral movement — the thing that turns one compromised laptop into a company-wide incident — has nowhere to go. <h2 id="how-a-session-actually-flows">How a session actually flows</h2> It helps to trace a single request end to end, because the marketing diagrams hide where the work happens. With a SASE client installed, the user opens a SaaS app. The client does not build a tunnel to your head office; it authenticates the user against your identity provider (the same SSO you already run), checks the device’s posture, and then connects to the nearest edge node in the provider’s network — often within a few milliseconds of the user. At that edge node, the security stack runs: the secure web gateway checks the destination against policy, the firewall-as-a-service applies rules, and if the destination is a sanctioned SaaS app the cloud access broker may apply data-handling policy. Then — and this is the bit the old model could not do — the traffic goes directly from the edge node to the SaaS provider, which is also in the cloud and likely close by. There is no trip back to your data centre. The thousand-mile hairpin from the opening of this article simply does not occur, because the inspection moved to the user instead of the user’s traffic moving to the inspection. For access to your own internal applications, ZTNA does the same dance but brokers a connection to a lightweight connector you run next to the app, so the app is never exposed to the public internet at all. The connector dials out to the SASE fabric; nothing dials in. That outbound-only posture is why ZTNA closes the inbound attack surface that a traditional VPN gateway, sitting on a public IP waiting for connections, leaves wide open. <h2 id="the-honest-trade-offs">The honest trade-offs</h2> SASE is genuinely good architecture, but the marketing oversells it, so here is the other side. You are trading your concentrator for their cloud. The whole model depends on the provider’s edge being up and reachable. When your internet link or their PoP has a bad day, everything routed through SASE has a bad day with it. You have not removed a single point of failure; you have outsourced it and made it bigger. Lock-in is real. The value comes from one vendor’s integrated policy engine, which is precisely what makes leaving expensive. The standards underneath (SAML, OIDC, your identity provider) are portable; the policy model, the dashboards, and the operational muscle memory are not. Inspection means decryption. For an SWG to filter HTTPS, it terminates TLS at the edge — your provider sees your traffic in the clear at that point. That is a meaningful trust decision, not a footnote, and it deserves a hard look at the provider’s certifications and data-handling before you sign. It is an enterprise-shaped tool with an enterprise-shaped price and project. This is procurement, a migration plan, and a pilot, not a weekend install. <h2 id="troubleshooting-the-migration">Troubleshooting the migration</h2> When a SASE rollout goes wrong, it is almost always one of a handful of things. <ul> <li> “It’s slower than the old VPN.” Usually the agent is sending traffic to a distant PoP, or split-tunnelling is misconfigured so internet-bound traffic is being backhauled needlessly. Check which edge node the client picked and confirm your traffic-steering rules match reality. </li> <li> “App X stopped working.” ZTNA is deny-by-default; an app nobody wrote a policy for is invisible. Inventory every application before cutover — the apps people forgot they used are the ones that page you. </li> <li> MFA fatigue and lockouts during rollout. Device-posture rules that are stricter than your actual fleet (demanding patch levels half the laptops do not meet) lock out legitimate users on day one. Audit the fleet first, set posture rules to match, then tighten. </li> <li> DNS surprises. Routing DNS through the SASE edge changes resolution for split-horizon and internal names. Confirm internal name resolution explicitly in the pilot rather than discovering it in production. </li> <li> Certificate and inspection breakage. Pinned-certificate apps and some native mobile clients refuse to talk through a gateway that re-signs TLS, because they expect a specific certificate and get the gateway’s instead. The usual remedy is a bypass list for those specific apps — accept that you cannot inspect them and route them around the gateway, rather than fighting clients that are behaving exactly as designed. </li> <li> Roaming and captive portals. Hotel and airport Wi-Fi with captive portals fights the always-on client, because the client tries to secure the connection before the user has clicked “I agree” on the portal page. Make sure the agent has a captive-portal detection mode and that your help desk knows the workaround, or your travelling staff will be the loudest voices in the rollout retrospective. </li> </ul> Pilot with one team, instrument it hard, and only widen the rollout once that group is boringly stable. Resist the temptation to flip everyone over at once because the dashboard looks green for the pilot group — the long tail of weird apps and edge cases only shows up at scale. <h2 id="is-it-worth-it-and-who-is-this-for">Is it worth it, and who is this for</h2> If you are a real organisation with dozens or hundreds of remote staff, a pile of SaaS apps, compliance obligations, and a VPN concentrator that is visibly buckling under daily load, SASE is the right shape of answer. The hairpin disappears, access becomes per-application and identity-aware, and your security and networking teams stop maintaining two disconnected stacks. The cost and the lock-in are the price of that consolidation, and at scale it is usually a price worth paying. If you are a small team, a developer wanting secure access to a few servers, or a homelabber, SASE is comically oversized for you — and this is the part the vendors will not tell you. You want the zero-trust outcome (no flat network, identity-aware access, no exposed ports) without the enterprise platform, and a <a href="/story/tailscale-vs-netbird-self-hosted-mesh-vpns-compared/">self-hosted mesh VPN like Tailscale or NetBird</a> delivers exactly that. WireGuard-based mesh networking gives you encrypted point-to-point connections with identity-based access controls, no central concentrator to hairpin through, and no five-figure contract. It is the small-scale embodiment of the same ideas SASE sells to the enterprise. Pick the tool sized to your actual blast radius. SASE solves a genuine enterprise problem that genuinely needs solving — just make sure it is your problem before you buy the cure.

Written by Smarc

Founder and editor of vo.rs. A lifelong tinkerer who self-hosts far more than is sensible, hardens Linux boxes for fun, and prods the latest AI tools to see what they can really do. The how-to guides here are the notes Smarc wishes had existed the first time round.

Tagged#SASE #remote work #networking #zero trust #vpn

Beyond VPNs: Leveraging Secure Access Service Edge (SASE) for Remote Workforces

What SASE actually is, where it earns its money, and where a mesh VPN is the smarter buy

Related Content

Tailscale: A Zero-Config Mesh VPN for People Who Hate Networking

MQTT Essentials: The Protocol Behind Every Smart Home

Reverse Proxy Done Right: Automatic HTTPS with Caddy in Ten Minutes

The Tunnel Home: Reaching Your Homelab from Anywhere with WireGuard