TLS VPN vs IPsec: The Five Fields Worth Reviewing

Ranking TLS VPNs against IPsec VPNs by protocol family answers a question nobody asked, and it usually cites a construction both families stopped using years ago. What a reviewer can actually assess is the negotiated protection, the peer identity, the client model and the exposed service. Those four things are visible in a deployment, and none of them follows from the product label. Ask for five fields and the conversation becomes concrete.

Five fields, and the label is not one of them

The first field is the supported software release, because a protocol description without a version is a brochure. The second is the negotiated protocol version, which decides which constructions are even available. The third is the protection suite, the fourth is the authentication method for both peer and user, and the fifth is the access scope the product grants after admission.

An SSL VPN label covers at least three different products: a full network client, an application proxy and a legacy browser-based portal. They expose different services and fail differently, so the label cannot stand in for the scope field.

What authenticated encryption actually changes

TLS 1.3 requires authenticated encryption, which removes the older MAC-then-encrypt construction from the protocol rather than leaving it optional. IPsec ESP has had authenticated-encryption suites for just as long, with AES-GCM defined in its own RFC. In both families the guarantee comes from the negotiated suite rather than the family name, which is why the field list starts with a version. A reviewer who cannot name the suite has nothing to assess.

That is why the historical comparison is misleading. A deployment pinned to an old TLS version with a CBC suite and one running TLS 1.3 with an AEAD suite are not the same security posture, even though both are TLS VPNs. The same split exists on the IPsec side between a modern ESP suite and a legacy combination.

Read the negotiated values instead of the configuration you intended. The commands below show what a live endpoint and a live tunnel actually agreed on.

openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas

If the endpoint will not negotiate TLS 1.3, that is a finding rather than a preference. If the tunnel lists a suite you did not expect, the configuration that matters is the one the peers selected, not the one in the template.

Peer identity is a separate question

Encryption without a verified peer protects the traffic from observers and hands it to whoever answered the connection. Peer authentication asks which identity is expected, what trust material validates it, and how the client behaves when the answer does not match. A certificate chain, a pinned key and a pre-shared secret are three different answers with three different operational costs.

Then ask the same questions about the user or device. A gateway that authenticates the machine and admits any user, or the reverse, has a specific posture that should be written down rather than assumed. Resource permissions applied after admission are part of the same field, because authentication is not authorization.

Preserving hostname and certificate checks matters more than the familiarity of the login window. A client configured to ignore verification has removed the only step that distinguishes your gateway from a convincing imitation.

The boundary the product exposes

A clientless portal proxies selected application operations through the gateway, so the user reaches an interface rather than a network. A full-tunnel client carries whatever its routes and filtering policy select, which is a much larger surface. Comparing the two by protocol strength misses the difference in what an attacker can reach through them. One exposes an application interface, the other exposes a routed network, and the two require different reviews.

Ask which service is exposed, which operations are authorised and what the gateway itself listens on. A management interface reachable from the same address as the user portal is a deployment finding, and no protocol choice compensates for it.

Per-application scope narrows the surface further, and it also changes the failure behaviour when the tunnel drops. A design that assumes full-tunnel reach will break in ways a per-app design does not, and the support load follows.

Decide the failure outcome and the lifecycle

What happens when authentication or protection is unavailable is a policy decision that belongs in the review. A blocked outcome and an unannounced direct fallback have different consequences, and the difference is invisible in a feature list. State the intended behaviour next to the resource it protects.

Include the gateway's patch and support lifecycle, its enabled external features and the update path for clients. A correct protocol choice does not make a badly deployed service safe, and most incidents live in that gap rather than in the cipher suite.

Write the five fields, the failure policy and the lifecycle owner into one page. That page is a review; a comparison of protocol families is an opinion.