Meraki Firewall & Switch VLAN Setup

When an isolated port transmits data, that data is mapped into an auxiliary VLAN. Data in the auxiliary VLAN will be mapped to the primary VLAN -only- for transmission to promiscuous ports. Promiscuous ports, in turn, transmit data into the primary VLAN. All ports can receive information in the primary VLAN.

Putting an otherwise isolated port into a community VLAN means that traffic it transmits will be mapped into both the auxiliary and the community VLAN. Community ports will receive data from both the primary and the community VLAN.

A given pair of ports will have bidirectional communication under the following conditions-

1. One or both are promiscuous, or...
2. Both are in the same PVLAN community.

VACL's are a completely different mechanism and provide some measure of per-packet (and usually protocol based) control of traffic bridged within a given VLAN. You might, for instance, block traffic on TCP/80 between all hosts within the VLAN while allowing all other traffic to pass.

It's possible to approximate the effects of PVLAN's by using a VACL but this tends to be somewhat fragile, difficult to manage and there are often inherent hardware limitations with which to contend (...highly dependent on platform).

One of your WAPs is in the 192.168.20.0/24 network on an unmanaged switch. That presents a problem if the controller is not allowed to access that network. What you really want to do is set up each WAP with a trunk. You want to trunk a management VLAN to the WAPs, along with the user VLANs for the WAPs. Unfortunately, you can't trunk with an unmanaged switch.

The ideal way is to create a management VLAN, and have the WAPs and the controller all connected to that VLAN. You also trunk whichever user VLANs you want the WAPs to advertise through SSIDs. You will need to replace the unmanaged switch with one that can do VLANs. This will also make the management of the WAPs more secure, and you can use the management VLAN to manage the switches, too.