OPNsense Firewall Rules: Isolate IoT Devices with Aliases and Schedules

IoT devices are a liability on your network—they phone home, ship with open ports, and can reach every other device. Isolate them with alias-driven OPNsense firewall rules that block local access and restrict internet to a schedule. You’ll end up with a ruleset you can audit in 30 seconds.

Prerequisites

You need an OPNsense firewall running and a dedicated network segment for IoT devices already carved out—typically a VLAN with its own interface and DHCP scope. The steps below reference an interface named IOT; substitute yours. You also need admin access to the OPNsense web UI.

Stop here if your IoT devices share a flat network with your laptops and phones. Create the VLAN first, assign it to an interface, enable DHCP, and confirm devices get addresses in that subnet before continuing. Without a separate network, there is nothing to isolate.

Create Aliases for IoT Devices

Aliases keep rules readable. Instead of raw IPs scattered across a dozen rules, you update one alias and everything follows. Create two: one for the IoT subnet and one for all private networks you want to block.

1. Go to Firewall → Aliases.
2. Click + Add.
3. Set Name to IoT_Network.
4. Set Type to Network(s).
5. Under Content, enter your IoT subnet in CIDR notation (e.g., 192.168.30.0/24).
6. Add a Description like "IoT VLAN subnet".
7. Click Save.

Repeat for a private-networks alias that captures all RFC1918 ranges you want off-limits:

1. Click + Add again.
2. Set Name to Private_Networks.
3. Set Type to Network(s).
4. Under Content, enter these three entries, one per line: - 10.0.0.0/8 - 172.16.0.0/12 - 192.168.0.0/16
5. Click Save, then Apply Changes.

If you have a specific IoT device that needs different treatment—say a printer that should never reach the internet—create a Host(s) alias with its MAC address or static IP. You can then reference it in a dedicated block rule without touching the rest of the IoT group.

You are done when: Both aliases appear in the alias list, and clicking each shows the correct networks under Content.

Define a Schedule for IoT Access

A schedule lets you cut off internet access during sleeping hours or weekends. The firewall evaluates it against the system clock on every packet, so keep the OPNsense time synced via NTP.

1. Go to Firewall → Schedules.
2. Click + Add.
3. Set Name to IoT_Internet_Allowed.
4. Under Month, leave all days selected (or pick specific days if you want a different weekend policy).
5. Under Time, define the window. For example, start at 06:00 and end at 23:00 to permit internet from 6 AM to 11 PM daily.
6. Add a Description like "IoT internet window".
7. Click Save.

You are done when: The schedule appears in the list. Hover over the status indicator to confirm it shows "active" during your defined window and "inactive" outside it.

Build Firewall Rules to Isolate IoT

Rules are processed top-down, first match wins. The order matters. Place more specific allow rules above broader block rules. All rules below go on the IoT interface, not floating, so they apply only to traffic entering from that segment.

Block IoT from Local Networks

This is the core isolation rule. It prevents any IoT device from reaching your LAN, management network, or other private subnets—while still allowing them to talk to the gateway for DNS and DHCP.

1. Go to Firewall → Rules → [IOT].
2. Click + Add to create a new rule.
3. Set Action to Block.
4. Set Protocol to any.
5. Under Source, choose Single host or network and select the IoT_Network alias.
6. Under Destination, choose Single host or network and select the Private_Networks alias.
7. Check Destination / Invert. This inverts the logic: the rule now blocks everything except destinations outside RFC1918 space—meaning internet traffic passes through to the next rule, but local traffic hits this block.
8. Set Description to "Block IoT to all local networks".
9. Click Save.

Allow IoT to Internet (with Schedule)

This rule sits above the block rule and explicitly permits internet-bound traffic, gated by the schedule.

1. Still on the IoT interface rules tab, click + Add.
2. Set Action to Pass.
3. Set Protocol to any.
4. Source: IoT_Network alias.
5. Destination: any.
6. Under Schedule, select IoT_Internet_Allowed.
7. Set Description to "Allow IoT to internet (scheduled)".
8. Click Save.

Drag this rule above the block rule. If the schedule is inactive, the rule is skipped and the block rule below catches the traffic.

Allow Necessary Services (DNS, NTP)

The block rule stops IoT devices from reaching your DNS server if it lives on another subnet. Add an allow rule for DNS and NTP above the block rule.

1. Click + Add on the IoT rules tab.
2. Set Action to Pass.
3. Set Protocol to UDP.
4. Source: IoT_Network alias.
5. Destination: Single host or network, enter your router's IP (e.g., 192.168.30.1) or a dedicated DNS server IP.
6. Destination port range: from 53 to 53.
7. Set Description to "Allow IoT DNS to gateway".
8. Click Save.

Repeat for NTP:

1. Click + Add.
2. Action = Pass, Protocol = UDP.
3. Source = IoT_Network.
4. Destination = your NTP server IP (often the same gateway).
5. Destination port range = 123 to 123.
6. Description = "Allow IoT NTP to gateway".
7. Click Save, then Apply Changes.

Here is the final rule order top to bottom on the IoT interface:

You are done when: An IoT device can resolve DNS and reach the internet during the allowed schedule window, but cannot ping or connect to any device on your LAN or other private subnets. Outside the schedule window, internet access stops.

Test Your Isolation

Test with any IoT device on the network—a smart plug, a camera, anything.

1. DNS test: Run nslookup opnsense.org or open a browser to any website. It should resolve and load during the allowed window.
2. Internet access during schedule: Confirm the device reaches the internet within the defined hours.
3. Internet blocked outside schedule: Wait for the schedule window to close or temporarily adjust the OPNsense system clock, then retry. Connections should time out.
4. Local isolation: Ping a known LAN IP (e.g., your desktop at 192.168.10.50). It must fail with "destination unreachable" or a timeout.
5. Cross-subnet scan: Try accessing a file share or printer on another subnet. It should not connect.

You are done when: All five tests produce the expected result.

Tune and Maintain

Enable logging on the block rule to see what IoT devices try to reach internally. Go to the rule, check Log packets that are handled by this rule, and apply. Then monitor Firewall → Log Files → Live View, filtering on the IoT interface. You will spot chatty devices fast.

Adjust the schedule as your habits change—weekend-only internet for a kids' media player, or a 30-minute window for a sprinkler controller to pull weather data. Add new IoT devices to the network alias if you use a MAC-based list; otherwise, any device on the IoT subnet inherits the rules automatically.

If you need cross-VLAN discovery for services like Chromecast or Home Assistant, set up an mDNS repeater (see Bridging the VLAN Gap: Set Up an mDNS Repeater for Cross-VLAN Discovery in Home Assistant).

Conclusion

You now have an alias-driven, schedule-gated IoT isolation ruleset. The same pattern works for guest networks, camera VLANs, or any segment you want to keep off your LAN while controlling internet access by the clock.