Client-to-Site and Clientless VPNs: How Remote Access Connects

Remote-access VPNs (virtual private networks) come in two deployment models. A client-to-site VPN uses installed software — a VPN client — that gives the whole device an encrypted network connection into the corporate LAN, as though it were plugged in at the office. A clientless VPN needs nothing installed: the user signs into a secure web portal over HTTPS, and a gateway proxies their access to specific internal applications through the browser. N10-009 tests whether you can match each model to the right scenario and explain the mechanics that make the clientless portal work.

Client-to-site: the device joins the network

With client-to-site (also called remote-access) VPN, software on the laptop — a native OS client or a vendor agent — authenticates to a VPN gateway and brings up an encrypted tunnel, typically using IPsec (Internet Protocol Security) or TLS (Transport Layer Security). The client receives an internal IP address and routes for corporate subnets, so the operating system itself is on the corporate network at layer 3. Every application on the device — file shares over SMB, remote desktop, thick database clients, print queues — works without modification, because the tunnel operates below the application layer.

That breadth is the model’s defining trait. It’s the right answer whenever a scenario says a remote employee’s laptop needs to reach internal resources “as if it were in the office.” It also carries the model’s obligations: the organization must install and update client software, and because the device gets real network reachability, it should be a managed, trusted endpoint — patched, running endpoint protection, and subject to posture checks before the tunnel comes up. Whether the tunnel carries all traffic or only corporate traffic is a separate configuration choice covered in split tunnel vs full tunnel.

Clientless: the browser is the client

A clientless VPN (commonly marketed as an SSL VPN portal, though modern deployments use TLS) flips the model. The user browses to the gateway’s HTTPS portal, authenticates — ideally with multifactor — and lands on a page of bookmarks for published applications: an intranet site, a ticketing system, webmail, sometimes RDP/SSH sessions rendered in the browser through HTML5 translation. Nothing is installed, no admin rights are needed on the endpoint, and when the session ends, no corporate software remains on the machine.

The access is deliberately narrow. The user doesn’t get an internal IP address or network-level reachability; they get exactly the applications the administrator published, and nothing else. That makes clientless the fit for a specific, recurring exam pattern: a contractor, partner, or employee on a personal, unmanaged device who needs occasional access to one or a few web applications. Installing a full client on hardware you don’t control is both impractical and risky; publishing the single app through a portal solves it with minimal exposure.

How the portal reaches servers the user can’t

The mechanics question the exam asks about clientless VPNs: how does clicking a bookmark connect the user to an internal server their browser can’t resolve or route to? The answer is that the gateway acts as a reverse proxy. The user’s browser only ever talks to the gateway’s public HTTPS address. When the user clicks a bookmark, the gateway opens its own connection to the internal application server — it sits on the corporate network and can resolve internal DNS (Domain Name System) names — then relays the application’s responses back through the portal session. Along the way it rewrites the content: internal URLs, links, and references in the pages are translated into portal URLs so that every subsequent click also flows through the gateway.

Two consequences follow. First, the internal server’s real address is never exposed to or reachable from the user’s device — the endpoint needs no routes, no internal DNS, no client config. Second, the rewriting is why clientless portals work best with well-behaved web applications: complex apps with embedded scripts, hard-coded addresses, or non-HTTP components can break under URL rewriting, which is when vendors fall back to HTML5-rendered sessions or push you toward a full client.

	Client-to-site	Clientless
Software on endpoint	VPN client installed	None — browser only
Scope of access	Network-level; all apps and protocols	Published applications only
Endpoint gets internal IP	Yes	No
Best-fit endpoint	Managed corporate device	Unmanaged/personal/partner device
Protocols supported	Any (IPsec/TLS tunnel below apps)	Web apps; RDP/SSH via HTML5 translation
Gateway’s role	Tunnel terminator/router	Reverse proxy with URL rewriting

Choosing between them (and running both)

Most organizations deploy both models from the same gateway — a gateway that may itself be a hardware appliance or a software instance deployed through network function virtualization. Employees on corporate laptops use the client for full access; contractors, auditors, and BYOD (bring your own device) users get portal accounts scoped to what they need. The decision inputs are consistent: who owns and manages the device, how many applications are needed, whether any of them are non-web protocols, and how much network exposure the user’s role justifies. Least privilege favors clientless whenever the requirement is narrow — publishing one application creates far less attack surface than handing out routable access to corporate subnets. Compliance boundaries sharpen the point: network-level access into a segmented environment such as a PCI cardholder data environment expands audit scope in a way a single published application does not.

Operationally, client-to-site generates the troubleshooting load you’d expect from installed software: client version mismatches, OS updates breaking virtual adapters, and posture-check failures. Clientless shifts the load to the gateway: certificate expiry on the portal, rewrite rules breaking an application after an update, and published-bookmark permissions.

How the N10-009 exam tests this

• Employee installs VPN software so the laptop can reach internal resources as if on the office network — identify client-to-site (remote-access) VPN. Site-to-site is the distractor; it connects two networks via their gateways with no per-user software at all.
• Contractor needs occasional access to a single internal web app from a personal device; no software installs allowed — the answer is a clientless (browser-based/SSL) VPN portal. A full client, site-to-site tunnel, or exposing the app directly to the internet are the distractors.
• “How does the portal connect users to servers their browser never resolves?” — the gateway proxies the connection on the user’s behalf and rewrites internal URLs into portal links, keeping internal addressing hidden from the endpoint.
• Least-privilege framing — given a narrow access need, prefer the option granting application-level access over network-level access; clientless beats client-to-site when only one or two web apps are required.

Scenario matching like this rewards repetition — run the patterns through Network+ practice questions until the device-and-access cues jump out.

Quick reference

• Client-to-site: installed client, encrypted tunnel, endpoint gets an internal IP — whole device joins the corporate network.
• Works for every protocol and application because the tunnel sits below the application layer.
• Clientless: HTTPS portal, no software, no internal IP — access limited to published applications.
• Gateway in clientless mode = reverse proxy: it connects to internal servers itself and rewrites URLs so all traffic flows through the portal.
• Unmanaged/BYOD/partner device + few web apps → clientless; managed laptop + broad access → client-to-site.
• Site-to-site VPN is neither: it links two office networks gateway-to-gateway, transparent to users.
• Complex web apps can break under URL rewriting — HTML5 rendering or a full client is the fallback.