IPsec Protocol: 4 Building Blocks Behind Every Tunnel

IPsec Protocol combines authentication, encryption, and automated key exchange into one framework, most commonly used to build a site to site tunnel between a remote plant and a central SCADA control room.

4 Building Blocks Inside IPsec Protocol

ESP is by far the most widely deployed of these four, since it alone covers confidentiality, integrity, and authentication in a single pass, which is why AH sees comparatively little real world use today.

AH Versus ESP in Detail

AH struggles behind a NAT device because its integrity check covers parts of the outer IP header, and any address rewriting along the path breaks that check completely.

ESP avoids that problem since its protected fields sit entirely inside the packet, leaving room for NAT traversal to wrap the whole thing in an ordinary UDP datagram when needed. This is one reason ESP dominates real IPsec Protocol deployments today.

Transport Mode Versus Tunnel Mode

Tunnel mode is the one that actually matters for a plant, since an IPsec Protocol site to site VPN between a remote RTU location and the central SCADA control room needs to hide whole subnets, not just a single host conversation.

How Internet Key Exchange Sets Up the Tunnel

Phase 1 of IKE builds a secure, authenticated control channel between the two gateways, confirming each side's identity and agreeing on the algorithms that will protect everything that follows.

Phase 2 then uses that already secured channel to negotiate the actual security associations that will carry real traffic, including which subnets are allowed through and whether a fresh key exchange happens for extra forward secrecy.

Security Associations and the SPI Number

Every security association only ever protects traffic in one direction, so a normal two way conversation always needs a matching pair of them, one for each direction.

The Security Parameter Index carried in that header is what lets a receiving gateway instantly pick the right set of rules out of potentially many active associations, much like a port number sorts traffic into the right application.

Choosing Modern Encryption and Integrity Algorithms

A tunnel configured with weak legacy defaults can technically work for years without complaint, which is exactly why it is worth revisiting an old IPsec Protocol configuration rather than assuming it was set correctly the day it was built.

Why NAT Traversal Exists at All

ESP carries no port number of its own, which means an ordinary NAT device has nothing to rewrite and quietly breaks the connection for more than one client behind the same address.

NAT traversal solves this by wrapping ESP inside an ordinary UDP datagram on port 4500 whenever a NAT device is detected during the key exchange, restoring the port information that NAT needs to function correctly.

Why OT Networks Lean on IPsec for Modbus and DNP3

Modbus TCP and DNP3, despite being two of the most widely deployed protocols in industrial control, were never built with any authentication, integrity checking, or encryption in their original specification.

That gap matters most the moment traffic leaves a trusted local network, such as a remote substation or a wellhead site connecting back to a central control room over a WAN link or the public internet.

A site to site IPsec tunnel closes that gap without touching a single line of RTU or PLC firmware, since the encryption happens entirely at the network layer between two gateways rather than inside the field devices themselves.

This fits neatly into the layered thinking behind the Purdue model, where a firewall and an IPsec tunnel typically sit at the boundary between the control network and anything reaching toward the enterprise or the outside world.

IPsec Protocol Against Newer Alternatives

OpenVPN runs in user space over TLS and is highly configurable, including the ability to run over TCP for traversing restrictive firewalls, but it generally trails IPsec and newer options on raw throughput.

WireGuard takes the opposite approach, using a tiny fixed codebase with modern cryptography baked in rather than negotiated, and it commonly benchmarks with lower latency and higher throughput than a comparable IPsec tunnel.

IPsec still holds its ground for site to site work because of how broadly it is supported across routers, firewalls, and legacy equipment, and because many compliance frameworks common in regulated industries explicitly reference it by name.

What Actually Gets Encrypted Inside a Packet

An unprotected IP packet leaving a remote RTU site normally exposes three things to anyone watching the wire, the source and destination addresses in the IP header, the port numbers in the TCP or UDP header, and the actual data itself.

In tunnel mode, ESP wraps that entire original packet, header and all, inside a brand new outer packet carrying the two VPN gateway addresses instead of the real internal ones.

An observer sitting between the two sites sees only two gateway addresses talking to each other, with no visibility into which internal host sent the traffic, which port it used, or what the payload actually contains.

That outer packet also carries an ESP trailer with padding and an authentication value, so the receiving gateway can confirm nothing was altered in transit before it ever decrypts and forwards the inner packet onward.

A Practical Checklist Before Turning On a Tunnel

A tunnel that passes its first connectivity test is not the same thing as a tunnel that has actually been verified end to end, so treat that checklist as a minimum rather than a formality to rush through.

Every one of these checks exists because a misconfigured IPsec Protocol tunnel tends to fail quietly rather than loudly, often passing basic ping tests while still leaving real application traffic blocked or unprotected.

Common Problems That Break an IPsec Protocol Tunnel

Mismatched Phase 1 or Phase 2 proposals are the single most common cause of a tunnel that never comes up at all, since both gateways must agree on every algorithm exactly, not just approximately.

A pre shared key typed with a stray space or a mismatched case on one side will also fail authentication silently, producing log messages that are easy to misread as a completely different problem.

Clock drift between gateways can interfere with certificate based authentication, since a certificate that looks perfectly valid on one device can appear expired or not yet valid on a device with an incorrect system clock.

Overlapping traffic selectors, where two different tunnels both claim the same subnet range, will also cause unpredictable routing behavior that is often mistaken for a security association problem instead of a configuration conflict.

Watch: IPsec Explained

IPsec Protocol Questions Engineers Ask

Related Articles on This Site

• SCADA Network Security
• Purdue Model ICS Cybersecurity
• Cybersecurity Standards for PLCs
• DNP3 and IEC 60870 5 104 SCADA Protocol Comparison
• Modbus Protocol Explained

External References

• StrongSwan IPsec Documentation
• Securing Modbus and DNP3 Traffic in Transit