VPNs and Secure Remote Access

VPNs and Secure Remote Access

What you'll learn

• Explain tunneling — and retell the submarine analogy the course began with
• Contrast IPsec's AH and ESP, and its transport versus tunnel modes, including the NAT interaction the book teaches so well
• Tell the PPTP post-mortem as a dated timeline — and extract its three professional lessons
• Choose among today's stack: IKEv2/IPsec, TLS VPNs, WireGuard — and split versus full tunnel
• State the modern rules for RDP exposure without hesitation

The submarine, resurfaced

This lesson builds on Chapters 1 and 14 of Dr. Tahseen Al-Doori's Network Essentials — and begins by collecting a promise from the course's very first module. There, a classic analogy from Dr. Al-Doori's course pictured the Internet as an ocean: ordinary traffic crosses like ships on public shipping lanes, visible to anyone watching the water. But suppose the cargo is private and the crossing must not be observed. Then you want a submarine — a vessel that slips beneath the surface, invisible for the whole crossing, surfacing only at its destination. Only the two endpoints ever know the voyage happened.

A VPN (virtual private network) is that submarine, and tunneling is how it dives: take the packet you actually want to deliver and seal it inside another packet. The outer packet is addressed gateway-to-gateway and travels the public Internet like any other; the inner packet — your real traffic, with its real source and destination — rides encrypted inside, unreadable to every router, ISP and eavesdropper along the way. Observers see that something travels between two endpoints; what it is, and where it is ultimately bound inside the private networks, stays submerged. Add lesson 3's key agreement (to establish the encryption) and lesson 4's authentication (to control who may board), and you have the whole machine. The working parts, as the book lists them: a VPN server or gateway awaiting connections, client software (or a peer gateway), an Internet path between them, and a VPN protocol that defines the tunnel. Which protocol — that question is this lesson's drama.

Before tunnels: the dial-up ancestry

Remote access predates the VPN, and Chapter 14's catalog of that ancestry is worth keeping — partly as history, partly because one member refuses to die. In the dial-up era, a remote worker's modem called the office directly, answered by a remote access server (Microsoft's RRAS being the era's household name). The line protocols came in two generations: SLIP (obsolete) — Serial Line Internet Protocol, carrying IP over a serial line with no authentication and no encryption, a protocol from a more innocent Internet — and PPP (legacy — still worth knowing), the Point-to-Point Protocol, which added real link negotiation and authentication and became the chassis on which later tunneling was built. Its descendant PPPoE (PPP over Ethernet) is the survivor: your fiber or DSL router may well still authenticate to your ISP with it today. Dial-up remote access itself is history; you met its funeral in Module 6's WAN story.

The PPTP post-mortem: a security parable in four dates

Every field has its cautionary tale; this one is networking's, and it runs on the ciphers-age-one-way clock from lesson 3.

The rise. As the Internet replaced direct dial-in, tunneling arrived, and Microsoft's PPTP (Point-to-Point Tunneling Protocol) made VPNs genuinely easy: built into Windows, simple to configure — the book notes it needs only username/password and no certificate infrastructure — riding PPP inside a tunnel, with authentication by MS-CHAPv2. Its contemporary rival L2TP (associated with Cisco's lineage) offered better security and PKI support at the cost of more setup, typically paired with IPsec for its encryption. The book compares the two fairly for their day, and its era's guidance — the book passes it along dutifully — was that MS-CHAPv2 was the standard to reach for first on Windows. Period-correct advice; hold that thought.

1998 — the crack in the hull. Cryptanalysis by Bruce Schneier and the researcher Mudge tore into PPTP's authentication and encryption design, showing MS-CHAP's challenge-response construction leaked far more than intended and that the MPPE encryption was no better founded. Version 2 patched the worst; the same pair analyzed v2 in 1999 and concluded the fundamentals remained fragile. The submarine had a documented flaw in its pressure hull — published, peer-reviewed, public.

2012 — the hull fails. Researchers demonstrated that MS-CHAPv2's cryptography reduces, in the worst case, to breaking a single DES key — the same 56-bit problem lesson 3 watched fall in 1998 — and a cloud cracking service promptly offered to recover any captured MS-CHAPv2 handshake in about a day, flat rate. Not a theoretical weakness: a product. From that day, any recorded PPTP session was retroactively readable. The security community's guidance became unambiguous: PPTP is dead; migrate.

