Four VLANs, One Rule Set, and a Contractor NAS

Three different mechanisms, because the requirements are three different kinds of thing:

• Guest VLAN 20: one L3 outbound rule set scoped to VLAN 20, a deny to Local LAN (and to all RFC1918 ranges) placed above the default allow, so guests reach the internet and nothing internal. No content filter beyond the basics; the splash page handles access.
• Contractor VLAN 40: a group policy bound to the VLAN is the right tool, not a pile of per-host rules. Inside it, a content-filtering profile with a permissive default for business categories and blocked categories elsewhere, plus explicit allow entries for the two SaaS apps and the file server. Layer 3 rules deny 10.20.10.0/24 and the other internal subnets except the one file server host.
• IoT VLAN 30: L3 deny rules for intra-VLAN and inter-VLAN traffic, with specific allow rules to the vendor's published endpoint ranges.

Ordering is the whole game because MX L3 rules are evaluated top-down, first match wins, and the implicit default is allow. Every deny must sit above the allow it is meant to override. The most common failure is a broad 'allow any' at the top that quietly renders every deny below it decorative. Write the deny rules first, then the allows, and read the list top to bottom as a stranger before you save it.

The NAS should not stay on VLAN 40 as an unmanaged guest of the corporate firewall. Right now it is on the same VLAN as the laptops, so traffic to it never crosses the MX and no firewall rule can affect it - which also means it is a stranger's device on your plant network with no visibility. Two workable placements:

1. Keep it on VLAN 40 and accept that it is only isolated from everything else by the VLAN boundary. This is the least effort and is defensible for a short engagement, but the NAS is on your infrastructure with unknown patch state.
2. Move it to its own small VLAN (or a dedicated port on a switch with the contractor's own addressing), with explicit allow rules from VLAN 40 to that single host and deny everywhere else. More work, much cleaner containment.

What breaks with a blanket deny to Local LAN is precisely this traffic: a deny to Local LAN placed above the NAS allow will silently kill contractor access to their own file share, and the symptom will present as 'the firewall is broken' with the laptop able to browse the web perfectly. The fix is ordering - the specific host allow must sit above the broad deny - plus a note on the rule explaining why, so the next admin does not 'clean it up'.

The requirement is not 'IoT may not reach each other' - it is 'IoT may not reach each other except the PLCs, which must'. Those are different rule sets and should be written as such.

The wrong instinct is to enable layer 2 isolation on the IoT SSID or switch ports. That is a blunt instrument: it blocks PLC-to-PLC traffic as happily as it blocks a camera talking to a badge reader, and it usually gets discovered during a production stoppage.

Instead:

• Split VLAN 30 into VLAN 30 (cameras and badge readers, no intra-VLAN exceptions needed at L3 because they are on the same subnet - note that same-subnet traffic does not traverse the MX, so L2 isolation is the only lever there) and VLAN 31 for the packaging line.
• For the line, allow the specific PLC-to-PLC pairs rather than the whole subnet, if the count is manageable. If it is not, allow intra-VLAN 31 and deny VLAN 31 to everything else, which is a conscious, documented trade.
• Cameras on VLAN 30 get layer 2 isolation on their switch ports or SSID, which is exactly the right tool there because they are on one subnet and talk only to the cloud.

The judgement point: L3 rules control traffic between subnets, L2 isolation controls traffic within one. Knowing which problem you actually have is the whole answer.