Edge Network Security

The Consystence edge runs at the boundary between a corporate IT network and an operational technology (OT) network of controllers and field devices. That boundary is the highest-value target on the site: anything that can reach the controller can, in principle, influence physical plant. The edge security model is therefore a SCADA threat model — segment the two networks, default-deny all traffic, and allow-list only the ports the edge needs (and, on the OT side, the exact controller addresses). It is not an OWASP-web threat model; there is no public attack surface here, only a tightly controlled industrial perimeter.

This page describes that model as implemented by the dual-NIC edge firewall, which generates an nftables ruleset for the device. For hardware provisioning see VL3 Edge Setup; for the broader runtime see the Edge overview.

Workshop-proven, pending hardware validation

The PLCnext border-gateway edge deployment is workshop-proven and awaiting VL3 hardware for full validation. Ports, interface names and rule shapes below are taken from the edge firewall source, but treat them as the current target rather than a fielded GA configuration.

Dual-NIC segmentation

The edge device has two physical network interfaces, and they never bridge:

Interface	Role	Faces	Default
eth0	IT uplink	The site server (upstream)	ItInterface
eth1	OT field	Controllers and field devices (downstream)	OtInterface

eth0 carries the edge’s connection home to the site server — telemetry, store-and-forward flush, configuration. eth1 carries only industrial protocol traffic to the controller. Keeping them on separate NICs means an attacker who reaches the IT side cannot route packets onto the OT side, and vice versa, because forwarding between the two interfaces is dropped entirely (BlockForwarding defaults to true).

flowchart LR
  SS["Site server<br/>(cloud / on-prem)"]
  subgraph EDGE["Edge device (dual-NIC, nftables)"]
    direction TB
    IT["eth0 — IT uplink<br/>outbound 443 / 53 / 123"]
    OT["eth1 — OT field<br/>44818 to controller only"]
    FW["forward chain:<br/>default-deny (no IT&lt;-&gt;OT routing)"]
  end
  CTRL["PLCnext / controller"]
  FIELD["Field IO"]

  SS <-->|"TLS"| IT
  OT <-->|"EtherNet/IP CIP"| CTRL
  CTRL --> FIELD
  IT -.x.- FW
  OT -.x.- FW

Default-deny posture

Every chain in the generated ruleset defaults to drop. Nothing is permitted unless a rule explicitly allows it, and that applies to inbound, outbound and forwarded traffic alike — the input, output and forward chains all start from a drop policy.

Default-deny on the output chain is deliberate and stronger than most host firewalls: even outbound connections the edge initiates must match an allow rule. Because IT-side outbound rules are matched primarily by port, pin the IT-side egress destinations wherever the deployment allows it, so the edge can only reach the hosts it needs — DNS, NTP and the site server. The OT side is always destination-pinned to the configured controller(s).

Established and related flows are accepted, invalid packets are dropped, and loopback is allowed in both directions. Everything that falls through is logged and dropped — see OT traffic monitoring.

Allowed ports

The reference policy opens exactly these flows. Nothing else reaches or leaves the device.

Define your allow rules before enabling the firewall

Allow rules are deployment-specific, so a real deployment must define its ItRules and OtRules explicitly — for the ports, interfaces and controller addresses the site uses — before enabling the firewall (see Configuration). Under default-deny only the flows you allow-list are permitted, so be sure to include the management access, DNS, NTP and upstream rules the device needs to stay reachable and to reach the site server.

Port	Protocol	Interface	Direction	Purpose
22	tcp	eth0 (IT)	inbound	SSH administration
443	tcp	eth0 (IT)	outbound	gRPC upstream to the site server (TLS — see transport note below)
53	tcp + udp	eth0 (IT)	outbound	DNS
123	udp	eth0 (IT)	outbound	NTP (time sync)
44818	tcp + udp	eth1 (OT)	inbound + outbound	EtherNet/IP CIP to the controller

A few points worth calling out:

• The OT side opens only EtherNet/IP CIP (44818). This is the protocol the edge — or, in the primary topology, the co-located PLCnext border gateway — uses to reach the ControlLogix IO rack. A deployment that acquires Modbus TCP devices directly from the edge likewise allow-lists TCP 502 on the OT side, pinned to the configured device addresses. See PLC communication.
• IT outbound is scoped to the ports the edge needs. The IT side may use only ports 443 (upstream), 53 (DNS) and 123 (NTP); pin those egress destinations wherever the deployment allows, so the edge reaches only the hosts it needs. The OT side is tighter still: it may only reach the configured controller(s) on 44818.
• SSH (22) is the only inbound IT rule. Administrative access is deliberately the single inbound exception, and it can be removed for fully headless deployments by editing the policy.

Match the 443 rule to the upstream transport

The upstream link’s transport depends on Upstream:ForceHttp3. The edge config default is true, which pins the gRPC channel to HTTP/3 (QUIC) — that is UDP 443, with the version pinned exactly, so there is no TCP fallback and the tcp-only rule above would drop the edge’s own upstream link. The site server currently serves gRPC over HTTP/1.1 and HTTP/2 only, so real deployments set Upstream:ForceHttp3 to false and the upstream runs gRPC over HTTP/2 on TCP 443 — which is what the tcp-only rule matches. If you do enable HTTP/3, change the outbound 443 rule to udp (or tcp+udp).