2024 — the burial. Microsoft — PPTP's own parent — deprecated both PPTP and L2TP for inbound connections in Windows Server 2025, steering the world to the modern stack. Deprecation is the industry's death certificate: issued, in this case, twenty-six years after the first published wound.

Three lessons, worth stating because you will reuse them your whole career. First: cryptographic breaks only widen — 1999's "fragile" became 2012's "cracked overnight as a service." Second: convenience is not a security property — PPTP's ease of setup was precisely why it lingered in small offices long after its breaking. Third: deprecation lags breakage by years or decades — so a professional tracks the research clock, not the vendor clock. The book's MS-CHAPv2 recommendation was right on its date; the date is the point. (MS-CHAPv2 itself lingers inside some enterprise Wi-Fi configurations even now — known-weak legacy; certificate-based EAP-TLS, lesson 4's strong end, is the current guidance.)

IPsec: the protocol suite that did it right

While PPTP sank, IPsec — the IP-layer security suite, specified for IPv4 and IPv6 alike since its original 1995 architecture — matured into the standard it remains. (You will often hear that IPsec is "built into IPv6" and bolted onto IPv4. It is a myth worth retiring: IPv6 once required nodes to implement IPsec, but RFC 6434 relaxed that to a recommendation in 2011, and IPv6 is no more encrypted by default than IPv4 is.) Two building blocks, straight from Chapter 14 with their jobs intact:

• AH (Authentication Header) provides integrity and authentication — proof the packet is unaltered and from the claimed sender — but no confidentiality: contents ride readable.
• ESP (Encapsulating Security Payload) provides encryption, plus authentication if desired — and is therefore what "IPsec VPN" means in practice. (Its ciphers have kept pace: the book's DES/3DES era gave way to AES per lesson 3.)

And two modes, whose difference the book teaches through a NAT question so good it deserves its full retelling. In transport mode, IPsec protects the payload end-host-to-end-host while the original IP header stays visible for routing. In tunnel mode, the entire original packet — header included — is encrypted and wrapped in a new outer packet, typically gateway-to-gateway. Now the book's question: what happens when encrypted traffic meets a NAT router — Module 4's address-rewriting middleman? NAT must read and rewrite addresses and ports; encryption exists to stop exactly that kind of meddling; in the wrong configuration the router simply cannot do its job. Tunnel mode is the elegant escape: the gateways encrypt between themselves, the outer header is theirs and public, and each site's private addressing — NAT included — carries on untouched inside. The trade the book honestly flags: within each site, between host and gateway, traffic travels unencrypted; the tunnel protects the crossing, not the harbors. (Modern IPsec also learned to slip through NAT when needed, wrapping itself in UDP — awareness level only.) Alongside ESP runs IKEv2, the suite's negotiator: it authenticates the endpoints and runs lesson 3's key agreement to establish the tunnel's keys, and its graceful handling of network changes — a phone hopping Wi-Fi to cellular without dropping the tunnel — is why it powers most built-in OS VPN clients.

Today's stack — and one old door to guard

The 2026 remote-access menu is short and healthy. IKEv2/IPsec (current): the standards-track choice, built into every major OS, mobility-friendly. TLS-based VPNs (current): OpenVPN and the many vendor "SSL VPN" gateways. OpenVPN's own default is UDP port 1194, but a TLS-based tunnel can be configured to run over TCP 443 — and vendor SSL-VPN portals usually do — which makes them the reliable choice on restrictive networks where only web ports are open (lesson 2 explained why everything migrated to 443). Note the limit: they slip past port-based filters, not past lesson 2's application-aware NGFWs, which can still identify a tunnel inside 443. WireGuard (current, the newest): a deliberately tiny protocol — a few thousand lines of code against the old suites' sprawling options — modern cryptography only, no negotiation of weaker choices possible, merged into the Linux kernel and prized for speed and auditability. Any of the three is a defensible default; none of them is PPTP. Two footnotes complete the menu. The consumer "privacy VPN" subscriptions advertised everywhere are the same tunneling technology pointed at a provider's exit servers — they shift your trust from the local network to the VPN company; they are not the corporate remote-access design this lesson builds. And at the ambitious end, zero trust (lesson 1's arc) is producing ZTNA — per-application access that verifies identity per request instead of admitting a device to a whole network; think of it as the VPN's least-privilege successor, arriving building by building.

Split versus full tunnel — the one deployment decision every VPN forces — in a paragraph: a full tunnel sends all the client's traffic through the office — every packet inspected by corporate defenses and shielded from the local café network, at the price of bandwidth and latency for every video call; a split tunnel routes only corporate destinations through the tunnel and lets ordinary browsing go direct — fast and cheap, but the direct traffic forgoes the office's protections and its visibility. Neither is "correct": it is policy — lesson 1's word — decided by what threats you are defending against.

One relative of the VPN needs its own warning label. RDP (Remote Desktop Protocol) — Chapter 14 covers it alongside Citrix's ICA — is remote control, not tunneling: your keystrokes travel up, screen images travel back, and the data never leaves the server, which is genuinely useful (the book's point) and still true. The modern reality the book could not know: RDP exposed directly to the Internet became one of the most-scanned, most-breached doors in computing — a favorite entry point for the ransomware you will meet next lesson, via password-guessing at scale and credential reuse. The 2026 rules are short: never naked on the Internet — reachable only through a VPN or gateway; NLA on (network-level authentication: prove identity before a session starts); MFA on the accounts (lesson 4); patched, rate-limited, logged. RDP through a tunnel is a fine tool; RDP as the front door is a breach schedule.

From the textbook to 2026

Chapter 14's conceptual spine — tunneling, the VPN's working parts, AH versus ESP, transport versus tunnel mode, the NAT insight — transfers whole; it is the protocol roster that turned over completely. SLIP and dial-up RRAS: history. PPTP: from recommended to broken to deprecated, per the timeline above — and L2TP inbound retired with it in 2024. MS-CHAPv2: known-weak legacy, EAP-TLS current. The living stack: IKEv2/IPsec, TLS VPNs, WireGuard, with ZTNA growing alongside and RDP surviving under strict house rules. The book's submarine, meanwhile, sails on untouched — the analogy outlived every protocol it first described.

Case study: Three companies, three remote-access designs

Real design work means matching the stack to the organization — there is no single right VPN, only right reasoning. Analyze each profile, commit to a design, then compare against the model answers.

Objective. For each company: choose the remote-access technology (and site-to-site arrangement where relevant), the authentication design, the tunnel policy (split/full), and the RDP stance — with a one-sentence justification each, plus the single biggest risk your design still leaves open.

Setup. Paper or a document; this lesson plus lessons 3 and 4 at hand. No lab equipment — this is judgment practice, the kind interviews probe.

Profile A — Alder Accounting. Eight staff, one office, one file server. Everyone works from home two days a week on company laptops. No in-house IT; a contractor visits monthly. Budget: modest. Current setup: the office router is a small-business firewall with built-in VPN support; the contractor has mentioned "the Windows server still has PPTP enabled from years ago."

Profile B — Crosstown Logistics. 120 staff across three depots, each with its own subnet and local server. Thirty drivers carry tablets on cellular networks that switch towers and networks all day. Depots need permanent secure links to each other; drivers need reliable access to the dispatch application. There is a two-person IT team and a RADIUS server already running for depot Wi-Fi.

Profile C — Lakeside Clinic. Forty staff handling patient records under strict confidentiality regulation. Most work on site; a dozen clinicians need remote access to the records system — and only to it. Two external billing contractors need access to one application for a six-month engagement. The clinic suffered a phishing incident last year; management wants phishing-resistant authentication and full audit trails.

Deliverable. Three short designs (five lines each: technology · authentication · tunnel policy · RDP stance · residual risk).

Model answers (compare, then improve yours).

Alder: Use the firewall's built-in IKEv2/IPsec (or WireGuard, if supported) for the eight laptops — built-in OS clients mean no per-seat software for a company with no IT. Authentication: per-user credentials plus MFA (TOTP at minimum, passkeys where the firewall's portal supports them). Split tunnel scoped to the office subnet only — eight home connections should not haul Netflix through one small-business uplink. RDP to the server: VPN-only, NLA on. And the first action item precedes all of this: disable PPTP today — a broken protocol enabled is an open door, whether or not anyone remembers it. Residual risk: home-laptop hygiene — mitigated by patching policy and the module's endpoint baseline, next lesson.

Crosstown: Two designs in one. Depot-to-depot: site-to-site IPsec tunnels in tunnel mode between the three firewalls — the classic gateway-to-gateway case, preserving each depot's internal addressing exactly as the NAT discussion taught. Drivers: IKEv2 mobile VPN — its survival across network changes is the feature the tablets' tower-hopping demands — authenticating via the existing RADIUS back office (lesson 4), with device certificates (EAP-TLS) rather than passwords typed on a truck's dashboard. Full tunnel for the tablets: they live on untrusted cellular and public Wi-Fi, so corporate inspection earns its latency. RDP: internal administration only, via the tunnels. Residual risk: a stolen tablet holds a valid certificate — mitigated by device screen locks, revocation procedures, and accounting logs that would show a tablet behaving out of pattern.

Lakeside: The clinicians get a full-tunnel VPN (IKEv2 or TLS-based) with passkey/FIDO2 authentication — phishing-resistant by construction, which is precisely the lesson of last year's incident — and access scoped by lesson 4's RBAC to the records system only. The billing contractors are the textbook ZTNA case: per-application access to exactly one system, expiring with the engagement — admitting contractor laptops to the clinic network with a general VPN would violate least privilege on day one. RDP: not exposed, period; clinicians reach applications, not desktops. Everything logged — accounting is a regulatory requirement here, not just good practice. Residual risk: the records application itself becomes the concentrated target — mitigated by patching, monitoring, and the segmentation this module has preached since lesson 1.

Self-check. Across your three designs: did every remote connection require MFA or better? Did anything face the raw Internet that could have sat behind a tunnel? Did the tunnel policy (split/full) follow from where the clients live rather than habit? Those three questions are the reviewer's checklist for any remote-access design.

Check yourself

1. Retell the submarine analogy in three sentences — naming what the ocean, the surface ships, and the submarine each correspond to — then state what tunneling adds that encryption alone does not.
2. A partner asks why the site-to-site link between two offices runs tunnel mode instead of transport mode, "since transport encrypts end to end." Answer with the NAT interaction — and name the honest trade tunnel mode makes.
3. Put these in date order and state each one's significance: Microsoft deprecates PPTP and inbound L2TP · cryptanalysis shows MS-CHAPv2 reduces to a single-DES search, cracked as a service · Schneier and Mudge publish their PPTP analysis. What is the professional moral of the gaps between the dates?
4. Choose from the current stack, one line of reasoning each: a startup wants the smallest, fastest, most auditable tunnel between two Linux cloud servers · a hotel's guest network blocks everything except web ports, and a traveling consultant must reach the office · a fleet of phones must hold a tunnel while hopping between Wi-Fi and cellular.
5. An MSP finds a client's file server reachable by RDP from the Internet, "because the owner works from home." List the modern rules being violated, in order of urgency, and the two-step fix that preserves the owner's workflow.
6. Your company debates split versus full tunnel for one hundred home workers. Give one strong argument each way, then name the lesson-1 concept that decides it.

Answers

1. The Internet is the ocean; ordinary traffic crosses it like surface ships, visible to any observer; a VPN is the submarine — only the endpoints know the voyage. Tunneling adds encapsulation: the real packet, addresses and all, rides sealed inside an outer packet, so observers learn nothing about the true endpoints or contents — encryption alone would scramble the cargo but leave the manifest readable.
2. Transport mode leaves the original header visible but protects the payload end to end — yet the sites' NAT routers must rewrite addresses, and what they need to touch, site-internal encryption choices can break; more to the point, tunnel mode lets the gateways encrypt gateway-to-gateway, wrapping the entire original packet so each site's private addressing and NAT continue untouched inside. The trade: between each host and its gateway, inside the site, traffic is unencrypted — the tunnel protects the crossing, not the harbors.
3. Schneier and Mudge's analysis (1998, with the MS-CHAPv2 follow-up in 1999) — the flaw documented; the single-DES reduction and cracking service (2012) — the flaw industrialized, any captured handshake readable in about a day; Microsoft's deprecation of PPTP and inbound L2TP (2024) — the vendor death certificate. Moral: breaks only widen, and deprecation lags breakage by decades — track the research clock, not the vendor clock.
4. WireGuard — minimal code, modern ciphers only, kernel-fast: built for exactly that server pair. A TLS-based VPN — it dresses as ordinary HTTPS on 443, the one door hotel firewalls leave open (lesson 2's story, exploited for good). IKEv2 — its mobility handling keeps the tunnel alive across network changes without re-authentication theater.
5. Violated: never-naked-on-the-Internet (most urgent — this is a scanned, brute-forced door and a known ransomware entry), MFA on the accounts, and likely NLA and lockout/rate-limiting besides. Fix: put RDP behind the firewall's VPN (IKEv2/WireGuard with MFA), then have the owner connect to the VPN first and RDP second — same desktop, one extra click, entire attack surface withdrawn from the Internet.
6. Full: every packet from an untrusted home network gets corporate inspection and protection — one policy, no gaps. Split: only corporate traffic burdens the office uplink; personal traffic stays personal and fast. The decider is lesson 1's word — policy: what threats the organization is defending against, and who is accountable — not a universal technical winner.

Key terms

• VPN / tunneling — a protected path across a public network; sealing the real packet inside an outer one, encrypted — the submarine, engineered.
• SLIP / PPP / PPPoE / RRAS — the dial-up ancestry: no-security serial IP (obsolete); the authenticated link chassis (legacy); its Ethernet descendant still authenticating broadband; the era's remote-access server.
• PPTP — Microsoft's easy early tunnel (obsolete — broken): analyzed 1998 (MS-CHAPv2 in 1999), cracked-as-a-service 2012, deprecated with inbound L2TP 2024.
• MS-CHAPv2 — the era's recommended authentication, now known-weak legacy; EAP-TLS is current guidance.
• L2TP — PPTP's more secure contemporary, PKI-capable, usually paired with IPsec; inbound deprecated by Microsoft in 2024.
• IPsec / AH / ESP — the IP-layer security suite: integrity-only header vs. encrypting payload — ESP is the VPN workhorse.
• Transport / tunnel mode — payload protection host-to-host with visible headers vs. whole-packet wrapping gateway-to-gateway. Tunnel mode between two public gateways keeps each site's private addressing intact inside the tunnel; a client sitting behind NAT needs NAT-Traversal (ESP wrapped in UDP 4500) whichever mode it uses. AH cannot traverse NAT at all — its integrity check covers the very IP addresses NAT must rewrite, one more reason ESP is what "IPsec VPN" means in practice.
• IKEv2 — IPsec's negotiator: authenticates endpoints, agrees keys, survives network changes; the built-in-client standard (current).
• TLS VPN — tunnels carried as HTTPS on 443; firewall-friendly by design (current).
• WireGuard — the minimal, modern-crypto-only tunnel in the Linux kernel; small enough to audit (current).
• ZTNA — zero-trust network access: per-application, per-request access; the VPN's least-privilege successor, arriving.
• Split / full tunnel — corporate-only versus all traffic through the tunnel; a policy decision, not a technical default.
• RDP / NLA — remote control (screen and keystrokes travel, data stays); network-level authentication before session start — and never exposed naked to the Internet.

Summary

• Tunneling seals the real packet inside an outer, encrypted one — the book's submarine analogy, still the clearest picture of a VPN ever drawn.
• The dial-up ancestry (SLIP, PPP, RRAS) is history, with PPPoE the working survivor; know the lineage, deploy none of it for security.
• The PPTP parable, in dates: recommended in its era, wounded by cryptanalysis in 1998, cracked as a service in 2012, deprecated by its maker (with inbound L2TP) in 2024 — breaks widen, convenience lingers, deprecation lags.
• IPsec's grammar: AH authenticates, ESP encrypts; transport protects payloads host-to-host, tunnel mode wraps whole packets gateway-to-gateway — which is why it and NAT coexist, at the honest price of cleartext inside each site.
• The current stack is short: IKEv2/IPsec, TLS VPNs, WireGuard — with ZTNA as the least-privilege horizon and MFA assumed everywhere.
• Split versus full tunnel is policy, not preference: decide by where clients live and what you must inspect.
• RDP is a fine tool behind a tunnel and a breach schedule in front of one: VPN-only, NLA, MFA, patched, logged.

Next lesson

The module closes with the enemy's catalog: the classic malware taxonomy the book teaches — virus, worm, trojan, spyware — and the modern additions it never saw coming, above all the ransomware economy that now dominates the breach statistics. Plus the defense baseline that stops most of it, assembled from every lesson in this module.

Sources and further study

• Al-Doori, T., Network Essentials, Chapters 1 and 14 — the submarine analogy, remote-access protocols, PPTP/L2TP comparison, IPsec modes and the NAT insight, RDP/ICA.
• Microsoft, "Features removed or deprecated in Windows Server 2025" — https://learn.microsoft.com/en-us/windows-server/get-started/removed-deprecated-features-windows-server-2025 — the 2024 death certificate for PPTP and inbound L2TP.
• WireGuard — https://www.wireguard.com/ — the protocol's design paper and documentation; a rare readable spec.
• Cloudflare Learning Center, "What is a VPN?" — https://www.cloudflare.com/learning/access-management/what-is-a-vpn/ — a current plain-language overview to compare against this lesson.