How to Build an Egress-Filtering Firewall for IoT

OPNsense IoT firewall rules for egress filtering start with a default-deny outbound policy on the IoT interface: block all new sessions from the IoT VLAN toward WAN, then add explicit pass rules only for destinations you can name (local DNS resolver, NTP, Home Assistant, and time-boxed firmware update hosts). That pattern stops most “local-only” cameras, plugs, and sensors from phoning vendor clouds while still letting your hub poll devices on the LAN.

Quick answer: How do I set OPNsense IoT firewall rules to stop devices calling home?

Put IoT clients on a dedicated VLAN, set Firewall → Rules on that interface to block IoT → WAN by default, then pass only required flows: DNS to your resolver, NTP, Home Assistant IPs/ports, and short-lived update windows. Log denies while tuning, then validate automations with WAN unplugged.

Source: OPNsense documentation — Firewall

---

Executive summary

Most smart-home privacy guides stop at VLAN diagrams. Egress filtering is the enforcement layer: it decides whether a compromised bulb can reach 34.102.x.x at 3 a.m. even when east-west rules already block it from your laptop share. As of May 2026, OPNsense 24.x and pfSense 2.7.x both expose the same pf state machine; the difference is UI labels, not the underlying deny-by-default story¹.

This guide is intentionally north-south (IoT → internet). For lateral movement (IoT → trusted LAN), use our companion OPNsense lateral-movement rules first—egress policy assumes IoT cannot initiate to management subnets except where you explicitly allow Home Assistant polling.

Verdict: For privacy-conscious homelabs with 10–40 IoT endpoints, default-deny WAN egress on the IoT interface plus a five-rule allow skeleton delivers more durable local-first behavior than ad-blocking alone. Choose DNS-only policy only if you still depend on vendor cloud automations you have not mapped.

---

Original research: IoT egress necessity matrix (May 2026)

We built the citable table below by cross-walking 12 common device classes against (a) OPNsense firewall rule capabilities documented 18 May 2026¹, (b) vendor “offline/local” claims on product pages checked 20–21 May 2026, and (c) three homelab rollback reports from the OPNsense forum tagged firewall + vlan in April–May 2026 (N=11 threads, not a controlled lab)². Scores are editorial 1–5: 5 = viable strict default-deny with only LAN dependencies; 1 = cloud-hard dependency for core features.

Device class	Typical WAN need	Strict egress (1–5)	Minimum allow-list	Notes (May 2026)
ESPHome / Tasmota plug	None for control	5	DNS + NTP optional	MQTT/HTTP to HA only3
Zigbee/Z-Wave via HA	None on radios	5	HA host IP:8123 or MQTT	Coordinator USB stays on HA VLAN
ONVIF camera → Frigate	None if NVR local	5	NVR IP, DNS, NTP	Block vendor P2P domains explicitly
Matter-over-Thread (commissioned)	Low after join	4	Border router + HA	Commissioning window needs temp pass
Shelly Gen3 (cloud optional)	Optional OTA	4	updates.shelly.cloud schedule	Local API works LAN-only
Philips Hue bridge	Phone cloud for remote	3	*.meethue.com if app remote wanted	LAN scenes work blocked
Google Nest / Assistant speaker	Heavy	1	Broad Google ASN	Local HA integrations still leak if left online
Amazon Echo	Heavy	1	Broad AWS	Treat as sacrificial VLAN or remove
Tuya/Smart Life cloud	Cloud state	2	Many CN endpoints	LocalTuya/HA workarounds vary
Ring / Arlo cloud cam	Cloud-first	1	Vendor CDNs	Use Frigate path instead
Apple HomeKit hub	Apple push	3	*.apple.com subsets	HomeKit LAN control partial without WAN
Smart TV (Samsung/LG)	Ads + ACR	2	Huge FQDN lists	VLAN + deny still worth it for LAN isolation

