COMP 6660 · Enterprise Cybersecurity Virtual Private Networks

00 Introduction

Lesson 4.3 examined the network security protocols that protect enterprise traffic — TLS, IPsec, SSH, and DNSSEC. This lesson examines the specific application of those protocols through which enterprises extend their networks across public infrastructure: virtual private networks.

VPNs have been the primary mechanism through which enterprises connect distributed sites, remote users, and — increasingly — cloud environments for three decades. They are built on the protocols examined in Lesson 4.3 — primarily IPsec for site-to-site connectivity and TLS for remote access — and they provide the network-level connectivity that enterprises rely on for distributed operations.

The role of VPNs in enterprise architecture is changing. As the perimeter model that VPNs originally supported has dissolved — as workloads have moved to the cloud, as users have worked from anywhere, as third-party services have proliferated — the assumptions on which traditional VPN architectures rest have become increasingly strained. VPNs remain essential for some use cases — site-to-site connectivity, cloud connectivity — but they no longer serve as the primary remote-access mechanism for many enterprises, having been superseded by zero-trust access approaches.

This lesson examines VPNs in detail. It defines what they are and what they provide. It examines the two principal categories — site-to-site and remote-access VPNs — their purposes and their architectures. It examines the technologies underlying VPNs — IPsec, SSL/TLS, WireGuard — and their characteristics. It examines tunnel design, split tunneling versus full tunneling, and the security limitations of VPN architectures. It examines the shift to zero-trust access and what it means for VPN use cases. And it closes with enterprise architecture considerations and the pitfalls that recur across organisations.

01 Learning objectives

By the end of this lesson you should be able to:

These objectives contribute to Unit 4 outcomes U4.1 (architecture design) and U4.3 (control recommendation), and to Module 2 outcomes M2.5 and M2.7. See the Unit 4 learning outcomes page for the full mapping.

02 What VPNs are

VPNs solve a specific problem: how to communicate securely over an untrusted network. Rather than relying on private leased lines or physically controlled infrastructure, enterprises use VPNs to create a logical private network on top of the public internet — exploiting the ubiquity and affordability of internet connectivity while obtaining the security properties that would otherwise require private infrastructure.

What VPNs provide

• Confidentiality. Traffic within the tunnel is encrypted, protecting it from interception.
• Integrity. Traffic is protected against modification in transit.
• Authenticity. The endpoints of the tunnel authenticate each other, providing assurance of the parties' identity.
• Network extension. The tunnel extends the private network — the endpoints appear to each other as though they were on the same network.
• Address translation. Traffic within the tunnel can use private IP addresses, regardless of the public addresses at the endpoints.

What VPNs do not provide

VPNs are frequently described as though they provided comprehensive security. They do not. Clarifying what they do not provide helps:

• Not protection from all attacks. VPNs protect traffic in transit. They do not protect against attacks that originate inside the tunnel — from a compromised endpoint, from malware, from a legitimate user acting maliciously.
• Not authentication of every user. A VPN authenticates the endpoints of the tunnel — not necessarily every user who sends traffic through it. An enterprise VPN may authenticate the endpoint (a device or a site gateway) without verifying the identity of each user.
• Not authorization. VPNs establish connectivity. They do not by themselves determine what the connected party is authorized to access; that requires additional controls.
• Not a substitute for application security. An application vulnerability is exploitable regardless of whether the attacker connects through a VPN.
• Not a substitute for network segmentation. A VPN typically provides broad network access to whoever is on the tunnel. It does not provide the fine-grained segmentation that limits lateral movement.

Why VPNs have been the default

VPNs became the default mechanism for extending enterprise networks because they solved a real problem — connecting distributed sites and remote users — in a way that was technically feasible, operationally manageable, and compatible with the perimeter-based security model. When the perimeter was the primary control, VPNs extended the perimeter to include remote users and remote sites — bringing them "inside" the network, where the perimeter-based controls could apply.

As the perimeter has dissolved, the assumptions on which traditional VPN architectures rest have become increasingly strained. But VPNs continue to serve important functions — particularly for site-to-site connectivity and cloud connectivity — and the technologies underlying them remain essential to enterprise architecture.

03 Site-to-site VPNs

