An SSL VPN gives remote users access to an internal network over TLS, usually on TCP 443. It comes as a clientless portal publishing named applications, or as a tunnel client that reaches the whole network. It passes networks that block IPsec, which is why most organizations have one.
- Runs on TCP 443, so it passes hotel and guest networks
- Portal mode grants applications, tunnel mode grants the network
- The cryptography is not what separates it from IPsec
- The appliance is internet facing, which is the real question
- MFA and fast patching decide the outcome, not the protocol
On this page
The two modesThe two modes SSL VPNs come in
The term covers two designs that share a protocol and almost nothing else. Vendors sell both SSL VPNs under the same name, which is the source of most of the confusion.
The clientless portal. The user opens a web page, authenticates, and reaches a list of published web applications: an internal site, a file share presented through the browser, sometimes a remote desktop session rendered in a browser tab.
Nothing is installed on the device. The appliance translates between the web browser and the internal service, which means it has to understand each application it publishes.
The tunnel client. The user installs a client, authenticates, and gets a virtual network adapter with an internal address. From that point it behaves like other VPNs: routes are pushed, data goes through the tunnel, and every internal service is reachable rather than a chosen few. The TLS connection is just the secure transport underneath.
The difference is the size of what the user reaches. A portal grants access to named applications. A tunnel grants access to the whole network, subject to whatever firewall rules exist behind it, which are often fewer than people assume.
| Clientless portal | Tunnel client | |
|---|---|---|
| Software on the device | None | A client to install |
| What the user reaches | Named applications only | The network, subject to rules |
| Works from an unmanaged device | Yes | Usually not |
| Supports arbitrary protocols | No | Yes |
| Effort to publish a new application | High, per application | None, it is already reachable |
| Risk if credentials are stolen | Limited to the published set | The whole network |
The sequenceWhat happens when a user connects to the VPN
The sequence is the same for both modes up to the point where they diverge, and knowing it makes the failure messages legible.
The TLS handshake. The client opens a TCP connection to port 443 on the appliance and completes an ordinary TLS handshake. The appliance presents a certificate, and if that certificate is expired or does not match the name users type, every connection fails at this step with a browser security warning rather than a VPN error.
Authentication. Credentials go over the now encrypted connection, and the appliance checks them against a directory, usually Active Directory or an identity provider. This is where the second factor is requested, and where a portal that authenticates against nothing more than a password is doing far less than it appears to be.
Authorization. The appliance decides what network access this user is entitled to. In portal mode that is a list of published applications; in tunnel mode it is a set of routes and, if anyone configured them, access rules.
The session, and where the two modes part. A portal session is a series of web requests that the appliance proxies to internal services, so the internal servers see the appliance rather than the user.
A tunnel session brings up a virtual adapter, pushes routes to the client, and from then on the internal network sees traffic from an address that belongs to the user rather than to the gateway.
That last difference matters for security logging. In portal mode the internal application logs the appliance address for every user, so attributing an action to a person means correlating two sets of log data. In tunnel mode each user has their own address and the internal logs are directly useful, provided somebody records which address was leased to whom.
Why choose itWhy anyone chooses SSL VPNs over IPsec
The security argument between SSL and IPsec VPNs is thinner than vendor material suggests. Both use strong modern encryption and both are secure. The decision is made on three practical grounds.
It goes through networks that block IPsec. IPsec uses IP protocol 50 and UDP ports 500 and 4500. Hotel wireless, guest networks and some mobile carriers block or mangle all three. SSL VPNs on TCP 443 look like ordinary HTTPS traffic and pass almost everywhere, which is the single reason most organizations end up with one.
It handles unmanaged devices. A clientless portal works from a device you do not control, which is either a genuine access requirement for contractors or a bad security idea depending on what data is published through it.
Access is granular by default. Publishing three web applications through a portal is a smaller grant than routing a user onto the network. That is a real security advantage, and it disappears entirely the moment the tunnel client is used instead.
Against that, IPsec VPNs keep two advantages. They are the standard for site to site tunnels between offices, where SSL VPN products are rarely used, and IPsec is a standard rather than a product, so a tunnel between two vendors' equipment is a normal thing to build.
The exposureThe part that matters most: the VPN appliance is exposed
Every SSL VPN terminates somewhere, and that somewhere is a device with a public address, listening on 443, that everybody on the internet can reach.
That is not a criticism of the design. It is what remote network access means, and IPsec concentrators have the same property. What is specific to this category is the record.
Internet facing remote access appliances, SSL VPN gateways prominently among them, have been the initial entry point for a large share of significant security incidents over the past several years. The pattern repeats: a vulnerability is published, exploit code follows within days, and unpatched appliances are compromised before their owners have scheduled the maintenance window.
Three properties make this category attractive to attackers.
It is reachable by definition. You cannot put a remote access gateway behind a firewall that blocks the internet, because the internet is where the users and their data are.
It holds credentials and sessions. A compromised VPN gateway is not just a foothold, it is a position that sees every authentication and every session.
It sits at the network boundary. By design it has a path into the internal network, which is exactly what an attacker wants next.
That produces a specific operating rule that is different from the rest of your patching: VPN appliances are patched first, on their own schedule, ahead of everything else. A monthly cycle is not fast enough for a device in this category. Patch management with rings and soak times is correct for a laptop fleet and wrong for network security appliances.
Four other things reduce the exposure.
| Control | What it stops | What it does not |
|---|---|---|
| Patch ahead of everything else | Exploitation of a disclosed flaw | A flaw nobody has disclosed yet |
| MFA on every account | Stolen and stuffed credentials | A session hijacked after login |
| Rules behind the tunnel | Free movement once inside | The initial access itself |
| Reviewing authentication logs | Nothing, but it tells you | Anything you never look at |
| Vendor advisory feed | Nothing, but it starts the clock | The patch still has to be applied |
Multi factor authentication on every account, without exception. Credential stuffing against VPN portals is constant and automated. MFA is the security control that makes stolen passwords insufficient for access.
Restrict what a connected user reaches. A tunnel client that lands on a flat network gives an attacker with valid credentials access to everything and every piece of data on it. Network rules behind the VPN are what limit that.
Watch the logs for the obvious. Authentication from unexpected countries, at unexpected hours, and configuration changes nobody made. This is one of the few security log sources small organizations genuinely should review.
Subscribe to the vendor security advisories. Not the newsletter, the advisory feed, so a published vulnerability reaches you the day it appears rather than the week after.
PitfallsWhere people go wrong
Patching VPN appliances on the normal cycle. It is the wrong schedule for the one device that everybody on the internet can reach and that has a documented history of being attacked within days of a disclosure.
Skipping multi factor authentication because it is inconvenient. A VPN portal with password only access is a login form on the public internet, and it is treated as one by every credential stuffing bot in operation.
Assuming the tunnel client is as granular as the portal. It is not. The portal publishes web applications; the client publishes the network. The same product sold under the same name behaves completely differently.
Leaving the tunnel with no rules behind it. Once data leaves the VPN it is inside the network. Whatever it may reach is decided by the rules on the other side, and often nobody wrote any.
Treating SSL VPNs as more secure because they use TLS. The encryption is not the difference between the two. TLS is what web browsers use, which makes it convenient, not what makes it secure.
Publishing the management interface alongside the VPN service. The administration page of the appliance should not be reachable from the internet, and on many network devices it is by default.
Forgetting the appliance exists. It runs for years without attention, the firmware falls a long way behind, and it is still the first thing anyone scanning your network will find.
ComparisonThree remote access protocols, and the property all three share
| Criterion | SSL VPN | IPsec | WireGuard |
|---|---|---|---|
| Transport | TCP 443, usually | Protocol 50, UDP 500 and 4500 | UDP, any port |
| Passes hotel and guest networks | Yes | Often not | Usually |
| Clientless option | Yes | No | No |
| Standard across vendors | No, product specific | Yes | Yes |
| Usual site to site choice | No | Yes | Sometimes |
| Configuration complexity | Low | High | Very low |
| Internet facing appliance required | Yes | Yes | Yes |
The last row is worth reading as the thing all three share rather than a difference. Every remote access method needs something listening on the internet, and how quickly that thing gets patched matters more to your security than which of the three protocols it speaks.
FAQFrequently asked questions
What is an SSL VPN?
Remote network access over a TLS connection, usually on TCP 443. SSL VPNs come as a clientless web portal publishing named applications, or as a tunnel client that behaves like other VPNs.
What is the difference between SSL VPNs and IPsec VPNs?
IPsec works at the network layer using its own protocols and ports; SSL VPNs work over TLS on TCP 443. The practical difference is that SSL VPN traffic passes through networks that block IPsec.
Are SSL VPNs more secure than IPsec?
No, and the question is usually the wrong one. Both use strong encryption. What decides the security outcome is multi factor authentication, how fast the appliance gets patched, and what network access a connected user has.
What is a clientless SSL VPN?
A web portal that publishes specific applications through the browser, with nothing installed on the device. The user gets access only to what has been published.
Do SSL VPNs need software installed?
The portal mode does not. The tunnel mode does, and the tunnel mode is what most organizations actually deploy for staff access.
Why do SSL VPNs work where IPsec does not?
Because they use TCP 443, which every network permits. IPsec needs IP protocol 50 and UDP 500 and 4500, which hotel and guest networks frequently block.
What port do SSL VPNs use?
TCP 443 in almost every deployment, so the traffic is indistinguishable from ordinary HTTPS at the network level. Some products also use UDP for the data channel once connected.
Why are VPN appliances targeted so often?
Because they are reachable from the internet by definition, they handle authentication, and they have a path into the internal network and its data. That combination makes them the most valuable single device on the network to compromise.
How quickly should VPN appliances be patched?
Faster than anything else on the network. Exploit code for disclosed vulnerabilities in this category typically appears within days, and attacks follow immediately.
Do I still need MFA if the VPN uses strong encryption?
Yes. Encryption protects the data in transit. It does nothing about an attacker who has a valid username and password, and a VPN portal is a login form on the public internet.
Can SSL VPNs replace a site to site tunnel?
Rarely a good fit. Site to site connections between offices are IPsec territory, and SSL VPN products are built around remote user access rather than permanent links between networks.
Is an SSL VPN the same as a VPN service for privacy?
No. This is remote access to a network you own. A consumer VPN service is a different product solving a different problem.
What network access should be restricted behind the VPN?
Everything not needed. A connected user should reach the specific servers and ports their role requires, not the whole internal network and all its data, which is what they get by default on most deployments.
Keep readingRelated concepts
Read next · Remote access What Is an IPsec VPN? The protocol SSL VPNs are usually chosen instead of, and still the right answer between two offices. Open this next11 min- Identity and access · 16 min What Is MFA? A VPN portal is a login form on the public internet, which makes this the control that matters most on it.
- Operations · 13 min Patch Management, and Why the Hard Part Is Not the Patching The appliance belongs outside the normal cycle, which is a decision the patching process has to make room for.
- Remote access · 12 min VPN Technologies, and Which One Belongs on Which Job How the second job is usually solved today.
- Ports · 10 min Port 22, and Why Changing It Is Not the Fix People Think The alternative to opening this port at the edge.