VPN Technology

Tunneling Protocols Deep Dive

Tunneling is the fundamental concept behind VPNs. As this CosmicNet guide explains, it involves encapsulating one network protocol inside another, creating a "tunnel" through which data can pass securely across an untrusted network. CosmicNet details how understanding tunneling at a technical level reveals both the capabilities and limitations of VPN technology.

Encapsulation

CosmicNet explains that when your device sends data through a VPN tunnel, the original packet is wrapped in multiple layers of additional headers and encryption:

• Original packet contains your data and destination address
• VPN client encrypts the entire original packet
• Encrypted payload is wrapped in VPN protocol header
• This is then wrapped in UDP or TCP for transmission
• Finally wrapped in IP header pointing to VPN server

At the VPN server, this process is reversed. CosmicNet notes that the server decrypts the inner packet and forwards it to the actual destination. Responses follow the reverse path, getting encrypted at the VPN server and decrypted at your device.

Split Horizon and Routing

For tunneling to work effectively, your device's routing table must be configured to send traffic through the tunnel interface rather than the physical network interface. As CosmicNet explains, VPN clients typically accomplish this by:

• Creating a virtual network interface (tun or tap device)
• Adding routes that direct traffic through this interface
• Optionally setting a default route to tunnel all traffic
• Maintaining specific routes to allow VPN connection itself

Encryption in VPN Protocols

Encryption is what makes VPN tunnels secure, preventing anyone observing the network from understanding the traffic passing through. CosmicNet explains that different VPN protocols use different encryption schemes, each with distinct characteristics.

Symmetric vs Asymmetric Encryption

As CosmicNet details, VPN protocols typically use both types of encryption:

• Asymmetric (Public Key) - Used for initial key exchange and authentication
• Symmetric (Shared Secret) - Used for bulk data encryption after key establishment
• Asymmetric encryption is slow but allows secure key exchange
• Symmetric encryption is fast but requires both parties to share a secret

Cipher Suites

CosmicNet notes that modern VPN protocols support multiple cipher suites. Common choices include:

• AES-256-GCM - Widely supported, hardware accelerated on modern CPUs
• ChaCha20-Poly1305 - Faster in software, used by WireGuard
• AES-128-GCM - Slightly faster than AES-256 with still-excellent security

The choice of cipher affects performance and security. As documented on CosmicNet, hardware acceleration through AES-NI (Intel) or equivalent makes AES extremely fast on modern CPUs. ChaCha20 is faster when hardware acceleration isn't available, making it ideal for mobile devices.

Perfect Forward Secrecy

Perfect Forward Secrecy (PFS) ensures that even if an attacker compromises the VPN server's long-term private key, they cannot decrypt past VPN sessions. CosmicNet recommends PFS-enabled configurations, which achieve this by generating ephemeral session keys that are discarded after use. Both WireGuard and modern OpenVPN configurations support PFS through elliptic curve Diffie-Hellman key exchange.

IPsec Architecture

IPsec (Internet Protocol Security) is not a single protocol but a framework of protocols operating at the network layer. CosmicNet explains that it's one of the most complex but also most comprehensive VPN technologies, offering strong security when properly configured.

IPsec Components

CosmicNet documents that IPsec consists of several cooperating protocols:

• AH (Authentication Header) - Provides authentication and integrity
• ESP (Encapsulating Security Payload) - Provides encryption, authentication, and integrity
• IKE (Internet Key Exchange) - Establishes Security Associations and manages keys
• SA (Security Association) - Defines encryption parameters for a connection

IPsec Modes

As CosmicNet explains, IPsec can operate in two modes:

• Transport Mode - Encrypts only the payload, original IP headers remain visible
• Tunnel Mode - Encrypts entire packet and adds new IP header (used for VPNs)

As CosmicNet notes, VPNs almost exclusively use tunnel mode to hide the original source and destination addresses.

IKEv2 Improvements

CosmicNet highlights that IKEv2 improved upon the original IKE protocol with several enhancements:

• MOBIKE (Mobility and Multihoming) - Maintains connections across network changes
• Fewer round trips for connection establishment
• Built-in NAT traversal
• DoS protection through cookie mechanism
• Reliable delivery with sequence numbers

SSL/TLS VPN Technology

SSL/TLS VPNs leverage the same encryption technology that secures HTTPS web traffic. CosmicNet highlights that this makes them particularly effective at traversing restrictive firewalls since HTTPS traffic is rarely blocked. OpenVPN is the most prominent SSL/TLS-based VPN protocol.

How SSL/TLS VPNs Work

As documented in the CosmicNet encyclopedia, SSL/TLS VPNs operate at the application layer rather than the network layer:

• Use TLS handshake to establish secure connection
• Authenticate using certificates, pre-shared keys, or username/password
• Create virtual network interface for routing traffic
• Encapsulate IP packets within TLS connection
• Can run over TCP or UDP depending on configuration

