Where Does Your IoT Data Go? Auditing IoT Device Network Traffic

The question almost nobody asks

An installer commissions a site. A 4G router comes online, a camera streams, a sensor reports, a cloud portal lights up green. The job is signed off. From that moment the device is trusted, largely because it works and nobody has any reason to look closer.

But working and understood are two different things. The device is holding a continuous conversation with the outside world that almost no one has ever inspected. It resolves domain names. It opens connections to IP addresses in various countries. It sends telemetry on some cadence, pulls firmware from somewhere, and quite possibly reports to third-party analytics services the buyer has never heard of. None of that appears on the dashboard. The dashboard only shows you the traffic the vendor wants you to see.

This matters for three practical reasons. First, cost: on a metered cellular SIM, chatter you did not ask for is money leaving the account every month. Second, security: you cannot protect what you cannot characterise, and a device with unrestricted internet access is a device that can reach anywhere an attacker wants it to. Third, sovereignty: for anything touching regulated data, "we do not actually know which servers our field estate connects to" is not a position you want to defend during an audit.

The good news is that this is one of the most investigable problems in IoT. You do not need a security product or a vendor's cooperation. You need a capture point, a few free tools, and a method. This guide gives you all three, with a cellular-router thread running through it because that is where the visibility problem is hardest and the stakes are highest.

What "phoning home" actually looks like

Before capturing anything, it helps to have a mental model of the path a single packet takes when an IoT device speaks to the internet. A typical journey looks like this:

Device → switch / router → DNS resolver → internet → CDN → vendor cloud → third-party services

Every hop in that chain is something you can observe and, later, control. The device first asks a DNS resolver to turn a name such as telemetry.vendor.example into an IP address. It then opens a connection, usually TLS on port 443, to that address, which very often belongs not to the vendor at all but to a hyperscaler (AWS, Azure, Google Cloud) or a content delivery network (Cloudflare, Akamai, Fastly). Behind that front door, the vendor's backend may in turn hand your data to analytics, crash-reporting or advertising services that never appear in any datasheet.

Your job as an auditor is to answer a specific list of questions about that conversation:

• Which domains does the device query, and how many distinct ones?
• Which IP addresses does it connect to, and which countries and networks (ASNs) do those belong to?
• Which ports and protocols does it use? Is anything in plaintext?
• How frequently does it phone home, and does it keep talking when it is supposedly idle?
• How much data does it actually send and receive?
• What happens when you block an individual destination?
• Does a firmware update introduce new destinations you never approved?

Answer those and you have a behavioural fingerprint. That fingerprint is the foundation for everything that follows, because once you know what normal looks like you can both lock the device down to it and spot when it deviates.

The standards backing: baseline, then restrict

This is not a fringe idea. In August 2025 NIST finalised Internal Report 8349, a methodology for characterising the network behaviour of IoT devices. It had sat as a draft since 2022; its release as a final publication is a signal that "know what your device should do on the network, then permit only that" has become mainstream guidance rather than expert folklore.

The report's logic is exactly the workflow in this guide. You capture the full range of a device's communications across its normal operating conditions, you document what you see, and from that you can implement access controls, firewall rules or access control lists, that limit the device to only what it genuinely needs. Restricting communication to the necessary set does two things at once: it reduces the attack surface, and it makes misbehaviour visible, because anything outside the permitted set now stands out.

NIST frames the output of this process as a MUD file. MUD, Manufacturer Usage Description, is a standard way to express the set of destinations and protocols a device is expected to use. Very few devices ship with a MUD file today, which is precisely why doing the characterisation yourself is worthwhile: you are producing the description the manufacturer never gave you.

Choosing your capture point

The single most important decision is where you observe the traffic. Get this right and everything downstream is straightforward. The principle is simple: capture at a point that every packet leaving the device must pass through. There are three common options.

1. Port mirroring on a managed switch

If the device sits on a managed switch, configure a mirror (SPAN) port that copies all traffic from the device's port to a port where a laptop running Wireshark is listening. This is non-intrusive and gives you a full copy of the wire. It is the cleanest option for mains-powered LAN devices such as cameras, NVRs and gateways on a wired network.

