Switching

Guest WiFi VLAN — How to Isolate Guests on a Switch and Router

G Gurpreet Singh April 23, 2024 5 min read
Animated diagram for Guest WiFi VLAN How to Isolate Guests on a Switch and Router, showing an access point sending expanding signal rings to three clients whose bars fall from four to one as the distance grows

Guest WiFi on the same network as your own devices means every visitor’s phone, and anything on it, sits alongside your file server, your printer and your cameras. Putting guests on their own VLAN fixes that properly.

The goal: guests get internet access, and reach nothing else, not your LAN, not your management interfaces, and ideally not each other.

The Design

VLANPurposeSubnet
10Internal users192.168.10.0/24
30Guest WiFi192.168.30.0/24
99Management192.168.99.0/24
999Native / unused

Guest traffic reaches the internet through the router and is denied everything else by an ACL applied inbound on the guest SVI.

Step 1, Create the VLAN

Switch(config)# vlan 30
Switch(config-vlan)# name GUEST-WIFI
Switch(config-vlan)# exit

Step 2, The Access Point Port

If the AP broadcasts more than one SSID mapped to different VLANs, its switch port must be a trunk:

Switch(config)# interface GigabitEthernet0/10
Switch(config-if)# description AP - Reception
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk native vlan 999
Switch(config-if)# switchport trunk allowed vlan 10,30
Switch(config-if)# switchport nonegotiate
Switch(config-if)# spanning-tree portfast trunk

If the AP is guest-only, an access port in VLAN 30 is enough:

Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 30
Switch(config-if)# spanning-tree portfast
Switch(config-if)# spanning-tree bpduguard enable

On the AP itself, map the guest SSID to VLAN 30. The exact syntax varies by vendor, but every business-grade AP supports per-SSID VLAN tagging. Consumer routers usually offer a “guest network” toggle that does the same thing internally.

Step 3, The Gateway (SVI)

Switch(config)# ip routing
Switch(config)# interface Vlan30
Switch(config-if)# description Guest WiFi gateway
Switch(config-if)# ip address 192.168.30.1 255.255.255.0
Switch(config-if)# ip helper-address 192.168.10.20
Switch(config-if)# no shutdown

The ip helper-address relays DHCP requests to a server on another VLAN. Omit it and guests get 169.254 addresses, this is the most common reason a new guest VLAN “does not work”.

Alternatively, serve DHCP locally so guests never touch your internal server:

Switch(config)# ip dhcp excluded-address 192.168.30.1 192.168.30.9
Switch(config)# ip dhcp pool GUEST
Switch(dhcp-config)# network 192.168.30.0 255.255.255.0
Switch(dhcp-config)# default-router 192.168.30.1
Switch(dhcp-config)# dns-server 1.1.1.1 8.8.8.8
Switch(dhcp-config)# lease 0 4

Note the DNS servers are public, not your internal resolver. Guests have no business seeing your internal DNS zone, which would otherwise hand them a map of your network.

Step 4, The ACL (the part that actually isolates)

Creating the VLAN alone does not isolate anything. A Layer 3 switch with interfaces in both VLANs will happily route between them. This ACL is what enforces the separation:

Switch(config)# ip access-list extended GUEST-IN

 ! Allow DHCP and DNS to the gateway
 permit udp any any eq 67
 permit udp 192.168.30.0 0.0.0.255 host 192.168.30.1 eq 53

 ! Block all RFC 1918 space, internal networks
 deny ip 192.168.30.0 0.0.0.255 10.0.0.0 0.255.255.255
 deny ip 192.168.30.0 0.0.0.255 172.16.0.0 0.15.255.255
 deny ip 192.168.30.0 0.0.0.255 192.168.0.0 0.0.255.255

 ! Block access to the switch and router themselves
 deny ip any host 192.168.30.1
 deny ip 192.168.30.0 0.0.0.255 192.168.99.0 0.0.0.255

 ! Everything else, the internet, is allowed
 permit ip 192.168.30.0 0.0.0.255 any

Switch(config)# interface Vlan30
Switch(config-if)# ip access-group GUEST-IN in

