I built a firewall that blocks my IoT devices from phoning home

In the modern connected home, the proliferation of Internet of Things (IoT) devices has created a convenience paradox. While smart lightbulbs, thermostats, and refrigerators promise streamlined living, they often come with a hidden cost: a relentless hunger for data transmission. We have observed that many of these devices, particularly those from non-premium manufacturers, engage in aggressive telemetry collection, sending usage patterns, network data, and even audio snippets back to manufacturer servers. This practice, known colloquially as “phoning home,” poses significant privacy risks and consumes valuable network bandwidth. We decided that our lightbulbs do not need internet access, and they never should. To enforce this mandate, we engineered a robust, multi-layered firewall solution designed to sever the external communication lines of our IoT ecosystem while preserving local control.

Understanding the IoT Privacy Dilemma and Phoning Home Risks

The premise of our project is rooted in a fundamental architectural observation: the vast majority of IoT devices require a persistent connection to a cloud server to function, even for tasks that should logically be handled locally. When a user flips a switch on a smartphone app to turn on a light, the signal often travels from the phone to the manufacturer’s cloud, then back down to the bulb. This “hairpin” routing introduces latency and creates a massive data trail.

The Architecture of Unnecessary Data Exfiltration

We analyzed traffic from various smart devices and discovered patterns of excessive data exfiltration. These devices frequently transmit:

• Network Scanning Data: Many IoT devices scan the local network for other devices, reporting MAC addresses and IP schemas to the cloud.
• Usage Metadata: Timestamps of when lights are turned on and off, duration of usage, and ambient light sensor readings.
• Payload Obfuscation: To bypass simple parental controls, devices often use DNS over HTTPS (DoH) or hardcoded DNS resolvers to bypass local network policies.

By blocking these connections, we are not merely reclaiming privacy; we are securing the local network perimeter. A compromised lightbulb is a pivot point into the network. If it can communicate freely with a malicious server, it becomes a vector for lateral movement.

Designing the Network Topology for Strict Segregation

To effectively block IoT devices from phoning home without rendering them useless, we cannot rely on simple MAC address filtering. We implemented a network segregation strategy using a dedicated VLAN (Virtual Local Area Network) for all IoT traffic. This approach isolates smart devices from the primary network where personal computers and mobile phones reside.

The Role of VLANs in IoT Security

By assigning IoT devices to a isolated VLAN, we create a logical barrier. The IoT VLAN has no routing rules allowing initiation of connections to the trusted internal network. However, we need devices on the trusted network to control the IoT devices (e.g., using a phone app). This requires specific firewall rules that allow traffic to flow only in the necessary direction and for specific protocols.

Our topology looks like this:

1. IoT VLAN (Tagged 20): Contains all smart bulbs, plugs, and speakers. No internet access allowed.
2. Management VLAN (Tagged 10): Contains the mobile devices and control hubs (like Home Assistant).
3. Router/Firewall (OPNsense/pfSense): The gatekeeper that enforces the rules.

Configuring the Router Firewall to Block External Access

The core of our solution lies in the firewall configuration. We utilized a pfSense-based router, but the logic applies to any enterprise-grade firewall. The goal is to create an “internet kill switch” for the IoT VLAN while permitting local discovery protocols (mDNS/Bonjour).

Step 1: The WAN Reject Rule

We first established a blanket rule on the WAN interface. Any traffic originating from the IoT VLAN’s source IP range destined for any external IP is immediately rejected. This is the primary kill switch.

• Protocol: Any
• Source: IoT_Subnet
• Destination: Any
• Action: Reject

Step 2: Blocking DNS Escapes

A common workaround for devices is to use hardcoded DNS servers (like Google DNS at 8.8.8.8) to bypass the local router’s DNS. To stop this, we created a rule that blocks all outbound UDP and TCP traffic on port 53 (DNS) from the IoT VLAN, except for traffic directed at our internal DNS resolver (e.g., AdGuard Home or Pi-hole). This forces devices to use our local DNS, allowing us to sinkhole their telemetry domains.

Step 3: Handling NTP and Time Sync

Many devices fail to function if they cannot synchronize time. We allow outbound NTP (Port 123) traffic to specific public NTP pools. While this leaks a tiny amount of metadata (that the device is online), it is often necessary for the device’s internal clock and SSL certificate validation.

Using DNS Sinkholing to Nullify Telemetry Endpoints

While the firewall blocks direct IP access, DNS sinkholing provides a granular layer of control. We set up a local recursive DNS resolver that acts as a black hole for known telemetry domains.

Identifying Phoning Home Domains

We utilized community-maintained blocklists (specifically looking at lists like “oisd” or “iot-analytics”) that categorize domains used for telemetry. When a lightbulb requests telemetry.smartbulb.com, the DNS resolver returns 0.0.0.0 (a non-routable address) instead of the real IP.

