This feature is extremely useful and popular for hotel (or service apartment) setup.

In most hotel compliance, it is required to isolate guest accesses, eg. block direct/peer-to-peer access among guests within the hotel network, particularly to minimize broadcast storms, prevent internal hacking and contain virus or worm outbreaks. For example, should one of the guest device is infected with worms, the worm propagation can't spread and infect other guest devices within the hotel. 

In short, client isolation ensures that each guest's device is only allowed to communicate upstream to its default gateway for direct outbound Internet access.

A typical mid-large size hotel would have two ways for guest Internet access, wireless and wired. For wireless access, the premise will be covered with Wi-Fi and guest device can connect to hotel Wi-Fi; for wired access, each room would have a LAN point, where guest can plug-in their PC directly with a UTP cable to get Internet access.

Client isolation in wireless network

For wireless client isolation, many enterprise grade Wi-Fi products would support a featured called "client isolation". Once this feature is turned on, each associated wireless client (user device) can only communicate with its default gateway, unable to scan or reach to other devices within the same network. 

Our MAP supports both AP or AP & SSID based client isolation. it is configurable in the template setting.

Client isolation in switch network

Client isolation in switched network essentially requires each switch-port (for each guest room) is isolated from each other. 

There're 3 ways to implement switch-port isolation:

1. Split rooms into VLANs. In the switch configuration, simply assign each switch-port to a different VLAN so that each guest room sits in a dedicated/separate VLAN. However, each VLAN also requires a dedicated network addressing. So the IP address planning can be massive, especially when there're many rooms (therefore many VLANs), eg. need to create many vlans and require many DHCP address pools for each VLAN etc. It's very tedious to configure and very difficult to maintain such network.

2. Use Private VLAN. In private VLAN configuration, all the ports/rooms are in one primary VLAN, in one network (therefore only need to maintain one address pool), but each port is in a secondary VLAN in isolated mode. This perfectly solves port isolation and simplifies IP addressing. BUT, private VLAN is only supported in some brands/models of switches, and it does require strong networking knowledge/skills to configure private VLANs. Moreover, many hotels are using switches that don't support private VLAN feature.

3. Bridge multiple VLANs. In this scenario, we put each room into a dedicated VLAN (similar to #1), then bridge all VLANs under one bridge, so that we only need to configure one flat network for the bridged network. This design has the best of both worlds - port isolation and simplified network addressing. And it only requires switches to support standard VLAN and trunking feature, which exist on most common/cheap switches already.

This section focuses on how to utilize mbox features to implement above #3 scenario.

In above design, the switch configuration is very simple:

• On the switch, assign each room switch-port to a dedicated VLAN. In some hotels, where the Wi-Fi solution doesn't support "client isolation" feature, you may have a AP plugged into the room LAN port, so the Wi-Fi is isolated by the switch-port configuration.

• each floor will have one or multiple switches, and each switch will uplink to the core switch in trunk mode, permitting all VLANs to pass through (you may further narrow down to the specific VLANs configured within the switch if needed)

• the core switch will connect mbox LAN interface (eg. eth1) and the switch-port will be running in will trunk mode, trunking all room VLANs to mbox.

• On mbox, we will configure VLANs to map to each room VLAN, and put all VLANs under a bridge interface

• Configure IP address and DHCP pool for the bridge interface (if captive portal is required, enable hotspot for the bridge interface)

NOTE: 

1. if there're many VLANs/rooms, we should split the VLANs into two or multiple bridge groups. It's recommended not to have more than 1,000 IP for each bridged network.

2. it's recommended to turn of spanning tree protocol under bridge interface (stp off). Some low-end switches may have spanning tree compatibility issues with mbox. So it's better just to turn off STP and prevent mbox to participate in switch spanning tree negotiation.

Below is an example of a typical hotel config:

-----------