Site-to-site VPNs connect two or more networks — sites, data centres, cloud environments — across a public network. The endpoints are network gateways rather than individual devices or users, and the tunnel connects the networks as though they were on the same local infrastructure.

Characteristics of site-to-site VPNs

• Gateway-based. The endpoints are network devices — routers, firewalls, or dedicated VPN gateways — rather than individual devices or users.
• Persistent. The tunnels are typically established and maintained continuously, rather than on demand.
• Transparent to endpoints. Users and systems at each site do not typically interact with the VPN directly; the tunnel is established and managed by the gateway.
• Broad connectivity. The tunnel provides network connectivity between the sites — subject to whatever routing and filtering the gateways apply.
• Static or dynamic addressing. Site-to-site VPNs may use static IP addresses (requiring fixed endpoints) or dynamic addressing (accommodating dynamic endpoints, common in cloud environments).

Common uses of site-to-site VPNs

Site-to-site VPN architecture considerations

Designing site-to-site VPNs involves several considerations:

• Routing. The VPN gateways must route traffic between the connected networks. Routing can be static (manually configured) or dynamic (through routing protocols such as BGP). Dynamic routing is more complex but more resilient to change.
• Addressing. The connected networks must have compatible (typically non-overlapping) address spaces. Overlapping address spaces require Network Address Translation (NAT) at the gateways.
• Redundancy. A single tunnel is a single point of failure. High-availability site-to-site VPNs use redundant tunnels — multiple gateways, multiple paths, or multiple providers.
• Bandwidth and performance. Site-to-site tunnels carry aggregate traffic between networks. Bandwidth provisioning, quality of service, and performance monitoring are essential for critical connections.
• Security policy. Site-to-site tunnels provide broad connectivity; the enterprise must apply security policy to determine what traffic is permitted. Often, the tunnel is combined with firewalls at the endpoints to filter traffic.
• Authentication. Site-to-site tunnels are typically authenticated through pre-shared keys or certificates. Certificates are preferred for their manageability at scale.

04 Remote-access VPNs

Remote-access VPNs connect individual users — employees, contractors, administrators — to the enterprise network from remote locations. The endpoint on the user's side is typically a device (laptop, mobile device) running VPN client software, and the endpoint on the enterprise side is a VPN concentrator or gateway.

Characteristics of remote-access VPNs

• Client-based. The user's device runs VPN client software that establishes the tunnel to the enterprise.
• On demand. Tunnels are typically established when the user connects and terminated when the session ends, rather than being persistent.
• User-level authentication. Remote-access VPNs typically authenticate the user — through passwords, tokens, certificates, or multi-factor authentication — as well as the device.
• Broad network access. Once connected, the user typically has access to the enterprise network as though they were on the local network — subject to whatever controls apply.
• Scalable to many users. Remote-access VPNs are designed to handle thousands of concurrent users, with concentrators providing the aggregation point.

Remote-access VPN architecture considerations

• Concentrator capacity. The VPN concentrator must handle the expected number of concurrent sessions, the expected bandwidth, and the encryption overhead. Capacity planning is essential.
• Authentication. Remote-access VPNs should use strong authentication — multi-factor authentication at minimum, phishing-resistant authentication where feasible. The VPN is a frequent target of credential attacks.
• Device posture. Modern remote-access VPNs frequently check device posture before granting access — whether the device is managed, whether it is patched, whether endpoint protection is running.
• Access policy. The VPN grants network access; the enterprise must define what the connected user can access. Access controls at the application and data layers are essential.
• Session management. Session timeouts, re-authentication requirements, and session termination policies determine the duration and conditions of access.
• Monitoring. VPN activity — successful and failed authentication, session duration, data volumes — should be logged and monitored.

The changing role of remote-access VPNs

Remote-access VPNs have been the primary mechanism through which enterprises supported remote work for decades. Their role is changing, for several reasons:

