Virtual Private Networks and Remote Connectivity

Introduction and Context

Remote connectivity allows users, offices, cloud services, and business partners to communicate across networks that the organisation does not fully control. The public Internet provides reach and flexibility, but it also introduces risks: traffic interception, identity theft, unauthorised access, malware propagation, insecure devices, and loss of visibility. A virtual private network (VPN) creates a protected logical connection over an underlying network, commonly the Internet.

A VPN does not make an organisation automatically secure. It supplies selected security properties—such as confidentiality, integrity, authentication, and access control—only when its protocols, endpoints, identities, and operational controls are correctly designed. Modern organisations increasingly combine traditional VPNs with zero-trust network access (ZTNA), identity-aware proxies, endpoint management, and software-defined perimeter technologies.

This chapter compares site-to-site and remote-access VPNs, explains tunnelling and major VPN protocol families, and develops a practical method for planning secure remote work connectivity. The central design problem is not simply “how to encrypt traffic,” but how to balance security, usability, performance, resilience, cost, and governance.

Learning Objectives

By the end of this chapter, a learner should be able to:

• distinguish site-to-site VPNs from remote-access VPNs;
• explain encapsulation, tunnelling, encryption, authentication, and key management;
• compare IPsec VPNs, TLS VPNs, and modern software-defined access;
• identify major performance and operational factors affecting VPNs;
• plan a secure remote-work connectivity design based on risk and business requirements;
• evaluate usability, endpoint posture, access scope, logging, and incident response; and
• recognise legal, ethical, and governance responsibilities associated with remote access.

1. VPN Foundations

1.1 What a VPN provides

A VPN is a system that creates a logical communication path between endpoints across another network. The protected path is often called a tunnel, although the tunnel is implemented through encapsulation and cryptographic processing rather than a separate physical cable.

A well-designed VPN may provide:

• Confidentiality: unauthorised observers should not be able to read protected content.
• Integrity: modifications should be detected.
• Peer authentication: each endpoint should establish that the other endpoint is trusted.
• Access control: authenticated users or systems should reach only authorised resources.
• Replay protection: captured valid messages should not be accepted again inappropriately.
• Availability: legitimate users should be able to connect when required.

These properties are distinct. Encryption can provide confidentiality, but it does not by itself establish that a user is authorised. A VPN gateway may authenticate a device while the device itself is infected. Consequently, VPN security must be treated as a system of controls rather than a single product feature.

1.2 Important terminology

A VPN endpoint is a device or software component that participates in a VPN. A VPN gateway terminates tunnels and commonly enforces policy. A client is software used by an individual device to connect. Encapsulation places one packet inside another packet. Decapsulation removes the outer wrapper at the receiving endpoint. A tunnel is the logical path created by this process.

A full-tunnel configuration sends most or all client traffic through the organisation’s VPN gateway. A split-tunnel configuration sends only selected organisational traffic through the VPN while other traffic uses the local Internet connection. Full tunnelling improves central inspection and policy consistency, but may increase bandwidth demand and latency. Split tunnelling can improve performance and reduce gateway load, but may expose corporate sessions to untrusted local networks and reduce monitoring visibility.

A security association (SA) is a set of negotiated parameters describing how protected traffic is handled. These parameters can include algorithms, keys, lifetimes, peer identities, and traffic selectors. Traffic selectors specify which addresses, protocols, or ports are permitted through a tunnel.

2. VPN Deployment Models

2.1 Site-to-site VPNs

A site-to-site VPN connects networks rather than individual users. Usually, a gateway at one office establishes a tunnel to a gateway at another office, data centre, cloud network, or partner environment. Internal hosts may communicate without running VPN software themselves.

For example, a company may connect its headquarters to a regional office using an IPsec tunnel. A packet travelling from a headquarters subnet to a regional subnet is encrypted at the headquarters gateway, transported across the Internet, and decrypted at the regional gateway.

Site-to-site VPNs are appropriate when:

• many users at each location require access;
• the connected networks are relatively stable;
• routing between sites is predictable; and
• centralised gateway management is preferable to installing clients on every host.