The Whitelisting Strategy

The challenge with aggressive blocking is breaking functionality. If a device requires a cloud connection for “Hey Google, turn on the lights,” blocking that domain entirely breaks voice control. To solve this, we employ a whitelist strategy:

1. Identify Essential Domains: We temporarily enable logging and check which domains the device queries to function.
2. Whitelist Specific APIs: We allow traffic to *.googleapis.com or specific AWS endpoints if they are required for the voice assistant to communicate with the cloud, while blocking all other telemetry.
3. Wildcard Blocking: For devices that do not require cloud interaction (like a Philips Hue bridge operating in local mode), we block all external DNS queries entirely.

Implementing Local Control Mechanisms

Once the internet is severed, we need a way to control the devices. We cannot rely on the manufacturer’s cloud app. We implemented Home Assistant on a local server to serve as the central control interface.

The Importance of Local Polling vs. Cloud Push

Home Assistant utilizes local APIs whenever possible. For Zigbee or Z-Wave devices, the communication is entirely local via the hub. For Wi-Fi devices that still require a cloud for the app, we use custom integrations that interact with the device over the local network, bypassing the cloud entirely. This often involves flashing devices with open-source firmware like Tasmota or ESPHome. However, for devices that cannot be flashed (like certain smart bulbs), the firewall rule set becomes the only line of defense. We configure Home Assistant to control these devices via local HTTP calls, and our firewall ensures the devices cannot accept incoming connections from the internet (WAN) or report data out.

Advanced Technique: MAC Address Filtering and Isolation

In addition to layer 3 (IP) firewalling, we employ layer 2 (MAC address) isolation on the switch level. This prevents IoT devices from communicating with each other directly. While a lightbulb doesn’t need to talk to a smart plug, a compromised bulb might try to infect the plug via a local exploit.

Configuring Private VLANs (PVLAN)

If your network switch supports it (common in Ubiquiti UniFi or Cisco managed switches), enabling Private VLANs is the ultimate security measure.

• Promiscuous Port: The router port (trunk).
• Isolated Ports: All IoT device ports. They can talk to the router but not to each other.
• Community Ports: (Optional) If you have a group of devices that need to talk locally (e.g., a Zigbee hub and a sensor), they can be grouped.

Verifying the Firewall Rules: How to Test Your Setup

We never assume a firewall is working without verification. We set up a monitoring environment to ensure no packets are escaping.

Using a Network Tap or Port Mirroring

We configured a mirror port on our switch to copy all traffic from the IoT VLAN to a network interface on a monitoring server running Wireshark. This allows us to see every packet leaving a specific lightbulb.

Analyzing Traffic with tcpdump

On the router itself, we run commands to capture traffic in real-time. A typical check looks like this: tcpdump -i VLAN20 -n host 8.8.8.8 If we see SYN packets (connection attempts) leaving the interface for external IPs, our rules are failing. If we see only ARP requests or mDNS (224.0.0.251) traffic, our isolation is successful.

Handling Specific Device Quirks

Not all IoT devices behave the same way. We encountered specific challenges that required unique solutions.

Smart TVs and Streaming Devices

These are the most difficult to block because they inherently need the internet for content. However, we still block their telemetry and “suggested content” servers. We create a separate rule set for the TV that allows Netflix/Disney+ IPs but blocks the “samba” advertising and usage statistics reporting servers (e.g., smarttv-*.com).

Voice Assistants (Alexa/Google Home)

These devices are always listening. Blocking their internet access entirely kills their utility. For these, we allow access to specific Amazon and Google domains required for wake word processing. However, we block the “Drop In” feature and detailed voice history uploading by blocking specific API endpoints used for those features.

Maintaining the Firewall: Long-Term Management

Building the firewall is the initial step; maintaining it is an ongoing process. Firmware updates can change a device’s behavior, causing it to try new domains.

Automated Blocklist Updates

We use a script that downloads updated telemetry blocklists weekly. This ensures that newly discovered data collection domains are automatically sinkholed.

Logging and Alerting

We enabled detailed logging on the firewall rules for the IoT VLAN. If a device generates a high volume of “Blocked” events, it signals that the device is aggressively trying to reconnect or that a firmware update has changed its behavior. We review these logs monthly to fine-tune the whitelist.

Conclusion: Achieving True Smart Home Privacy

By building a custom firewall, we have effectively taken back control of our smart home. Our lightbulbs illuminate the room instantly via local commands, yet they remain ignorant of the wider internet. They cannot report our sleeping habits to a server in a foreign country, nor can they be recruited into a botnet. While the manufacturer intended for these devices to be part of an ecosystem, we have forcibly reclaimed them for our private ecosystem. The result is a faster, more secure, and significantly more private smart home environment. This approach requires technical diligence, but the peace of mind regarding data sovereignty is an invaluable return on investment.