• Cloud adoption. As applications move to cloud services, users do not need to connect to the enterprise network to access them. The VPN becomes an unnecessary detour — the user could access the cloud service directly, with identity-based controls providing security.
• Zero-trust architecture. Zero Trust (Module 1, Lesson 2.7) replaces the perimeter-based access model with identity-based access. Rather than connecting to the enterprise network and being trusted by virtue of that connection, users access applications directly and are authorized by identity, device, and context.
• Scalability. During the shift to remote work in 2020, many enterprises discovered that their remote-access VPNs could not scale to the increased number of concurrent users. This drove adoption of alternatives.
• User experience. VPN clients add friction — connection delays, client software management, occasional connectivity issues. Zero-trust access typically provides a better user experience.
• Security. Broad network access via VPN provides more access than most users need. Zero-trust access provides narrower, identity-based access that reduces the consequence of any single compromise.

For these reasons, many enterprises are reducing their reliance on remote-access VPNs in favour of zero-trust access approaches, examined further in Section 8. Remote-access VPNs remain appropriate for some use cases — administrative access, access to legacy systems, specific regulatory contexts — but they are no longer the default mechanism for general remote work.

05 VPN technologies

VPNs are implemented through several technologies, each with different characteristics, use cases, and configuration considerations. The three principal families are IPsec, SSL/TLS, and WireGuard.

IPsec VPNs

IPsec VPNs use the IPsec protocol suite (Lesson 4.3) to establish tunnels between endpoints. They operate at the network layer and protect all traffic between the endpoints, regardless of application.

• Strengths. Network-layer protection, independent of applications; mature and widely deployed; well-suited to site-to-site connectivity.
• Weaknesses. Complex configuration; interoperability challenges between implementations; NAT traversal issues; the tunnel hides traffic from inspection.
• Typical use. Site-to-site VPNs; cloud connectivity; some remote-access deployments.

SSL/TLS VPNs

SSL/TLS VPNs use TLS (Lesson 4.3) to establish tunnels between clients and VPN gateways. They typically provide access through a web browser (clientless) or through a lightweight client (client-based).

• Strengths. Simpler configuration than IPsec; traversal of firewalls and NAT straightforward (uses standard TLS ports); clientless options reduce client software management; well-suited to remote access.
• Weaknesses. Typically application-layer rather than network-layer protection; less well-suited to site-to-site connectivity; performance limitations for high-throughput use cases.
• Typical use. Remote-access VPNs; partner and supplier access; web-based access to internal applications.

SSL/TLS VPNs are further categorised as:

• Clientless SSL VPNs. Users connect through a web browser, accessing internal applications through a portal. Simpler for users (no client software) but typically limited in the applications and protocols supported.
• Client-based SSL VPNs. Users install a lightweight client that establishes the tunnel. More capable than clientless but requires client management.

WireGuard

WireGuard is a modern VPN protocol designed for simplicity, performance, and security. It has become increasingly popular since its introduction in 2016, and is now integrated into many operating systems and enterprise VPN products.

• Strengths. Simple design (a small codebase, easier to audit); modern cryptography (Curve25519, ChaCha20, BLAKE2); high performance; integrated into the Linux kernel and available for other platforms.
• Weaknesses. Less mature than IPsec; fewer enterprise features; less well-integrated with enterprise management and monitoring systems; still evolving.
• Typical use. Site-to-site connectivity; remote access in environments that support it; contexts where simplicity and performance matter.

Comparing VPN technologies

Other VPN technologies

Beyond the three principal families, several other technologies are used for specific VPN use cases:

• MPLS (Multiprotocol Label Switching). Provider-managed private networking; not strictly a VPN but often discussed in the same context. Provides private connectivity without encryption (encryption is added separately where required).
• SD-WAN (Software-Defined Wide Area Network). Modern WAN architecture that can incorporate VPN functionality, with application-aware routing and centralised policy.
• Zero-trust network access (ZTNA). Often described as the successor to remote-access VPNs; provides identity-based access to applications rather than network-level connectivity.
• Cloud provider connectivity services. Cloud providers offer managed connectivity services — AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect — that provide private connectivity to cloud environments without the complexity of self-managed VPN tunnels.

06 Tunnel design

A tunnel is the logical connection through which VPN traffic flows. Tunnel design determines how the tunnel is established, what it protects, and how it behaves under failure or attack.

Tunnel establishment

Tunnels are established through a negotiation between the endpoints:

