IPsec VPN sounds like a term from network documentation, but in practice, it describes a very specific thing: a way for company data to travel across the internet "in a secure envelope." IPsec operates at the network layer (IP layer) and can provide key security services – confidentiality (encryption), integrity (protection against changes along the way), and authentication (assurance of who is on the other end).
For this "tunnel" to even be created, there's still a need to agree on rules and keys – this is handled by IKE (usually IKEv2). IKE allows the two ends of the connection to authenticate each other and determine exactly how to protect traffic.
In this article, we'll explain IPsec VPN: what it is, how it works, and why organizations so often choose it for location connectivity and remote work. No "magic" or configuration required – you'll understand the concepts most frequently encountered in conversations with your administrator or IT provider.
IPsec VPN – What It Is and Why Companies Still Use It
Is IPsec VPN "just another kind of VPN"? Yes, but with an important difference: IPsec It operates at the network level (IP layer), protecting traffic at the source before it reaches the application. It's not a single program, but a set of standards that collectively ensure secure transmission across IP networks.
In practice, IPsec VPN was created to allow data to be transferred over public networks (e.g., the internet) in a controlled and secure manner. The easiest way to think of it is as safe corridor between two points – data still „travels through the Internet”, but is protected according to established rules.
What protection does IPsec provide?
IPsec is designed to provide three key "security services" for network traffic: confidentiality, integrity, and authentication (verification of who is on the other end). This is formally described in the IPsec architecture in RFC 4301, and practical implementation guidelines are published by NIST, among others.
The most important benefits for business are usually two:
• Securely connect locations and resources – e.g. office, warehouse, branch, server room – so that the traffic between them is not „in plain sight”.
• Consistent traffic protection rules – IPsec allows you to specify exactly what needs to be protected and how, instead of relying solely on the security of individual applications.
Why does this even exist when we have HTTPS and encrypted applications?
This is a common question. HTTPS is great for securing communication between a specific application (e.g., a browser and a service). IPsec solves a different problem: protects network traffic more "systemically"„, regardless of whether we're talking about a single application or multiple services, servers, and devices running simultaneously within a company. That's why IPsec is so popular in site-to-site connections and classic corporate deployments.
At the end of this section, it is worth remembering one sentence: IPsec VPN is a standard way to build a secure tunnel at the IP level to protect traffic between networks or devices according to clearly defined rules.
How IPsec VPN works in practice – a step-by-step mechanism„
What actually happens when you set up an IPsec VPN? In simple terms: two ends of the connection (e.g. two firewalls or a computer and a gateway) VPN) firstly establish the principles of cooperation, and only then do they start protect and transmit the right traffic. IPsec is a security standard for traffic at the IP layer, so it thinks about data a bit differently than applications – it's interested in "network traffic," not a single website or service.
1) First, decide: what should go through the VPN anyway?
In a typical implementation, IPsec acts as a "set of security rules for traffic." The device evaluates packets and decides whether the traffic:
• is to be sent normally,
• is to be rejected,
• whether it should be covered by IPsec protection (i.e. go into the tunnel).
In IPsec documents you will come across terms like "policy" and "security associations" – it is a way of describing, what traffic we protect and by what methods.
2) Then "negotiating the details": IKE creates a secure basis
For the tunnel to be safe, the parties must:
• mutually authenticate (e.g. with a shared key or certificate),
• establish protection algorithms and parameters,
• exchange cryptographic keys in a controlled manner.
This is the role IKE (most often IKEv2) – a protocol that compiles and maintains the security „agreements” (Security Associations) needed for IPsec to function.
A good business analogy: IKE is like procedure for agreeing on rules and issuing identifiers, and IPsec/ESP is just proper, protected transport. First, we determine "who, with whom, and on what terms," and only then does the "cargo" go.
3) Proper transmission: traffic flows in the tunnel and the keys are periodically refreshed
Once the parameters are established, IPsec begins protecting traffic—usually through the ESP mechanism (most commonly found in VPNs), ensuring confidentiality and integrity. Important: these protections are not "set once and for all." The tunnel has lifetimes and can be renewed (rekeyed) to mitigate risk and maintain operational stability.
4) What about NAT and the "strange ports" 500/4500?
Many networks use NAT (address translation) along the way. IPsec has a standard solution for this: NAT Traversal (NAT-T), where ESP can be encapsulated in UDP – usually on port 4500, after this has been agreed upon during IKE. This is why in practice you often see UDP ports 500 (IKE) and UDP 4500 (IKE/ESP over NAT).
In summary, IPsec VPN works as a set of rules + a policy negotiation mechanism (IKEv2) + the actual data protection and transmission (usually ESP). This allows traffic to pass through the internet in a controlled, encrypted, and sustainable manner.
What does IPsec consist of – ESP, AH, tunnel and transport modes?
Why do abbreviations like ESP, AH, and "tunnel mode" appear in IPsec descriptions? Because IPsec isn't a single protocol. It's a set of elements that can be combined depending on the purpose: whether you want to encrypt data, authenticate it, or what part of the IP packet you are protected. These principles are described in the IPsec architecture (RFC 4301), and specific "building blocks" have separate specifications.
ESP – the most common IPsec VPN „engine”
ESP (Encapsulating Security Payload) is the IPsec element that, in practice, most often stands for what is commonly called "IPsec VPN." ESP can provide:
• confidentiality (i.e. data encryption),
• data integrity and origin authentication (i.e., the certainty that the packet has not been changed along the way and comes from the correct party),
• protection against repetition (anti-replay), which limits attempts to "play back" captured traffic.
There is one important thing to note: ESP protects above all load (payload) – IP headers usually need to remain "readable" to the network to some extent, otherwise the packet won't reach its destination. This is one reason why the mode of operation (tunnel/transport) really matters.
AH – Integrity Without Encryption (and Why You See It Less Often Today)
AH (Authentication Header) provides:
• integrity (protection against modification),
• authentication of data origin,
• and anti-replay protection,
But does not provide confidentiality, i.e. it does not encrypt the content.
In practice AH is less common today, because a similar effect (integrity without encryption) can also be achieved through ESP, using so-called "null encryption" or algorithms ensuring integrity without confidentiality. NIST explicitly indicates that ESP can replace AH in such scenarios.
Transport mode and tunnel mode – what exactly is „inside” the protection?
This is the most important difference that is worth understanding without going into configurations.
Transport mode
• IPsec protects mainly package load, and the "outer" IP header remains the header of the same packet.
• The simplest way: you secure your communication host-host (e.g. two specific devices).
Tunnel mode
• IPsec "packs"„ the entire original IP package inside and adds a new outer IP header.
• The simplest way: you build a tunnel gate-gate (site-to-site) or user-gateway, where the edge device "represents" the network on its side.
Tunnel mode is most common in corporate VPNs., because it's a natural fit for connecting networks and working through security gateways. NIST emphasizes that ESP in tunnel mode is very common in real-world implementations.
In summary, you'll most often encounter IPsec in the "ESP + tunnel mode" version, as it provides encryption and supports connections between networks well. AH exists and makes sense in certain cases, but in many implementations, its role is taken over by ESP configured for integrity.
The two most common IPsec VPN models in the company – site-to-site and remote access
Which type of IPsec VPN are you most likely to encounter in companies? Usually one of two: connection site-to-site or user-network (remote access). Both use the same fundamentals of IPsec (IP layer traffic protection) and IKE (security negotiation), but differ in their purpose, the "participants" in the connection, and what day-to-day use looks like.
1) IPsec site-to-site: a secure "bridge" between sites
Is this a solution for companies with branches, warehouses, or hybrid work? Very often, yes. In the site-to-site model, you connect two local networks (e.g., an office and a warehouse) so that selected traffic between them is sent through an encrypted tunnel. VPN gateways (firewalls/edge devices) are most often the ends of the connection, and users in the middle of the network usually don't need to click anything – everything happens "in the background.".
What does this mean in practice (without technical jargon, but precisely):
• A stable, predictable connection between locations, so that systems can operate as if they were on one network (of course, within the scope of established rules).
• Consistent traffic protection rules – you can protect specific subnets and services, instead of relying solely on the security of individual applications.
The most common business context:
• headquarters – branch
• office – warehouse / production
• connection with a partner (B2B), when you exchange data system-to-system
2) IPsec remote access: secure user access to company resources
What if the problem isn't locations, but remote work? This is where the remote access model comes in: a single user (e.g., a laptop) establishes an IPsec tunnel to a VPN gateway to access corporate resources in accordance with security policies. This approach is often based on IKEv2, which is responsible for authentication and establishing security parameters.
What is most important here from the company's perspective:
• Identity and access control – remote access requires good authentication (e.g. certificates, MFA within the access system), because the „end” of the tunnel is the user’s device.
• Security in intermediate networks – the user can connect from home, a hotel or via a mobile network, therefore the standards describe mechanisms for dealing with NAT and typical Internet realities (e.g. NAT-T).
A good example of the practical use of IPsec/IKEv2 in the remote model are VPN implementations in a Windows environment (e.g. Always On VPN), where the tunnel is to provide the required protection to the VPN gateway.
How can you quickly distinguish between these two models?
The easiest way is to look at it, what do you connect:
• if you connect two networks and you want them to work stably "location to location" - to site-to-site,
• if you connect user with the company network – to remote access.
Site-to-site is an "infrastructure" model—it connects locations and operates in the background. Remote access is "user-centric"—it provides secure remote access but requires greater discipline in terms of authentication and access policies.
When IPsec Makes Sense – and When to Consider a Different Approach
Is IPsec VPN a solution for everything? No. IPsec is a very mature standard for securing IP traffic, but its advantages are primarily revealed in specific scenarios. NIST explicitly describes IPsec as a tool for providing security services at the network layer and emphasizes that the technology choice should be based on a real-world use case—not simply on popularity.
When IPsec VPN Makes the Most Sense
IPsec is usually a good choice when:
• You connect network to network (site-to-site) and you want a stable, predictable tunnel between locations (office-branch, office-warehouse).
• You need traffic-level protection, not just a single app – IPsec protects IP packets according to policy, regardless of whether the packet contains ERP, files, VoIP, or another service.
• You have a firewall/router based environment, where IPsec is standardly supported and easy to maintain operationally.
• It is important to check safety parameters (algorithms, rules, key lifetimes) and the ability to unify them across the entire organization.
• You want a structured model with authentication and security negotiation (IKE/IKEv2), instead of "ad hoc" application-dependent settings.
• You have formal or audit requirements, where a standard approach and well-described mechanisms (IPsec/IKE) make it easy to justify "how" and "with what" you protect the transmission.
When is it better to consider an alternative?
A different approach may be better when:
• Simplicity for end users is paramount (rapid implementation, few elements to configure on devices) – in this case, TLS/SSL-based VPNs or "application-based" solutions are often considered. NIST discusses alternatives and the context for technology selection.
• Your goal is to access a specific application, not the entire network – in many organizations, models based on „per application” access work better (less wide reach, lower risk of lateral movement).
• You have highly mobile users and variable networks (Wi-Fi/LTE, frequent access point changes). This can be done using IPsec, but sometimes solutions designed for mobility are more operationally convenient (e.g., IKEv2 profiles in remote access solutions).
• The environment "on the road" complicates connectivity (NAT, restrictive networks) – IPsec has NAT-T-type mechanisms, but sometimes TLS-based solutions can more easily overcome the restrictions.
• You need maximum protocol simplicity and implementation auditability – some organizations are considering more modern, more minimalist VPN protocols (e.g., WireGuard), which are designed with simplicity and low implementation complexity in mind.
• You have a heterogeneous environment and want to reduce the "cost of living"„ (different vendors, different hardware versions, frequent changes). Then the decision often comes down to the operational level: what will be easier to standardize, monitor, and maintain in your environment.
IPsec VPN is particularly powerful where you want to securely and reliably connect networks or build a standard, controlled IP-level tunnel. When minimal user complexity or application-based rather than network-based access is a priority, it's worth consciously considering the alternatives described in best practices (e.g., NIST) and choosing a solution based on the purpose, not the technology itself.
Frequently asked questions
IPsec does not change the fact that you are using the internet - it protects specific traffic, that has been covered by the IPsec policy (i.e., traffic "selected" for the tunnel). In the site-to-site model, this typically applies to communication between two networks, and in remote access, between a user's device and the company's network. This approach is described as protecting traffic at the IP level, in accordance with security rules.
Not quite. IPsec operates at the network (IP) level, so it can protect traffic from multiple services and protocols "system-wide," not just a single application. VPN TLS/SSL-based protocols often operate closer to the application layer and are sometimes chosen for other purposes (e.g., easier access to selected resources). NIST describes IPsec and indicates that alternatives are worth considering depending on the scenario.
IKE (most often IKEv2) is a "handshake layer" that allows two parties authenticate and establish rules and keys for IPsec. In practice, IKEv2 is responsible for establishing and maintaining Security Associations (SAs), without which IPsec cannot operate securely. This is not an "add-on," but a standard element of the entire mechanism.
UDP 500 is typically associated with IKE, or connection negotiation. When NAT is involved, NAT Traversal (NAT-T) often comes into play, where IPsec can use UDP 4500 to reliably traverse address translation devices. This is standardized in the NAT-T RFCs for IKE.
It depends on the configuration – IPsec is comprised of standards and mechanisms, but real security comes from the selection of settings: authentication methods, algorithms, IKE parameters, key lifetimes, and a consistent policy. Therefore, best practices (e.g., NIST) emphasize proper implementation and maintenance, not just the choice of technology.
IPsec adds overhead (encryption, additional headers, tunnel handling), so some impact on performance is normal. In practice, the difference depends on the hardware (cryptographic acceleration), link quality, MTU, and whether the tunnel is well-suited to the traffic. NIST discusses practical aspects of IPsec implementations, including design and operational implications.
IPsec VPN is a set of standards that protect network traffic at the IP level—most often via ESP, with policy and key negotiation handled by IKEv2. In companies, it's primarily used in two models: site-to-site (network connection) and remote access (remote user access). This solution is particularly effective where a stable, predictable tunnel and a consistent security policy are essential—and its effectiveness depends on proper configuration.