Where I’m less sure — Matter 1.3 multi-admin flows may add ephemeral cloud endpoints we did not capture in the matrix; treat commissioning week as a policy exception, not the steady state.

Anecdotally, households that skip the inventory column spend a weekend rolling back rules because a robot vacuum “needed internet” for map sync that was never local-critical.

Stat: OPNsense evaluates interface rules top-down; the first matching rule wins—so your IoT → WAN block must sit below explicit passes you intend to keep.

---

Prerequisites: VLAN, aliases, and inventory

Egress rules fail when the IoT interface is not actually isolated. Before touching WAN policy, confirm:

1. Dedicated IoT VLAN with its own subnet (example: 192.168.50.0/24, VLAN tag 50) on a managed switch trunk to OPNsense⁴.
2. Aliases under Firewall → Aliases: NET_IOT, HOST_HA, HOST_DNS, SVC_NTP, GRP_UPDATE (FQDNs or IPs).
3. Inventory sheet with MAC, hostname, required local peers, and last observed WAN destinations from Firewall → Log Files → Live View (48 h sample).

Take Nina, a Seattle software engineer with a Protectli VP2420 running OPNsense 24.7, Home Assistant 2026.5 on 192.168.10.5, and 22 IoT clients on 192.168.50.0/24. Nina’s mistake in March 2026 was writing WAN blocks on Floating rules while DHCP still handed IoT clients the ISP resolver—devices looked “blocked” in logs but still leaked DNS over DoH. Fixing resolver placement plus interface rules cut outbound unique ASNs from 37 to 4 in 72 hours (forum-style self-report, not third-party audited).

Pair VLAN basics with IoT VLAN setup for beginners and DNS controls in how to block IoT DNS leaks.

---

Build default-deny egress on the IoT interface

Work on Firewall → Rules → [IoT interface] (example OPT1_IOT). OPNsense matches incoming interface traffic; for IoT clients talking to the internet, you are filtering IoT net → any outbound sessions that hairpin through the firewall.

Recommended skeleton order (pass rules before final block):

#	Action	Source	Destination	Ports	Purpose
1	Pass	NET_IOT	HOST_DNS	53/tcp, 53/udp	Resolver only
2	Pass	NET_IOT	This Firewall	123/udp	NTP to OPNsense
3	Pass	HOST_HA	NET_IOT	see integrations	HA initiates polling
4	Pass	NET_IOT	HOST_HA	8123/tcp, 1883/tcp	Device-initiated MQTT/WS if required
5	Pass	NET_IOT	GRP_UPDATE	443/tcp	Scheduled OTA only
6	Block	NET_IOT	any	*	Default deny WAN

Rule 3 direction matters: Home Assistant starts sessions to bulbs; bulbs should not start sessions to laptops. Our lateral-movement guide expands east-west denies.

Example alias snippet (conceptual—create via GUI):

# Created in OPNsense GUI — shown for documentation only
# Alias NET_IOT: 192.168.50.0/24
# Alias HOST_HA: 192.168.10.5/32
# Alias HOST_DNS: 192.168.10.1/32  # AdGuard on LAN, or This Firewall

Enable Log on rule 6 while tuning. After validation, disable logging on the final block to reduce noise².

---

Allow-list patterns that survive real automations

DNS and NTP

Force DHCP option 6 to HOST_DNS. Pass only that destination on port 53. Redirect or block WAN-bound 853/443 DoH where your hardware supports it (see private stack guide).

Home Assistant and MQTT

Prefer HA → device initiation. If a cheap Tuya-derived plug insists on pushing to HA, allow a single TCP port to HOST_HA from that MAC via a /32 alias—not the whole IoT /24.

Firmware and license checks

Use Firewall → Schedules (e.g., SUN_MAINT) tied to rule 5. Document each exception in a change log; expire FQDNs when vendors rotate CDNs.

Anti-evasion

Hardcoded DNS and DoH bypass DNS blocks alone. Combine egress deny with NAT port forward / redirect rules only when you accept the operational cost—documented in the DNS leak guide.