Where the PLCnext gRPC link sits

In the primary PLCnext border gateway topology the edge reaches the co-located PLCnext over a Unix Domain Socket (/run/plcnext/grpc.sock, the PLCnext gRPC service on 41100). That is local inter-process communication on the same host — it never crosses a network interface, so it needs no firewall rule. The OT firewall governs the EtherNet/IP CIP traffic (44818) that PLCnext exchanges with the field. Direct EtherNet/IP CIP from the edge process itself is the interop path for third-party and legacy controllers.

OT traffic monitoring

Beyond default-deny, the OT side is allow-listed by source and destination address, not just by port:

• Inbound OT rules pin the allowed source addresses, so the edge accepts EtherNet/IP CIP only from the specific controller(s) configured for the site, not from anything else that appears on the OT segment.
• Outbound OT rules pin the destination addresses, so the edge can only talk to those controllers.

This address pinning is the enforcement half of OT traffic monitoring: a rogue device plugged into the field network cannot initiate CIP sessions with the edge, and the edge cannot be coerced into scanning hosts it was not provisioned for. The observation half is the passive network monitor described below.

Every packet that falls through the allow rules is logged before it is dropped, with a distinct marker per chain so drops are easy to separate in the kernel log. Under normal operation the forward chain should log nothing, because nothing legitimately routes across the IT/OT boundary — so any forward-chain drops are a strong signal worth investigating. Output-chain drops surface processes attempting egress on unpermitted ports.

Passive monitoring: the OT network monitor

Enforcement is only half the picture. Alongside the firewall, the edge runs a passive OT network monitor that observes rather than blocks: on each collection interval it reads per-interface counters from /proc/net/dev and lists established connections via ss — connection-level metadata only, no deep packet inspection — and flags three anomaly classes:

Anomaly	Trigger
Unexpected source	An established connection from an IP not in AllowedOtSources
Traffic spike	Combined rx+tx rate on the monitored interface exceeds TrafficSpikeThreshold (bytes/sec)
Unexpected port	An established connection where neither endpoint port is in ExpectedOtPorts

It is configured under the NetworkMonitor section (values shown are the shipped defaults, with the per-site controller address):

{
  "NetworkMonitor": {
    "Enabled": true,
    "MonitorInterface": "eth1",
    "CollectInterfaces": ["eth0", "eth1"],
    "IntervalMs": 10000,
    "AllowedOtSources": ["192.0.2.10"],
    "ExpectedOtPorts": [44818],
    "TrafficSpikeThreshold": 10000000
  }
}

Both halves are surfaced through the edge’s local diagnostics API — current interface metrics, active connections, detected anomalies and firewall status. That API is a management surface: bind it to a trusted management interface and keep it off the OT side.

Configuration

The policy is declarative and binds from the edge configuration under the Firewall section. Allow rules are deployment-specific, so define ItRules and OtRules explicitly for the ports, interfaces and controller addresses the site needs, as below. Setting Enabled to false applies no rules at all (use only for bench testing). A site’s controller addresses go in AllowedSources on the OT rules.

{
  "Firewall": {
    "Enabled": true,
    "ItInterface": "eth0",
    "OtInterface": "eth1",
    "BlockForwarding": true,
    "ItRules": {
      "InboundAllow": [
        { "Port": 22, "Protocol": "tcp", "Description": "SSH" }
      ],
      "OutboundAllow": [
        { "Port": 443, "Protocol": "tcp", "Description": "gRPC upstream (TLS)" },
        { "Port": 53, "Protocol": "tcp+udp", "Description": "DNS" },
        { "Port": 123, "Protocol": "udp", "Description": "NTP" }
      ]
    },
    "OtRules": {
      "InboundAllow": [
        {
          "Port": 44818,
          "Protocol": "tcp+udp",
          "Description": "EtherNet/IP CIP",
          "AllowedSources": ["192.0.2.10"]
        }
      ],
      "OutboundAllow": [
        {
          "Port": 44818,
          "Protocol": "tcp+udp",
          "Description": "EtherNet/IP CIP",
          "AllowedSources": ["192.0.2.10"]
        }
      ]
    }
  }
}

Each FirewallRule carries a Port, a Protocol (tcp, udp, or tcp+udp), a Description (rendered as the inline nftables comment), and optional AllowedSources. An empty AllowedSources means any source/destination — so for OT rules you should always pin the controller addresses.

Why segmentation matters here

Network segmentation is a control-safety boundary, not just a confidentiality one. The edge can issue tag writes that reach physical equipment, so limiting who can talk to the edge — and what the edge can talk to — directly bounds the blast radius of any compromise.

AI is advisory-only

The platform’s AI configures, queries, classifies and explains — it never commands equipment. Any future on-edge ML inference (a roadmap capability — see Edge ML) would be advisory only, for diagnostics, never actuation. Hard interlocks and safety functions live in the IO modules and safety relays, independent of the edge, the network and the AI. No firewall rule, and no AI output, can override a hardware interlock. See Architecture: AI.

Related

• VL3 Edge Setup — provisioning the dual-NIC device
• PLCnext Border Gateway — the primary OT path
• PLC Communication — EtherNet/IP CIP and gRPC drivers
• Edge overview — the edge runtime in context