Their limitations include broad network exposure, complex routing, dependence on gateway availability, and the possibility that a compromised device at one site can attack systems at another. Network segmentation and restrictive traffic selectors are therefore essential.

2.2 Remote-access VPNs

A remote-access VPN connects an individual user device to an organisation’s network or applications. The user normally authenticates through a client application or web portal. Access may be granted to a broad internal network, a defined application set, or a single service.

Remote-access VPNs support home workers, travelling employees, administrators, contractors, and emergency access. Their security depends heavily on endpoint condition and user identity. A stolen password, unmanaged personal computer, outdated VPN client, or infected endpoint can undermine an otherwise strong gateway.

2.3 Comparison

A hybrid architecture is common: site-to-site VPNs connect stable infrastructure, while remote users access applications through remote-access VPN or identity-aware services.

3. Tunnelling and Cryptographic Operation

3.1 Encapsulation

Suppose an internal packet has an original header and payload. A VPN endpoint can encrypt the original packet and place it within a new outer packet. The outer packet contains addressing information needed to cross the public network. At the destination, the receiving endpoint verifies, decrypts, and forwards the original packet.

In tunnel mode, the original IP packet is protected and a new outer IP header is added. This is widely used for gateway-to-gateway VPNs. In transport mode, the original IP header remains visible while the payload is protected; this is more common for host-to-host protection and some specialised deployments.

A simplified overhead relationship is:

Here, L_inner is the original packet length, H_VPN is the VPN protocol overhead, H_outer is the new outer-header overhead, and L_outer is the resulting transmitted packet length. All quantities are measured in bytes. The relationship is an approximation because padding, authentication tags, alignment, and optional headers may change the exact value. Larger overhead reduces the effective payload capacity of a link.

3.2 Authentication and encryption

Modern VPNs normally use authenticated encryption or encryption combined with a strong integrity mechanism. Authenticated encryption simultaneously protects confidentiality and detects tampering. Examples include AES-GCM and ChaCha20-Poly1305, subject to the protocol and implementation supporting them securely.

Key establishment is separate from bulk data encryption. A protocol such as IKEv2 or TLS handshake procedures authenticates peers and negotiates session keys. Strong deployments use certificates, modern public-key exchanges, secure random numbers, and regular rekeying. Pre-shared keys may be acceptable for limited site-to-site arrangements, but a single shared secret across many devices creates poor accountability and a large compromise impact.

3.3 MTU, fragmentation, and performance

VPN headers consume part of the maximum transmission unit (MTU). If the protected packet becomes too large, it may be fragmented or dropped. Fragmentation can reduce performance and create troubleshooting problems, particularly when path MTU discovery is blocked by firewalls.

A simplified payload estimate is:

P_max is the approximate maximum protected payload, MTU_path is the path MTU in bytes, H_outer is the outer transport and network header size, and H_VPN is VPN overhead. This estimate assumes that no additional encapsulation occurs and that the path supports the stated MTU. Administrators should validate values experimentally and configure appropriate TCP maximum segment size (MSS) adjustments where necessary.

VPN performance also depends on encryption acceleration, processor capacity, concurrent sessions, bandwidth, latency, packet loss, server location, and inspection services. Throughput alone is not sufficient: interactive voice and video are especially sensitive to delay and jitter.

4. Major VPN Technologies

4.1 IPsec VPNs

IPsec is a suite of standards for protecting IP communications. In common deployments, Internet Key Exchange version 2 (IKEv2) negotiates authentication and security associations, while Encapsulating Security Payload (ESP) protects traffic. IPsec supports both site-to-site and remote-access designs.

Strengths include strong network-layer protection, broad support in enterprise equipment, and suitability for persistent gateway-to-gateway tunnels. IPsec can be efficient and transparent to applications because applications do not necessarily need to understand the tunnel.

