Manual

The same guest network everywhere

One guest network, ten branches, and the question of where that traffic leaves the building.

A guest network at one location is half an hour of work. At ten locations it becomes a design question: the same VLAN number, the same SSID and the same passphrase everywhere, but its own address range and its own way out per building.

The plan

You fill in the site's VLAN table once. The guest VLAN is one row in it, with Isolated on and Internet on. Every location on the network board gets its own address range, and that settles the guest network's address per building.

LocationRangeGuest VLAN 20DHCP pool
Head office10.1010.10.20.1/24.10 to .254
Branch Zwolle10.2110.21.20.1/24.10 to .254
Branch Breda10.2210.22.20.1/24.10 to .254

Do not put the guest VLAN at the top of the table. Wired ports default to the first VLAN in the table, so with the guest network there, every wired port on every device lands on the guest network. The tool reports this as an error as soon as the first VLAN is marked isolated, because it looks like a working configuration and it is a security problem.

What "isolated" actually does

The Isolated tick produces one firewall rule per location: new connections from the guest VLAN to anything other than the WAN interfaces are dropped. Guests reach the internet and nothing else.

That also answers the local-or-central question. In the generated configuration a site tunnel counts as LAN, not as WAN. An isolated guest VLAN therefore does not enter the tunnel either. What the tool builds is always local breakout: guests reach the internet at their own location.

For most companies that is the right answer. Sending guest traffic through the tunnel to the head office means the uplink there has to carry the sum of every branch, that an outage at the head office also kills the Wi-Fi in Breda, and that traffic from an unknown device travels across your own network.

When it does have to be central

Sometimes it has to be: a filtering obligation, one outgoing address for a portal, or a hotspot that lives centrally. The tool has no setting for this. You build it by hand, and in three places:

  • Take the Isolated tick off the guest VLAN and arrange the separation with the matrix under Firewall instead, so you decide where it may go.
  • Add a forward rule on the branch router that accepts traffic from the guest VLAN towards the tunnel interface. A custom rule in the Firewall section can take a tunnel as its out-interface.
  • Widen the allowed-address of the WireGuard peer on both sides with the guest subnet, and make sure the NAT rule at the head office lets that traffic out.

Note that the matrix also writes a closing drop per VLAN towards everything in the LAN list, and the tunnel is in that list. Without the explicit accept rule the guest traffic still does not enter the tunnel, however you tick the matrix. Write down what you added and why, or in two years that one rule is inexplicable.

Keeping the SSIDs identical

You fill in the site's SSIDs once, with the name, the security, the passphrase and the VLAN they belong to. That table goes to every device that broadcasts Wi-Fi: to the CAPsMAN controller if you have one, and otherwise to the access points themselves.

That is exactly what roaming needs. When a visitor walks from one end of the building to the other, the name, the security and the passphrase have to be identical, or the connection drops and they have to log in again. The check reports it when not every access point broadcasts the same SSIDs.

Two things to watch:

  • If the site has a CAPsMAN controller and some access points are set up as standalone, the tool says so. Use the controller's CAP script instead, or you manage half of them centrally and half by hand.
  • If you give a device its own selection of VLANs, the tool checks whether the guest VLAN is still among them. An SSID on a VLAN that access point does not carry raises a warning, and rightly so: that SSID would broadcast into nothing.

A speed limit for guests

The QoS section has limits per host or per network. Put the guest subnet in with a maximum up and down, and it lands in the script as a simple queue. That is per router, so per location, which is also the right place: a guest in Zwolle should not be able to eat the line in Breda, and cannot.

Keep in mind that QoS switches FastTrack off. On a small router that costs throughput; see QoS and bandwidth.

What the checks catch

  • The first VLAN is isolated, which would put every wired port on the guest network.
  • A VLAN that exists on one end of a cable and not on the other: that VLAN stops at the cable.
  • An SSID on a VLAN the device does not carry.
  • Not every access point broadcasting the same SSIDs.
  • Two locations on the same address range, which means two guest networks on the same subnet.

Further reading: A guest network that is actually separate, A speed limit for guests and One CAPsMAN for several buildings.

Want to try it right away? Open the configurator