IM Engineer Study Notes
← Back to list
Networking
#VPN#IPSec#SSLVPN#터널링#ZTNA#133회#126회
Last updated · 2026-10-01

VPN (Virtual Private Network)

1. Overview

A. Definition

A technology that builds an encrypted virtual dedicated channel (tunnel) over a public network (the Internet), so that data physically traverses the public network yet is sent and received securely as if over a logically dedicated line.

The essence of a VPN is not "ownership" but "construction." Whereas a leased line gains security by exclusively owning a physical circuit, a VPN overlays software-based mechanisms—encryption, authentication, and integrity—onto an Internet circuit shared with others, producing a level of trust equivalent to exclusive ownership. In other words, even though countless packets traverse the same optical fiber together, a VPN erects a "logical wall" that only specific senders and receivers can open, effectively imitating a dedicated network.

B. Background and Necessity

Laying a physical leased line for inter-branch communication or for teleworkers accessing the corporate network is secure, but its cost explodes in proportion to region and distance. A Seoul–Busan leased line and a Seoul–New York leased line can differ in monthly rental cost by tens of times precisely because of this distance dependency, and binding globally scattered branches and remote workers entirely with leased lines is unrealistic even for large enterprises. The Internet is already deployed worldwide, so its marginal cost is effectively near zero, but as an open network where anyone can peek at packets, using it as-is carries a high risk of eavesdropping, tampering, and impersonation.

A VPN takes only the strengths of both, overlaying a tunnel imbued with encryption, authentication, and integrity on top of the cheap Internet, thereby achieving leased-line-grade security at far lower cost. Because a connection is established simply by "reaching the Internet," regardless of distance, a new branch or an employee on an overseas trip can gain secure access immediately without laying any circuit—scalability and agility being the decisive advantages over leased lines.

In particular, since the 2020s, as remote work became routine and corporate resources dispersed from on-premise data centers to the cloud (SaaS·IaaS), demand to "connect securely anytime, anywhere, from any device" surged. In the past, resources were concentrated within the physical perimeter of the office; now both users and resources are scattered beyond the perimeter. This shift elevated VPNs from an optional feature to basic infrastructure of corporate networks, and simultaneously created pressure to evolve toward next-generation models such as ZTNA, discussed later.

C. Characteristics

Three characteristics distinguish a VPN from other security technologies. First, virtualization: it creates a dedicated path through software configuration alone, without laying a new physical circuit. Second, end-to-end protection: encryption is maintained across the entire span between the two endpoints, not merely over a particular segment. Third, transparency: once a tunnel is up, upper-layer applications can communicate as-is without even knowing they operate over a VPN. These three combined produce the practical appeal of a VPN: "low cost, high trust, no modification."

2. Overall VPN Operation Structure

A VPN connection is clearly understood as two stages: "establishing the tunnel (control plane) → flowing data through the established tunnel (data plane)." The structure diagram below shows the full flow in which a tunnel forms between a remote user and the head-office gateway, and plaintext traffic travels through it encrypted.

flowchart LR
  subgraph Client["User device"]
    APP["Business app(plaintext)"] --> VC["VPN client(encryption)"]
  end
  VC -->|"Encrypted tunnel"| NET["Public Internet"]
  NET -->|"Encrypted tunnel"| GW["VPN gateway(decryption)"]
  subgraph HQ["Head-office internal network"]
    GW --> SRV["Business servers·DB"]
  end

Plaintext traffic generated at the device passes through the VPN client, where it is encapsulated and encrypted, then exits to the public Internet. Along the way, ISPs, routers, and relay nodes can see only the ciphertext and the outer header; they cannot learn the inner destination or contents. The gateway on the far side, at the other end of the tunnel, decrypts the packet back to its original plaintext and forwards it into the internal network. Thus the security perimeter shifts from the "physical circuit" to the two endpoints—the device's VPN client and the head-office gateway—and the entire span between these two endpoints becomes a single virtual dedicated segment.

The key in this structure is where encryption and decryption occur at the endpoints. Because encryption begins at the device and is undone at the gateway, plaintext is never exposed even if a packet is intercepted anywhere in between. However, "inside" the gateway, decrypted plaintext flows, so the structure simultaneously harbors the weakness that if the gateway itself is attacked, the interior is exposed directly. This weakness leads to the limits of the perimeter-based trust model discussed later.

3. IPSec VPN vs SSL VPN

flowchart LR
  subgraph IPSec["IPSec VPN · L3"]
    A["Head office"] --- B["Branch"]
  end
  subgraph SSL["SSL VPN · L4~7"]
    U["Remote user"] --- W["Web/App"]
  end