Limitations include configuration complexity, interoperability differences, NAT traversal requirements, and possible difficulty passing through restrictive networks. Correct traffic selectors, routing, certificates, and rekey settings require careful administration. IPsec does not automatically provide application-level authorisation; a user who reaches a subnet may still have excessive access unless firewall rules and identity controls restrict it.

4.2 TLS VPNs

TLS VPNs use Transport Layer Security, the protocol family also used to protect HTTPS. They are commonly implemented as browser-based portals, client-based tunnels, or application proxies. Because TLS traffic commonly traverses networks that permit web traffic, TLS VPNs can be useful from hotels, airports, and other restrictive locations.

A portal may provide access to selected applications without exposing an entire internal network. A client-based TLS VPN may create a virtual network interface and support broader access. TLS VPNs integrate naturally with web authentication, certificates, single sign-on, and multifactor authentication.

Their limitations include dependence on gateway software, browser or client compatibility, and the risk that a convenient portal becomes a high-value target. TLS security still depends on current protocol versions, certificate validation, secure cipher configuration, patching, and protection against credential theft.

4.3 WireGuard and other modern implementations

WireGuard is a modern VPN protocol designed with a relatively small codebase and a focused cryptographic design. It uses public-key identities and modern cryptographic primitives, and it is often valued for performance and ease of deployment. It can support site-to-site and remote-access scenarios, but organisational features—such as identity lifecycle management, detailed posture checks, and central policy workflows—may require additional systems.

The important engineering lesson is not that one protocol is universally superior. Selection must consider interoperability, supportability, identity integration, logging, compliance, client platforms, and the organisation’s ability to respond to incidents.

4.4 Software-defined access and zero-trust approaches

Traditional VPNs often place an authenticated user on a network and then rely on network segmentation to limit access. Software-defined access (SDA), zero-trust network access (ZTNA), and identity-aware proxy systems instead attempt to grant access to specific applications based on policy.

A typical policy decision may use:

• user identity and group membership;
• device identity and security posture;
• application sensitivity;
• location and network context;
• time and behavioural signals; and
• authentication strength.

The principle is never trust solely because of network location; continuously evaluate access based on identity, context, and policy. ZTNA does not eliminate tunnels or encryption. It changes the control model by reducing implicit network-level trust and making application access more granular.

ZTNA is not automatically safer. Poor identity governance, weak agents, misclassified applications, or unavailable policy services can create risk or operational failure.

5. Designing Secure Remote Work Connectivity

A professional design begins with requirements rather than product selection.

Step 1: Classify users, devices, and applications

Identify employees, contractors, privileged administrators, third parties, and temporary workers. Record whether devices are organisation-managed, personally owned, or unmanaged. Classify applications by sensitivity, availability requirement, and access pattern.

A payroll database, for example, should not be treated like a public documentation portal. Administrative access should normally require stronger authentication, managed devices, restricted source conditions, approval, and enhanced logging.

Step 2: Select the access model

Use a site-to-site VPN for stable network-to-network connectivity where network-level integration is justified. Use a remote-access VPN when users need controlled access to several internal services and the organisation can manage endpoint and account security. Prefer application-specific, identity-aware access where users need only a small number of services or where broad network access would create unacceptable lateral-movement risk.

Step 3: Establish identity and device controls

Multifactor authentication should be required, especially for privileged and external access. Phishing-resistant methods, such as hardware security keys or passkeys, provide stronger protection than SMS codes. Use central identity lifecycle processes so that leavers, role changes, and contractors are handled promptly.

Device controls may include full-disk encryption, supported operating systems, endpoint detection and response, secure configuration, automatic updates, screen locking, and certificate-based device identity. A VPN should not be used to compensate for an unmanaged or demonstrably compromised endpoint.

Step 4: Define least-privilege policy

Access should be limited by user role, device status, application, protocol, and time where appropriate. Administrative accounts should be separate from ordinary accounts. Network segmentation, host firewalls, and application authorisation should remain in place after a VPN connection is established.

Step 5: Engineer performance and resilience

Estimate concurrent users and peak traffic. A simple planning estimate is:

