VLAN Setup for a Small Office: Separate Guest Wi-Fi and Staff Devices

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.

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:

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:

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:

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

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 for how the same segmentation thinking applies in the cloud, and UPS sizing for 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