What IPsec is and what it does

IPsec (Internet Protocol Security) is a framework of security protocols designed to protect IP-based communication. In practical terms, IPsec aims to provide confidentiality (encryption) and integrity/authentication (detecting tampering) for traffic carried over IP.

A key scoping point: IPsec is not “security for the whole internet.” It secures traffic that is intentionally routed through an IPsec-protected path between defined endpoints (for example, two gateways or two hosts). If a connection doesn’t match the security policy that triggers IPsec, plain traffic may still occur.

How IPsec works (the main building blocks)

IPsec protection is typically built from components that decide when to protect traffic and how to protect it.

  1. Security policies (selectors) An IPsec implementation uses policies that define which traffic flows should be protected (e.g., by source/destination IPs and possibly ports). If traffic matches the selectors, the IPsec system applies the chosen protection.

  2. Security associations (SAs) For the matched traffic, IPsec relies on Security Associations—runtime agreements that identify the protection parameters for a particular direction of traffic (for example, what encryption/integrity algorithms to use and with what keys).

  3. Key management and negotiation Many deployments use a separate key management protocol to negotiate and refresh SAs and cryptographic material. The negotiation step is also where peers authenticate each other (depending on configuration).

  4. Encapsulation and integrity for packets IPsec applies cryptographic protection to packets. Two common operational modes exist:

  • Transport mode: protects the payload portion of the IP packet while leaving much of the outer IP header visible.
  • Tunnel mode: encapsulates the original packet inside a new outer IP packet, allowing the protected connection to appear as traffic between the tunnel endpoints.

Because the mode changes packet treatment, it affects troubleshooting, network visibility, and how routing/policy engines see traffic.

Modes, compatibility, and why “it depends” matters

IPsec can be implemented in multiple ways, and successful protection depends on alignment between both ends.

Common differences that affect whether you actually get protection:

  • Mode choice (transport vs tunnel): The same policy intent can require different packet flow and configuration.
  • Algorithm and protocol support: If peers don’t support matching cryptographic suites or packet-processing parameters, negotiations may fail or fall back to weaker/non-protective behaviors (depending on the specific implementation and configuration).
  • NAT and traversal behavior: Real networks often include address translation, which can complicate how peers identify flows and maintain SAs. Deployments may require specific handling.
  • Traffic selectors and routing: Even with a working IPsec tunnel, not all traffic will be protected if it doesn’t match selectors or if routing sends traffic outside the protected path.

Uncertainty to keep in mind: the exact behavior (including failure modes) can differ between implementations and versions. Treat any “it always works” expectation as a risk—verify in your environment.

It helps to separate IPsec from neighboring terms that people often mix up:

  • VPN is a category; IPsec is a protocol suite. A VPN can be built using different technologies; IPsec is one approach that can protect IP traffic.
  • Firewalls control traffic; IPsec protects traffic. Firewalls focus on filtering and rules. IPsec focuses on protecting what’s allowed to pass, once policy and routing direct it into the IPsec path.
  • TLS protects applications; IPsec protects IP-level flows. TLS secures specific sessions between applications. IPsec secures network-layer traffic, which may include application flows.

In practice, many secure designs use multiple layers together rather than relying on one mechanism.

Practical checks: confirm protection instead of assuming it

Use verification steps that focus on evidence of negotiation, protection, and correct traffic selection.

  1. Confirm that traffic matches the IPsec policy Check that the source/destination traffic you care about actually matches the configured selectors. If it doesn’t, IPsec won’t apply to it.

  2. Verify the negotiated parameters and state Look for signs that SAs were established (for example, a “connected/established” tunnel or active security associations). Also verify that the negotiated protection includes encryption and integrity, and that the chosen algorithms are those you expect.

  3. Check for replay/tamper detection behavior When integrity protection is active, tampering should be detected rather than silently accepted. While you may not intentionally test attacks, you can still monitor logs/alerts for authentication or integrity errors.

  4. Inspect paths for unexpected plaintext routing Compare what you expect (traffic flowing through the IPsec path) versus what the network actually does. If you observe endpoints communicating without IPsec being applied, it may indicate routing or policy mismatch.

  5. Validate endpoints and credentials/authentication If peer authentication is misconfigured, negotiation can fail or security may not be established. Validate peer identity and the authentication method used in your setup.

If any check is unclear, use cautious interpretation: a “tunnel configured” state doesn’t automatically prove that the specific traffic flow you care about is protected.

Key limitations and common gotchas

IPsec is powerful, but it has practical constraints:

  • Configuration accuracy matters. Policies, selectors, algorithms, and keys must align on both sides.
  • Operational overhead exists. Key management, rekeying, and monitoring are part of real deployments.
  • Scope is defined by policy. Only traffic that matches the IPsec policy becomes protected.
  • Debugging can be non-trivial. Packet encapsulation changes visibility, and network middleboxes can introduce complications.

The best takeaway is to treat IPsec as “security for specific, negotiated IP flows,” not a universal blanket.

How to place IPsec correctly in your security model

If your goal is a secure online world, IPsec is one tool that can protect IP traffic between chosen endpoints. It complements other controls such as secure endpoint configuration, least-privilege access, and firewall filtering.

Before you rely on it operationally, focus on the verifiable chain: policy match → SA established → negotiated protections in effect → traffic actually flowing through the protected path. That’s where confidence comes from.