B_required is estimated aggregate bandwidth, N_concurrent is the number of simultaneous users, R_average is average traffic per user, and P_peak is a dimensionless peak factor greater than or equal to 1. This is only a planning approximation: real capacity must also consider protocol overhead, burst behaviour, encryption processing, inspection, video traffic, and service-level requirements.

For example, if 80 users are expected to generate an average of 2 Mbit/s each during a busy period and a peak factor of 1.5 is used, the estimate is:

The result is 240 Mbit/s of estimated aggregate traffic before additional engineering margin and overhead. The calculation does not prove that a 240 Mbit/s appliance is adequate; gateway throughput, encrypted-session limits, failover, and uplink capacity must also be tested.

Use geographically suitable gateways, redundant Internet links where justified, health monitoring, configuration backups, and documented failover procedures. Test business-critical applications under realistic load rather than relying only on vendor figures.

Step 6: Monitor and respond

Collect authentication events, tunnel establishment and termination, policy decisions, administrative changes, endpoint posture results, and unusual data-transfer indicators. Logs should be time-synchronised, protected against unauthorised alteration, retained according to policy, and connected to incident response processes.

A mature operation defines what happens when a device is lost, a certificate is revoked, a user reports phishing, a gateway is attacked, or suspicious remote sessions appear. Emergency disablement must be possible without destroying evidence.

6. Illustrative Case: Northbridge College Remote Learning Access

Background

Northbridge College has 1,200 staff members, 8,000 students, a learning management system, a finance system, research servers, and administrative services. During a severe weather event, staff must work remotely. The college initially considers placing all remote users on a single full-network VPN.

Problem

A single broad VPN would be easy to explain but would expose many internal services to every authenticated user. Student and staff devices vary considerably, and the finance system contains sensitive personal and payment information. Video teaching also creates substantial bandwidth demand.

Analysis

The college separates requirements into categories. Students require the learning platform and library services. Most staff require collaboration systems and selected administrative applications. Finance staff require the finance system from managed devices. System administrators require privileged access through a controlled workstation and stronger authentication.

The risk analysis identifies credential theft, unmanaged endpoints, lateral movement, gateway overload, and loss of audit evidence as major risks.

Approach and solution

The college adopts a hybrid design:

1. A site-to-site IPsec VPN connects the main campus to a cloud-hosted disaster-recovery environment.
2. ZTNA-style application access is used for the learning platform, collaboration services, and selected administrative applications.
3. A remote-access TLS VPN remains available for legacy applications that cannot yet be published through an application proxy.
4. Phishing-resistant MFA is required for staff and administrators.
5. Finance access requires a managed device, endpoint health checks, a finance role, and additional approval for high-risk operations.
6. Administrator access is restricted to a privileged access workstation and is logged with enhanced detail.
7. Split tunnelling is used for approved high-volume teaching media, while sensitive institutional traffic remains subject to central controls.
8. Gateway capacity, authentication services, and Internet links are monitored, with a tested emergency capacity plan.

Outcome

The college reduces unnecessary network exposure while preserving access to older systems. Users experience different access methods based on application need, but single sign-on reduces repeated authentication. Security operations can revoke a user or device centrally and investigate anomalous sessions.

Learning points

The case demonstrates that remote connectivity should be designed around applications, identities, and risk—not merely around the question of whether a user can reach the internal network. It also shows that transition architectures are practical: legacy VPN access can coexist with more granular software-defined access while applications are modernised.

7. Limitations, Governance, and Ethical Issues

VPNs can create a false sense of security. Encryption does not protect data after it reaches an authorised endpoint, and it cannot prevent an authorised user from misusing information. A compromised endpoint may use a valid tunnel to spread malware. Centralising remote access also creates an attractive target: a stolen administrator credential or vulnerable gateway can have extensive consequences.

Privacy must be considered when collecting device posture, location, behavioural, or session data. Monitoring should have a defined purpose, proportional scope, controlled access, retention limits, and transparent organisational policy. Employees should understand what is inspected and why. Local employment, privacy, data-protection, and cross-border-transfer laws may apply.

