# VLAN Setup for a Small Office: Separate Guest Wi-Fi and Staff Devices > Plan and configure VLANs for a small office so guest Wi-Fi cannot reach staff PCs, printers or the NAS: VLAN plan, trunk ports, SSID tagging and firewall rules. Source: https://www.epifive.com/blog/vlan-setup-small-office-guest-wifi · Published 2026-10-25 · EpiFive ## Key takeaways - Guest isolation needs three things together, which are a separate VLAN and subnet for guests, VLAN tagging on the guest SSID, and a firewall rule that blocks guest traffic to internal subnets. - Connect each access point to a trunk port that carries every VLAN used by its SSIDs, and keep SSIDs off the native VLAN. - On Meraki access points, per-SSID VLAN tagging requires the SSID to run in bridge mode, and Layer 2 isolation also depends on bridge mode. - Give guests internet access and DNS only, and deny access to printers, the NAS, servers and the management VLAN. - Test from a phone on the guest network, because a plan is only proven when guest devices cannot reach internal addresses. To separate guest Wi-Fi from staff devices, put guests on their own VLAN and subnet, tag the guest SSID with that VLAN, carry the VLAN to the router or firewall over a trunk port, and add a firewall rule that lets the guest subnet reach the internet but nothing internal. A separate SSID name alone does not isolate anyone. The isolation happens at the router or firewall. This guide is for small office owners and part-time administrators with a business router or firewall, a managed switch and one or more access points. The steps are vendor-neutral, and Cisco Meraki's published documentation is used as the worked example where a concrete setting is needed. Menu names on your own equipment will differ. By the end you will have a VLAN plan, a working guest network, and a test that proves staff devices are out of reach. ## What a VLAN does here A VLAN (virtual LAN) splits one physical network into separate logical networks. Frames carry a tag (802.1Q) that identifies the VLAN, and devices on different VLANs cannot talk to each other except through a router or firewall. That makes the router the place where you decide what guests may reach. Three pieces work together: - **VLAN and subnet.** Each VLAN gets its own IP subnet and its own DHCP scope. - **Tagging.** The SSID or switch port places traffic in the right VLAN. - **Inter-VLAN policy.** The router or firewall allows or blocks traffic between subnets. ## Prerequisites - A router or firewall that supports multiple VLAN interfaces (sometimes called sub-interfaces) and per-interface firewall rules. - A managed switch that supports 802.1Q trunking and per-port VLAN assignment. - Access points that can map SSIDs to VLANs. - A maintenance window, because you will change switch ports and the network may drop briefly. - A backup of the current router and switch configuration. - Out-of-band access: be able to reach the router console or a wired port on the existing network if you lock yourself out. ## Step 1: Design the VLAN plan Keep the plan small. Four VLANs cover most offices. | VLAN ID | Name | Example subnet | Purpose | | --- | --- | --- | --- | | 10 | Staff | 10.10.10.0/24 | Laptops, desktops, staff Wi-Fi | | 20 | Servers and printers | 10.10.20.0/24 | NAS, printers, VoIP base stations | | 30 | Guest | 10.10.30.0/24 | Visitors, personal phones | | 99 | Management | 10.10.99.0/24 | Switch and access point management | These IDs and subnets are examples. Pick any ranges that do not overlap and that you will not clash with when you use a VPN. Avoid VLAN 1 for anything you care about, because many switches use it as the default. ## Step 2: Create the VLAN interfaces and DHCP scopes on the router On the router or firewall, create one interface per VLAN with the gateway address of each subnet, and a DHCP scope for each: ```text VLAN 10 gateway 10.10.10.1/24 DHCP 10.10.10.100-10.10.10.200 VLAN 20 gateway 10.10.20.1/24 static or small DHCP scope VLAN 30 gateway 10.10.30.1/24 DHCP 10.10.30.50-10.10.30.250, short lease VLAN 99 gateway 10.10.99.1/24 static addresses preferred ``` A short DHCP lease on the guest scope stops the pool filling up with visitors' phones. The exact syntax varies by vendor, so follow your router's documentation. ## Step 3: Configure the switch ports Two port types are needed: - **Trunk ports** carry multiple tagged VLANs. Use them for the link to the router and for each access point. - **Access ports** place one device in one VLAN, untagged. Use them for PCs, printers and the NAS. For an access point, Cisco Meraki's VLAN tagging documentation says each AP must connect to a trunk port on the upstream switch or router that carries every VLAN the wireless network uses. The AP sends tagged client data and untagged management traffic, so a plain access port does not work. The same document says no SSID should be on the native (untagged) VLAN, and that you should limit broadcast traffic on the trunk port to protect wireless performance. A practical port map: ```text Port 1 trunk to router/firewall VLANs 10,20,30,99 Port 2 trunk to access point VLANs 10,30,99 (native VLAN 99 for AP management) Port 3 access, VLAN 20 NAS Port 4 access, VLAN 20 printer Port 5+ access, VLAN 10 staff PCs ``` If your access point management uses the native VLAN, set the native VLAN on the AP trunk to the management VLAN. By default Meraki AP management traffic is untagged, and the wired network must allow it so the AP can reach its cloud dashboard. To tag management traffic, assign a VLAN along with a static IP address to the AP. ## Step 4: Map SSIDs to VLANs Create two SSIDs on the access points: - **Staff**: WPA2 or WPA3 with a strong passphrase or 802.1X, tagged VLAN 10. - **Guest**: its own passphrase (or a captive portal if your system supports it), tagged VLAN 30. On Meraki access points, VLAN tagging is configured under **Configure** > **Access control** and applies to all data traffic from clients on an SSID. The SSID must be in bridge mode for VLAN tagging, whether it is applied per SSID, per user or per device type. A group policy VLAN overrides the SSID VLAN and any per-user setting, which is worth knowing if guests unexpectedly land elsewhere. ### NAT mode versus bridge mode Meraki also offers a NAT mode in which the AP hands out addresses and clients are isolated from one another automatically, with no VLAN tagging. That can be enough for a very small guest network where you do not want to touch the wired network. It cannot be combined with VLAN tagging on the same SSID, and it does not carry guest traffic onto your firewall for policy. For a network you want to control and log centrally, use bridge mode with a VLAN. Meraki's Layer 2 LAN isolation setting, which stops clients on the same SSID from talking to each other, requires bridge mode according to the Ansible Meraki SSID module documentation. Turn it on for the guest SSID so one visitor's device cannot reach another's. ## Step 5: Write the firewall rules The router default may allow traffic between its own interfaces. Write rules explicitly, in this order, on the guest interface: ```text 1. Allow guest -> DNS server (the router or a public resolver) UDP/TCP 53 2. Allow guest -> DHCP on the router UDP 67-68 3. Deny guest -> 10.10.10.0/24, 10.10.20.0/24, 10.10.99.0/24 4. Deny guest -> the router's own management interfaces 5. Allow guest -> any (internet) ``` Order matters: the deny rules for internal subnets must come before the final allow. If you block "all private ranges" instead of listing your subnets, you also protect against VLANs you add later. A community discussion on Meraki's forum shows that people are not always sure whether a Layer 2 isolation setting alone is enough once VLANs are in use, so do not rely on it. Write an explicit deny. On the staff and server interfaces, add a rule that blocks new connections from the guest subnet and allows return traffic as normal. ## Step 6: Test the isolation Test from a phone or laptop that is not on your staff network. 1. Join the guest SSID. Confirm the address is in the guest subnet, for example 10.10.30.x. 2. Browse the internet. It should work. 3. Try to ping or browse to a staff PC, the NAS and the printer by IP address. Each should fail. 4. Try the router's management address. It should fail from the guest network. 5. Join two phones to the guest SSID and try to reach one from the other. With Layer 2 isolation on, this should fail. 6. From a staff device, confirm access to the NAS and printer still works. Write the results down. Repeat after any change to the firewall or access points. ## Troubleshooting | Symptom | Likely cause | Fix | | --- | --- | --- | | Guest clients get no IP address | Trunk to the AP does not carry VLAN 30, or no DHCP scope on the VLAN interface | Add VLAN 30 to the AP trunk and the router interface | | Guests land on the staff subnet | SSID has no VLAN tag, or a group policy overrides it | Set the SSID VLAN tag; check group policy VLAN settings | | AP drops guest traffic | The VLAN ID on the SSID is not carried by the switch trunk | Allow the VLAN on the trunk. APs drop packets with VLAN IDs that are not tied to their SSIDs or clients | | AP offline after changing ports | Management traffic is untagged and the native VLAN is wrong | Set the native VLAN on the AP trunk to the management VLAN, or tag management with a static IP | | Guests can reach the NAS | Missing or mis-ordered deny rule | Move the deny rules above the allow-any rule | | Staff cannot reach printers | Printers are on a different VLAN with no allow rule | Add an allow rule from staff to the printer VLAN for printing ports | | Per-user VLAN from RADIUS ignored | RADIUS override not enabled | Enable the RADIUS VLAN override setting on the SSID | ## Closing checklist - Four VLANs planned with non-overlapping subnets. - Router interfaces and DHCP scopes created. - Trunk ports to the router and each access point; access ports for wired devices. - Staff and guest SSIDs each tagged with their own VLAN, none on the native VLAN. - Firewall rules deny guest to internal subnets and router management, then allow internet. - Layer 2 client isolation on the guest SSID. - Isolation test recorded. For the wider picture, see [Azure landing zone for a small business](https://www.epifive.com/blog/azure-landing-zone-small-business) for how the same segmentation thinking applies in the cloud, and [UPS sizing for office network gear](https://www.epifive.com/blog/ups-sizing-office-network-gear) so the switch and router survive a power cut. ## References - Cisco Meraki, VLAN Tagging: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/VLAN_Tagging - Cisco Meraki community, SSID with network isolation: https://community.meraki.com/t5/Wireless/SSID-with-network-isolation/m-p/62591 - Ansible cisco.meraki.meraki_mr_ssid module: https://docs.ansible.com/ansible/6/collections/cisco/meraki/meraki_mr_ssid_module.html ## Frequently asked questions ### Is a separate guest SSID enough to isolate guests? Not by itself. A second SSID on the same VLAN and subnet puts guests on the same network as staff devices. Isolation comes from mapping the guest SSID to its own VLAN and subnet and then blocking traffic from that subnet to your internal subnets at the router or firewall. ### Why must the access point connect to a trunk port? An access point that serves several SSIDs on different VLANs sends tagged frames for each VLAN, plus untagged management traffic. The switch port must therefore be a trunk that carries every VLAN the wireless network uses. Access points drop traffic tagged with VLAN IDs that are not tied to any of their SSIDs or clients. ### Should an SSID use the native VLAN? No. Cisco Meraki's guidance says no SSID should be on the native (untagged) VLAN for security reasons. Keep the native VLAN for access point management traffic or leave it unused, and tag every SSID. ### Do I need a managed switch for VLANs? If the router and access points are the only devices carrying guest traffic, a switch that cannot tag VLANs will not carry the tags between them. You need a switch that supports 802.1Q VLAN trunking between the access point and the router or firewall.