• Authentication. The endpoints authenticate each other — through pre-shared keys, certificates, or other mechanisms.
• Parameter negotiation. The endpoints agree on the algorithms, keys, and parameters for the tunnel — encryption, integrity, key exchange, and lifetime.
• Key establishment. The endpoints establish the keys used to protect traffic through the tunnel.
• Tunnel establishment. The tunnel is established and begins carrying traffic.

Encapsulation

VPN tunnels work through encapsulation — the original packet is wrapped within a new packet that carries it through the tunnel. The encapsulated packet contains:

• The original packet. The traffic being protected — either encrypted or in a form that will be encrypted.
• Tunnel headers. The headers that identify the tunnel and carry the encapsulated packet across the public network.
• Protection information. Encryption, integrity, and authentication data.

At the far end of the tunnel, the packet is decapsulated — the tunnel headers are removed, the protection is verified, and the original packet is delivered to its destination.

Tunnel types

Tunnel security considerations

• Authentication strength. The tunnel is only as strong as the authentication of its endpoints. Pre-shared keys are weaker than certificates; shared keys across many endpoints are weaker still.
• Cryptographic parameters. The algorithms and key lengths used in the tunnel determine the protection. Modern algorithms and adequate key lengths are essential.
• Forward secrecy. Where the tunnel provides forward secrecy (PFS, ECDHE), compromise of a long-term key does not compromise past sessions.
• Tunnel lifetime. Tunnel lifetimes determine how often keys are re-established. Shorter lifetimes provide greater security at the cost of more frequent negotiation.
• Routing and filtering. The tunnel provides connectivity; the enterprise applies routing and filtering to determine what traffic is permitted. The tunnel is not a substitute for firewalling.
• Visibility. Encrypted tunnels hide traffic from inspection. Where inspection is required (for security monitoring or compliance), the enterprise must either decrypt at the tunnel endpoint or use compensating controls.

07 Split tunneling versus full tunneling

A fundamental design decision in remote-access VPNs is whether traffic is routed through the VPN tunnel or directly to the destination. The two approaches — split tunneling and full tunneling — have different security, performance, and operational characteristics.

Full tunneling

In full tunneling (also called forced tunneling), all of the user's traffic — whether destined for enterprise resources or the public internet — is routed through the VPN tunnel.

• Security benefits. All traffic is subject to the enterprise's security controls — firewalls, inspection, monitoring, data-loss prevention. The enterprise can enforce consistent policy.
• Visibility benefits. The enterprise can see all of the user's traffic, which is valuable for detection and compliance.
• Performance costs. All traffic travels through the VPN concentrator, adding latency and consuming bandwidth. Internet-bound traffic takes an indirect path.
• Concentrator load. The VPN concentrator must handle all of the user's traffic, including traffic that would otherwise go directly to the internet — increasing capacity requirements.
• User experience. Slower internet access, particularly for bandwidth-intensive applications.

Split tunneling

In split tunneling, only traffic destined for enterprise resources is routed through the VPN tunnel. Traffic destined for the public internet goes directly from the user's device.

• Performance benefits. Internet-bound traffic takes a direct path, improving performance and reducing the load on the VPN concentrator.
• Bandwidth savings. The enterprise's bandwidth for VPN traffic is reduced, since internet traffic does not traverse the tunnel.
• Security costs. Traffic that goes directly to the internet is not subject to the enterprise's controls — the enterprise loses visibility into the user's internet activity, and cannot enforce policy on it.
• Risk of exposure. A compromised device with split tunneling can be used as a bridge between the enterprise network and the internet — potentially allowing the adversary to pivot through the device.
• Policy complexity. The enterprise must define what traffic is routed through the tunnel and what is not — a policy that requires configuration and can be misconfigured.

The split tunneling trade-off

Selecting between them

The selection between full and split tunneling depends on the enterprise's priorities:

• Full tunneling is appropriate where security and visibility are the priority — where the enterprise needs to control and observe all of the user's traffic. Common in regulated industries, high-security environments, and contexts where data-loss prevention is critical.
• Split tunneling is appropriate where performance and scalability are the priority — where the enterprise wants to reduce the load on its VPN infrastructure and provide better user experience. Common in large user populations and contexts where the enterprise's internet-bound traffic is not the primary security concern.
• Split tunneling with selective routing is a hybrid approach — some categories of traffic (e.g., traffic to known-malicious destinations, traffic to cloud services that require inspection) is routed through the tunnel, while other traffic is not. This approach requires sophisticated policy but can balance the trade-offs.

