Lesson 4 of 5 5 min read

Firewall Rules and DNS Filtering for IoT

VLANs create the boundaries; firewall rules enforce them. Without rules, most routers will happily route traffic between all VLANs, defeating the purpose of segmentation. This lesson covers the essential firewall rules for an IoT-segmented network, explains stateful firewall concepts, and introduces DNS filtering as an additional security layer.

The Three Critical Default Rules

At a minimum, your inter-VLAN firewall should implement these three rules, processed in order:

  1. Allow Established/Related: Allow traffic from IoT VLAN to Trusted VLAN if the connection state is established or related.
  2. Block IoT to Trusted: Drop all new connection attempts from the IoT VLAN to the Trusted VLAN.
  3. Allow Trusted to IoT: Allow all traffic from the Trusted VLAN to the IoT VLAN.

The result: your laptop on the trusted VLAN can initiate connections to IoT devices (to control them, view camera feeds, access their web interfaces), but IoT devices cannot initiate connections to your trusted devices. This is the asymmetric trust model that forms the foundation of IoT segmentation.

Why “Allow Established/Related” Is Safe

New users often worry that the “allow established/related” rule opens a backdoor. It does not. Modern firewalls are stateful: they track every connection in a state table. Here is how it works:

  • When your laptop (Trusted VLAN) sends a request to a smart plug (IoT VLAN), the firewall records this connection in its state table—source IP, destination IP, source port, destination port, and protocol.
  • When the smart plug sends its response back, the firewall checks the state table, finds a matching entry, and classifies the return traffic as established. The response is allowed through.
  • If the smart plug tries to initiate a new connection to the laptop—one that does not match any existing entry in the state table—the firewall classifies it as a new connection. Rule 2 catches it and drops it.

The related state handles secondary connections that are spawned by an existing connection. For example, FTP uses a control connection and a separate data connection. The data connection is “related” to the control connection. In practice, this is rarely relevant for IoT traffic, but including it prevents obscure breakages.

This approach means a compromised IoT device cannot reach out to your trusted network, but your trusted devices can still fully control and monitor all IoT devices.

Setting Up Rules in UniFi

In the UniFi Network application:

  1. Navigate to Settings > Firewall & Security > Firewall Rules.
  2. Under LAN In rules (traffic entering the router from a LAN), create the rules in this order:

Rule 1: Allow Established/Related from IoT

  • Type: LAN In
  • Action: Accept
  • Protocol: All
  • Source: IoT network (VLAN 20)
  • Destination: Trusted network (VLAN 1)
  • Match State: Established, Related

Rule 2: Block IoT to Trusted

  • Type: LAN In
  • Action: Drop
  • Protocol: All
  • Source: IoT network (VLAN 20)
  • Destination: Trusted network (VLAN 1)

The “allow trusted to IoT” direction is permitted by default in most setups, as there is typically no rule blocking it. If you have a default-deny policy between all VLANs, add an explicit allow rule for trusted-to-IoT traffic.

Apply the same pattern for your cameras VLAN: allow established/related from cameras to trusted, block all new from cameras to trusted.

Restricting IoT Internet Access

Beyond blocking IoT-to-trusted traffic, you can further restrict what IoT devices can do on the internet. A strict approach:

  1. Allow DNS (UDP/TCP port 53) to your local DNS server (or the gateway if the router handles DNS).
  2. Allow NTP (UDP port 123) to any destination, so devices can sync their clocks. Many IoT devices malfunction if they cannot reach an NTP server.
  3. Allow HTTPS (TCP port 443) to any destination, since most cloud-connected IoT devices communicate over HTTPS.
  4. Allow HTTP (TCP port 80) if needed for firmware updates (some manufacturers still serve updates over HTTP).
  5. Block everything else from the IoT VLAN.

For maximum security, you could whitelist specific cloud endpoints per device (e.g., allow your Ring camera to reach only *.ring.com and *.amazonaws.com), but this is extremely tedious to maintain and breaks whenever the manufacturer changes their infrastructure. The DNS/NTP/HTTPS approach provides a practical balance.

DNS Filtering with Pi-hole or AdGuard Home

