OT Deep Packet Inspection on Cellular Routers

Why a firewall on the router is no longer the whole answer

I have been fitting cellular routers into telemetry cabinets for the best part of twenty years, and for most of that time the security conversation was simple. Lock down the WAN, put a VPN back to the head end, change the default password and move on. That still matters. It is just no longer enough for the sites that are now being pulled into scope by regulators: water, energy, battery storage, EV charging and manufacturing.

The reason is the protocols. Modbus, DNP3, IEC 60870-5-104 and Siemens S7 were designed for closed networks. They have little or no authentication of their own. If a packet arrives at a PLC on the right port, the PLC generally does what it is told. A conventional router firewall can say that 192.168.1.20 is allowed to reach the PLC on TCP 502. What it cannot say is whether that conversation is a harmless read of a temperature value or a write that changes a setpoint.

That is the job of OT deep packet inspection: parsing the industrial protocol itself, understanding the function code inside the payload, and allowing or blocking at that level. A customer recently asked me about the Moxa OnCell G4308-LTE4-GL for exactly this reason, and it sent me off to map out who actually ships this capability in a cellular box, who sells it as a subscription on a firewall, who leaves you to build it yourself, and whether the IoT SIM networks can do any of it for you.

What deep packet inspection means on an OT router

The term gets stretched on datasheets, so it is worth being precise. I think of inspection as a ladder. Most industrial cellular routers stop on the second rung.

Two caveats run through everything below. First, DPI cannot read what it cannot see: if traffic is wrapped in TLS or a VPN before it reaches the inspecting device, the payload is opaque. Second, the most dangerous traffic in an OT network is often local, between an HMI and a PLC on the same LAN segment, so where the inspection sits in the topology matters as much as how clever it is.

The Moxa OnCell G4308-LTE4: an industrial router with OT DPI built in

The G4308 is interesting because it comes from the industrial networking side rather than the firewall side. It is a DIN-rail LTE Cat 4 router with eight Gigabit Ethernet ports, dual nano SIMs, an RS-232/422/485 serial port, GNSS, one digital input and one relay output, and redundant 12 to 48 VDC power inputs. Moxa lists a standard operating range of -10 to 55°C for the GL model, with a wide-temperature -T variant also in the range.

The part that caught my customer's eye is the firewall. Alongside the usual IP, MAC, port and ICMP filtering and a long list of DoS and scan protections, Moxa's specification lists deep packet inspection for eleven OT protocols:

• Modbus TCP and Modbus UDP
• DNP3, IEC 60870-5-104 and IEC 61850 MMS
• EtherNet/IP, Mitsubishi MELSEC and Omron FINS
• OPC UA, Siemens S7 Communication and S7 Communication Plus

Moxa says more protocols will follow in firmware updates. In its own description, the DPI engine examines the data portion of packets and detects and blocks forged or malicious packets. Security extends to Secure Boot, RADIUS, access control lists, up to 15 IPsec tunnels and an OpenVPN client, and the datasheet lists EN 18031-1, the standard tied to the EU radio equipment cyber security requirements. Management runs through Moxa Remote Connect, MXview One, MXconfig and MXsecurity.

How granular is it?

This is the question I would put to Moxa before buying, because DPI on a datasheet does not tell you how fine-grained the rules can be. There is a big difference between "identify Modbus TCP and reject malformed packets" and "allow function 03 reads from the HMI, deny function 06 writes unless they come from the engineering workstation, and only within this register range".

Moxa's own DPI material describes exactly the kind of policy you would hope for: filtering on Modbus source device ID and function code, and a firewall set to allow Modbus reads while dropping writes. What I have not been able to confirm from the published G4308 documentation is whether register-range rules are available, and whether the same depth of control applies to all eleven protocols or mainly to Modbus. If command-level enforcement is the reason you are buying it, ask your distributor to demonstrate the exact policy you need on the unit before you commit.

Who else builds OT inspection into a cellular box

Look across the market and the products fall into two camps. On one side are industrial routers that have gained OT security, which is where Moxa sits. On the other are serious security appliances that have gained ruggedisation and cellular modems, from Fortinet, Check Point and Palo Alto, usually with the OT intelligence sold as a subscription. The second camp generally has far broader security engines; the first is simpler and cheaper to run. Here is how the credible options compare as of October 2026.

The firewall vendors

