I see a lot of network segmentation guides that turn into a mess of 50+ firewall rules. Overkill. You can isolate a class of devices like IoT with a clean, maintainable structure. The goal is a single, explicit policy path for the IoT VLAN. Here's how I'd do it on a FortiGate, treating it like a CI/CD pipeline: define your inputs (devices), your stages (security profiles), and your outputs (allowed traffic).
First, your network object and addressing scheme. Keep it simple.
```
config firewall address
edit "IoT_VLAN_Subnet"
set subnet 10.0.30.0 255.255.255.0
set associated-interface "iot-vlan"
next
end
```
Now, the policy. The key is to start with a single, explicit ALLOW rule for IoT outbound, then lock everything else down. This rule sits above your general deny.
```
config firewall policy
edit 10
set name "IoT_Outbound_To_Internet"
set srcintf "iot-vlan"
set dstintf "wan1"
set srcaddr "IoT_VLAN_Subnet"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set utm-status enable
set ssl-ssh-profile "certificate-inspection"
set av-profile "default"
set webfilter-profile "default"
set ips-sensor "default"
set application-list "default"
next
edit 11
set name "DENY_IoT_To_Internal"
set srcintf "iot-vlan"
set dstintf "internal" "dmz"
set srcaddr "IoT_VLAN_Subnet"
set dstaddr "all"
set action deny
set schedule "always"
set service "ALL"
next
end
```
Critical points:
* Rule 10 applies your UTM profiles (AV, IPS, Web Filter). This is your quality gate.
* Rule 11 is an explicit deny from IoT to your trusted internal/DMZ interfaces. This creates the isolation.
* The implicit deny after rule 11 blocks IoT from any other interface you might add later.
* Any needed exceptions (like a smart hub needing to talk to your media server) become a new, numbered rule *above* rule 11. This maintains auditability.
The result is a minimal rule set that's easy to debug. You now have a pipeline: IoT traffic enters, gets inspected, can only exit to the internet, and is blocked from internal resources. Any new IoT device gets the same treatment automatically. Complexity only grows if you add specific, justified exceptions, which are tracked as separate rules.
This approach with one explicit allow rule is really clean. What's your take on blocking IoT devices from talking to each other within the same VLAN? Would you handle that on the switch or with another firewall rule?
Still learning.
Excellent question. This gets into the layered security model. For true isolation, you need to handle intra-VLAN communication at the switch layer with private VLANs or equivalent port isolation. Relying on a firewall rule for this is inefficient.
The firewall rule would have to be a deny rule placed above your explicit allow, using the same source and destination addresses. That creates asymmetric routing hairpins. All that East-West traffic gets hauled up to the firewall only to be dropped, consuming resources and adding latency. The switch can drop the frame right at the ingress port.
If your switching hardware supports it, implement private VLANs (PVLANs). All "IoT_VLAN_Subnet" devices are placed in isolated or community ports, with a single promiscuous port for the firewall gateway. They can only talk to the gateway, never to each other. This enforces the isolation at L2, aligning perfectly with your single, clean firewall policy for North-South traffic.
infrastructure is code