DNS filtering adds another security layer by blocking malicious domains, telemetry endpoints, and advertising trackers at the DNS resolution level. Two popular self-hosted options:

  • Pi-hole: A DNS sinkhole that runs on a Raspberry Pi, a VM, or a Docker container. It intercepts DNS queries and checks them against blocklists. Blocked domains resolve to 0.0.0.0, preventing the device from connecting. Pi-hole provides a web dashboard showing every DNS query on your network, which is invaluable for understanding what your IoT devices are communicating with.
  • AdGuard Home: Similar to Pi-hole but with built-in DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) support, encrypted DNS upstream by default, and a slightly more modern interface. It also supports per-client settings, allowing you to apply different blocklists to different VLANs.

To use DNS filtering with VLANs, set the DHCP server for each VLAN to hand out the IP address of your Pi-hole or AdGuard Home instance as the DNS server. For example, if Pi-hole runs at 192.168.1.53, configure every VLAN’s DHCP scope to use 192.168.1.53 as the DNS server. You will also need a firewall rule allowing DNS traffic (port 53) from all VLANs to the Pi-hole’s IP address.

The Hardcoded DNS Problem

Some IoT devices ignore the DNS server provided by DHCP and instead hardcode their own DNS resolver—most commonly Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1. This bypasses your Pi-hole or AdGuard Home entirely, rendering DNS filtering ineffective for those devices.

The solution is a DNS redirect rule (also called a NAT redirect or destination NAT rule). This rule intercepts any DNS traffic (destination port 53) leaving the IoT VLAN and redirects it to your local DNS server, regardless of what destination the device originally specified.

Implementation on pfSense/OPNsense

Create a port-forward rule under Firewall > NAT > Port Forward:

  • Interface: IoT VLAN
  • Protocol: TCP/UDP
  • Source: IoT subnet
  • Destination: Any (with “invert match” unchecked)
  • Destination Port: 53
  • Redirect Target IP: Your Pi-hole or AdGuard Home IP
  • Redirect Target Port: 53

Add a second rule to exclude traffic already destined for your DNS server from being redirected (to avoid loops).

Implementation on UniFi

On UniFi, you can create a destination NAT rule under Settings > Firewall & Security > NAT with similar parameters. Newer UniFi firmware also supports this through the Traffic Management section.

Logging and Monitoring

Firewall rules are only useful if you know they are working. Enable logging on your drop rules so you can see when IoT devices attempt to reach your trusted network. This serves two purposes:

  • Verification: If you see blocked traffic in the logs, your rules are working correctly.
  • Threat detection: A sudden spike in blocked traffic from a specific IoT device may indicate it has been compromised and is attempting lateral movement or network scanning.

On pfSense/OPNsense, logging is enabled per rule with a checkbox. On UniFi, firewall logs are available in the System Log under the firewall/routing category. Pi-hole and AdGuard Home provide DNS query logs through their web dashboards, showing every domain every device on your network has attempted to resolve.

Applying Rules to the Camera VLAN

Security cameras deserve even stricter rules than general IoT devices. Consider these additional restrictions for the camera VLAN:

  • Block all traffic from the camera VLAN to every other internal VLAN (trusted, IoT, guest, management).
  • If you use local NVR recording (e.g., Frigate, Blue Iris), allow traffic from the camera VLAN only to the NVR’s IP address on the appropriate port (typically RTSP on port 554).
  • If cameras require cloud access for remote viewing, allow HTTPS outbound only.
  • Block outbound HTTP (port 80) from the camera VLAN to prevent unencrypted data exfiltration.

Rule Order Matters

Firewalls process rules top to bottom and stop at the first match. If you place “Block IoT to Trusted” before “Allow Established/Related,” the block rule will match all IoT-to-trusted traffic including valid response packets, breaking communication entirely. Always place allow-established/related rules before block rules.

Summary

The foundation of IoT firewall policy is three rules: allow established/related traffic from IoT to trusted (safe because of stateful tracking), block all new connections from IoT to trusted, and allow trusted to IoT. Beyond this, restrict IoT internet access to DNS, NTP, and HTTPS. DNS filtering with Pi-hole or AdGuard Home blocks malicious and tracking domains, but you must handle the hardcoded DNS problem with a NAT redirect rule for port 53. Always enable logging on drop rules for verification and threat detection. With firewall rules in place, the final challenge is making legitimate smart home features—device discovery, casting, and voice control—work across VLAN boundaries.

Lesson Complete