As enterprises have adopted zero-trust access approaches, the split tunneling debate has become less central — because zero-trust access provides identity-based access to specific applications rather than network-level connectivity, the question of what traffic is routed through the tunnel becomes less relevant. The enterprise's security controls apply to the specific applications accessed, not to the network as a whole.

08 VPN security limitations

VPNs provide valuable security properties — confidentiality, integrity, and authenticity for traffic in transit. They also have significant limitations, and understanding them is essential to using VPNs appropriately.

Limitation 1 — Network-level trust

VPNs establish network-level connectivity. Once connected, the user typically has access to the enterprise network as though they were on the local network. This model assumes that being on the network implies trust — an assumption that is increasingly recognised as unsound.

Implication: VPNs are not a substitute for identity-based access control. The enterprise must apply controls at the application and data layers to limit what a connected user can access.

Limitation 2 — Compromised endpoints

A VPN protects traffic between endpoints; it does not protect against attacks that originate from a compromised endpoint. If the user's device is compromised, the adversary can use the VPN connection as though they were the user.

Implication: Device posture — whether the device is managed, patched, and free of malware — is essential to the security of VPN access. Modern VPN architectures check device posture before granting access.

Limitation 3 — Credential compromise

VPN authentication is only as strong as the credentials used. If the user's credentials are compromised — through phishing, credential theft, or reuse — the adversary can authenticate to the VPN as the user.

Implication: VPN authentication should include strong factors — multi-factor authentication at minimum, phishing-resistant authentication where feasible. The VPN is a frequent target of credential attacks precisely because compromise provides broad access.

Limitation 4 — Aggregation point

VPN concentrators are aggregation points — many users connect through a small number of concentrators. This makes them attractive targets; a compromise of a concentrator affects all of the users connected through it.

Implication: VPN concentrators warrant strong controls — hardened configuration, monitoring, and rapid patching for vulnerabilities. Concentrators that have been compromised are among the most serious incidents an enterprise can experience.

Limitation 5 — Traffic inspection blind spots

Encrypted VPN tunnels hide traffic from inspection. Where the enterprise requires inspection — for security monitoring, for data-loss prevention, for compliance — encryption interferes with the ability to provide it.

Implication: The enterprise must either decrypt traffic at the tunnel endpoint (which requires the endpoint to be trustworthy and the decryption to be managed securely) or accept the visibility limitations and compensate through other controls.

Limitation 6 — Lateral movement

A user connected through a VPN typically has broad access to the enterprise network. An adversary who compromises the user's connection — through credential theft or device compromise — can move laterally within the enterprise, exploiting the broad access the VPN provides.

Implication: Segmentation of the enterprise network (Lesson 4.5) limits lateral movement even when a VPN connection is compromised. Least privilege and identity-based access control reduce what a connected user can access.

Limitation 7 — Availability dependency

VPNs introduce a dependency — on the VPN concentrator, on the network path between the user and the concentrator, and on the authentication infrastructure. Failure of any of these components affects the user's ability to access enterprise resources.

Implication: VPN architectures should be designed for high availability — redundant concentrators, redundant network paths, and redundant authentication infrastructure. Failure modes should be planned for.

09 The shift to zero-trust access

The limitations of traditional VPN architectures have driven the shift to zero-trust access — a category of approaches that provide identity-based access to specific applications rather than network-level connectivity to the enterprise network. The shift is examined here as a complement to the VPN material, since it represents the direction of enterprise access architecture.

What zero-trust access provides

Zero-trust access approaches

Where VPNs remain appropriate

The shift to zero-trust access does not eliminate the need for VPNs. VPNs remain appropriate for several use cases:

• Site-to-site connectivity. VPNs remain the standard for connecting enterprise networks — offices, data centres, cloud environments. The application-level model of zero-trust access does not apply to network-level connectivity between sites.
• Cloud connectivity. IPsec tunnels between enterprise networks and cloud environments remain common, even where zero-trust access is used for user access.
• Administrative access. Some administrative access — to infrastructure, to legacy systems, to network devices — requires network-level access that zero-trust access does not provide. VPNs remain appropriate for these contexts.
• Legacy systems. Systems that cannot support the application-level access model of zero-trust access may require VPN access.
• Regulatory contexts. Some regulatory environments require specific access mechanisms — including VPNs — that zero-trust access approaches may not satisfy.

