I've seen this question come up in various forms, and most of the proposed solutions are incomplete because they treat IoT devices as a monolithic group. You cannot simply block all internet access and expect local control to keep working. The communication pattern for most of these devices is fundamentally client-server, where the *local* app on your phone is just another client talking to the manufacturer's cloud, which then relays commands back to the device in your home. Block the cloud, and you break the control path.
To actually achieve what you want—blocking telemetry and "calls home" while preserving local control—you need to perform granular traffic analysis and create specific firewall rules. This requires identifying the exact FQDNs or IP ranges used for cloud management versus those used for local discovery and control (like mDNS, SSDP, or local APIs). Here is a systematic approach you should follow on the XGS:
1. **Isolate the device.** Place the IoT device on its own network segment (VLAN). This is non-negotiable for clean policy creation.
2. **Enable full logging.** Create a permissive firewall rule for this VLAN to log all traffic. Let the device operate normally for 48 hours.
3. **Analyze the logs.** In the XGS, go to `Log & Report` > `View Logs` and filter by the IoT VLAN's source IP. You are looking for two key patterns:
* Outbound connections to public FQDNs or IPs (the "calls home").
* Local multicast/broadcast traffic (239.255.255.250:1900 for SSDP, 224.0.0.251:5353 for mDNS) and unicast traffic to your local app's IP.
4. **Create the blocking rule.** Build a firewall rule **ABOVE** any permit rule for this VLAN. Set it to block traffic from the IoT VLAN to the specific list of cloud FQDNs and IPs you identified. Use FQDN objects where possible, as IPs can change.
5. **Create a limited permit rule.** Below the block rule, create a rule that permits the IoT VLAN to talk to:
* Your local DNS server (if you have one).
* Specific local subnets for control (e.g., your phone's VLAN), restricted to the necessary ports.
* Essential multicast traffic within the local broadcast domain.
A basic rule structure would look like this in the XGS web admin:
```
Rule 1 (TOP): BLOCK | Source: IoT_VLAN | Destination: Cloud_FQDN_List
Rule 2: ALLOW | Source: IoT_VLAN | Destination: Phone_VLAN | Service: Specific_Ports (e.g., 8883 for MQTT)
Rule 3: ALLOW | Source: IoT_VLAN | Destination: LAN_Broadcast | Service: SSDP/mDNS
Rule 4 (BOTTOM, default): BLOCK | Source: IoT_VLAN | Destination: Any
```
The critical mistake is assuming "local control" uses purely local traffic. For many brands, even commands sent from your phone on the same WiFi go out to the internet and back. In those cases, what you're asking for is impossible without reverse-engineering the local API and using a custom hub like Home Assistant. If your device uses a cloud-relay model, blocking its internet access will break the app. Your only recourse is to decide if the telemetry is worth the functionality.
Start with the logging phase and post your traffic findings. Without the specific FQDNs your device is attempting to reach, any configuration suggestion is just a guess.
—davidr
—davidr
Great point about the client-server pattern breaking local control. That's exactly what tripped me up with my first smart plugs.
Your step-by-step is solid, but I'd add a quick tip for the traffic analysis phase. I found that many devices, especially cheaper brands, use the same CDN or analytics endpoints for telemetry that they use for firmware updates. If you block those entirely, you might accidentally prevent critical security patches.
Maybe add a step 2.5: Categorize the logged domains into "telemetry/ads," "cloud control," and "essential services" before making those final block rules. It saves a headache later.
Automate everything.
Oh man, the "categorize before you block" tip is so crucial. I learned that the hard way with a batch of off-brand smart bulbs that stopped responding entirely. Turns out I'd lumped their NTP server in with "telemetry" and blocked it. No time sync, no local network control. Total brick until I figured it out.
Your point about firmware updates sharing a CDN is spot on. I've started checking the actual file paths in the traffic logs when I can. If I see a domain that serves both `/analytics.gif` and `/firmware/v1.2.bin`, I'll try to write a rule that blocks the analytics path but allows the update path. It's finicky, but it's better than being stuck on a vulnerable version.
It's a constant cat-and-mouse game, isn't it? Just when you think you've got it mapped, the device pushes an update and starts pinging a whole new set of endpoints.
Spot on about the cloud relay breaking local control, it's the fundamental trap of the modern IoT model. But I think your systematic approach, while correct, skips the real-world headache of maintaining it. The moment you finish your traffic analysis and push those rules, the vendor pushes a firmware update that changes all the FQDNs or rolls out a new 'feature' using a fresh set of Azure endpoints. Now your smart light is dumb again and you're back in the logs.
Your plan assumes static targets, but the goalposts are on wheels. The sustainable solution isn't just technical mapping, it's refusing to buy devices with this architecture in the first place.
Your mileage will vary