VPN Technologies

VPN Technologies Beyond IPsec

A Virtual Private Network (VPN) creates a logical connection between endpoints across a public or shared network. Encryption, authentication, and integrity depend on the protocol and its configuration. IPsec is a broad framework for building such tunnels, while other technologies use different transport, authentication, and key-management models. Each option therefore has a distinct scope, deployment requirement, and limitation.

These differences affect the protection provided, firewall traversal, client requirements, and operational work. PPTP is a historical protocol with documented weaknesses. SSL/TLS VPNs use TLS mechanisms and can expose selected resources through a browser or a client application. WireGuard uses a small, fixed set of cryptographic primitives and UDP transport. PPTP, L2TP/IPsec, SSL/TLS VPNs, and WireGuard differ in tunnel encapsulation, client support, and the mechanisms used to establish protected communication.

PPTP (Point-to-Point Tunneling Protocol): A Historical Protocol

The Point-to-Point Tunneling Protocol, or PPTP, was among the first widely deployed VPN protocols. It was developed in the mid-1990s by a consortium that included Microsoft. Its goal was to simplify remote access to organizational networks over dial-up links, before broadband Internet access became common. The PPTP specification describes connection control, a GRE tunnel, and the transport of PPP frames.

How PPTP Works

PPTP creates a tunnel using Generic Routing Encapsulation (GRE). GRE carries frames from the Point-to-Point Protocol (PPP), while the PPTP control channel uses TCP port $1723$. GRE has IP protocol number $47$ and encapsulates PPP frames in IP packets. This mechanism separates session control from data transport.

In the PPP layer, PPTP commonly used authentication methods such as Microsoft's MS-CHAP and MS-CHAPv2. Data encryption was usually provided by MPPE (Microsoft Point-to-Point Encryption), which in older deployments used RC4 with 40-bit or 128-bit keys. The presence of an encryption mechanism does not remove weaknesses in authentication or the lack of independent integrity protection.

PPTP Security Limitations

PPTP is an obsolete protocol that should not be used to protect communications. MPPE relies on the deprecated RC4 cipher, and MS-CHAPv2 has documented cryptographic weaknesses that permit attacks against a captured authentication exchange. The described PPTP profile does not provide the modern confidentiality and integrity expected for remote access.

Capturing an MS-CHAPv2 exchange can allow recovery of authentication material, while the weaknesses in MPPE limit the protection of the resulting traffic. Attack effectiveness depends on configuration, password strength, and access to authentication material. Computational cost alone is not a sound basis for treating PPTP as secure.

PPTP should be disabled in new deployments and replaced with a protocol that provides current authentication, integrity protection, and key management. In a legacy system, its use should be recorded as a risk with a migration plan. Keeping PPTP in the comparison is useful because it shows that GRE tunneling and PPP encryption alone do not satisfy current VPN security requirements.

L2TP (Layer 2 Tunneling Protocol): Tunneling without Encryption

The Layer 2 Tunneling Protocol (L2TP) combined elements of PPTP with Cisco's L2F (Layer 2 Forwarding). The protocol transports PPP frames in L2TP sessions and tunnels, usually using UDP port $1701$.

L2TP itself provides tunneling and session multiplexing. It encapsulates PPP frames and carries control messages between tunnel endpoints. It does not provide data confidentiality, so an intercepted packet can expose its contents without a separate protection layer. L2TP is a transport mechanism; IPsec or another policy-approved protocol must supply security functions.

L2TP over IPsec: Separating the Roles

The combination of L2TP and IPsec separates tunneling from protection. L2TP handles the session and PPP-frame transport, while IPsec ESP protects the L2TP packets. The resulting protection depends on negotiated algorithms, authentication, keys, and gateway configuration. The roles are therefore separated:

• L2TP establishes the communication tunnel, negotiates sessions, and encapsulates data, typically PPP frames. It manages tunnel and session identifiers between the client and server.
• IPsec (specifically ESP) protects the L2TP packet. ESP can provide confidentiality, integrity, source authentication, and anti-replay protection, which L2TP does not provide by itself.

The combination adds encapsulation layers: a PPP frame is carried by L2TP, and the L2TP packet is carried by ESP. Compared with an IPsec profile without L2TP, it adds header and processing overhead. The actual cost depends on hardware, algorithms, and packet size.

Advantages and Disadvantages of L2TP/IPsec

