Set up UniFi WiFi for a holiday rental

Goal and requirements

Give guests usable internet access while separating their devices from owner computers, infrastructure and cameras. This example is a single holiday property with one booking group at a time. It starts with internet-only guest access and a separate Owner WiFi network. Shared casting and printing require an additional, deliberate design.

Use a UniFi gateway, supported managed switching and APs, plus an owner laptop connected through a trusted network. Keep the existing management network unchanged. Have a configuration backup and a written check-in process before changing the live guest network.

Configure the networks

  1. Create Owner and Guest networks. Use Main10, 192.168.10.0/24, for owner devices and Guest30, 192.168.30.0/24, for visitors. Set each gateway to .1 and DHCP to .100 through .199. Use unused addresses and leave IPv6 disabled on the new guest network for this IPv4 exercise. Configure a separate equivalent policy before later enabling IPv6.
  2. Create the WiFi names. In Settings › WiFi, create Property Owner mapped to Main10 and Property Guest mapped to Guest30. Use different passwords, stored in the owner's password manager. Select the APs serving guest areas. Ensure VLAN 30 is permitted on their upstream links. A hidden SSID does not replace access control. The SSID settings include the password and choice of broadcasting APs. [1]
  3. Block guest access to local networks. In Settings › Networks › Guest30, enable Network Isolation. In the guest SSID, enable Client Device Isolation. For clients on different APs or wired ports, also use Device Isolation ACLs on supported switches and verify the result. AP client isolation alone does not cover every path through the property. [2]
  4. Restrict access to the gateway itself. Open the firewall policy editor. Depending on Network version, this appears under Settings › Zones or Policy Engine › Zones. Create policies scoped to source network Guest30 and destination zone Gateway. For this example, allow UDP destination port 67 for DHCP and TCP/UDP destination port 53 for DNS before blocking other Guest30-to-Gateway traffic. Preserve existing return-traffic handling. Do not apply the block to the owner's network. [3]
  5. Check infrastructure requirements. The previous rule deliberately permits only the services this example uses at the gateway. If a deployment uses another gateway-hosted service, document and allow its required port before the final block. Check all gateway addresses from the guest network, because testing only 192.168.30.1 can miss a management service reachable through another gateway address.
  6. Set a practical speed limit. Under Settings › Profiles › WiFi Speed Limits, create a guest profile and apply it to Property Guest. For an assumed internet service measured at 100 Mb/s down and 20 Mb/s up, an initial per-client limit of 20 down and 5 up is a test setting. Adjust it to the guest experience and actual service. Per-client limits do not constitute a guaranteed aggregate bandwidth reservation. [4]

Establish a changeover routine

  1. Prepare the next password. Generate a new guest password after checkout and before the next arrival. Edit Property Guest under Settings › WiFi, replace the password and save. Reconnect a test phone using the new password. Confirm that a device attempting a fresh connection with the old password fails. Allow for provisioning and disconnection of existing sessions before treating rotation as complete.
  2. Update the guest instructions. Replace the password and any QR code on the welcome card. Include the WiFi name, a brief connection procedure and a support contact. Keep console credentials and the owner password out of the guest material. Test the printed instructions using a phone that has forgotten the network.
  3. Check property equipment. Owner-managed smart devices should remain on IoT20 or another deliberate network, so rotating the guest password does not strand them. If a television belongs to Guest30 for casting, its credentials will also need updating. With client isolation enabled, local casting may be blocked even when both devices have internet access. Document that choice instead of disabling isolation without examining the consequences.

Verify as a guest

Connect two test devices. Confirm that each receives 192.168.30.x, can browse public websites and cannot open an owner computer's known service, the NVR's interface or gateway administration. Test the two clients on the same AP and then different APs. If wired sockets are available to guests, repeat the test through those sockets.

Confirm the owner's trusted connection still manages the site and that cameras continue recording. Test a video call or streaming session under normal load, then record any adjustments to the speed limit.

If guests cannot obtain an address or resolve websites after the gateway rule, check the DHCP and DNS exceptions and their order first. From the trusted owner connection, disable the new blocking rule while correcting it. If guest clients can reach each other across APs, inspect switch ACL support and the actual forwarding path. Preserve the previous configuration until the full acceptance test passes.

Sources

Back to the series

Leave a comment

Please note, comments need to be approved before they are published.