Two things about this ACL:

  • The third deny covers 192.168.0.0/16, which includes the guest subnet itself, so guest-to-guest traffic that reaches the SVI is blocked too.
  • Order matters. The permits for DHCP and DNS come first because first match wins. Put the broad permit at the bottom.

Step 5, Client Isolation

The ACL only sees traffic that reaches the router. Two guests on the same access point communicate at Layer 2 and never touch it. On an open or shared-password network that means one guest can scan and attack another.

Enable client isolation (also called AP isolation, station isolation, or peer-to-peer blocking) on the guest SSID. Every business AP supports it, and it should be on by default for any guest network.

For wired guest ports, the switch equivalent is a protected port:

Switch(config-if)# switchport protected

Protected ports cannot forward traffic to other protected ports on the same switch.

Step 6, Rate Limiting

Without it, one guest streaming video degrades the connection for everyone, including your staff.

Switch(config)# class-map match-all GUEST-TRAFFIC
Switch(config-cmap)# match access-group name GUEST-SUBNET

Switch(config)# policy-map LIMIT-GUEST
Switch(config-pmap)# class GUEST-TRAFFIC
Switch(config-pmap-c)# police 20000000 conform-action transmit exceed-action drop

Switch(config)# interface Vlan30
Switch(config-if)# service-policy input LIMIT-GUEST

Many wireless controllers also support per-client rate limits, which is a better fit, it stops one heavy user without capping the whole guest network.

Verification

Switch# show vlan brief
Switch# show interfaces trunk
Switch# show ip interface Vlan30
Switch# show access-lists GUEST-IN
Switch# show ip dhcp binding

Then test from a guest device, which is the only verification that counts:

  1. Confirm it receives an address in 192.168.30.x.
  2. ping 8.8.8.8, should succeed.
  3. Browse a website, should work.
  4. ping 192.168.10.x (an internal host), must fail.
  5. ping 192.168.30.1, should fail if you denied it.
  6. Try to reach the switch’s management IP, must fail.
  7. From one guest device, ping another, must fail with client isolation on.

Run show access-lists GUEST-IN afterwards and check the hit counters moved on the deny lines. Zero hits on a deny rule usually means the traffic never reached it.

Things People Miss

  • Internal DNS given to guests. Hand out public resolvers only.
  • Management VLAN reachable. The ACL must deny the management subnet explicitly.
  • Client isolation left off. The ACL does nothing about guest-to-guest traffic.
  • mDNS and Bonjour leaking. Guests seeing your AirPrint printers and Chromecasts means multicast is crossing the boundary.
  • The guest password never changing. Rotate it, or use a captive portal with per-visit codes.
  • No rate limit. One guest saturates the circuit.
  • WPS or an open SSID. Use WPA2/WPA3 with a rotated passphrase, or a captive portal.

Frequently Asked Questions

Does a separate VLAN alone isolate guests?

No. A VLAN separates broadcast domains, but a Layer 3 device with interfaces in both will route between them. The ACL is what enforces isolation.

Can I do this on a consumer router?

Most have a “guest network” feature that provides the same separation internally, though usually without the granularity to allow specific exceptions. For anything beyond basic isolation you need a managed switch and a router that supports VLANs.

Why do guests get 169.254 addresses?

DHCP is not reaching them, either ip helper-address is missing on the SVI, or the guest VLAN is not allowed on the trunk to the access point.

Should guests be able to see each other?

No. Enable client isolation on the SSID. On an open or shared-password network, one guest can otherwise scan and attack another.

What DNS servers should guests use?

Public ones, 1.1.1.1, 8.8.8.8 or a filtering service. Never your internal resolver, which would expose your internal namespace.

How do I stop one guest using all the bandwidth?

Rate limit the guest VLAN with a policy map, or better, apply a per-client limit on the wireless controller so one heavy user does not cap everyone.

GU
Written by

Gurpreet Singh

Hey! I"m Gurpreet Singh and I Have 7+ Years of experience in the Network & Security Domain as well as the Cloud Infra Domain. I am Certified with Cisco ( CCNA ), CheckPoint ( CCSA ), 1xAWS, 3xAZURE, and 3xNSE. So I love to share my tech knowledge with you.

Leave a Reply

Your email address will not be published. Required fields are marked *