2. Capturing on the router or gateway itself

Where there is no managed switch, or where the device reaches the internet through a cellular router, the router itself is your capture point. Every packet the device sends to the internet transits the router's interfaces, so a capture there sees the full egress picture. This is the approach that matters most for cellular IoT, because on a mobile link there is no convenient physical wire to tap: the WAN side is the operator network.

3. A dedicated inline tap or transparent bridge

For higher-assurance work you can insert a small device (a Raspberry Pi or industrial SBC bridging two interfaces) inline between the IoT device and the network, capturing as it forwards. This is more effort but gives you a persistent, device-specific vantage point and is a good basis for an ongoing "watch box" on a critical asset.

Capturing traffic on a Teltonika cellular router

Because RutOS is built on OpenWrt, a Teltonika router gives you a full Linux userland and, with it, the standard capture tools. This makes a cellular router one of the best vantage points you have: it is the chokepoint for an entire remote site, and you can reach it over SSH or through RMS without a site visit.

SSH into the router and capture on the LAN bridge to see what the connected devices are sending upstream, or on the mobile interface to see what actually leaves the site:

# Capture LAN-side traffic from connected IoT devices to a file
tcpdump -i br-lan -nn -s 0 -w /tmp/lan-capture.pcap

# Or capture what actually egresses on the mobile WAN interface
# (interface name varies by firmware, e.g. qmimux0 / wwan0 / mob1s1a1)
tcpdump -i mob1s1a1 -nn -s 0 -w /tmp/wan-capture.pcap

# Live view of DNS lookups only, no file, useful for a quick look
tcpdump -i br-lan -nn -l port 53

Storage on the router is limited, so keep captures short and pull the file off the device for analysis rather than filling the flash. Copy it back with scp and open it in Wireshark on your workstation:

scp root@192.168.1.1:/tmp/lan-capture.pcap ./
wireshark lan-capture.pcap

Depending on firmware version, RutOS also exposes a packet-capture function in the web interface, which wraps the same underlying tcpdump and is convenient when you would rather not use the command line. For a fleet, the same capture can be triggered remotely through RMS, so you can characterise a device in the field without anyone attending site. Confirm the exact mobile interface name on your firmware before relying on a WAN-side capture, as it differs across RutOS releases and modem types.

Step one: what names is it asking for?

DNS is the most informative single layer to start with, because the names a device looks up tell you who it intends to talk to in plain language, before any encryption gets in the way. Extract every DNS query from your capture and count them:

# List queried domain names, most frequent first
tshark -r lan-capture.pcap -Y "dns.flags.response == 0" \
  -T fields -e dns.qry.name | sort | uniq -c | sort -rn

Read the result as a story. A well-behaved sensor might query a handful of names: its vendor's telemetry endpoint, a firmware host, an NTP pool for time, and a DNS resolver. A device that returns a long and varied list of domains, particularly analytics, advertising or unfamiliar third-party names, is telling you its data goes further than the box it sits in.

Step two: where in the world are those servers?

Names tell you intent; addresses tell you reality. Pull the distinct destination IP addresses the device actually connected to:

# Destination IPs by connection count
tshark -r lan-capture.pcap -T fields -e ip.dst | sort | uniq -c | sort -rn

Then enrich each address with the network it belongs to. A quick whois lookup, or an offline GeoIP/ASN database, turns a bare IP into something meaningful: the organisation that owns it and the country it sits in.

whois 203.0.113.10 | grep -Ei "orgname|country|netname"

Now you can classify every destination. Expect to see three broad categories: the vendor's own infrastructure, a hyperscaler or CDN fronting the vendor's service, and infrastructure such as NTP and DNS. What you are hunting for is the fourth category: destinations that do not fit. A connection to a residential ASN, a hosting provider in a country with no business being in the path, or an address that appears only intermittently and briefly, all deserve explanation. None is proof of compromise on its own, but each is a thread worth pulling.

Step three: ports, protocols and plaintext

The transport tells you how exposed the conversation is. In Wireshark, open Statistics → Conversations and sort by bytes to see, at a glance, which flows dominate and on which ports. The common IoT ports and what they signify:

Even though 443 traffic is encrypted, you are not blind. The TLS handshake carries the destination hostname in the Server Name Indication field of the ClientHello, in the clear. Filter for it in Wireshark with tls.handshake.extensions_server_name and you can list exactly which hostnames a device is reaching over HTTPS, without decrypting a single byte of payload.

Step four: how often, and how much?

Cadence and volume separate a well-behaved device from a noisy or misbehaving one. Two questions matter most: does the device talk when it should be idle, and how much does it move when it does?

Leave a capture running with the device doing nothing of consequence. A thermostat that reports every fifteen minutes should be near-silent between reports. If it is opening connections every few seconds while idle, you are paying for that and you should understand why. For flow-level accounting over longer windows, an OpenWrt-based router can run a lightweight NetFlow exporter such as softflowd, giving you per-destination byte counts without keeping full packet captures. For a quick answer from a pcap you already have, Wireshark's Statistics → Endpoints ranks every peer by bytes transferred.

This is where the cellular and cost angle becomes concrete. IoTPortal's own reporting on public-IP industrial routers found that unsolicited bot traffic alone can consume 10 to 30 GB of mobile data per month on a poorly secured device on a public IP, before a single byte of legitimate traffic has passed. Baselining is how you notice that, and egress control, covered below, is how you stop paying for it.

Reading the results: normal versus suspicious

Once you have names, addresses, ports, cadence and volume, you can write down what normal looks like for this device. Everything else is measured against that baseline. The contrast usually looks like this:

This table is also, in effect, how you detect a compromised device without installing anything on it. Most IoT hardware cannot run endpoint security software, so its behaviour on the network is the only telemetry you have. A device that suddenly resolves new domains, reaches a new country, scans ports or uploads far more than usual has changed its behaviour, and behavioural change on a device that is supposed to do exactly one thing is the strongest signal of compromise you will get. IoTPortal's guide to endpoint security and VLAN containment covers how to isolate a device once it starts behaving oddly.

From audit to allowlist: the payoff

Characterisation is only half the value. The other half is using it. Most IoT deployments run with an implicit rule of "device VLAN to internet: allow anything". Your audit gives you everything you need to replace that with an explicit allowlist, which is the single highest-value control you can apply to an IoT estate.

The target policy is default-deny egress, permitting only the destinations your baseline proved the device needs:

Device → DNS resolver         # allow
Device → NTP time source      # allow
Device → vendor cloud (FQDN)  # allow
Device → firmware host        # allow
Device → management platform  # allow
Device → everything else      # DROP

On a Teltonika router you build this with traffic rules in the firewall, denying the device zone's outbound traffic by default and adding permit rules for the specific destinations. The engineering point that makes this worth the effort: a compromised device that cannot reach arbitrary command-and-control infrastructure is a device with a dramatically smaller blast radius. It may be infected, but if it can only physically reach its own cloud and a time server, the malware has nowhere to call home.

For cellular estates there is a second, stronger enforcement layer available at the connectivity level. A private APN can constrain what the SIM is able to reach across the carrier network itself, so egress control does not depend solely on the device's own firewall being correctly configured and unmodified. This is where network traffic auditing meets connectivity design; IoTPortal's explainer on private versus public IP for cellular IoT sets out how APN choice shapes both reachability and exposure.

An audit checklist you can reuse

Run this once per device type, then keep the baseline on file and re-run it after any firmware update:

1. Pick a capture point: SPAN port, the router itself, or an inline tap.
2. Capture a representative window covering active and idle periods.
3. Extract and count DNS queries; note any encrypted-DNS blind spot.
4. List destination IPs; enrich with ASN and country; flag anything that does not fit.
5. Map ports and protocols; flag plaintext and any inbound that succeeds.
6. Measure cadence and volume, especially during idle time.
7. Write down the baseline: the permitted set of names, addresses and ports.
8. Convert the baseline into default-deny egress rules on the router, and a private APN where the estate is cellular.
9. Re-audit after firmware updates and compare against the stored baseline.

Frequently asked questions