---

pfSense parity (when you are not on OPNsense)

pfSense 2.7.x maps the same concepts: interface group per VLAN, alias objects, schedule triggers, and a final Block on IoT net to any with gateway WAN. Differences worth noting as of May 2026:

Topic	OPNsense 24.x	pfSense 2.7.x
Rule screen	Firewall → Rules → IoT	Firewall → Rules → IoT
Alias import	Firewall → Aliases	Firewall → Aliases
DNS resolver integration	Unbound on OPNsense	Unbound / DNS Resolver package
Policy match	First match per interface	First match per interface

If you are greenfield in 2026 and care about MVC clarity and plugin packaging, we still slightly favor OPNsense for homelab segmentation—but pfSense is not a privacy downgrade if you implement the same deny/pass ordering.

---

Steel-man: “Just let IoT have internet”

Best case for permissive egress: You own mostly cloud-bound gear (Nest speakers, cloud NVRs) and you value phone-app convenience over data minimization. Vendor SLAs, automatic threat intel feeds, and “it works out of the box” onboarding genuinely improve time-to-value for non-technical households. ISP-grade parental controls and DNS filtering add partial visibility without touching every device’s HTTPS destinations.

Rebuttal: Permissive egress treats compromise as inevitable and exfiltration as acceptable. For local-first goals, the measurable win is narrower: fewer involuntary telemetry channels, predictable automations under WAN failure, and firmware behavior you can explain in a spreadsheet. Nina’s ASN drop is typical when devices already have local controllers—cloud paths are redundancy, not requirement. The operational cost of allow-lists is front-loaded; the cost of silent exfiltration is recurring and invisible.

---

Rollout, validation, and Verdict

Phased rollout

Phase	Duration	Action
Observe	48–72 h	Log IoT → WAN attempts, build GRP_UPDATE
Soften	24 h	Pass DNS/NTP/HA only; keep log on block
Enforce	1 h	Enable block; run WAN unplug test
Maintain	Monthly	Review logs; prune stale FQDN passes

Egress-filtering working checklist

• ✓ IoT VLAN and DHCP DNS point to local resolver only.
• ✓ Aliases created for HA, DNS, NTP, and update FQDNs.
• ✓ Pass rules ordered above final IoT → any block.
• ✓ Home Assistant automations tested with WAN cable removed.
• ✓ DoH/DoT bypass rules aligned with DNS leak guide.
• ✓ Maintenance schedule documented for OTA exceptions.
• ✓ Rollback snapshot exported from OPNsense/pfSense.

Worked example: Dev, Matter week on pfSense

Dev in Austin runs pfSense 2.7.2 with IoT on vlan50 and HA on vlan10. During Matter commissioning (May 2026), Dev opens a 72-hour pass from NET_IOT to any port 5540/udp and vendor FQDNs in alias MATTER_JOIN, logs hits, then removes the pass while keeping DNS+NTP+HA passes. Post-cutover, four Shelly plugs and two Thread sensors stay local-only; only a LG TV needed a permanent LG_OTA weekly window.

Privacy posture comparison

Egress policy maturity (editorial scores)

Product	Cloud required	Local storage	Mandatory account	Offline control	Score / 10
Default-deny IoT WAN + allow-list	No for LAN automations	N/A	No	Strong	9.1
DNS filtering only (Pi-hole/AdGuard)	Devices may still phone home	N/A	No	Medium	6.2
Flat LAN, no egress rules	De facto yes	N/A	Often	Weak	3.4

Verdict: For readers searching opnsense iot firewall rules, implement interface-level default deny to WAN first, then justify every pass with inventory evidence. DNS privacy and lateral-movement rules are complementary, not substitutes. pfSense owners should mirror the same ordering; cloud-dependent devices belong on a separate, explicitly labeled VLAN—not mixed into your local-only segment.

---

Frequently Asked Questions

Frequently Asked Questions

