VPNs and remote access for the small office

Why this matters

Remote access is where small networks get compromised. The pattern is always the same: somebody needed to reach a machine from home, the quickest way was to forward the remote desktop port, and six months later the whole network is encrypted.

The exam covers VPNs because the alternative to knowing about them is that pattern. It asks what a VPN changes, which kind suits which requirement, and why a connection that establishes might still carry no traffic.

There is also a simple conceptual payoff. A VPN changes where a machine appears to be, and almost every VPN behaviour — good and bad — follows from that one sentence.

The lesson

What a VPN actually changes about where a machine appears to be

A VPN builds an encrypted tunnel between two points and routes some or all of a device's traffic through it. From the far end's point of view, the device is now on the far network: it has an address there, it reaches internal resources directly, and its traffic appears to originate there.

Three consequences follow, and each is examinable:

• Resources that were unreachable become local. A file share on the office subnet is now reachable by its internal address, because the device is, in routing terms, on that subnet.
• The apparent source of traffic moves. Services that restrict access by address see the office address rather than the home one. That is the whole point for a business, and it is why a VPN is sometimes used simply to satisfy an address restriction.
• The tunnel is encrypted end to end, which is what makes untrusted networks usable. On a public wireless network, the VPN is the control that makes the other users irrelevant.

What a VPN does not do is make the device secure. A compromised laptop connected by VPN is a compromised laptop on the office network, with the tunnel obligingly carrying the attacker's traffic. That is worth stating because users and some scenarios treat the VPN as a security measure for the endpoint, and it is not.

Client-to-site against site-to-site, and which problem each one solves

Client-to-site — often called remote access VPN — connects one device to a network. Software on the laptop or phone establishes the tunnel, usually with a user credential and increasingly with a second factor. It is the answer when the requirement is "our staff need to reach the office from wherever they are".

Site-to-site connects two networks permanently, router to router. Users at either end need no software and usually do not know the tunnel exists; traffic for the other site is simply routed. It is the answer when the requirement is "our two offices need to behave like one network".

Choosing between them from a scenario is straightforward once the question is "how many things are moving":

• One roaming user, many locations → client-to-site.
• Two fixed locations, many users → site-to-site.
• A branch office whose staff also travel → both, which is a common real answer.

One design point that catches people: two sites joined by a site-to-site VPN must use different internal subnets. If both are 192.168.1.0/24, no host can distinguish local from remote, and the tunnel is useless. This is the practical reason lesson 14 recommended changing the default range.

Split tunnelling: the trade-off, stated in terms of what traffic goes where

A VPN client can be configured two ways.

Full tunnel sends all traffic through the VPN, including ordinary internet browsing. It comes back out through the office internet connection, subject to the office's filtering and logging.

• Advantage: one set of controls applies wherever the user is. Nothing bypasses the organisation's filtering.
• Cost: all traffic consumes the office link twice, and a video call or a large download from a remote worker competes with the office.

Split tunnel sends only traffic destined for the office network through the tunnel; everything else goes out the local connection directly.

• Advantage: far less load on the office link, better performance for everything not office-related.
• Cost: the organisation's filtering and inspection no longer sees the user's general internet traffic, and a device could reach a hostile site and the office network simultaneously.

There is no universally correct answer, which is why the exam phrases it as a trade-off. The deciding factors are the capacity of the office link and how much the organisation depends on inspecting user traffic.

Remote desktop and remote assistance, and why exposing one to the internet is a mistake

Two distinct things that scenarios deliberately confuse:

• Remote desktop gives you the machine. The console is locked, you have a session, and the local user is not part of it. It is an administrative tool.
• Remote assistance shares the existing session with the user's consent. The user sees what you are doing and can revoke it. It is a support tool.

Choosing correctly is usually decided by whether the user needs to watch. Helping someone through a task is remote assistance; working on a machine nobody is sitting at is remote desktop.

The security point is about exposure rather than either tool. Forwarding remote desktop's port 3389 to the internet is one of the most reliably exploited configurations there is: automated scanning finds it within hours, and credential guessing runs continuously thereafter. The correct pattern is to require a VPN first and reach remote desktop across it, so the exposed service is the VPN — designed to be exposed — rather than the desktop protocol.

Third-party remote support tools sidestep the forwarding problem by having both ends connect outward to a broker. That removes the inbound exposure and replaces it with trust in the vendor, which is a different decision rather than no decision.

Diagnosing a VPN that connects but carries nothing, which is a routing problem

This symptom is specific and the causes are few, which makes it a favourite scenario.

If the tunnel establishes, authentication succeeded and the path to the VPN endpoint works. So the fault is above that:

• Overlapping subnets. Both networks use the same range, so the client never routes anything into the tunnel. The most common cause by a distance.
• Routes not pushed. The client has a tunnel and no instruction about which destinations to send through it. Symptom: nothing internal is reachable, everything external is fine.
• Split tunnel excluding what the user wants. A narrower version of the same thing.
• Name resolution not updated. The tunnel carries traffic, but the client is still using its home resolver and cannot resolve internal names. Symptom: internal resources reachable by address and not by name — which is the same signature lesson 11 described, appearing in a new place.
• Firewall at the far end permitting the tunnel and not the traffic inside it.

The diagnostic order follows the same shape as every other connectivity problem: ping an internal address across the tunnel, then resolve an internal name, then reach the service. The step that fails names the layer, and the layer names the fix.