LAN isolation: plan subnets and bind devices

LAN isolation assigns devices to separate subnets and creates boundaries between those subnets. It reduces lateral access and discovery between business devices; it does not choose a proxy node or public egress by itself.

This guide assumes that your first route already works. Use one or two non-critical devices for the first isolation test.

What you should confirm

• The isolated subnet is created under the correct LAN or VLAN parent interface.
• The test device receives the intended isolated IP after reconnecting.
• Devices in different isolated subnets cannot reach each other, while devices in the same subnet can communicate as designed.
• The router-access setting matches the intended boundary without blocking Internet access.
• Any routing rule for the isolated device is separately verified by public IP.
• You know how to move a device back and what deleting a subnet will remove.

Protect the management path first

1. Export a configuration backup from Advanced settings → System settings → Backup and restore.
2. Keep one management device in a normal, unisolated LAN.
3. Prepare a spare phone or test computer that can disconnect and reconnect.
4. Avoid a live trading, streaming, or remote-work window.
5. Add one device at a time during the first test.

Backups may contain node addresses, credentials, and rules. Store them privately.

Understand the two views

Isolation boundaries are subnet-based:

Put devices that must be separated into different subnets. Put devices that need local sharing in the same subnet.

1. Enable the LAN isolation entry

In the SoloIP page, open the LAN isolation tab. If it is not visible, open Advanced settings, find the LAN isolation capability, enable it, and return to the new tab. Enabling the entry does not create a subnet or move a device.

2. Create an isolated subnet

Open LAN isolation → Isolated subnets and choose New isolated subnet. Start with two subnets if you need to test communication between two devices.

Select the parent interface

Choose the LAN or VLAN where the test device is currently connected. The device list is read from this interface. Confirm the parent in iKuai's online-user view instead of creating subnets on unrelated interfaces.

Choose automatic or manual ranges

Automatic recommendation is suitable for a first test. Manual input uses the format A.B.<start>-<end>.0/24, for example:

10.88.10-11.0/24

Avoid existing LAN, VLAN, VPN, and static-route ranges. The example is not a universal address plan.

Set capacity

Capacity is 1-253 devices per subnet. Use capacity 1 when every device needs a separate boundary; use a larger value when a group must communicate locally. The gateway uses .1 and client addresses are allocated from the available range.

Choose a gateway MAC

The default random locally administered MAC is suitable for most tests. A vendor OUI is only for an explicit gateway-MAC plan.

Save and wait until the subnet shows its address, gateway, capacity, and status without an error.

3. Set router access and IP allocation

Open Isolation settings.

Block devices from accessing the router

When enabled, isolated devices cannot open the management page or other router addresses, but Internet access is not blocked by this switch. Keep an unisolated management device.

Device IP allocation

Use random allocation for a first test. Use a fixed or predictable allocation only when the device and subnet plan require it, and document the resulting addresses.

4. Bind a test device

Open the Devices view, find the online device under the matching parent interface, and bind it to one isolated subnet. Confirm the state changes to a pending reconnect or equivalent status. Do not bind the only management device.

5. Reconnect the device

Disconnect and reconnect Wi-Fi or the Ethernet link, or renew its DHCP lease. Check that the device receives an address from the isolated subnet and that the page no longer asks for a reconnect.

6. Verify isolation

Use two test devices in different subnets and test a local address on each side. Then test two devices in the same subnet if local sharing is expected. Finally, open a public site to confirm that Internet access remains available.

7. Add routing for an isolated device

Isolation and routing are separate. Create a specific rule for the isolated IP or subnet, select the intended node/group/interface, and follow verify the current egress path. Do not assume that an isolated device automatically uses a proxy node.

8. Expand only after the test passes

Add one more device, verify its address and boundary, then continue. Record the subnet, parent interface, capacity, gateway MAC, and rule target in the operating notes.

Move a device back or delete a subnet

Move a device back to the ordinary LAN

Unbind the device, renew its DHCP lease, and confirm it receives an ordinary LAN address. Check both router access and the original routing rule.

Delete an isolated subnet

Review which devices and rules are bound to it. Delete only after moving or removing those bindings; otherwise devices may lose their expected address or route.

Management page is unreachable

Use the unisolated management device, a dedicated management VLAN, or a local console. Do not expose the management page to the public Internet as a workaround.

Common problems

Device list is empty

Check that the subnet parent interface matches the device's current LAN/VLAN and that the device is online.

Device stays in “reconnect required” state

Renew DHCP, reconnect the link, and confirm that the address range is not exhausted or conflicting with another network.

Two devices in one isolated subnet can still communicate

That is expected. Isolation blocks between subnets, not within one subnet.

“Isolated but unbound” appears

The device is visible under the isolated parent but has not been assigned to a subnet. Bind it, then reconnect.

Device can use the Internet but not the router page

That is the expected result when router access is blocked. Use the management device on the ordinary LAN.

Device is isolated but has no Internet

Check its IP, gateway, parent interface, routing rule, node health, and DNS mode in that order.

A new rule did not replace the old one

Inspect rule order and the exact isolated IP/CIDR. Change one rule at a time and verify with a new connection.

Next step

After the boundary is stable, review proxy modes, node scheduling, and configuration backups.