Remote Access VPN and SSL VPN

Let us start with the big picture. Every time you connect to the internet from a coffee shop, your data travels across a public network. Anyone with the right tools can see that data unless it is encrypted. Encryption is the process of scrambling data so that only the intended recipient can read it. A Virtual Private Network (VPN) creates an encrypted tunnel between your device and a company's private network, shielding your data from anyone on the public internet.

A Remote Access VPN is the traditional VPN most people imagine. You install a special piece of software called a VPN client on your laptop or phone. When you want to connect, you open that client, enter your username and password (often plus a second factor like a code from your phone), and the client establishes an encrypted tunnel to a VPN concentrator — a dedicated server at the company's data centre. Once the tunnel is up, your device gets an IP address from the company's internal network, so it behaves exactly like a computer inside the office. You can access file servers, printers, internal websites, and any other resource you could reach from your desk. This is called a full-tunnel or split-tunnel configuration, depending on whether all your internet traffic goes through the company network or only the company traffic.

Now, an SSL VPN is different. SSL stands for Secure Sockets Layer, the same technology that makes the padlock icon appear in your web browser when you visit a secure website. With an SSL VPN, you do not need to install any special client software. Instead, you open any standard web browser (Chrome, Firefox, Edge, Safari), type in the URL of your company's SSL VPN gateway, and log in. The gateway presents you with a web page that contains links to the specific applications you are allowed to use — maybe your company email, a shared drive, or a timesheet system. When you click one of those links, the gateway creates a secure, encrypted connection just for that application. It is called a clientless VPN because the only software you need is already on your device: the web browser.

Why do both exist? The answer is flexibility and security. A remote access VPN (also called IPsec VPN) is powerful — it gives users full network access, which is great for employees who need to use many different internal tools. But that power also means risk: if a hacker steals a user's laptop and the VPN credentials, they can access the entire company network. An SSL VPN is more restrictive by design. It only gives access to specific applications, so even if credentials are stolen, the hacker can only reach the few applications the gateway exposes. SSL VPNs are also easier to deploy because users do not need to install software — IT just sets up the gateway once and users connect through any browser.

Here are the key components you need to know for the exam:

Both technologies use a handshake process to establish the tunnel. When you start a remote access VPN, your client and the concentrator first agree on which encryption algorithms to use, then exchange keys (digital values used to scramble and unscramble data), and finally verify each other's identity. This is called the IKE (Internet Key Exchange) protocol. For SSL VPNs, the handshake is the same as when you visit a secure website: the browser checks the gateway's digital certificate, they agree on encryption, and then the user logs in.

The exam expects you to understand the differences between these two approaches and when each is appropriate. For example, if a company needs to give a contractor access to only one web-based application for two weeks, an SSL VPN is the right choice because it is quick to set up and limits access. If a company wants its full-time employees to have access to the entire network from home, a remote access IPsec VPN is the better fit.

Imagine you are the sole IT administrator for a mid-sized company called GreenLeaf Consulting, which has 200 employees. Until last month, everyone worked in the office. Now, due to a new flexible work policy, 80 employees will work remotely three days a week. Your boss says, 'Make it secure and make it happen by Friday.'

Your first job is to decide which technology to use. You know that the remote employees need access to three main systems: their email (which is web-based), a document management system (also web-based), and a legacy accounting application that can only be accessed via a direct network connection (it does not work through a browser). The 120 employees still in the office do not need VPN access at all.

You decide to use a combination approach. For the 80 remote workers, you set up an SSL VPN gateway. You configure it to give them access to the two web-based applications through a simple portal page. When they go to https://vpn.greenleaf.com, they log in with their Microsoft Entra ID (formerly Azure Active Directory) credentials and a one-time passcode sent to their phone. They see two clickable icons: one for email and one for the document system. This takes you about two hours to configure on the gateway.

But the legacy accounting application is a problem. It requires direct network access, which the SSL VPN cannot provide because it only works with web traffic. So you deploy a remote access IPsec VPN for the five employees in the accounting department who need that legacy app. You install a VPN client on each of their laptops, configure the client with the company's VPN concentrator IP address, and create firewall rules to allow only their traffic to reach the accounting server. This takes another two hours.

Now, let us walk through what happens when a remote user named Priya connects. Priya opens her laptop at a coffee shop. She opens Chrome and types the SSL VPN URL. The gateway presents a login page. She enters her username and password, then checks her phone for the six-digit code from her authenticator app. She enters that code. The gateway authenticates her against the company's Microsoft Entra ID, then creates an encrypted tunnel between her browser and the gateway. She sees her two application links. She clicks the email link, and a new browser tab opens showing Outlook — but the address bar still shows the gateway's URL, not the internal email server's address. That is because the gateway is acting as a proxy, forwarding her traffic securely.

Meanwhile, in accounting, David needs the legacy app. He opens the VPN client installed on his laptop. He enters his username and password, and the client sends that to the company's VPN concentrator. The concentrator verifies his credentials and checks that his laptop has the company's security certificate installed. Once verified, the client and concentrator negotiate an encrypted tunnel using IPsec. David's laptop now has an IP address from the company's internal network (192.168.1.50, for example). He opens the legacy accounting application, which connects directly to the server at 10.0.0.25. It works exactly as if David were sitting at his desk in the office.

For the exam, you need to know that real-world deployments often mix both technologies. You also need to understand the operational differences: SSL VPNs are easier to manage because there is no client software to install or update on hundreds of devices. IPsec VPNs give more control and full network access but require client management. You would also set up logging to see who connected, when, and from where. Most modern firewalls (like Cisco Firepower) can act as both SSL VPN gateways and IPsec concentrators, so you might buy one device to handle both roles.