The difference between the two approaches originates in which layer of the network stack the tunnel is bored through, and that choice divides their uses. IPSec VPN encrypts the IP packet itself at the network layer (L3), so once the tunnel is up, all application traffic above it is protected transparently. Because the entire network is connected without the user being aware, it suits always-on branch-to-head-office connections (Site-to-Site), but it requires installing and configuring a dedicated client.

By contrast, SSL VPN protects at the transport-to-application layers (L4~7) with TLS and can be accessed with just a web browser, offering great install-free convenience. Instead, it opens access on a per-application basis, making fine-grained access control easy, which suits remote users (Remote Access) connecting from arbitrary locations. In short, the selection criterion is "connect the entire network (IPSec) or open only the needed apps (SSL)."

The layer difference directly translates into the granularity of security management. IPSec opens the entire network to a user who has entered the tunnel, making management simple but exposing a broad range once breached. SSL VPN can narrow privileges per application—"this user gets only groupware and the accounting web app"—which is advantageous for targets like partners and external personnel to whom only the minimum should be opened. In practice, it is common to run both in parallel: "IPSec for the inter-branch backbone, SSL VPN for individual telework and partner access."

Category IPSec VPN SSL VPN
Operating layer Network (L3) TransportApplication (L47)
Access method Dedicated client required Web browser (install-free)
Main use Always-on inter-branch (Site-to-Site) Remote user access (Remote Access)
Access scope Entire network Per-application unit
Security protocol ESP/AH, IKE TLS/SSL
Strength Broad, transparent connection Fine-grained access control, convenience

4. Core VPN Technology Elements and IPSec Details

flowchart LR
  T["Tunneling"] --> E["Encryption"]
  E --> A["Authentication"]
  A --> I["Integrity"]
  I --> K["Key management"]

A VPN's safety holds only when five elements interlock like a chain. Because the whole collapses if even one is missing, each element must be examined from the perspective of "why it is needed."

Tunneling is the skeleton that wraps the original packet in a new header (encapsulation) to pass it through the public network, using L2TP·PPTP, IPSec's ESP/AH, or SSL/TLS. Encapsulation plays the role of "carrying private-network packets with a different addressing scheme over the public network," but by itself it does not hide the contents. Therefore encryption (confidentiality) handles data confidentiality, masking the payload with a symmetric key such as AES. The reason a symmetric key is used is that bulk traffic must be processed quickly; asymmetric keys are slow and so are used only in a limited way for key exchange.

However, if the counterpart is a disguised attacker, encryption is meaningless, so authentication verifies both communicating ends with IKE, digital signatures, and certificates. Unless you confirm "is the party I am now encrypting and sending to really the head-office gateway," you are exposed directly to a man-in-the-middle (MITM) attack in which an attacker intercepts midway while pretending to be the gateway. Whether bits were manipulated in transit is detected by integrity via HMAC and hashes, preventing an attacker from arbitrarily scrambling the ciphertext to induce malfunction.

Finally, without key management that securely shares the symmetric key and changes it periodically, everything above collapses. Using the same key for a long time accumulates traffic and becomes vulnerable to cryptanalysis, so IKE (Internet Key Exchange) securely agrees on session keys via Diffie-Hellman (DH) exchange and periodically renegotiates (rekeying).

Element Description Representative technology
Tunneling Encapsulating the original packet L2TP·PPTP·IPSec(ESP/AH)·SSL/TLS
Encryption (Confidentiality) Data confidentiality Symmetric key (AES, etc.)
Authentication Verifying both ends' identities IKE·digital signatures·certificates
Integrity Detecting tampering HMAC·hashes
Key management Session-key exchange·renewal IKE

IPSec has two encapsulation modes. Transport mode encrypts only the payload and keeps the original IP header, used for end-to-end (host-to-host) communication, while Tunnel mode encrypts the entire packet including the original IP header and wraps it in a new header, used for gateway-to-gateway Site-to-Site connections. The reason tunnel mode also hides the original IP header is to avoid exposing to the outside which internal hosts behind the gateway are communicating (the internal topology).

An IPSec connection is established through two IKE phases. The sequence below depicts the flow in which phase 1 sets up a management security channel (IKE SA) and phase 2 agrees on the actual data tunnel (IPSec SA).

sequenceDiagram
  participant A as Initiator (branch GW)
  participant B as Responder (head-office GW)
  A->>B: "IKE Phase 1: DH exchange·mutual authentication"
  B-->>A: "IKE SA established (management channel)"
  A->>B: "IKE Phase 2: ESP parameter negotiation"
  B-->>A: "IPSec SA established (data tunnel)"
  A->>B: "Encrypted data transfer (ESP)"

In phase 1, both sides share a secret via DH exchange and authenticate each other with certificates or a pre-shared key (PSK) to create a secure management channel called the IKE SA. In phase 2, over that channel they negotiate the actual data-protection cipher suite and keys to establish the IPSec SA. Thanks to this design that "separates the negotiation channel from the data channel," the data keys can be renewed frequently without repeating heavy authentication each time, securing both performance and security at once.