Third-party access requires written agreements, named accounts, expiry dates, least privilege, and evidence of removal. Cryptographic algorithms and VPN products must be patched and reviewed as vulnerabilities emerge. Organisations should consult current standards and guidance, such as relevant NIST publications, ISO/IEC 27001 control frameworks, national cybersecurity guidance, and applicable data-protection law.

Artificial intelligence may assist with anomaly detection, capacity forecasting, and alert triage, but automated decisions can produce false positives, discriminate against unusual but legitimate work patterns, or expose sensitive telemetry to an external provider. Human review, explainability, access controls, and testing are necessary before AI materially affects access decisions.

8. Best-Practice Checklist

• Define whether each connection is site-to-site, remote-user, partner, or application-specific.
• Prefer phishing-resistant MFA for important access.
• Use certificates or managed identity rather than widely reused shared secrets.
• Keep gateways, clients, operating systems, and endpoint agents patched.
• Apply least privilege and restrict traffic selectors and routes.
• Segment sensitive systems even behind a VPN.
• Decide deliberately between full and split tunnelling.
• Measure latency, packet loss, MTU behaviour, gateway load, and concurrent sessions.
• Centralise logs and test incident-response actions.
• Provide secure, usable instructions and support for users.
• Review third-party access and remove it when no longer required.
• Test failover and capacity under realistic conditions.
• Reassess the design as applications move to cloud services and user roles change.

Chapter Summary

VPNs create protected logical connections over untrusted or shared networks, but their effectiveness depends on authentication, endpoint security, authorisation, configuration, monitoring, and response. Site-to-site VPNs connect networks and are suitable for stable infrastructure, while remote-access VPNs connect individual users and devices. IPsec provides network-layer protection and is common for persistent gateway tunnels. TLS VPNs integrate well with web access and restrictive networks. WireGuard and similar implementations offer modern, focused protocol designs, while ZTNA and software-defined access provide more granular, identity- and application-centred control.

Secure remote-work planning requires classification of users, devices, applications, and data; selection of an appropriate access model; strong identity and device controls; least-privilege policy; performance and resilience engineering; and continuous monitoring. Full and split tunnelling involve different security and performance trade-offs. VPNs are valuable security mechanisms, but they are not substitutes for segmentation, endpoint protection, application authorisation, governance, or incident response.

Key Terms

VPN: A logical protected connection established across another network.

Site-to-site VPN: A VPN connecting two or more networks through gateways.

Remote-access VPN: A VPN connecting an individual user device to organisational resources.

Tunnel: A logical communication path created through encapsulation and decapsulation.

Encapsulation: Wrapping an original packet inside another packet.

Decapsulation: Removing the outer packet wrapper at the receiving endpoint.

IPsec: A suite of standards for protecting IP communications.

TLS VPN: A VPN or application-access service built using Transport Layer Security.

Security association: Negotiated parameters governing protected communication.

Traffic selector: A rule defining which traffic may use a security association.

Full tunnelling: Routing most or all client traffic through the VPN gateway.

Split tunnelling: Routing only selected traffic through the VPN.

MFA: Authentication requiring two or more independent evidence factors.

ZTNA: An access approach that grants application access based on identity and context rather than network location alone.

Least privilege: Providing only the access necessary for an authorised task.

MTU: The largest packet size that a network path can transmit without fragmentation under specified conditions.

MSS: The maximum TCP payload size advertised by a host.

Traffic selector: Address, protocol, or port criteria used to define protected traffic.

Endpoint posture: The security state and compliance condition of a connecting device.

Lateral movement: An attacker’s movement from one compromised system to other systems.

Review Questions

5 Short Answer Questions

1. What is the primary difference between a site-to-site VPN and a remote-access VPN?
2. Define encapsulation in the context of VPN tunnelling.
3. State two advantages and one limitation of full tunnelling.
4. Why is multifactor authentication important for remote access?
5. What is the main access-control principle associated with ZTNA?

5 Long Answer Questions