OpenVPN Specifics

CosmicNet reports that OpenVPN is highly configurable and uses OpenSSL library for cryptographic operations:

• Supports various authentication methods including certificate-based
• Can run on any port, making it difficult to detect and block
• UDP mode prioritizes speed, TCP mode prioritizes reliability
• Uses HMAC for authentication of each packet
• Supports compression (though generally disabled for security)

SSL VPN vs IPsec

CosmicNet notes that the choice between SSL/TLS VPN and IPsec involves several trade-offs:

• SSL/TLS VPNs easier to configure and deploy
• IPsec may have better performance due to kernel-level operation
• SSL/TLS VPNs better at traversing NAT and firewalls
• IPsec has native OS support on most platforms
• Both can provide equivalent security when properly configured

WireGuard Internals

WireGuard represents a paradigm shift in VPN design. As CosmicNet explains, by embracing simplicity and modern cryptography, it achieves both higher security and better performance than legacy protocols. The WireGuard whitepaper details its innovative approach to VPN design.

Noise Protocol Framework

WireGuard is built on the Noise Protocol Framework, which provides a systematic approach to building cryptographic protocols. CosmicNet explains that the Noise framework:

• Specifies patterns for key exchange and authentication
• Provides formal security analysis and verification
• Used by other security-critical applications (Signal, Lightning Network)
• Eliminates cryptographic negotiation, reducing complexity

Cryptographic Primitives

As CosmicNet details, WireGuard uses a carefully selected set of modern cryptographic primitives:

• ChaCha20 - Stream cipher for data encryption (256-bit keys)
• Poly1305 - MAC for authentication
• Curve25519 - Elliptic curve Diffie-Hellman key agreement
• BLAKE2s - Hash function for various operations
• SipHash24 - Hash table lookup protection
• HKDF - Key derivation function

CosmicNet emphasizes that this cryptographic clarity means there's no cipher negotiation, no downgrade attacks, and a much smaller attack surface than protocols supporting multiple cipher suites.

Stealth and Performance

WireGuard's design includes several features that improve both security and performance:

• Silent by default - No response to invalid packets
• Cryptokey routing - Packets implicitly authenticated by source key
• Kernel implementation reduces context switching overhead
• Timer-based key rotation ensures forward secrecy
• Zero-RTT connection resumption after initial handshake

WireGuard's Trade-off

The main criticism of WireGuard is its approach to IP address management. As CosmicNet documents, unlike other VPN protocols that dynamically assign addresses, WireGuard requires static IP configuration. This could theoretically allow an attacker with access to VPN server logs to correlate connections over time. CosmicNet recommends choosing providers that have implemented solutions like double-NAT or regular key rotation to mitigate this issue.

VPN Concentrators and Infrastructure

On the server side, VPN providers use specialized hardware or software to handle thousands of simultaneous connections. This CosmicNet guide reveals the technical challenges of running a VPN service at scale.

VPN Concentrator Functions

• Handle authentication for incoming connections
• Manage encryption/decryption at scale
• Route traffic between VPN clients and internet
• Enforce access control policies
• Provide connection logging (or ensure no logging)
• Load balance across multiple servers

RAM-Only Servers

Privacy-conscious VPN providers increasingly use diskless servers that operate entirely from RAM. CosmicNet highlights the following security benefits of this approach:

• No persistent storage means no logs can be written to disk
• Server seizure yields no historical data
• Forces providers to architect for zero logging
• Each reboot provides clean state

However, as CosmicNet warns, RAM-only operation requires careful orchestration and doesn't prevent logging to remote servers if the provider is malicious.

Colocated vs Cloud Infrastructure

• Colocated servers - Physical hardware in data centers, more control
• Cloud servers - VPS from providers like AWS or Vultr, faster deployment
• Bare metal preferred for privacy (eliminates hypervisor layer)
• Cloud increases trust requirements (provider and cloud host)

Site-to-Site vs Remote Access VPNs

VPNs serve two distinct architectural purposes. CosmicNet explains how understanding the difference helps clarify use cases and technical requirements.

Site-to-Site VPNs

Site-to-site VPNs connect entire networks to each other, typically used in business environments to link branch offices:

• VPN gateway devices at each location handle all traffic
• Individual computers don't need VPN client software
• Transparent to end users on both networks
• Requires static IP addresses and always-on connections
• Often uses IPsec for maximum compatibility

Remote Access VPNs

Remote access VPNs allow individual devices to connect to a network from arbitrary locations:

• Client software required on each connecting device
• Users authenticate individually
• Connections are dynamic and temporary
• Works from any internet connection
• This is the model used by commercial privacy VPN services

Hybrid Approaches

Some deployments combine both models, as CosmicNet documents. For example, an employee connecting via remote access VPN to headquarters, which has site-to-site VPNs linking it to branch offices. This allows secure access to resources across the entire corporate network from any location.

