An SSE Gateway is Versa’s Security Service Edge enforcement point, deployed as a Versa-hosted cloud gateway or an on-premises appliance, that terminates SASE client tunnels and site-to-site connections and enforces authentication, decryption, and threat and access policy on the traffic passing through it.
Key takeaways
- An SSE gateway is Versa’s enforcement point for SASE traffic.
- It terminates SASE client tunnels and site-to-site tunnels alike.
- Deployed via Director, then discovered and onboarded in Concerto.
- Requires a public-CA certificate covering every gateway FQDN in use.
- Trusted Network Detection lets it skip tunnels on trusted networks.
On this page: Why it mattersHow it worksSSE Gateway deployment modelsSSE gateways & VersaFAQ
Why is an SSE Gateway important?
Security Service Edge only works if traffic actually flows through the security stack – every ZTNA check, every TLS inspection, every threat-protection decision has to happen somewhere, on some device, before traffic reaches the internet or a private application. An SSE gateway is that somewhere: the single enforcement point where a remote user’s client tunnel, or a branch’s site-to-site tunnel, lands before its traffic goes anywhere else. Without it, SASE policy is just a document; with it, policy is what traffic actually experiences.
Centralizing enforcement at the gateway is also what makes SASE consistent across very different connection types. A user working from a laptop over the internet, a branch reaching the same private application over an SD-WAN overlay, and a Terminal Server session shared by dozens of users all need the same identity-aware, posture-aware policy applied – and they can, because the gateway is where authentication, decryption, and access control converge regardless of how traffic arrived.
What is an SSE Gateway?
An SSE gateway terminates two kinds of connections. Versa SASE clients build IPsec, TLS, or DTLS tunnels to it directly, registering against a portal FQDN and authenticating per user. Sites reach it through site-to-site IPsec or SD-WAN overlay tunnels, so an entire branch’s traffic – not just individual clients – can be routed through the same enforcement point. Either way, once traffic lands on the gateway it is subject to the same authentication, TLS decryption, threat protection, and access-policy evaluation.
Because clients resolve a gateway by FQDN, TLS certificate coverage matters as much as network reachability: the gateway’s device certificate, signed by a public CA, must cover every FQDN variant clients and browsers will use – the secure-access root domain and, for clientless reverse-proxy access, a separate myapps wildcard. Redundant gateways deployed for high availability need their own certificates with staggered expiration dates, so a renewal on one gateway never coincides with a lapse on its pair.
SSE Gateway deployment models
Gateways are provisioned on Director as a Cloud-Security device type using the Hub Controller role, one dedicated template workflow and one dedicated device group per gateway – templates aren’t shared across gateways. WAN interfaces on the gateway carry circuit tags that scope what each circuit is used for: NO_DIA disables direct internet access on a circuit, NO_S2S excludes it from site-to-site tunnels, NO_RAC_RAS blocks it from SASE client connections, and DIA_ON_PROVIDER enables source NAT for sub-tenant internet traffic at the provider level – leaving a circuit untagged makes it available for all three traffic types.
Once deployed, gateways are discovered from Versa Concerto: an administrator adds the owning Director node to Concerto, runs tenant discovery, and the gateways provisioned under that Director’s provider tenant appear for onboarding into regions and tenants. A gateway can also run in trusted-network-assisted mode, where it recognizes clients connecting from a private IP behind an existing SD-WAN or IPsec tunnel and skips building a redundant SASE tunnel, while still tracking identity and posture over a lightweight control channel.
SSE gateways & Versa
Deploying an SSE gateway and onboarding tenants walks through the full path: Director-side template and device-group creation, certificate installation, DNS and time configuration, then Concerto-side discovery and root-domain configuration for gateway FQDNs. Trusted Network Detection (gateway-assisted) lets an SSE gateway tell trusted from untrusted connections by the client’s source IP and skip tunnel creation for clients already inside a secured network, while still enforcing user-specific policy through the control channel.
The gateway also anchors identity in scenarios a client can’t cover on its own. Behind a shared Windows Terminal Server, where the VOS appliance would otherwise see one IP address for every logged-in user, the Terminal Server Agent registers each session with the SSE gateway over the SD-WAN overlay or an IPsec tunnel to the portal URL, giving the gateway per-user visibility and policy enforcement it couldn’t get from network traffic alone.
Frequently asked questions
What is the difference between an SSE gateway and a SASE client?
The client is endpoint software that builds a tunnel; the SSE gateway is the enforcement point the tunnel terminates on. The client authenticates the user and carries traffic; the gateway inspects, decrypts, and applies policy to that traffic once it arrives.
Can an SSE gateway handle both client tunnels and site-to-site tunnels?
Yes. The same gateway terminates SASE client connections from individual users and IPsec or SD-WAN site-to-site tunnels from entire branches, applying the same authentication, decryption, and access-policy stack to both, so a single gateway design covers remote users and connected sites without separate infrastructure for each.
Why does an SSE gateway need a public CA-signed certificate?
Clients connect over HTTPS to FQDNs the gateway serves, and a public CA-signed certificate lets client-based and clientless connections trust the gateway without installing extra root certificates on every device – required for both the secure-access and reverse-proxy FQDN variants.
What is Trusted Network Detection on an SSE gateway?
It lets the gateway recognize, from the client’s source IP, when a user is already inside a network with an existing secure connection – such as an office behind an SD-WAN overlay – and skip building a redundant client tunnel while still enforcing identity and posture policy.
How does an SSE gateway handle shared Terminal Server sessions?
By default it can’t distinguish users sharing one Terminal Server IP address. The Terminal Server Agent registers each user session with the gateway separately, over the existing SD-WAN or IPsec tunnel, so the gateway can apply per-user access control instead of one shared policy.
More on SSE Gateways
If you want to learn more, these are sources we trust.
| MEF 117: SASE Service Attributes and Framework | Versa Networks: SD-WAN | Versa Academy |
|---|---|---|
| The MEF SASE standard, whose framework covers the security service edge functions an SSE gateway enforces. | How Versa packages SD-WAN alongside the SSE gateways that enforce security for its traffic. | Versa’s training portal, including hands-on courses on SSE gateway deployment and onboarding. |
Related terms
If you’re reading about SSE gateways, these are worth looking at next.
| Security Service Edge | Versa SASE Client | Site-to-Site Tunnel |
|---|---|---|
| The cloud-delivered security architecture SSE gateways enforce, spanning ZTNA, SWG, CASB, and DLP. | The endpoint software that builds one of the two tunnel types an SSE gateway terminates. | The other tunnel type an SSE gateway terminates, carrying branch and private-application traffic. |