The result is that most enterprises operate a hybrid access architecture — zero-trust access for most user access to modern applications, VPNs for site-to-site connectivity and for the use cases that require network-level access. The two approaches coexist, each applied where it fits.

10 Enterprise VPN architecture

Designing enterprise VPN architecture involves several decisions — the use cases, the technologies, the topology, and the controls. This section brings the material of the lesson together into a practical architecture.

Architecture decisions

Architecture pattern

A common enterprise VPN architecture pattern combines several components:

11 Common pitfalls

Enterprise VPN programmes fail in predictable ways. Recognising the pitfalls accelerates improvement.

Pitfall 1 — Treating the VPN as a trust boundary

Assuming that traffic or users inside the VPN tunnel are trustworthy because they are inside. The VPN protects traffic in transit; it does not verify the trustworthiness of the parties or the traffic.

Mitigation: Apply identity-based controls and least privilege to VPN-connected users. Do not rely on network location as a basis for trust.

Pitfall 2 — Broad network access

Granting VPN users broad access to the enterprise network — typically with the assumption that they are trusted employees. Broad access expands the consequence of any compromise.

Mitigation: Apply least privilege to VPN access. Segment the network so that VPN users access only the systems they need.

Pitfall 3 — Weak VPN authentication

Using password-only or weak multi-factor authentication for VPN access. The VPN is a frequent target of credential attacks precisely because compromise provides broad access.

Mitigation: Require strong multi-factor authentication; prefer phishing-resistant authentication for high-value access.

Pitfall 4 — No device posture checks

Granting VPN access without checking device posture — whether the device is managed, patched, and free of malware. A compromised device can be used to attack the enterprise network through the VPN.

Mitigation: Check device posture before granting VPN access; deny or limit access for non-compliant devices.

Pitfall 5 — Unmanaged VPN concentrators

VPN concentrators that are not patched, not monitored, or not hardened — providing a high-value target for adversaries.

Mitigation: Apply strong configuration to VPN concentrators; patch promptly for vulnerabilities; monitor for anomalies.

Pitfall 6 — Inconsistent policy between VPN and zero-trust

Where the enterprise operates both VPN and zero-trust access, applying inconsistent policy — with different authentication requirements, different access controls, different monitoring — producing inconsistency and potential gaps.

Mitigation: Align policy across access mechanisms. Apply consistent authentication, authorization, and monitoring regardless of the mechanism used.

Pitfall 7 — No monitoring of VPN activity

Logging VPN connections but not monitoring the activity within them. Anomalies — unusual access patterns, unusual data volumes, unusual times — go undetected.

Mitigation: Monitor VPN activity as part of the enterprise's security monitoring. Detect anomalies and investigate them.

Pitfall 8 — No migration strategy from VPN to zero-trust

Continuing to operate a traditional remote-access VPN without a strategy for migrating to zero-trust access — accumulating technical debt and missing the security benefits of the newer approach.

Mitigation: Develop a strategy for migrating user access to zero-trust where appropriate, and for retaining VPN only where it is needed. Treat the transition as an architecture programme, not an infrastructure replacement.

12 Key concepts

The terms below are used throughout Unit 4. Capture them in your own words as you work through the lesson.

Virtual private network (VPN)

A mechanism for extending a private network across a public network — typically the internet — by establishing an encrypted tunnel between two endpoints.

Tunnel

The logical connection through which VPN traffic flows — established through negotiation between endpoints, protecting traffic through encapsulation and encryption.

Encapsulation

The wrapping of an original packet within a new packet that carries it through the tunnel. The encapsulated packet contains the original packet, tunnel headers, and protection information.

Site-to-site VPN

A VPN connecting two or more networks — sites, data centres, cloud environments. The endpoints are network gateways; the tunnel provides network-level connectivity between the sites.

Remote-access VPN