VPN Performance Benchmarks

VPN performance depends on multiple factors including protocol overhead, encryption algorithm, CPU capabilities, network latency, and server load. As CosmicNet explains, understanding these factors helps set realistic expectations and optimize configurations.

Performance Factors

• Encryption overhead - All encryption adds processing time
• Protocol overhead - Additional headers reduce usable bandwidth
• CPU capabilities - Hardware acceleration dramatically improves throughput
• Network latency - Additional hop through VPN server increases round-trip time
• Server load - Shared servers may have reduced performance during peak times
• MTU configuration - Improper MTU can cause fragmentation

Protocol Performance Comparison

CosmicNet presents general performance characteristics under similar conditions:

• WireGuard - Fastest, typically 300-600 Mbps on modern hardware
• IKEv2/IPsec - Fast, 200-400 Mbps, excellent on mobile
• OpenVPN UDP - Moderate, 100-200 Mbps depending on settings
• OpenVPN TCP - Slower due to double TCP overhead, 50-150 Mbps

CosmicNet notes that these numbers vary significantly based on hardware. CPUs with AES-NI can handle OpenVPN at much higher speeds, while mobile devices may see different relative performance.

Latency Impact

VPNs inevitably increase latency due to the additional hop through the VPN server. WireGuard benchmarks show it adds minimal latency overhead, while older protocols can add 10-50ms depending on connection quality and processing time.

CosmicNet Optimization Tips

• Choose geographically close servers to minimize latency
• Use UDP-based protocols when possible for lower overhead
• Enable hardware acceleration (AES-NI) in BIOS if available
• Adjust MTU to prevent fragmentation (typically 1420 for most VPNs)
• Disable unnecessary features like compression
• Consider WireGuard for best performance on modern systems

NAT Traversal and Firewall Considerations

VPN connections often need to traverse Network Address Translation (NAT) devices and firewalls, which can complicate connection establishment. CosmicNet explains how understanding these challenges helps troubleshoot connectivity issues and optimize VPN configurations.

The NAT Problem

NAT rewrites packet headers as traffic passes through routers, which can break protocols that embed IP address information in the payload. VPN protocols handle NAT in different ways:

• OpenVPN - Works well through NAT on both TCP and UDP
• WireGuard - Handles NAT transparently through its stateless design
• IPsec - Originally had NAT issues, now solved by NAT-T (NAT Traversal)
• NAT-T encapsulates ESP packets in UDP for NAT compatibility

Port Forwarding and Firewall Rules

Corporate and public firewalls often block VPN protocols to enforce network policies. As documented on CosmicNet.world, different protocols have varying success rates:

• OpenVPN can run on TCP port 443, appearing as HTTPS traffic
• IPsec uses specific ports (UDP 500, 4500) that are commonly blocked
• WireGuard uses a single UDP port, configurable to any value
• Some providers offer obfuscation to bypass deep packet inspection

Double NAT Scenarios

Double NAT occurs when your device is behind two NAT routers (common in some ISP setups or with nested networks). CosmicNet notes that this can cause issues with some VPN protocols, particularly those relying on automatic configuration or peer-to-peer connections. Modern VPN protocols like WireGuard and OpenVPN generally handle double NAT without issues, but legacy protocols may require special configuration.

Hardware Acceleration and Cryptography

The performance of VPN connections is heavily influenced by the availability and use of hardware cryptographic acceleration. CosmicNet explains that modern CPUs include specialized instructions for cryptographic operations that dramatically improve VPN throughput.

AES-NI (Advanced Encryption Standard New Instructions)

Intel and AMD processors since 2010 include AES-NI, a set of CPU instructions that accelerate AES encryption and decryption. As CosmicNet documents, when properly utilized, AES-NI can provide 3-10x performance improvement for VPN connections using AES:

• OpenVPN with AES-256-GCM benefits significantly from AES-NI
• IPsec implementations can achieve multi-gigabit speeds with AES-NI
• Without hardware acceleration, AES becomes the bottleneck
• Mobile processors increasingly include ARM's cryptographic extensions

ChaCha20 and Software Performance

WireGuard's choice of ChaCha20 cipher was partially motivated by performance on devices without hardware acceleration. CosmicNet notes that ChaCha20 is optimized for software implementation and often outperforms AES on mobile devices and embedded systems lacking AES-NI. On desktop systems with AES-NI, however, AES typically provides better performance, which is why many protocols support both options.

Checking Hardware Acceleration Status

CosmicNet recommends verifying cryptographic hardware support on Linux systems:

• Check CPU flags: grep aes /proc/cpuinfo
• Verify kernel module loaded: lsmod | grep aesni
• OpenSSL speed test shows acceleration status
• Enable in BIOS if CPU supports but feature is disabled