• Protection: With correctly configured IPsec, current algorithms, and proper authentication, L2TP/IPsec can provide confidentiality, integrity, and anti-replay protection.
• Native Client: Many operating systems include L2TP/IPsec support, so some environments do not require an additional client. Availability and vendor recommendations depend on the system version.
• Complexity and Firewalls: L2TP uses UDP $1701$, IPsec ESP uses IP protocol $50$, and IKE uses UDP $500$. With address translation, IPsec can use UDP $4500$ through NAT-T. The firewall policy must permit the required traffic set.

SSL/TLS VPNs: Access through TLS

HTTPS uses TLS to protect an application connection to a server. The same protocol can secure remote access to organizational resources. An SSL/TLS VPN uses TLS authentication and record protection; the gateway determines which resources are exposed and in which mode.

A common advantage of an SSL/TLS VPN is the ability to use TCP $443$, a port often permitted for HTTPS. This does not automatically bypass a firewall: an organization can filter connections, inspect TLS, or block unknown gateways. In hotel, airport, and other restrictive networks, this transport profile may be easier to accommodate than IPsec, but the result depends on network policy.

SSL/TLS VPNs typically come in two flavors:

1. SSL Portal VPN (Clientless)

This is the simplest form of SSL VPN. The user does not need to install any dedicated VPN client software on their computer. They simply open a web browser, navigate to a special secure web portal provided by their organization, and log in.

The portal then acts as a secure gateway, presenting the user with a webpage containing links to internal company resources like email, file shares, or internal applications. When the user clicks a link, the SSL VPN gateway fetches the content from the internal server on their behalf and securely presents it within their browser.

The solution provides secure access to a limited set of web-based applications but does not provide full network access.

2. SSL Tunnel VPN (Full Tunnel)

For full network access, an SSL Tunnel VPN is used. This mode requires a client application on the user's device. Historically, deployments used Java or ActiveX applets downloaded from the portal; current deployments generally use standalone client programs.

This client software creates a virtual network interface and establishes a TLS tunnel to the VPN gateway. It then routes all or some of the computer's traffic through the encrypted tunnel, depending on configuration. The user can access network resources in a way similar to a traditional IPsec VPN. Many deployments use TCP $443$, while some also use UDP or DTLS, so the transport depends on the product. OpenVPN is a popular open-source project that uses TLS for its control channel and can operate over TCP or UDP.

WireGuard: A Simple VPN Protocol

WireGuard is a VPN protocol designed around simple configuration, current cryptographic primitives, and UDP transport. Its peer-to-peer model uses public keys, assigned addresses, and allowed traffic prefixes.

The Philosophy of Simplicity

IPsec and OpenVPN include many operating modes, negotiation mechanisms, and compatibility options. This flexibility increases the implementation scope and the number of settings that an audit must examine. WireGuard limits protocol state, primitive selection, and configuration format. The smaller feature set supports code review and configuration analysis, while security still depends on the implementation, private-key protection, and routing rules.

A Fixed Cryptographic Set

WireGuard defines one cryptographic primitive set instead of negotiating many optional suites. Limiting the choice supports implementation consistency and reduces the chance of enabling an unsuitable algorithm. The protocol uses:

• ChaCha20 and Poly1305 in an AEAD construction for encryption and data authentication.
• Curve25519 for ECDH key exchange between peers.
• BLAKE2s and HKDF for hashing and key derivation.
• SipHash24 for hash-table key protection.

The fixed set limits cryptographic configuration choices, but it does not replace key management, software updates, or access control. Administrators still have to protect private keys and define the permitted addresses correctly.

Performance and Mobility

WireGuard operates exclusively over UDP. It has an implementation in the Linux kernel and implementations for other systems; its limited protocol state and lack of multi-suite negotiation reduce control overhead. Throughput and latency depend on the implementation, processor, MTU, and path, so comparison with IPsec or OpenVPN requires measurements in the target environment.

WireGuard can update a peer endpoint after receiving a correctly authenticated packet. This helps when an endpoint changes from Wi-Fi to a cellular network; a periodic keepalive can assist with NAT mappings. WireGuard is available in the Linux kernel and has clients for major platforms, but a deployment still requires separate checks of routing, firewall policy, and key distribution.

Summary and Selection Criteria

VPN technologies differ in protection scope, transport, client support, and administration. The table summarizes typical properties; a final assessment must check the protocol version, configuration, and organizational policy.

For a new VPN deployment, the choice between OpenVPN, another SSL/TLS VPN, and WireGuard should follow requirements for clients, transport, routing, and key management. L2TP/IPsec can remain an option where built-in clients are required and its dependencies and limitations are accepted. PPTP should not protect confidential communication. Understanding the protocols helps users and administrators determine which data is protected, where the tunnel ends, and which risks remain at endpoints and on the public network.