5. Comparison and Cases

Looking at concrete application patterns makes the selection logic of the two approaches clear. When a certain global manufacturer binds its 30-odd branches worldwide, it configures an IPSec tunnel mode persistently on each branch router so that they use one another like a single corporate network. Employees access the internal ERP without being aware of the VPN, and connections automatically renegotiate even if dropped. By contrast, the same company provides an SSL VPN portal to teleworkers and outsourced staff, so that a mere browser login grants access only to a few authorized web systems. In an outsourcing environment where dedicated software cannot be installed on the laptop, install-free access is a great advantage.

A sense of the performance figures matters too. Encryption and decryption operations consume CPU, so processing them in software alone without dedicated crypto-acceleration hardware can create bottlenecks around several hundred Mbps to a few Gbps in high-bandwidth segments. That is why head-office gateway-class equipment usually embeds hardware acceleration such as AES-NI. As for attack cases, PPTP was historically known to be crackable within a few hours due to a vulnerability in MS-CHAPv2 authentication, so it is no longer recommended, and new deployments are converging on IPSec (IKEv2) or modern WireGuard-family options.

6. Deep Dive: Evolution to ZTNA·SASE

The most fundamental limitation of traditional VPNs lies in the perimeter-based trust model. Because "entering the tunnel" is treated as "being an insider," if one employee's account or device is compromised, an attacker can move laterally across the entire internal network through that tunnel. In reality, many large breaches followed the path of "initial intrusion with a stolen VPN account → internal spread," exposing the structural flaw of the "trust once, trust forever" model.

The alternative to this is ZTNA (Zero Trust Network Access). ZTNA does not treat "being attached to the network" as grounds for trust; instead it re-evaluates the user, device, and context (location, time, device security posture) at every moment of access to a resource. The access unit is also narrowed from the entire network to a specific application, so that even if one account is breached, lateral movement to anything but that one app is impossible. Furthermore, it reduces the attack surface by hiding the very existence of resources before access (Dark Cloud).

flowchart TB
  subgraph Legacy["Traditional VPN: perimeter trust"]
    L1["Enter tunnel"] --> L2["Trust entire internal network"]
  end
  subgraph ZT["ZTNA: continuous verification"]
    Z1["Access request"] --> Z2["Re-evaluate every access"]
    Z2 --> Z3["Allow only specific app"]
  end

Going further, SASE (Secure Access Service Edge) is a model that integrates security functions—ZTNA·SWG·CASB·FWaaS—and SD-WAN networking at the cloud edge, so that wherever users are, they receive security inspection and optimal-path routing together at the nearest PoP (point of presence). If a VPN is a backhaul structure that "first pulls everything to the head office, then exits," SASE "inspects at the edge and sends straight to the cloud," reducing latency. That said, VPNs are not disappearing immediately; many enterprises take a hybrid strategy of keeping the Site-to-Site backbone on IPSec while gradually transitioning only user remote access to ZTNA.

7. Considerations and Implications

  • Balancing performance and security (split tunneling): Since encryption/decryption induces CPU·bandwidth overhead, instead of sending all traffic through the tunnel, one can compromise performance with split tunneling, which tunnels only internal destinations and lets ordinary Internet traffic exit directly. However, the split segment bypasses security inspection, so policy lines must be drawn, such as forcing a full tunnel for sensitive work.
  • Limits of perimeter-based trust and combining zero trust: Even while keeping a VPN, the equation "access = trust" must be broken. It should be combined with zero-trust principles that evaluate the user, device, and context at every access, and operated in the direction of blocking lateral movement by narrowing the access unit from the network to the application.
  • Strengthening authentication and preparing for account takeover: Since VPN account takeover is a principal initial path of breaches, one must move beyond password-only authentication and make MFA (multi-factor authentication) and device-trust verification (device certificates·EDR integration) mandatory.
  • Keeping cipher suites and protocols current: Remove vulnerable protocols such as PPTP, maintain current standards like IKEv2·TLS 1.3 and sufficient key lengths (AES-256, etc.), and proactively review a roadmap for migrating to post-quantum cryptography (PQC).
  • Designing for availability and scalability: Now that VPNs have become essential infrastructure due to routine remote work, they must be designed through gateway redundancy, load balancing, and concurrent-session capacity planning so that service does not drop even during access surges at particular moments.

References

In one line: A VPN is a low-cost security technology that builds a virtual dedicated network with an encrypted tunnel over a public network, divided into network-layer IPSec (inter-branch) and application-layer SSL (remote access), with tunneling·encryption·authentication·integrity·key-management as its core elements, and it is evolving beyond the limits of perimeter trust toward ZTNA·SASE that verify every access.