Fortinet's FortiGate Rugged range runs full FortiOS, and the FortiGuard OT Security Service adds IPS signatures and application control aimed at industrial protocols and equipment, including virtual patching for PLCs and HMIs that cannot be updated. At launch Fortinet quoted 3,060 OT protocol signatures and 1.1 Gbps of threat protection throughput for the 70G-5G-DUAL. The important detail in the name is that it carries two separate 5G modems rather than two SIM slots sharing one, so both UK operators can be live at once.

Check Point's 1595R is the one I would look at hardest for granular command control. It is a DIN-rail or wall-mount gateway rated from -40 to 75°C, available wired-only or with a dual SIM 5G modem, and the datasheet names BACnet, CIP, DNP3, IEC 60870-5-104, IEC 60870-6 (ICCP), IEC 61850, MMS, Modbus, OPC DA and UA, PROFINET and Siemens Step7 among more than 1,800 SCADA protocols and commands, with virtual patching through IPS signatures for known ICS vulnerabilities. That is considerably more than protocol recognition. Palo Alto's PA-400R ruggedised range includes the PA-450R-5G and the IP65 outdoor PA-455R-5G, the latter with dual SIM slots, four PoE ports and support from PAN-OS 12.1.

The trade-off with all three is commercial rather than technical. You are buying an enterprise firewall in a rugged case, with an annual security subscription per site, and a management platform your OT team may not already run. For a substation or a water treatment works that is often fine. For a fleet of 400 pumping stations, the per-site licence becomes the whole business case.

Cisco and Hirschmann

Cisco takes a different route. The IR1101 and IR1800 rugged routers can host the Cyber Vision sensor as an IOx application, which captures industrial flows, decodes the protocols and sends metadata to a central Cyber Vision Center. That is excellent for asset visibility and detection across many sites, but it is a monitoring architecture, not a protocol firewall in the Moxa sense.

Hirschmann's EAGLE40 family has no modem at all, but I include it because many integrators already pair a cellular router with a separate industrial firewall. Its DPI enforcer modules for Modbus TCP, OPC, EtherNet/IP, IEC 104 and DNP3, plus a firewall learning mode, make it a strong partner for an existing router estate.

Do any Teltonika routers do this?

No, not natively, and I say that as someone who has deployed more Teltonika kit than anything else. RutOS has a stateful firewall, custom rules, DDoS and port-scan protection, VLANs and a very broad VPN stack, and the current releases are actively patched. When asked directly in one of its own RutOS webinars whether there is any IDS or IPS, Teltonika answered that there is not.

The source of confusion is that RutOS speaks the industrial protocols fluently. It can act as a Modbus client and server, a DNP3 outstation and more, collecting data and forwarding it to the cloud. That is protocol support, so the router can talk to your equipment. It is not protocol inspection of traffic passing through it. If you want the background on how these OpenWrt-based platforms are put together, our guide to OpenWrt industrial routers covers it, and our piece on cellular router security covers the hardening basics that apply whatever you buy.

Could you build an OT security sensor into a Teltonika?

On paper, yes. In production, it needs proving. Where Teltonika does open a door is the RUTC series. The RUTC40 is a global LTE Cat 4 edge router with a Telit modem, a dual-core MediaTek ARM Cortex-A53 at 1.3 GHz, 1 GB of RAM, 8 GB of eMMC flash and dual-band Wi-Fi 6, and Docker is supported as an installable package across the RUTC40, RUTC41, RUTC42 and RUTC50. One UK distributor lists the RUTC40 at around £370 excluding VAT. That is a fraction of a rugged NGFW, which makes it tempting to containerise the inspection yourself.

Getting an inspection engine to start in a container is the easy part. There are really three separate questions, and the first does not answer the other two. Can it run in Docker on the router? Can it actually see all the traffic you care about, given how RutOS bridges the LAN and how the container is networked? And can a dual-core 1.3 GHz CPU inspect that traffic at useful throughput without starving the router itself? Inline prevention adds a fourth: a container running on the router is not automatically sitting in the forwarding path, so making it block traffic means deliberately steering packets through it, with all the risk that brings. With that said, two open-source engines are worth looking at.

Suricata: signature IDS with OT parsers

Suricata has native app-layer parsers and rule keywords for Modbus, DNP3 and EtherNet/IP with CIP. The DNP3 keywords match on application function codes such as write, operate, direct_operate and cold_restart, which is exactly the level of detail you want. A pair of simple local rules might look like this:

