IPsec and WireGuard are their own protocols on their own ports. A TLS VPN wraps the tunnel in the same handshake your browser uses, on port 443, which is why it works from hotel networks, guest Wi-Fi, and anywhere a firewall only permits web traffic.
That traversal advantage is the whole reason the category exists.
The three common shapes
| Product | Transport | Auth | Notes |
|---|---|---|---|
| OpenVPN | UDP or TCP 443 | Certificates + user | The reference implementation |
| SSTP | TCP 443 | Certificates + user | Windows-native, Microsoft ecosystem |
| Clientless | HTTPS | User + app | Reverse proxy, no client |
Clientless is not really a tunnel: it publishes one application through a proxy. It belongs in the same conversation because it often replaces a full tunnel for a single intranet page.
How OpenVPN works
Two channels:
- Control channel — TLS handshake, certificate verification, key exchange.
- Data channel — encrypted packets using keys derived from the control channel.
The server pushes configuration to the client: routes, DNS servers, domain search, and sometimes a redirect-gateway flag for full tunneling.
That push is why a profile is more than a certificate: the server decides what the client can reach.
Certificates are the authentication
A TLS VPN normally has three layers:
| Layer | Proves | Fails when |
|---|---|---|
| Server certificate | The server is yours | Expired or wrong CN |
| Client certificate | The device is enrolled | Revoked or missing |
| User credentials | The person is authorized | Shared password |
Client certificates are the part districts under-use. They let you revoke a device without changing anyone's password, which is the difference between a ten-minute response and a week of resets.
Port 443 is the point
If your VPN is on UDP 1194, a network that permits only web traffic will block it. Moving to TCP 443 makes the tunnel indistinguishable from HTTPS to most middleboxes — and slower, because TCP-in-TCP behaves badly under loss.
MTU, again
Every tunnel reduces the usable MTU. For OpenVPN over UDP, 1500 minus 60 bytes of overhead is a common starting point; TLS adds more.
The symptom is always the same: ping works, small requests work, large transfers hang. Set the MTU explicitly and test with a large DF packet through the tunnel.
Worked example: a staff laptop profile
client
remote vpn.marionisd.net 443
proto tcp
dev tun
ca ca.crt
cert staff-laptop.crt
key staff-laptop.key
auth-user-pass
remote-cert-tls server
Server side:
push "route 10.0.0.0 255.0.0.0"
push "dhcp-option DNS 10.0.0.3"
push "dhcp-option DOMAIN marionisd.net"
Three pushed values decide whether the laptop behaves like it is inside the district: the route, the resolver, and the domain. Missing DNS is why "the VPN connects but nothing resolves."
What breaks in production
- Expired client certificates, which produce a connect-then-drop that looks like a credentials problem.
- No DNS push, so internal names fail while IPs work.
- TCP mode on a lossy link, which collapses throughput because TCP retransmits inside TCP.
- MTU not set, producing the classic large-packet stall.
- Full tunnel without policy, so a home laptop becomes a flat internal host.
- No revocation process, so a lost device keeps working.
Checklist
- Server and client certificates have an expiry you monitor.
- A revocation path exists and has been tested.
- DNS and domain search are pushed, not configured by hand.
- MTU is set explicitly and tested.
- UDP is preferred unless traversal requires TCP 443.
- The tunnel's access is scoped by policy, not by "connected."
Next
The tunnel is up. Continue with Split Tunneling and the Return Path, where most "VPN is slow" tickets actually live.