VPN Services
A Virtual Private Network (VPN) creates encrypted tunnels across untrusted networks, extending private network connectivity to remote sites and users. VPN technology enables organisations with distributed operations to function as a unified network regardless of geographic separation, providing confidentiality and integrity for data traversing the public internet. For mission-driven organisations operating across multiple countries with staff connecting from field offices, partner locations, and home environments, VPNs represent foundational infrastructure for secure communications.
- VPN Tunnel
- An encrypted connection between two endpoints that encapsulates traffic, making it unreadable to intermediate networks. Traffic enters the tunnel at one endpoint, travels encrypted across the internet, and emerges decrypted at the other endpoint.
- VPN Gateway
- A device or software component that terminates VPN tunnels, handling encryption, decryption, and routing of traffic between the VPN and the local network.
- Split Tunnelling
- A configuration where only traffic destined for specific networks traverses the VPN, while other traffic (such as general internet browsing) routes directly to the internet without VPN encryption.
- Full Tunnelling
- A configuration where all traffic from the client traverses the VPN regardless of destination, providing complete traffic inspection and policy enforcement at the cost of increased latency and bandwidth consumption at the VPN gateway.
VPN Types
VPN deployments divide into three fundamental categories based on what endpoints they connect and how those endpoints authenticate. Understanding these categories determines architecture decisions, protocol selection, and operational requirements.
Site-to-site VPNs connect entire networks through persistent tunnels between VPN gateways. When a user at Site A accesses a resource at Site B, their traffic travels normally within Site A’s network until it reaches the VPN gateway, which encrypts and forwards it to Site B’s gateway for decryption and local delivery. Users remain unaware of the VPN; their devices require no VPN client software. Site-to-site VPNs suit connecting headquarters to regional offices, linking data centres, or establishing permanent connectivity with partner organisations. The tunnels remain active continuously, with automatic re-establishment after network disruptions.
Remote access VPNs connect individual devices to a central network through on-demand tunnels initiated by client software. A staff member working from home launches their VPN client, authenticates, and establishes an encrypted tunnel to the organisation’s VPN gateway. Their device then functions as if physically present on the office network, accessing internal resources directly. Remote access VPNs require client software on each connecting device and authentication infrastructure to validate users. The tunnels exist only while actively connected, terminating when the user disconnects or after idle timeouts.
Mesh VPNs connect multiple sites or devices directly to each other without routing through a central hub. Each node maintains tunnels to every other node (full mesh) or to a subset of nodes with routing between them (partial mesh). Mesh architectures eliminate single points of failure and reduce latency by enabling direct communication between any two points. However, they introduce complexity: a full mesh of 10 sites requires 45 individual tunnels, and 20 sites requires 190 tunnels. Mesh VPNs suit organisations requiring resilient connectivity between autonomous sites that communicate heavily with each other rather than primarily with a central location.
SITE-TO-SITE VPN
+------------------+ +------------------+| SITE A | | SITE B || | | || +------------+ | | +------------+ || | Workstation| | | | Server | || +-----+------+ | | +-----+------+ || | | | | || +-----v------+ | Encrypted Tunnel | +-----v------+ || | VPN | | ======================> | | VPN | || | Gateway +--+------------------------------+--+ Gateway | || +------------+ | Public Internet | +------------+ || | | |+------------------+ +------------------+Figure 1: Site-to-site VPN connecting two networks through gateway-to-gateway tunnel
Protocol Selection
VPN protocols determine encryption strength, performance characteristics, compatibility, and operational complexity. Four protocols dominate current deployments, each with distinct trade-offs that influence suitability for different contexts.
IPsec (Internet Protocol Security) operates at the network layer, encrypting IP packets themselves. IPsec consists of two phases: IKE (Internet Key Exchange) establishes the secure channel and negotiates encryption parameters, while ESP (Encapsulating Security Payload) or AH (Authentication Header) handles the actual traffic encryption. IPsec supports both tunnel mode (encrypting entire packets for site-to-site VPNs) and transport mode (encrypting only payloads for host-to-host communication). Most enterprise network equipment includes hardware acceleration for IPsec, delivering high throughput with minimal CPU impact. IPsec configuration requires precise matching of parameters between endpoints; mismatched settings produce cryptic failures. The protocol works poorly with NAT (Network Address Translation) without additional encapsulation, complicating deployments where endpoints sit behind consumer routers.
OpenVPN uses TLS/SSL for key exchange and can operate over either UDP or TCP. Running over TCP port 443 makes OpenVPN traffic indistinguishable from HTTPS web traffic, enabling connectivity through restrictive firewalls and networks that block other VPN protocols. OpenVPN runs in userspace rather than the kernel, simplifying deployment but limiting throughput compared to kernel-based protocols. A typical OpenVPN server on modern hardware handles 100-200 Mbps; kernel-based protocols on the same hardware achieve 500+ Mbps. OpenVPN’s flexibility comes from its extensive configuration options, which simultaneously create opportunities for misconfiguration. The protocol enjoys broad client support across operating systems and mobile devices.
WireGuard implements a minimal, auditable protocol with approximately 4,000 lines of code compared to OpenVPN’s 100,000+ lines. WireGuard operates in the kernel, achieving throughput competitive with IPsec while maintaining simpler configuration. The protocol uses modern cryptography (ChaCha20, Curve25519, BLAKE2s) without legacy algorithm negotiation; both endpoints must support the same fixed cryptographic suite. WireGuard’s simplicity extends to its connection model: peers are identified by public keys, and the protocol silently drops packets from unknown sources without responding. This makes WireGuard connections appear as if no service exists to port scanners. WireGuard lacks built-in user authentication; implementations typically layer authentication through external systems or manage access through public key distribution.
SSL/TLS VPNs (distinct from OpenVPN) provide clientless browser-based access to specific applications rather than full network connectivity. Users access a web portal, authenticate, and interact with published applications through the browser. The VPN gateway proxies connections to internal resources, presenting them through a web interface. SSL VPNs suit providing contractors or partners with access to specific applications without granting network-level access or requiring client software installation. They cannot provide full network connectivity; applications must be specifically published and proxied.
| Protocol | Layer | Throughput | NAT Traversal | Firewall Bypass | Configuration |
|---|---|---|---|---|---|
| IPsec | Network (3) | 500+ Mbps with hardware | Requires NAT-T | Often blocked | Complex, precise matching |
| OpenVPN | Application (7) | 100-200 Mbps | Native support | TCP/443 appears as HTTPS | Flexible, many options |
| WireGuard | Network (3) | 500+ Mbps | Native support | UDP only, often blocked | Minimal, fixed crypto |
| SSL/TLS VPN | Application (7) | Varies by gateway | Native support | HTTPS native | Portal-based |
Architecture Patterns
VPN architecture determines how traffic flows between sites, which paths remain available during failures, and where administrative complexity concentrates. Three patterns suit different organisational structures and requirements.
The hub-and-spoke topology routes all inter-site traffic through a central hub, typically headquarters or a primary data centre. Each spoke site maintains a single tunnel to the hub. Traffic between spoke sites traverses two tunnels: spoke A to hub, then hub to spoke B. This topology minimises tunnel count (N-1 tunnels for N sites) and centralises policy enforcement, logging, and security inspection at the hub. Hub-and-spoke suits organisations with most resources concentrated at headquarters and spoke sites primarily consuming central services. The hub becomes a single point of failure; hub outages isolate all spokes from each other even if their individual tunnels remained viable.
HUB-AND-SPOKE TOPOLOGY
+------------------+ | HEADQUARTERS | | (Hub) | | | | +------------+ | | | VPN | | | | Gateway | | | +-----+------+ | +--------+---------+ | +---------------------+---------------------+ | | | v v v+------------------+ +------------------+ +------------------+| REGIONAL | | COUNTRY | | FIELD || OFFICE A | | OFFICE B | | OFFICE C || | | | | || +------------+ | | +------------+ | | +------------+ || | VPN | | | | VPN | | | | VPN | || | Gateway | | | | Gateway | | | | Gateway | || +------------+ | | +------------+ | | +------------+ |+------------------+ +------------------+ +------------------+
Traffic A to C: A --> Hub --> C (two tunnel hops)Figure 2: Hub-and-spoke VPN topology centralising traffic through headquarters
The full mesh topology establishes direct tunnels between every pair of sites. Traffic between any two sites traverses a single tunnel without intermediate hops. Full mesh eliminates the hub as a bottleneck and single point of failure; any site can communicate directly with any other site even if other sites fail. Tunnel count grows quadratically: N sites require N(N-1)/2 tunnels. Ten sites need 45 tunnels; 20 sites need 190 tunnels. Each tunnel requires configuration and monitoring on both endpoints, and adding a new site requires configuring tunnels to every existing site. Full mesh suits small numbers of sites (under 10) with heavy peer-to-peer traffic and strong availability requirements.
The partial mesh with regional hubs combines elements of both patterns. Sites within a region connect to a regional hub; regional hubs connect to each other and to global headquarters in a mesh. Intra-region traffic routes through the regional hub (one hop), while inter-region traffic routes through regional hub to regional hub (two hops). This pattern reduces tunnel count while maintaining regional resilience: a regional hub failure affects only its region, and inter-region connectivity remains available through alternative hub paths. Partial mesh suits geographically distributed organisations with natural regional clustering of operations and communication patterns.
PARTIAL MESH WITH REGIONAL HUBS
+-------------------------------------------------------------------+| GLOBAL MESH || || +------------+ +------------+ +------------+ || | HQ |<------->| EMEA |<------->| APAC | || | Hub | | Hub | | Hub | || +-----+------+ +-----+------+ +-----+------+ || | | | || | | | || +----+----+ +-----+-----+ +-----+-----+ || | | | | | | || v v v v v v || +------+ +------+ +------+ +------+ +------+ +------+ || |Site 1| |Site 2| |Site 3| |Site 4| |Site 5| |Site 6| || +------+ +------+ +------+ +------+ +------+ +------+ || |+-------------------------------------------------------------------+
Total tunnels: 3 (hub mesh) + 6 (spoke-to-hub) = 9Full mesh equivalent: 28 tunnelsFigure 3: Partial mesh with regional hubs balancing resilience and complexity
Remote Access Architecture
Remote access VPNs require additional architectural components beyond site-to-site deployments: client software distribution, user authentication, and access policy enforcement. The architecture must accommodate devices the organisation does not fully control, users connecting from untrusted networks, and dynamic allocation of network resources to connecting clients.
The VPN gateway terminates remote connections and bridges authenticated clients onto the internal network. Gateway placement influences security posture: gateways in a DMZ (demilitarised zone) prevent direct internet exposure of internal networks even if the gateway is compromised. The gateway maintains a pool of IP addresses for assignment to connecting clients, either from a dedicated VPN subnet or from existing internal subnets. Dedicated VPN subnets simplify firewall rules and traffic monitoring; internal subnet assignment makes clients indistinguishable from on-premise devices.
Authentication verifies user identity before granting network access. Local authentication stores credentials on the VPN gateway itself, suitable only for very small deployments. Integration with directory services (Active Directory, LDAP, or cloud identity providers) enables centralised credential management and immediate access revocation when users leave the organisation. Multi-factor authentication adds a second verification step, typically a time-based code from a mobile app or hardware token. VPN authentication should always require MFA; credentials alone provide insufficient protection given the network access VPNs grant.
REMOTE ACCESS VPN ARCHITECTURE
+-------------------------+ | ORGANISATION |+----------------+ | NETWORK || | | || Remote User | | +-------------------+ || +----------+ | Encrypted | | | || | VPN | | Tunnel | | Internal | || | Client +---+-----------------+->+ Resources | || +----------+ | | | | || | | +-------------------+ |+----------------+ | ^ | | | | | +--------+--------+ | | | VPN Gateway | | +-----------+ | | +-------------+ | | | | | | | Auth | | | | Identity +---------------+--+-+ Integration | | | | Provider | Auth Query | | +-------------+ | | | | | | | | +-----------+ | +-----------------+ | | | | | | DMZ | +-------------------------+ | InternetFigure 4: Remote access VPN with identity provider integration
Client deployment mechanisms vary by device ownership and management. Organisation-managed devices receive VPN clients through software deployment tools alongside pre-configured connection profiles. Personal devices (BYOD) require users to download and install clients manually; providing detailed installation instructions and configuration files reduces support burden. Mobile devices present additional complexity: iOS and Android include built-in VPN clients supporting IKEv2 and IPsec, while OpenVPN and WireGuard require dedicated apps from application stores.
Split Tunnelling
Split tunnelling decisions represent a trade-off between security visibility and user experience. Full tunnelling routes all client traffic through the VPN, enabling the organisation to inspect, filter, and log all user activity. Split tunnelling routes only organisation-destined traffic through the VPN, allowing general internet traffic to flow directly from the user’s local connection.
Full tunnelling provides several security benefits: traffic passes through organisational security controls (firewalls, web filters, intrusion detection), logging captures complete user activity, and data exfiltration to external services becomes visible. However, full tunnelling degrades user experience when the VPN gateway is geographically distant. A user in Nairobi connecting to a gateway in London experiences 180ms additional latency on all internet activity. Streaming video, video calls, and large downloads consume bandwidth at the gateway rather than the user’s local connection, potentially saturating limited WAN capacity.
Split tunnelling improves performance for internet-bound traffic but creates security gaps. Traffic to external cloud services (personal email, file sharing, social media) bypasses organisational controls. A user accessing a compromised website while split-tunnelling could have malware delivered directly without security inspection. Malicious software on the user’s device could exfiltrate data through the direct internet path while the VPN connection provides access to internal resources.
A middle path uses application-based split tunnelling or inverse split tunnelling. Application-based split tunnelling routes traffic from specific applications through the VPN regardless of destination, while allowing other applications direct internet access. A user’s web browser might route directly while their email client routes through the VPN. Inverse split tunnelling routes all traffic through the VPN except explicitly excluded destinations, such as known video conferencing services that perform poorly over VPN connections. These configurations require VPN clients that support application or destination-based routing decisions.
For field contexts with limited bandwidth, split tunnelling often becomes necessary regardless of security preferences. A field office sharing a 2 Mbps satellite connection among 15 staff cannot sustain full tunnelling without severe performance degradation. Routing only traffic destined for internal resources through the VPN preserves connectivity while accepting reduced visibility into external traffic.
High Availability
VPN gateway failures disrupt all dependent connectivity: site-to-site tunnels disconnect, remote users lose access, and inter-site communication halts. High availability configurations ensure continuous VPN service despite individual component failures through redundant gateways and automatic failover mechanisms.
Active-passive failover deploys two gateways with only one actively handling traffic. The passive gateway monitors the active gateway’s health and assumes its responsibilities if the active gateway fails. Failover typically completes within 30-60 seconds, during which VPN connectivity is unavailable. Site-to-site tunnels re-establish automatically once the passive gateway activates; remote access clients may require reconnection depending on client software behaviour. Active-passive configurations use gateway resources inefficiently (the passive gateway sits idle during normal operation) but provide simple, well-understood failover behaviour.
Active-active configurations distribute traffic across multiple gateways simultaneously. Load balancers direct incoming connections to available gateways based on health checks and load distribution algorithms. If one gateway fails, the load balancer redirects new connections to remaining gateways; existing connections on the failed gateway must reconnect. Active-active configurations require session synchronisation between gateways to maintain connection state or must accept brief disruption during failover. Active-active uses all gateway resources continuously and provides capacity scaling beyond single-gateway limits.
HIGH AVAILABILITY VPN
+----------------+ | Load Balancer | | (health check) | +-------+--------+ | +-----------------+-----------------+ | | v v +----------------+ +----------------+ | VPN Gateway | | VPN Gateway | | (Active) | | (Active) | | | State Sync | | | Sessions: 150 |<--------------->| Sessions: 140 | +-------+--------+ +-------+--------+ | | +----------------+------------------+ | +-------v-------+ | Internal | | Network | +---------------+
Gateway failure: Load balancer health check fails New connections route to surviving gateway Existing sessions reconnect (5-15 seconds)Figure 5: Active-active VPN gateway configuration with load balancing
For site-to-site VPNs, dual-tunnel configurations establish tunnels from each site to multiple hub gateways. Dynamic routing protocols (BGP or OSPF) running over the VPN tunnels detect path failures and redirect traffic to surviving tunnels. Dual-tunnel configurations require routing protocol support on site VPN gateways and coordination of route advertisements across the VPN infrastructure.
Field Deployment Considerations
VPN operation in field contexts contends with challenges absent from typical enterprise deployments: intermittent connectivity, high latency satellite links, frequent IP address changes, and networks that actively interfere with VPN protocols.
High-latency connections affect VPN establishment time and throughput. IPsec IKE negotiation requires multiple round trips; on a 700ms satellite link, initial tunnel establishment takes 5-10 seconds. OpenVPN’s TLS handshake similarly requires multiple exchanges. Once established, high latency affects TCP-based protocols more than UDP: TCP’s congestion control interprets latency as network congestion, reducing throughput below link capacity. VPN protocols running over UDP (WireGuard, IPsec in UDP mode, OpenVPN over UDP) perform better on high-latency links.
Intermittent connectivity causes repeated tunnel re-establishment. Each disconnection requires fresh key negotiation on reconnection, consuming time and generating authentication load at the VPN gateway. Aggressive keepalive settings detect failures quickly but generate traffic overhead and may trigger disconnections during brief signal interruptions. Conservative keepalive settings reduce overhead but delay failure detection. A 30-second keepalive interval balances responsiveness with tolerance for momentary connectivity gaps.
Protocol-specific reconnection behaviour affects user experience. WireGuard maintains connection state silently during brief outages, resuming transmission when connectivity returns without visible reconnection. OpenVPN and IPsec detect connection loss through keepalive failure and require explicit reconnection, presenting the user with reconnection dialogs. For mobile users moving between networks (cellular to WiFi, or between cell towers), WireGuard’s seamless roaming provides noticeably smoother operation.
Restrictive networks block VPN protocols through deep packet inspection. Some network operators block UDP entirely, breaking WireGuard and UDP-mode IPsec. Port-based blocking affects protocols on well-known ports. OpenVPN over TCP port 443 appears identical to HTTPS traffic at the packet level, evading most blocking techniques. Advanced blocking systems can detect VPN traffic through traffic analysis even when encrypted; organisations operating in countries with sophisticated censorship infrastructure may require additional obfuscation layers.
Configuration adjustments for field deployment include: MTU reduction (1300-1400 bytes instead of 1500) to accommodate encapsulation overhead and prevent fragmentation on constrained links; extended timeouts (60-120 second connection timeout instead of 30 seconds) to tolerate slow handshakes; reduced keepalive frequency (60-120 seconds instead of 30 seconds) to minimise overhead while maintaining connection detection.
VPN and ZTNA Relationship
Zero Trust Network Access represents an architectural evolution from VPN-based connectivity, replacing network-level access with application-level access decisions. Understanding the relationship between these technologies informs strategic planning and migration decisions.
Traditional VPNs grant authenticated users access to network segments. A user connecting to the VPN receives an IP address on the internal network and can reach any resource that network connectivity and firewall rules permit. The trust boundary exists at VPN authentication: once authenticated, users have broad network visibility. This model originated when organisational resources resided on internal networks and the security challenge was providing remote access to that internal network.
ZTNA grants authenticated users access to specific applications rather than network segments. Each application access request undergoes independent verification based on user identity, device posture, and contextual factors. A user authenticated to access the grants management system cannot automatically access the HR system or file servers; each application requires separate authorisation. The trust boundary exists at each application access decision rather than at network entry.
Organisations need not choose exclusively between VPN and ZTNA. Hybrid approaches use ZTNA for application access while maintaining VPN for scenarios ZTNA handles poorly: access to legacy applications that cannot integrate with identity-aware proxies, bulk data transfer that performs poorly through application proxies, and administrative access to infrastructure that requires network-level connectivity. The strategic direction moves toward ZTNA for application access while VPN retreats to infrastructure administration and legacy compatibility.
Migration from VPN to ZTNA proceeds incrementally. Modern web applications adopt ZTNA first; they already authenticate users and can integrate with identity providers directly. Legacy applications with embedded authentication remain on VPN while the organisation evaluates ZTNA proxy solutions or application modernisation. Infrastructure administration (SSH to servers, RDP to workstations) often remains on VPN longest, as these protocols assume network connectivity and integrate poorly with application proxies.
For organisations with limited IT capacity, VPN remains a pragmatic choice. VPN technology is mature, well-documented, and supported by readily available open source software. ZTNA implementations require more sophisticated identity infrastructure and ongoing policy management. The security benefits of ZTNA are real but require operational capacity to realise.
Technology Options
Open Source
strongSwan provides a comprehensive IPsec implementation for Linux, supporting IKEv1 and IKEv2, certificate and pre-shared key authentication, and integration with various authentication backends. strongSwan handles both site-to-site and remote access VPN scenarios. Configuration uses text files with extensive documentation; the learning curve reflects IPsec’s inherent complexity. strongSwan is included in most Linux distribution repositories and deployed widely in enterprise environments.
OpenVPN Community offers the open source version of OpenVPN, providing remote access and site-to-site VPN capabilities. OpenVPN Community lacks the management interface of commercial editions; configuration requires editing text files and distributing configuration profiles manually. Client software exists for all major platforms. OpenVPN Community suits organisations with Linux administration skills and modest scale (under 100 concurrent connections per gateway).
WireGuard ships as a kernel module in Linux 5.6+ and as userspace implementations for other platforms. Configuration is minimal: each peer is defined by a public key and allowed IP ranges. WireGuard lacks built-in user management, dynamic IP assignment, or authentication integration; organisations implement these capabilities through wrapper tools like wg-quick, or dedicated management interfaces like Firezone or Netmaker. WireGuard suits organisations prioritising performance and simplicity over enterprise management features.
Firezone layers user management, identity provider integration, and web-based administration over WireGuard. Users authenticate through OIDC/SAML identity providers; Firezone handles key generation and distribution automatically. Firezone provides the management capabilities WireGuard lacks while preserving WireGuard’s performance characteristics. The open source version supports unlimited users with self-hosted deployment.
Commercial with Nonprofit Programmes
Cisco AnyConnect provides enterprise remote access VPN with broad platform support, split tunnelling controls, and integration with Cisco security infrastructure. Cisco offers nonprofit pricing through Cisco’s Social Impact programme and TechSoup. AnyConnect suits organisations with existing Cisco infrastructure seeking integrated management.
Palo Alto GlobalProtect offers remote access VPN integrated with Palo Alto next-generation firewalls, providing unified policy enforcement across VPN and direct traffic. Palo Alto provides nonprofit discounts through direct engagement. GlobalProtect suits organisations with Palo Alto firewall investments.
OpenVPN Access Server packages OpenVPN with web-based administration, user management, and simplified client provisioning. The free tier supports 2 concurrent connections; paid licences scale from there. OpenVPN Inc offers nonprofit discounts for larger deployments. Access Server suits organisations wanting OpenVPN protocol capabilities with reduced administrative complexity.
Implementation Considerations
For organisations with limited IT capacity
Begin with remote access VPN using WireGuard or OpenVPN, prioritising solutions that minimise ongoing administration. Firezone provides identity provider integration with straightforward deployment on a single Linux server. Configure split tunnelling to reduce bandwidth requirements at the VPN gateway; ensure traffic to cloud services hosting organisational data (Microsoft 365, Google Workspace, cloud-hosted applications) routes through the VPN while allowing direct internet access for general browsing.
A single VPN gateway without high availability suits organisations where brief outages are acceptable. Document the gateway recovery procedure so anyone with server access can restore service. Monitor VPN service status through simple health checks (attempting connection from an external network daily) rather than sophisticated monitoring infrastructure.
For organisations with established IT functions
Implement high availability for VPN gateways serving critical connectivity. Active-passive failover provides adequate availability for most organisations; active-active suits those requiring zero-downtime maintenance windows or exceeding single-gateway capacity. Integrate VPN authentication with central identity management and enforce MFA for all VPN access.
Establish site-to-site VPNs using hub-and-spoke topology for predictable traffic patterns or partial mesh for regional autonomy. Implement routing protocols over VPN tunnels to enable automatic failover between redundant paths. Monitor VPN tunnel status, throughput, and latency; alert on tunnel failures before users report them.
Develop a migration path toward ZTNA for application access while maintaining VPN for infrastructure administration. Identify applications suitable for ZTNA protection (modern web applications with SSO integration) and evaluate ZTNA solutions that integrate with your identity provider.
For field deployments
Select VPN protocols that tolerate high latency and intermittent connectivity. WireGuard’s silent handoff during network transitions provides the smoothest experience on unreliable connections. Configure MTU values conservatively (1300 bytes) to prevent fragmentation issues across varied network paths.
Test VPN connectivity from representative field locations before deploying staff who depend on it. Satellite links, mobile networks, and local ISPs may block or throttle VPN traffic unpredictably. Maintain fallback options: if WireGuard is blocked, OpenVPN over TCP/443 often succeeds where other protocols fail.
Implement split tunnelling in bandwidth-constrained field offices. Route traffic to internal resources through VPN while allowing direct internet access for general purposes. Accept the security trade-off where operational necessity demands it; compensate through endpoint protection on field devices.