1. Explain how an IPsec tunnel protects traffic from one network gateway to another, including the roles of authentication, key negotiation, and ESP.
2. Compare IPsec VPNs and TLS VPNs in terms of operating layer, deployment, usability, and limitations.
3. Discuss how endpoint posture affects the security of a remote-access VPN.
4. Explain the performance effects of VPN overhead, MTU, latency, packet loss, and gateway capacity.
5. Describe a complete secure remote-work design for an organisation with employees, contractors, administrators, and sensitive databases.

3 Analytical / Application Questions

1. An organisation wants every remote user to access its entire internal network through one VPN. Analyse the security and operational risks and recommend a more granular alternative.
2. A company has 150 simultaneous users, each producing an estimated 1.5 Mbit/s during peak work, with a peak factor of 1.4. Calculate the approximate aggregate bandwidth requirement using B_required ≈ N_concurrent × R_average × P_peak, then explain why the result is not sufficient by itself for procurement.
3. Design an access strategy for a contractor who needs one internal web application for six weeks using an unmanaged device. Specify authentication, authorisation, monitoring, expiry, and the conditions under which access should be denied.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a site-to-site VPN?

A. It connects individual users to one application through a browser.

B. It connects networks through VPN gateways.

C. It encrypts only files stored on a laptop.

D. It replaces all firewall rules between internal systems.

Correct Answer: B. It connects networks through VPN gateways.

Question 2

What is the principal security advantage of full tunnelling?

A. All client traffic can be subjected to central organisational controls.

B. It eliminates the need for endpoint security.

C. It guarantees unlimited bandwidth for remote users.

D. It prevents all phishing attacks.

Correct Answer: A. All client traffic can be subjected to central organisational controls.

Question 3

Which technology is most closely associated with network-layer protection of IP traffic?

A. IPsec

B. HTML

C. DNS

D. SMTP

Correct Answer: A. IPsec

Question 4

What is a major risk of granting a remote user broad internal network access?

A. Reduced need for authentication

B. Increased potential for lateral movement after endpoint compromise

C. Guaranteed lower latency

D. Removal of all routing requirements

Correct Answer: B. Increased potential for lateral movement after endpoint compromise

Question 5

What does ZTNA generally attempt to do?

A. Trust every device located inside an office building

B. Grant access to specific applications using identity and context

C. Disable encryption for internal traffic

D. Replace multifactor authentication with passwords

Correct Answer: B. Grant access to specific applications using identity and context

Question 6

A VPN path has an MTU of 1,500 bytes, with 40 bytes of outer headers and 60 bytes of VPN overhead. Using the simplified relationship P_max ≈ MTU_path − H_outer − H_VPN, what is the approximate protected payload?

A. 1,400 bytes

B. 1,460 bytes

C. 1,500 bytes

D. 1,600 bytes

Correct Answer: A. 1,400 bytes

Question 7

Which control most directly limits access after a user has authenticated?

A. Least-privilege authorisation policy

B. Increasing monitor brightness

C. Disabling system logs

D. Using a longer network cable

Correct Answer: A. Least-privilege authorisation policy

Question 8

Which factor is especially important when selecting a remote-access VPN for hotel or airport networks?

A. Ability to operate through commonly permitted web traffic

B. Requirement for a private leased line at every hotel

C. Removal of all certificate validation

D. Dependence on broadcast-only networking

Correct Answer: A. Ability to operate through commonly permitted web traffic

Question 9

An organisation has 80 concurrent users, average traffic of 2 Mbit/s, and a peak factor of 1.5. What is the estimated aggregate bandwidth using B_required ≈ N_concurrent × R_average × P_peak?

A. 120 Mbit/s

B. 160 Mbit/s

C. 240 Mbit/s

D. 320 Mbit/s

Correct Answer: C. 240 Mbit/s

Question 10

Why should VPN logs be time-synchronised and protected from alteration?

A. To improve the colour of the VPN interface

B. To support reliable investigation and accountability

C. To increase packet fragmentation

D. To remove the need for access policies

Correct Answer: B. To support reliable investigation and accountability