Iptables + Carrier-Grade strongSwan: A Hardened Foundation for OT Security

Operational technology networks were built for availability and determinism, not for adversarial network conditions. That mismatch is exactly what makes them attractive targets: a control network that was air-gapped in 2005 is, in 2026, almost always connected to something — a historian server, a vendor support tunnel, a corporate WAN link — and every one of those connections is a way in.

There’s no single product that fixes this. But there is a well-understood, battle-tested pattern from the carrier and telecom world that maps cleanly onto OT: put a stateful packet filter at the edge of every segment, and force everything that crosses a trust boundary through an authenticated, encrypted IPsec tunnel. In Linux terms, that’s iptables (or its nftables backend) paired with strongSwan running in a carrier-grade configuration. This post lays out why that combination holds up for OT specifically, and where a managed zero-trust VPN platform like rackit.io’s could plausibly extend into this space.

Why OT needs a different security posture than IT

A few properties of OT environments change the calculus compared to a typical IT network:

Patch cycles are measured in years, not weeks. A PLC or RTU firmware update can require a planned outage, vendor sign-off, and re-validation of a safety case. You can’t rely on the endpoint to defend itself.
Availability outranks confidentiality. A dropped packet on a SCADA polling loop can matter more than a leaked credential. Security controls that add latency or jitter, or that can fail closed in a way that halts a process, need to be chosen carefully.
Protocols were not designed with security in mind. Modbus, DNP3, and plenty of proprietary fieldbus protocols have little to no built-in authentication or encryption. The network layer has to carry the security burden the protocol doesn’t.
The Purdue model still matters. Even where it’s blurred by IIoT and cloud historians, segmentation between the enterprise zone, the DMZ, and the various control levels is still the baseline architecture most OT security standards (IEC 62443, NIST SP 800-82) are built around.

Given that, the goal isn’t “install an agent on every PLC.” It’s controlling what network traffic is even allowed to reach OT assets, and encrypting and authenticating anything that has to cross a segment boundary — which is precisely what a firewall-plus-IPsec pairing is good at.

What each layer actually contributes

iptables: deterministic, stateful segmentation

At the perimeter of an OT zone — or better, at the boundary of every Purdue level and every conduit between them — iptables gives you:

Default-deny stateful filtering. With conntrack, only explicitly permitted flows (and their return traffic) are allowed; everything else is dropped and logged. For OT this typically means allow-listing specific protocols (Modbus/TCP on 502, DNP3 on 20000, OPC UA, etc.) between specific host pairs, not broad subnet-to-subnet rules.
Custom chains per conduit. Rather than one flat ruleset, each inter-zone conduit (enterprise-to-DMZ, DMZ-to-control, engineering-workstation-to-PLC) gets its own chain, which keeps the ruleset auditable against your network diagram instead of becoming an unreadable list.
Rate limiting and connection caps. hashlimit and connlimit matches protect field devices — which often have tiny TCP stacks — from being knocked over by a scan or a misbehaving IT tool, intentional or not.
Integration with the kernel’s IPsec policy database. Netfilter can match on --policy ipsec state, so you can write rules like “only accept this protocol if it arrived inside an IPsec SA” — which is the glue that turns iptables and strongSwan into one system rather than two independent ones.

strongSwan: carrier-grade IPsec/IKEv2

strongSwan’s “carrier-grade” reputation comes from features that matter a lot more in OT than they might in a typical remote-access VPN:

IKEv2 with MOBIKE, so a tunnel endpoint (a remote substation router on a cellular or satellite backhaul, for instance) can survive an IP address change without a full re-key — important when links are unreliable rather than absent.
Certificate-based mutual authentication, avoiding shared PSKs across a fleet of remote sites, with per-device certs that can be individually revoked.
charon with strongswan.conf tuning for dead-peer detection (DPD) and rekey timing suited to long-lived, low-throughput links rather than bursty enterprise traffic.
VTI (virtual tunnel interface) mode, so each IPsec SA appears as a normal routable interface — which means iptables, routing policy, and monitoring tools all treat it like any other link rather than needing IPsec-specific handling.
High-availability clustering (via pluto/charon HA extensions or an external cluster manager) so a firewall/VPN gateway failure doesn’t take down a control conduit — critical when the alternative is an unplanned process shutdown.

The two together

The pattern that actually matters is: iptables enforces what’s allowed to happen; strongSwan enforces who’s allowed to be on the network at all. A remote engineering laptop, a vendor support connection, or a link between plants doesn’t get a route to anything until it’s authenticated and inside an IPsec SA — and once it is, iptables still restricts it to only the specific protocols and hosts its role requires. Neither layer is sufficient alone: a firewall without strong tunnel authentication trusts source IPs, which are trivially spoofed or reused; a VPN without a restrictive firewall behind it just gives an authenticated user or device a flat network to roam.

A reference layout

A conduit between, say, a remote pump station and a central SCADA host typically looks like this:

Remote site router terminates an IKEv2 tunnel to the central gateway, authenticated by a per-site certificate.
The tunnel presents as a VTI interface on both ends.
iptables on the central gateway allow-lists only the specific SCADA polling protocol, source, and destination through that VTI — everything else, including any other traffic that might arrive over the same physical link, is dropped.
DPD and MOBIKE keep the tunnel resilient to the kind of flaky connectivity common on cellular or radio backhaul, without opening a window where traffic could pass unauthenticated.
Logging on both the netfilter and IKE layers feeds a central SIEM, so an unexpected negotiation attempt or a drop-logged protocol violation is visible quickly rather than discovered during an incident review.

This is not exotic. It’s the same architecture carriers have used for years to secure cell site backhaul and interconnects — OT networks have very similar constraints (unreliable links, high availability requirements, latency sensitivity) and can reuse the pattern directly.

Where rackit.io fits — and where it doesn’t, yet

rackit.io’s current product is a managed, zero-trust IKEv2 VPN appliance aimed at home and small-office users: certificate-backed connections, one-time passphrases, IP allow-lists, and fully managed hardware. That’s worth calling out directly, because the underlying primitives — IKEv2 tunnel termination, per-device allow-lists, a managed control plane that keeps configuration consistent across many endpoints — are the same primitives an OT-grade deployment needs. Managed strongSwan at consumer scale and managed strongSwan at industrial-conduit scale are different products, but they’re built from the same parts.

What would need to change to credibly serve OT:

Support for VTI-mode tunnels and iptables policy generation scoped to industrial protocols, not just “allow this user’s traffic.”
Carrier-grade tuning (DPD/MOBIKE timing, HA clustering) validated against the kind of unreliable, low-bandwidth links common at remote OT sites.
Alignment with IEC 62443 zone/conduit terminology in the product and docs, so it maps onto how OT security teams and auditors already think about the network.
A support and change-management model that respects OT maintenance windows, rather than the “we’ll take it from here” fully-automated update posture that makes sense for a home appliance but not for a control network.

None of that is a knock on the current product — it’s a reasonably direct description of the gap between “good consumer zero-trust VPN” and “OT-grade conduit security,” and it’s the kind of gap that’s closable because the hard part (a correct, carrier-grade IKEv2 implementation) is already there.

Takeaway

For OT, the iptables-plus-strongSwan pattern isn’t a novelty — it’s the same defense-in-depth approach carriers already use for exactly the kind of unreliable, high-availability-critical links OT networks depend on: default-deny, protocol-specific filtering behind an authenticated, encrypted tunnel, with resilience features built for real-world link conditions rather than a stable office LAN. Any team already running managed IKEv2 at scale has the hardest part of that stack built. Extending it to OT is a scoping and hardening exercise, not a from-scratch build.