alert modbus any any -> $PLC_NET 502 (msg:"Modbus write to PLC from non-engineering host"; modbus: access write; sid:9000001; rev:1;)
alert dnp3 any any -> $RTU_NET 20000 (msg:"DNP3 cold restart issued"; dnp3_func:cold_restart; sid:9000002; rev:1;)

Zeek with CISA ICSNPP: deep visibility and logging

Zeek is a network monitoring framework rather than a blocking engine, but CISA's ICSNPP project adds full parsers for S7comm, S7comm-plus, OPC UA Binary, EtherNet/IP and CIP, BACnet, Omron FINS and PROFINET IO CM, among others, plus extended logging for Zeek's built-in Modbus and DNP3 analysers. On an OT site that gives you a detailed, searchable record of who issued which command to which device, which is gold during an incident.

How I would approach it

• Start in detection mode. Run Suricata as an IDS watching the LAN bridge, not inline, so a crashed container cannot take the site offline.
• Write narrow rules for the commands that matter on that site (writes, restarts, firmware downloads) rather than loading a large generic ruleset into 1 GB of RAM.
• Ship alerts and Zeek logs back over the existing VPN to a central SIEM or log server. A router is the wrong place to store weeks of logs; Teltonika itself recommends external storage for Docker workloads.
• Only consider inline blocking once you have weeks of clean baselines, and accept that you now own the tuning.

The same thinking applies to choosing where compute lives in general; our comparison of smart modules, SBCs and routers is a useful frame if you are weighing a separate sensor box instead.

Can the IoT SIM network do it for you?

This was the part I was most curious about, because the IoT connectivity providers now run their own mobile cores and could, in principle, inspect everything a SIM sends. Several do offer network-side security, and some of it is genuinely good.

• Wireless Logic offers Anomaly & Threat Detection, which runs in its mobile core and combines AI anomaly detection, threat intelligence and deterministic rules to flag issues such as botnet behaviour, SIM misuse and DDoS, with no software on the device. It sits alongside NetPro private networking and supports PCAP downloads and compliance reports.
• KORE SecurityPro provides rule-based alerting on unplanned device behaviour and network anomalies at the connection level.
• emnify streams connection events and traffic metadata, including DNS queries and IP endpoints, into your own systems, and Cloud Connect keeps device traffic on a private IPsec or AWS Transit Gateway path rather than the public internet.
• Onomondo offers Traffic Monitor, which captures packets to and from a device in the network for analysis, plus usage limits, alerts and private connectors.
• Vodafone Business IoT launched AI anomaly detection in late 2024, but it is aimed at service and fault anomalies rather than security inspection.

None of them, as far as I can find, offers protocol-aware OT inspection of Modbus or DNP3 commands, and there are structural reasons why. The network only sees traffic that leaves the router over the SIM, so a rogue write between an HMI and a PLC on the same LAN never reaches it. And if you have done the right thing and tunnelled everything back over IPsec or WireGuard, the core sees an encrypted tunnel and nothing more.

What I would specify, and why it matters now in the UK

Pulling it together, this is the shortlist I would work from. It is a commercial map rather than a ranking, because the right answer depends as much on what the customer already runs as on the feature list.

Whichever box goes in, think in layers. SIM and APN controls form the outer ring. The cellular edge device provides the firewall, the VPN and, ideally, OT-aware inspection. Segmentation inside the site keeps PLCs, HMIs and RTUs apart. Above all of that sit central logging, a SIEM or OT monitoring platform, an asset inventory, virtual patching and an incident response plan. For years the honest answer to "how is this remote PLC protected?" was "it is behind a private APN and a VPN". On its own, that answer is no longer enough.

The regulatory push is real. The Cyber Security and Resilience Bill, which amends and extends the 2018 NIS Regulations, cleared its Commons stages in June 2026 and moved to the Lords, and government has signalled that the NCSC Cyber Assessment Framework will act as the baseline for security duties. Security monitoring is a core CAF outcome. For remote OT sites with no other security sensor, it becomes increasingly difficult to demonstrate meaningful monitoring when the edge device cannot distinguish legitimate industrial traffic from potentially dangerous commands. If you are reviewing remote sites against that framework, pair this with a look at OT backup and recovery, because detection without a tested recovery path only gets you halfway.