Why SSL VPN and Site-to-Site VPN Are Not Opposites
SSL VPN and site-to-site describe different axes: who joins the network and how the tunnel is built. Naming both ends the category error.
Ask two administrators to describe the same VPN and one may answer "SSL VPN" while the other says "site-to-site", as though the two were rival options in a menu. They are answers to different questions, and treating them as alternatives produces comparisons that cannot be resolved. One label says which endpoints are being joined; the other says what carries the traffic between them. Keep the axes apart and most of the argument disappears.
Two labels, two separate questions
Topology answers who is joining what. A remote-access design attaches individual users or devices to a gateway, usually with per-user identity and a pool of addresses. A site-to-site design joins two networks through gateways, so the interesting identity is the peer gateway rather than the person at a keyboard. Those are different operational problems, from address planning to who can revoke access at 2 a.m.
Mechanism answers how the tunnel is built and authenticated. IPsec with IKEv2, a TLS-based product that carries IP inside it, and a browser-facing application portal are mechanism choices, and each has its own negotiation, cipher suites and failure modes. None of them implies a topology, and a topology does not pick a mechanism.
Put the two axes in one table and the confusion becomes visible, because every cell of the grid can be filled. What the grid cannot do is tell you which combination your vendor shipped, since product names collapse both axes into one marketing phrase.
Where the category error comes from
Vendors sold "SSL VPN" for years as the opposite of "IPsec VPN", which made a mechanism comparison look like a topology choice. The phrase has aged badly on its own terms as well, since current designs use supported TLS versions and the SSL name survives mainly as a product category.
| Axis | Question it settles | What it cannot tell you |
|---|---|---|
| Topology | Whether users join a gateway or two networks join each other | Which protocol carries the traffic, or how peers prove identity |
| Mechanism | Which protocol suite builds the tunnel and negotiates keys | Whether the endpoints are people, devices or routers |
| Access surface | Whether the client sees a routed network or a set of published applications | Which topology or mechanism is underneath the portal |
| Authentication | What proof each side presents, and to whom | Whether the traffic is later authorized per resource |
Two related myths follow from the same collapse. The first is that IPsec means site-to-site; IKEv2 was designed for client-to-gateway relationships too, so an individual laptop can join with IPsec. The second is that a TLS-based product means remote access only; OpenVPN is routinely used to carry traffic between two sites, and its TLS use is concentrated in the control and authentication exchange rather than in a browser session.
A useful test for any description: if swapping one word changes both the endpoints and the protocol, the sentence is mixing the axes. "SSL VPN versus site-to-site" fails that test, because the first term names a mechanism family and the second names a topology.
Describe a deployment so it can be compared
Write four slots and fill them: endpoints, mechanism, authentication and access surface. A branch link might read as an IKEv2 gateway pair between two named prefixes with certificate authentication and no user-level portal. A remote-access service might read as a TLS-based client that assigns per-user addresses, requires a second factor at login and publishes only an internal DNS zone.
Those sentences are comparable in a way that product names are not. Two remote-access designs can be measured against the same user workflow and the same revocation path, and two intersite designs against the same prefix list, traffic policy and failure requirements. The labels organize the comparison; they do not replace it.
The terminology has a published anchor as well. The IETF's VPN terminology document separates several service models, including remote access and site-to-site, from the mechanisms used to build them, which is exactly the distinction that keeps getting lost.
Read the negotiated protocol, not the product name
The label on the box does not establish what a running tunnel agreed to. Ask the peer directly, on the TLS side, and read the protocol version and cipher the handshake produced rather than the version in the brochure.
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefFor an IPsec gateway the equivalent observation comes from the implementation's own status output, which reports the IKE and ESP proposals in use. Either way, the point is the same: the mechanism axis has to be read from the live session, because a client and gateway can negotiate down to something older than either administrator expected.
ipsec statusall | grep -E "IKE|ESP"After that, the remaining questions are the ones no label answers. Which protocol versions are still accepted, how is the gateway's identity validated, what algorithm set is permitted, who authorizes a given user for a given resource, and what revokes access when a device is lost. A topology diagram and a mechanism name are the beginning of that list, not a substitute for it.
Keep the two labels, then, but use them for what they are: a short way to say which endpoints are joined and how the tunnel is built. The moment either one is used to rule out the other, the description has stopped describing anything.