What Is an IPsec VPN? How Secure Tunnels Protect Traffic Across the Internet
Learn what an IPsec VPN is, how IKE and IPsec work together, and why organizations use encrypted tunnels to protect traffic between devices and networks.
An IPsec VPN creates a protected connection between devices or networks that need to communicate across an untrusted network such as the public internet. Instead of sending ordinary IP traffic directly between those endpoints, the VPN protects the packets before they leave one side and verifies and decrypts them when they reach the other.
IPsec stands for Internet Protocol Security. It is a family of protocols used to protect IP traffic by providing encryption, integrity checking, and authentication. In many VPN deployments, IKE first establishes and authenticates the secure relationship between the endpoints, and IPsec then protects the actual data flowing through it, the same layered idea behind what a VPN is.
The result is what people commonly call an encrypted VPN tunnel.
Private network A
│
▼
IPsec gateway
║
║ encrypted IPsec tunnel
║ across the internet
▼
IPsec gateway
│
▼
Private network B
This architecture is widely used for site-to-site VPNs, where entire networks need to communicate securely, and for remote-access VPNs, where an individual device connects back to a private network.
IPsec Protects IP Packets Rather Than One Particular Application
One of IPsec’s defining characteristics is that it operates at the IP layer. It does not need every application to implement its own special VPN protocol.
A web application, database connection, file service, or another IP-based application can send traffic normally. The IPsec implementation protects that traffic according to the security policy configured on the device or VPN gateway, which is one reason APIs and other higher-level services can ride across the tunnel without changing their own protocols.
That gives IPsec a broad scope. Instead of saying, “encrypt this one browser connection,” the network can say, “traffic between these networks must travel through IPsec.”
For example, a company might have one office using the network 10.10.0.0/16 and another using 10.20.0.0/16. The gateways can be configured so that traffic between those private networks is automatically protected before crossing the internet.
Applications inside either office may not need to know that IPsec exists at all.
IKE Establishes the Secure Relationship First
Before two IPsec endpoints can securely exchange protected traffic, they need to agree on how that protection will work.
This is where IKE, the Internet Key Exchange protocol, comes in, as specified in RFC 7296 for IKEv2.
IKE allows the endpoints to authenticate each other, negotiate cryptographic parameters, and establish the keys and security associations required by IPsec. Depending on the deployment, authentication may use pre-shared keys, digital certificates, or other supported credentials.
A simplified sequence looks like this:
VPN endpoint A VPN endpoint B
│ │
│──── IKE negotiation ────────►│
│◄── authentication / keys ────│
│ │
│════ protected IPsec traffic ═│
The distinction matters because IKE and IPsec are doing related but different jobs. IKE establishes and manages the secure connection; IPsec protects the network traffic that uses it.
Modern deployments commonly use IKEv2, which improves several areas of connection management compared with older IKE versions and is widely supported by operating systems, firewalls, and VPN appliances.
IPsec Encrypts and Verifies the Data
Once the required security associations have been established, IPsec can protect packets crossing the tunnel.
Encryption provides confidentiality. Someone intercepting the protected traffic somewhere between the VPN endpoints should not be able to read the original packet contents without the relevant cryptographic keys, the same property discussed more broadly in SSL certificate chains.
IPsec also provides integrity protection. The receiver can verify that protected data was not modified while in transit. If an attacker changes a packet, the integrity check should fail and the packet can be rejected rather than silently accepted as legitimate.
Authentication is another important property. The VPN endpoints establish trust so that each side can determine that protected traffic belongs to the expected secure relationship rather than an arbitrary sender.
Together, these properties address three important network risks: someone reading the traffic, someone modifying it, and someone impersonating a trusted VPN endpoint.
ESP Carries Most Modern IPsec VPN Traffic
The IPsec family includes several components, but Encapsulating Security Payload, or ESP, is the protocol most commonly associated with modern encrypted IPsec VPNs, as defined in RFC 4303.
ESP can provide encryption as well as integrity and authentication protection for network traffic. In tunnel deployments, the original IP packet is protected and carried inside a new IP packet that allows the encrypted data to cross the intervening network.
Conceptually:
Original private packet
↓
Protected by IPsec ESP
↓
New packet crosses internet
↓
Remote gateway verifies/decrypts
↓
Original packet forwarded
This encapsulation is what allows two private networks to communicate over the public internet without exposing their internal traffic in its normal form.
Older descriptions of IPsec may also mention the Authentication Header, or AH. AH focuses on authentication and integrity rather than confidentiality, but ESP is far more common in ordinary VPN deployments because encryption is usually required and ESP works better with many real-world network configurations.
Site-to-Site VPNs Connect Entire Networks
A common IPsec use case is a site-to-site VPN.
Imagine a company with offices in Auckland and Sydney. Each office has its own local private network, but employees and services need to communicate across both locations.
Instead of exposing internal services directly to the internet, the organization can establish an IPsec tunnel between the two network gateways.
Traffic between the approved private networks is routed into that tunnel, encrypted, sent across the internet, and decrypted by the gateway at the other site. From the perspective of devices inside the offices, the remote network can behave much like another reachable private network.
This design is especially useful because individual employees usually do not need to start a VPN client manually. The gateways maintain the secure connection on behalf of the networks behind them.
Site-to-site IPsec is also common between an organization’s office network and a cloud environment. A company may connect its on-premises network to a private network hosted by a cloud provider so that internal applications can communicate without making every service publicly accessible, a pattern closely related to VPN vs proxy and other network-boundary decisions.
Remote Access Protects Individual Users
IPsec can also support remote-access VPNs.
In this model, the remote endpoint is an individual device rather than another network gateway. A laptop outside the office establishes an authenticated VPN connection to the organization’s VPN server or firewall.
Once connected, traffic intended for private company resources can travel through the encrypted tunnel.
A remote employee might then access internal dashboards, development systems, file services, or administrative tools that are not reachable directly from the public internet.
The underlying idea is the same as site-to-site IPsec, but the endpoints and access model differ. Site-to-site VPNs generally connect networks continuously, while remote-access VPNs connect individual users or devices as needed.
Remote access also places more importance on user authentication, endpoint security, and authorization. Establishing the tunnel should not automatically grant unrestricted access to every internal system.
Tunnel Mode Is What Most People Picture as a VPN
IPsec can operate in different modes, but tunnel mode is the one most closely associated with VPNs.
In tunnel mode, the original IP packet is protected as part of the encapsulated payload, and a new outer IP header is added so the packet can travel between the IPsec endpoints.
This is useful when private packets need to cross a public network.
For example, a packet may originally be addressed from one private host to another:
10.10.1.25 → 10.20.4.8
Those private addresses are meaningful inside the connected networks, but the internet cannot simply route the packet between them. The VPN gateways wrap and protect that traffic inside packets addressed between the gateways’ public network addresses.
At the remote side, the outer protection is removed and the original private packet continues toward its intended destination.
IPsec also has transport-mode uses, where protection is applied differently and the original IP header remains visible. For ordinary site-to-site VPN explanations, however, tunnel mode is the most relevant mental model.
NAT Can Complicate IPsec Connections
Real networks often use Network Address Translation, or NAT. Home routers, office firewalls, and mobile networks frequently translate private addresses into public ones before sending traffic to the internet.
That can create complications for some IPsec traffic because the packet structure and addressing can change while the packet is in transit.
Modern IPsec deployments commonly handle this using NAT Traversal, often abbreviated NAT-T. Instead of trying to send ESP directly through a NAT device, the IPsec traffic can be encapsulated so it passes through NAT more reliably, which is the deployment reality described in RFC 3947.
This is one reason IKE and IPsec implementations need to do more than simply “turn on encryption.” They also have to work with the practical realities of firewalls, address translation, changing networks, and intermediate infrastructure.
The Tunnel Protects Traffic Between the VPN Endpoints
The phrase “secure tunnel” can sound as though every part of the communication becomes secure automatically. The protection has a specific boundary.
If two gateways establish an IPsec tunnel, IPsec protects traffic while it moves between those gateways. Once the remote gateway decrypts the packet, it continues across the destination network according to that network’s normal security controls.
That means this:
Office device ─► VPN gateway ═══► VPN gateway ─► Server
IPsec
does not imply that IPsec itself encrypts the final local segment from the remote gateway to the server.
Other protections may still be used there. An HTTPS application can continue using HTTPS, database encryption can protect a database connection, and access controls can restrict which users or devices are allowed to reach the destination, which is why NIST’s zero trust guidance still matters even inside a tunnel.
IPsec protects an important part of the network path, but it does not replace every other layer of security.
Encryption Does Not Remove the Need for Access Control
A VPN establishes a protected route. It does not automatically determine what someone should be allowed to do after they use that route.
Suppose a remote user successfully establishes an IPsec VPN connection. The organization still needs rules deciding whether that user can access a source-code repository, finance system, production database, or administrative interface.
Good VPN design therefore combines network protection with authentication and authorization, much like two-factor authentication strengthens access decisions above the network layer.
The tunnel answers:
Can this traffic cross the network securely?
Access-control systems still need to answer:
Should this user or device be allowed to reach this resource?
Treating everyone connected to the VPN as fully trusted can create a large security boundary. Modern network designs often restrict access further based on identity, device posture, network segment, or application sensitivity.
IPsec Protects Against Eavesdropping and Tampering, Not Every Threat
An IPsec VPN provides strong protections for traffic in transit when correctly configured. An attacker observing the internet path should not be able to read encrypted payloads, and modified protected packets should fail integrity verification.
But IPsec cannot protect a compromised endpoint.
If malware already controls the laptop before traffic enters the VPN tunnel, encrypting that traffic does not remove the malware. Likewise, if an authorized user sends harmful commands through the VPN, the tunnel faithfully protects those commands while they travel.
IPsec also does not replace patching, endpoint security, strong authentication, application security, or monitoring, a broader defense-in-depth point also reflected in Cisco’s IPsec VPN overview.
The correct interpretation is that IPsec protects network communication between trusted VPN endpoints. It is one security layer, not a complete security architecture by itself.
The Core Flow Is IKE First, Protected Traffic Second
The easiest way to understand an IPsec VPN is to separate connection setup from data transfer.
First, IKE establishes trust and negotiates the connection. The endpoints authenticate one another, agree on cryptographic settings, and derive the information needed to protect traffic.
Then IPsec carries the protected data. Packets matching the VPN policy are encrypted and integrity-protected, sent across the internet, verified at the remote endpoint, and forwarded toward their destination.
That gives the whole process a simple structure:
IKE → authenticate and establish keys → IPsec → encrypt and protect packets → internet → remote endpoint → verify and decrypt.
Site-to-site deployments use that model to connect entire private networks, while remote-access deployments use it to connect individual devices to protected resources.
An IPsec VPN is therefore best understood as a secure network path: IKE establishes and authenticates the relationship between the endpoints, and IPsec protects the actual packets so they can cross an untrusted network without being read or silently altered in transit.