VPN

A VPN builds an encrypted tunnel through public networks and thereby connects sites or individual devices to the company network. This article explains how it works, its forms of use, and the limits of the model when employees access distributed applications from anywhere.

Hardly any technology has shaped remote access as much as the Virtual Private Network. For decades, companies have used it to couple sites over the internet and bring employees into the corporate network, on a large scale at the latest since many teams moved to home offices. The technology is also ubiquitous for connecting cloud environments and partners. At the same time, the model shows its limits: whoever dials in often stands in the entire network at once, central gateways slow down traffic, and the dial-in points themselves are a popular attack target. A sober look at how it works and where it reaches its limits is therefore worthwhile.

What is a VPN?

A VPN (Virtual Private Network) builds an encrypted tunnel through a public network, usually the internet. Within this tunnel, data packets travel protected from eavesdropping and manipulation, as if both sides were directly cabled together. Two basic forms shape enterprise use: a site-to-site VPN connects entire networks to one another, for example headquarters to a branch office or to a cloud environment. A remote access VPN, by contrast, connects individual end devices to the corporate network, typically via a client on the notebook. Common protocols are IPsec, TLS-based methods, and WireGuard.

Depending on the protocol, the tunnel operates at the network layer or above it and transports any application, from file services to database connections. It is precisely this property that makes the VPN versatile and at the same time coarse: it connects networks, not individual applications.

How it works

The process follows the same pattern in all variants, regardless of the protocol used:

Authentication: Client and gateway prove their identity, via certificates, credentials, or both. Only then is the tunnel established.
Key exchange: Both sides negotiate session keys, with IPsec the IKE protocol handles this step.
Encapsulation and encryption: Original packets are encrypted, packaged into new packets, and transported over the public network. At the end of the tunnel, they are unpacked and decrypted.
Address assignment: With remote access, the end device receives an internal address and behaves as if it were inside the corporate network.
Routing: Either all traffic runs through the tunnel or only the traffic to internal destinations. The latter is called split tunneling and relieves the gateway, but shifts control of internet traffic to the end device.
Operation: On the company side, firewalls or dedicated concentrators terminate the tunnels. They need ongoing updates, capacity planning, and monitoring, because they are reachable from the internet.

Why it matters

Encryption protects data on its way through public networks from eavesdropping and alteration.
Sites can be coupled economically without dedicated leased lines.
Employees reach internal systems from the home office and on the move.
Cloud environments are connected to the corporate network in a controlled manner via site-to-site tunnels.
Established protocols such as IPsec and WireGuard are widely supported and well documented.
For many audits and contracts, encrypted transmission is a basic requirement that a VPN reliably fulfills.

Typical scenarios

A manufacturing company couples its plant and headquarters via a site-to-site tunnel so that ERP access and machine data flow securely.
A service provider is given time-limited remote access to a maintenance system, and the access is deactivated after the project ends.
Employees in the home office reach file servers and internal applications via the VPN client.
A cloud environment is connected to the data center via IPsec until a more modern connection is in place.
For administrators, a separate, strictly secured VPN access remains in place as an emergency route, while regular access already runs via ZTNA.

VPN or ZTNA: where is the difference?

A remote access VPN effectively places the end device into the corporate network. After dial-in, far more is often reachable than the task requires, and a compromised device can move laterally through the network. On top of this come two structural problems: all traffic flows through central gateways that become a bottleneck, and it is precisely these gateways that stand open on the internet, which is why vulnerabilities in VPN products are regularly and actively exploited. ZTNA reverses the principle: access is granted per application, only after verification of identity and device state, and the applications remain invisible from the outside. In modern SASE/SSE platforms , ZTNA is the building block that replaces the dial-in VPN. The switch succeeds step by step: first, standard applications and external access move to ZTNA, while the VPN remains in place for a transitional period for special cases such as older protocols.

KAEMI as your partner

KAEMI operates secure site connectivity and remote access as a managed service and objectively assesses where a VPN remains the right choice and where more modern methods take over. For coupling sites, SD-WAN replaces rigid tunnel architectures with centrally controlled, application-aware connections. For access by employees and external parties, the path usually leads to ZTNA as part of SASE/SSE: Secure Access . In doing so, we ensure an orderly transition: existing tunnels keep running until every application has an equivalent or better access route. If you want to modernize your remote access, get in touch .

Frequently asked questions about VPN

What is the difference between a site-to-site and a remote access VPN?

A site-to-site VPN connects entire networks via gateways, for example headquarters and a branch office, and the end devices notice nothing of it. A remote access VPN connects individual devices to the corporate network via a client. Site-to-site tunnels run permanently and are operated centrally, remote access is created per session and depends on the login of the respective person.

Why are VPN gateways considered a popular attack target?

VPN gateways have to be reachable from the internet so that users can dial in. Attackers therefore specifically scan for known vulnerabilities in these systems and sometimes exploit them within a few days of disclosure. Anyone operating a VPN therefore needs very short patch cycles, MFA for all access, and monitoring of logins.

Does a VPN make the connection noticeably slower?

The encryption itself costs little performance on modern hardware. What becomes noticeable is rather the detour: if all traffic runs through a central gateway, the path to cloud services lengthens considerably, and the gateway becomes a bottleneck at peak times. Split tunneling mitigates this but opens up uncontrolled internet traffic on the end device.

Is a VPN still up to date?

For coupling sites and cloud environments, the technology remains solid, and there it increasingly runs as a building block within SD-WAN. For remote access by people, by contrast, the standard is shifting to ZTNA, because application-specific access offers a smaller attack surface. The answer therefore depends on the purpose, an immediate complete exit is rarely necessary.

Does ZTNA replace the VPN entirely?

For access to applications, ZTNA replaces the dial-in VPN in most cases. Exceptions remain scenarios that require genuine network access, such as older protocols, administration routes, or the coupling of entire sites. In practice, the two methods therefore run in parallel for a while, until the remaining special cases are cleanly replaced or deliberately retained.