A VPN connecting individual users to the enterprise network from remote locations. The user's device runs VPN client software; the tunnel provides network-level access to the enterprise.

IPsec VPN

A VPN using the IPsec protocol suite. Operates at the network layer; protects all traffic between endpoints. Well-suited to site-to-site connectivity.

SSL/TLS VPN

A VPN using TLS. Typically provides remote access through a web browser (clientless) or a lightweight client. Well-suited to remote access.

WireGuard

A modern VPN protocol designed for simplicity, performance, and security. Integrated into many operating systems and enterprise VPN products.

Full tunneling

A VPN configuration in which all of the user's traffic is routed through the tunnel — providing comprehensive security control and visibility at the cost of performance.

Split tunneling

A VPN configuration in which only traffic destined for enterprise resources is routed through the tunnel; internet traffic goes directly. Provides better performance at the cost of security control and visibility.

Hub-and-spoke

A VPN topology in which multiple remote sites connect to a central hub. Simple to manage; the hub is a single point of failure and a bottleneck.

Full mesh

A VPN topology in which every site connects to every other site. Resilient but complex to manage; scalability limits.

Dynamic multipoint

A VPN topology in which tunnels are established on demand between sites. Combines the manageability of hub-and-spoke with the performance of full mesh.

VPN concentrator

The endpoint in the enterprise that terminates remote-access VPN connections. A high-value target; warrants strong controls.

Zero-trust network access (ZTNA)

A category of approaches that provide identity-based access to specific applications rather than network-level connectivity. The successor to remote-access VPNs for most user access.

Software-defined perimeter (SDP)

A zero-trust access approach in which resources are hidden from unauthorised subjects; access is brokered through a controller that establishes connections only when policy allows.

Secure Access Service Edge (SASE)

A cloud-delivered architecture that combines networking and security services — including zero-trust access, secure web gateway, and cloud access security broker — providing consistent policy regardless of user location.

13 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 2. They are not graded, but completing them will substantially improve your preparation.

14 Self-check

Answer the questions below before moving to Lesson 4.5. If you cannot answer a question confidently, revisit the corresponding section.

15 Summary

This lesson has examined virtual private networks — the mechanisms through which enterprises extend their networks across public infrastructure. The essential points are:

• VPNs extend a private network across a public one by establishing an encrypted tunnel between two endpoints. They provide confidentiality, integrity, authenticity, and network-level connectivity — but not comprehensive security, application-level access control, or identity-based access.
• Site-to-site VPNs connect networks through gateway devices. Used for office-to-office connectivity, data-centre-to-data-centre connectivity, and cloud connectivity. Design considerations include routing, addressing, redundancy, and performance.
• Remote-access VPNs connect individual users through client software. Have been the primary mechanism for remote work for decades; their role is changing as zero-trust access becomes preferred for most user access.
• VPN technologies include IPsec, SSL/TLS, and WireGuard. IPsec for network-layer connectivity; SSL/TLS for remote access; WireGuard for simplicity and performance. Match the technology to the use case.
• Tunnel design determines how VPNs protect traffic. Authentication, parameter negotiation, encapsulation, and tunnel topology determine what the tunnel protects and how it behaves.
• Split tunneling versus full tunneling is a fundamental design decision. Full tunneling provides comprehensive control and visibility; split tunneling provides better performance and less concentrator load. The choice depends on the enterprise's priorities.
• VPNs have significant security limitations. Network-level trust; compromised endpoints; credential compromise; aggregation points; traffic inspection blind spots; lateral movement; availability dependency.
• The shift to zero-trust access is underway. Zero-trust access provides identity-based access to specific applications rather than network-level access — reducing the consequence of any single compromise and providing better user experience.
• VPNs remain appropriate for specific use cases — site-to-site connectivity, cloud connectivity, administrative access, and legacy systems — in a hybrid access architecture alongside zero-trust access.
• Common pitfalls recur. Treating the VPN as a trust boundary; broad network access; weak authentication; no device posture checks; unmanaged concentrators; inconsistent policy; no monitoring; no migration strategy.

These ideas prepare for Lesson 4.5, which examines firewalls and segmentation — the controls that determine what traffic is permitted within the enterprise network and that limit the lateral movement on which VPN-based attacks depend.