I was looking at my gateway logs at about two in the morning last night, and I saw something that would have made a normal person throw their smart toaster out the window. My cheap little LED controller, the one that cost me maybe twelve dollars, was trying to open a connection to an IP address in a sub-network I did not recognize. Today's prompt from Daniel is about exactly this, the phenomenon of consumer internet of things devices calling home and how we can actually tell the difference between a simple update check and something more sinister. We are living in the smart home paradox. We bring these devices into our most private spaces because they are convenient and cheap, but the hidden cost is a persistent, often encrypted tunnel back to a server in a jurisdiction that does not share our views on data privacy.
Herman Poppleberry here, and Corn, you are touching on one of my absolute favorite technical anxieties. Daniel is right to be concerned because most people just plug these things in, click allow on the app, and never look back. But if you actually pull back the curtain with something like Wireshark, the amount of chatter is staggering. We have moved from the era of dumb devices to an era where every light bulb and fridge is essentially an always-on edge compute node. These things have enough processing power to run complex scripts, and they are sitting right behind your firewall.
It really is a violation of trust. I think for most listeners, the first time they see a packet capture of their own network, it feels like a digital home invasion. You see these heartbeats every few seconds. But the challenge is that not every outbound packet is a threat. We have to define what calling home actually means. Is it just a firmware check, or is it something more?
We have to distinguish between necessary connectivity and data exfiltration. For example, many smart cameras use STUN or TURN servers. STUN stands for Session Traversal Utilities for NAT, and TURN is Traversal Using Relays around NAT. These are functionally necessary for peer-to-peer connectivity. If you want to see your camera feed on your phone while you are at the grocery store, the camera and the phone need a way to find each other through your router's firewall. That requires a handshake with a third-party server. That is a legitimate call home. But when your smart light switch is sending fifty megabytes of encrypted data to a random server in the middle of the night, that is not a handshake. That is a moving van taking your data out the front door.
So where do we even start when we are looking at a wall of encrypted traffic? If everything is wrapped in transport layer security, how do we know if it is a heartbeat or a heist?
You have to start with the handshake. Even if the actual payload of the traffic is encrypted using TLS, the initial connection phase often gives away the store. When a device first wakes up or tries to reach out, it usually performs a domain name system lookup. If you are monitoring your network, that is your first point of intelligence. Is it looking for an update server at a known manufacturer domain, or is it looking for a random alphanumeric string that smells like a command and control node? You should also look at the destination Autonomous System Number, or ASN. If your light bulb is talking to an ASN owned by a reputable cloud provider like Amazon Web Services or Google Cloud, that is one thing. If it is talking to a known high-risk ASN in a region known for hosting botnets, that is a massive red flag.
And even if it is a manufacturer domain, that is not always a clean bill of health. I have seen devices that use standard telemetry as a cover. They will send a heartbeat every thirty seconds that is maybe two hundred bytes, which is totally normal. It is just saying, hey, I am still alive, do you have any instructions for me? But then you see these bursts. Suddenly, at three in the morning, that two hundred byte heartbeat turns into a fifty megabyte upload. That is when the alarm bells should go off.
That is the signal versus noise problem. Standard telemetry, like firmware checks or time synchronization using network time protocol, follows a very predictable pattern. It is small, it is periodic, and it is usually directed at a well-known server. But when you see a shift in the duty cycle or the payload size, you are looking at something else. One thing I always tell people to look at is the server name indication, or SNI. In the initial client hello of a TLS handshake, the device often tells the server which domain it is trying to reach. Now, with the rollout of Encrypted Client Hello, or ECH, this is getting harder to see, but many IoT devices are still using older implementations of TLS where the SNI is visible in plaintext. If that SNI points to a known cloud relay, it might be benign. But if it is an IP address with no associated domain, or a domain registered three days ago, you have a problem.
I suspect a lot of these manufacturers insist on proprietary cloud relays specifically so they can bypass local protocols. If they used Matter or local mDNS discovery, they would not need to reach out to a server in another country just to turn on my light bulb. But by forcing everything through their cloud, they get the data, and they get to maintain a persistent connection to the heart of your network.
It is a deliberate architectural choice. By making the device a client that initiates an outbound connection, they bypass almost every consumer firewall. Most routers allow all outbound traffic by default. So the device calls home, establishes a bidirectional tunnel, and now the manufacturer has a persistent straw into your living room. What is particularly wild is that as of the first quarter of twenty twenty-six, over sixty-five percent of consumer IoT devices are still using hardcoded IP addresses for their primary reporting. They do not even bother with DNS because they want to make it harder for you to sinkhole the connection using something like a Pi-hole. They are essentially building their own private internet on top of yours.
That is a great point. If I block the domain, but the device just reaches out to a hardcoded IP, my DNS-based blocking is useless. I actually saw a case study recently comparing a standard Tuya-based smart plug to a device running open source firmware like Tasmota or Esphome. The Tuya plug was constantly hitting servers in multiple geographic regions, even when it was idle. It was checking in with servers in Oregon, then Frankfurt, then Shanghai. The Tasmota device, once integrated with Home Assistant, had zero outbound traffic. It stayed entirely within the local network. That contrast is the best evidence we have that this calling home behavior is rarely about functionality and almost always about data or control.
And the data they are taking is not just whether your light is on or off. The January twenty twenty-six IoT Security Baseline report highlighted that forty percent of smart appliances are transmitting device-specific metadata during every single heartbeat. We are talking about your MAC address, your local network topology, the signal strength of neighboring Wi-Fi networks, and even the names of other devices on your network. They are mapping your home from the inside out. They know when you are home, when you are sleeping, and what other tech you own.
It feels like we are paying these companies to install sensors for their own market research. But there is a darker side to this too, right? It is not just about telemetry. These devices are increasingly being used as infrastructure for other people's activities.
You are hitting on the second-order effects, which are arguably more dangerous for the internet as a whole. Many of these low-cost IoT devices are being compromised and turned into residential proxies. Because these devices have a legitimate residential IP address provided by your internet service provider, they are incredibly valuable to bad actors. If a botnet wants to scrape a website, launch a credential stuffing attack, or bypass a streaming service's geo-fence, they do not want to do it from a data center IP that will be immediately blocked. They want to do it from your smart fridge or your connected garage door opener.
This connects back to what we discussed in episode one thousand eight about the geo-blocking fallacy. People think that if they just block IP ranges from specific countries, they are safe. But if your smart bulb is acting as a SOCKS5 proxy, a bad actor in a different country can route their traffic through your bulb. To the rest of the world, that malicious traffic looks like it is coming from your house in your neighborhood. You are essentially providing cover for their operations without ever knowing it.
It is the perfect disguise. And because most consumer routers do not inspect outbound traffic for proxy patterns, you would never notice the performance hit. Your light bulb might be using five percent of your upload bandwidth to help a botnet bypass geo-fencing, and you would just think your internet is a little laggy today. This is why the technical distinction between a heartbeat and a proxy stream is so critical. A heartbeat is a few packets. A proxy connection involves long-lived TCP sessions with high entropy data moving in both directions. If you see a device that has a persistent connection to an IP in Virginia or Ireland or anywhere else, you have to look at the traffic symmetry.
Explain that symmetry concept a bit more for the listeners.
Standard IoT communication is very asymmetrical. You send a small command, like turn on, and the device sends a small acknowledgement. Even telemetry is usually a one-way burst of data. But if you see a device where the upload and download volumes are roughly equal and the connection stays open for hours, that is a classic sign of proxy activity. The device is relaying data. It is receiving a request from the controller and passing it along to a target, then passing the response back. That kind of bidirectional, high-volume flow is almost never legitimate for a simple smart device.
We also have to talk about the reality of network segmentation. Daniel mentioned that very few people have the discipline to set up a VLAN. I get it. It is a pain to configure. You have to deal with mDNS reflectors and Avahi just so your phone on the main network can see the smart speaker on the IoT network. If you do it wrong, your phone cannot talk to your smart speaker, and everyone in the house is annoyed. But at this point, with the level of exfiltration we are seeing, a VLAN is not just for nerds anymore. It is a basic safety requirement.
It really is the only way to achieve true isolation. If you put all your untrusted IoT devices on a separate virtual local area network and then use firewall rules to prevent them from talking to your main computers or your network attached storage, you have at least contained the blast radius. We went into the weeds on how to do this properly in episode one thousand seventy-one when we talked about advanced router routing. The key is to allow the devices to talk to the internet if they must, but never let them initiate a connection to your private devices. You want a one-way street where you can talk to them, but they cannot talk to you.
And even then, I would argue you should try to cut off their internet access entirely whenever possible. I have a few cameras that I have completely blocked from the internet at the router level. I use a local server to record the footage. But here is the thing that drives me crazy, Herman. Some of these devices are programmed to fail if they cannot call home. I have seen smart switches that will literally stop responding to physical button presses if they lose their connection to the cloud for more than twenty-four hours.
That is the ultimate vendor lock-in. It is a software-defined kill switch. They justify it by saying it is for security or to ensure the device has the latest updates, but in reality, it is about maintaining that connection. If you block the internet access, and the device enters a boot-loop or stops functioning, you know you have a device that does not belong to you. You are just renting the right to use it as long as the manufacturer is happy. This is a huge misconception people have. They think blocking the internet is a silver bullet, but often it just turns your twenty dollar light bulb into a twenty dollar paperweight.
It is a total lack of agency. It makes me think about the future of this space. Are we ever going to get to a point where there is a privacy-first certification? Something that tells a consumer, this device is local-only by default and will never call home unless you explicitly enable a feature?
We are seeing the beginnings of that with the FCC's Cyber Trust Mark program, which is finally gaining some traction here in twenty twenty-six. We are also seeing Matter and Thread mature, but even there, the implementation matters more than the standard. The standard allows for local control, but it does not forbid cloud connectivity. What I would love to see is a literal physical switch on these devices, a hardware disconnect for the Wi-Fi or the cloud functionality. But until that happens, the burden is on us to be the network police.
Which brings us to the practical side of this. If someone is listening and they want to start auditing their own home, what is the three-tier approach you would recommend? Because we cannot all be running Wireshark on a dedicated laptop twenty-four seven.
The first tier is isolation. If your router supports it, put your IoT devices on a guest network at the very least. It is a crude form of segmentation, but it keeps them away from your primary data. The second tier is sinkholing. Use a DNS-based blocker like Pi-hole or AdGuard Home. This will catch the low-hanging fruit, the devices that are trying to reach known tracking and telemetry domains. You can find pre-made blocklists specifically for IoT telemetry, like the OISD lists or the Firebog collections, which are updated daily.
And the third tier? That is where it gets fun.
Tier three is active monitoring and sinkholing at the IP level. This requires a slightly more advanced firewall, something like pfSense or OPNsense, or even a high-end consumer appliance. You want to look for any device that is bypassing your DNS settings and reaching out to hardcoded IPs. Once you identify those IPs, you can create a rule to null-route them. A null-route basically tells the router to drop those packets into a black hole. But you have to be careful. If you block the wrong IP, you might break the device's ability to get the time via NTP, and then its SSL certificates will fail because the device thinks it is nineteen seventy, and the whole thing stops working.
I also want to mention some tools for people who are on macOS or Linux and want to see what is happening on their local machine, not just the network. Tools like Little Snitch or LuLu are incredible for this. They give you a popup every time a process tries to make a network connection. It is eye-opening to see a simple utility app trying to connect to a marketing server in the middle of a task. It gives you that same sense of control that we are trying to achieve for the whole network.
Those tools are great because they provide context. They tell you exactly which process is responsible for the traffic. On a network level, you just see a MAC address and a bunch of packets. On the host level, you see that it is the updater service or the analytics engine. That distinction is vital for understanding the intent behind the traffic. If you see a process called weather-widget trying to open a SOCKS5 tunnel to a server in a different country, you know you have a compromised process.
We should also touch on the fact that moving toward local-first ecosystems is the only long-term solution. We talked about this in episode seven hundred twenty-three regarding home security cameras. If you buy a camera from a brand that requires a cloud subscription, you have already lost the privacy battle. But if you buy a high-quality Power over Ethernet camera and run it into a local network video recorder that is air-gapped from the internet, you have total control. The hardware is yours, the data is yours, and the network is silent.
That is the gold standard. If you cannot see the traffic, you do not own the device. It is a simple rule, but it is hard to live by in a world that wants everything to be smart and connected. I think the takeaway for Daniel and for everyone else is that you have to be proactive. The default state of a modern consumer device is to be a snitch. It is designed to report back everything it can because that data has value. Your job as the network administrator of your own home is to make that data as expensive and difficult to collect as possible.
It is about raising the cost of surveillance. If enough of us start segmenting our networks and blocking these telemetry streams, manufacturers might eventually realize that local-first is a selling point, not a bug. But until then, I will keep looking at my logs at two in the morning and wondering why my light bulb needs to talk to a server in Virginia.
And I will be right there with you, probably reading a white paper on the latest obfuscation techniques they are using to hide that traffic. It is an arms race, Corn, but it is one that is worth winning. We have to remember that these devices are guests in our homes. We should treat them with the same level of scrutiny we would give a stranger walking through our living room.
I think we have covered the core of the calling home issue. It really comes down to that signal versus noise distinction and having the tools to see what is actually moving across the wire. If you can identify the handshake, monitor the payload symmetry, and implement basic segmentation, you are already ahead of ninety-nine percent of the population.
Definitely. And do not be afraid to break things. Sometimes the best way to learn what a device is doing is to block its access and see what fails. If it stops working entirely, you know it was doing something it should not have been. It is the ultimate diagnostic tool.
That is a very Herman approach to troubleshooting. Just break it and see what happens. But honestly, it is the most effective way to find the dependencies. Well, I think that is a wrap on this one. Thanks as always to our producer Hilbert Flumingtop for keeping the gears turning behind the scenes.
And a big thanks to Modal for providing the GPU credits that power this show. We literally could not do this without that serverless horsepower.
This has been My Weird Prompts. If you are finding these deep dives useful, a quick review on your favorite podcast app really does help us reach more people who are trying to navigate this weird technical landscape.
We are also on Spotify if you want to follow us there and get notified as soon as new episodes drop.
Until next time, keep an eye on those logs.
Stay curious.