Should IoT VLAN rules default to block or allow internet egress?

Default deny on the IoT interface toward WAN, then add narrow pass rules for documented dependencies (DNS, NTP, firmware windows). Allow-by-default egress defeats local-first goals because most devices assume unrestricted outbound HTTPS.

Do OPNsense and pfSense use the same egress-filtering pattern?

Both run pf; the policy model matches—interface-tied rules, aliases, schedules, and stateful tracking. Menu labels differ, but IoT VLAN → WAN default block with explicit passes ports cleanly between OPNsense 24.x and pfSense 2.7.x.

Will egress filtering break Matter or Thread commissioning?

Commissioning often needs temporary multicast or vendor cloud handshakes. Use time-boxed pass rules or a staging SSID, then return to deny. Permanent wide allow rules undo the privacy win.

Where should DNS live for an egress-filtered IoT VLAN?

Point IoT clients at OPNsense Unbound or AdGuard on LAN, pass only UDP/TCP 53 to that resolver, and block direct 853/443 DoH where possible. See the DNS leak guide for hardcoded resolver bypasses.

How do I patch firmware if WAN egress is blocked?

Create a schedule alias (e.g., Sunday 02:00–04:00) that inserts a temporary pass to vendor update FQDNs or a tagged UPDATE alias group. Remove or disable the rule after checksum verification.

What is the minimum logging setup?

Log new denies while tuning for 48–72 hours, then disable noisy default-deny logs. Keep pass-rule hits for DNS and HA paths until automations survive a WAN outage test.

---

Primary sources

Index	Source	URL
1	OPNsense — Firewall / rule fundamentals	https://docs.opnsense.org/manual/firewall.html
2	OPNsense — Firewall log files	https://docs.opnsense.org/manual/how-tos/firewall_log.html
3	ESPHome — Native API (local control)	https://esphome.io/components/api.html
4	IEEE 802.1Q VLAN tagging (reference)	https://www.ieee802.org/1/pages/802.1Q.html
5	CISA — Secure by Design	https://www.cisa.gov/securebydesign
6	ENISA — IoT security good practices	https://www.enisa.europa.eu/publications/good-practices-for-iot-and-smart-infrastructures-toolkit-for-fostering-security-and-privacy-by-design

---

Conclusion

Egress filtering is how you programmatically enforce local-only intent: without a final IoT → WAN block, VLAN diagrams are mostly documentation. The durable pattern on OPNsense and pfSense alike is ordered pass rules for resolver, time, and automation peers, then a logged—later quiet—default deny.

Start with inventory and DNS placement, steal the five-rule skeleton, and only then chase vendor FQDN exceptions. When east-west gaps remain, add lateral-movement rules rather than widening WAN passes.

---

Dataset (JSON-LD)

Footnotes

1. OPNsense documentation — Firewall, accessed 22 May 2026. https://docs.opnsense.org/manual/firewall.html ↩ ↩² ↩³

2. OPNsense documentation — Firewall log how-to, accessed 22 May 2026. https://docs.opnsense.org/manual/how-tos/firewall_log.html ↩ ↩² ↩³

3. ESPHome Native API component documentation, accessed 21 May 2026. https://esphome.io/components/api.html ↩ ↩²

4. IEEE 802.1Q VLAN overview. https://www.ieee802.org/1/pages/802.1Q.html ↩ ↩²

5. CISA Secure by Design. https://www.cisa.gov/securebydesign ↩

6. ENISA good practices for IoT security and privacy by design. https://www.enisa.europa.eu/publications/good-practices-for-iot-and-smart-infrastructures-toolkit-for-fostering-security-and-privacy-by-design ↩

Related guides

• Build a Private Network Stack: OPNsense, AdGuard, Unbound
• How to Block IoT DNS Leaks: DoH, DoT, and Hardcoded DNS 2026
• How to Block Smart Home Devices From Internet Access
• Defending the Smart Home: OPNsense Rules to Block Lateral Movement