Dear @dpsguard,

 

@Fae , please count my vote in for this feature request.

 

 

Thank you for the feedback. I've written it down.

 

And hopefully broken portal template that does not work and wastes everyone's time, will also be fixed.

 

I'm so sorry for any inconvenience caused. For the guide about external portal server, I'll confirm with the senior engineer and ask the writter to correct it if there is something wrong.

 

I am however not sure if this Guest Networks feature only implements client-isolation (within the clients of the same AP) plus RFC1918 block, or this also blocks IP communications between all clients of the same SSID throughout the Multi AP network?

 

Guest network will block clients from reaching any private IP subnet. With Guest Network enabled,

1. All wireless devices connected to the SSID cannot communicate with each other;
2. All wireless devices connected to the SSID will be blocked from reaching any private IP subnet (10.0.0.0 -- 10.255.255.255; 172.16.0.0 -- 172.31.255.555; 192.168.0.0 -- 192.168.255.255 ). 

 

Fae wrote

Guest network will block clients from reaching any private IP subnet. With Guest Network enabled,

1. All wireless devices connected to the SSID cannot communicate with each other;
2. All wireless devices connected to the SSID will be blocked from reaching any private IP subnet (10.0.0.0 -- 10.255.255.255; 172.16.0.0 -- 172.31.255.555; 192.168.0.0 -- 192.168.255.255 ). 

 

I'm afraid I have to disagree.

 

When using the same network for the LAN and a Guest network, the »Guest Network« setting does block wireless devices from reaching any private IP subnet only for IP traffic, but not for non-IP traffic. Guests connected to the Guest Network can still find out which devices are connected to the private LAN as you can see in following screenshot. The issue here is that the guest network and the private LAN use the same broadcast domain:

 

 

 

 

dpsguard wrote

And R1D2, I do have VLANs and that portion works fine where no communication happens from Guest VLAN to any other VLAN, set up via ACLs / firewall rules.

 

A VLAN will block any IP traffic as well as any non-IP traffic from the Guest VLAN into any other VLAN as long as you don't enable Inter-VLAN routing in the router.

 

Client isolation is needed to prevent any traffic between clients connected to the same SSID of the same EAP.

 

Private IP rules are needed to block any IP traffic between clients in the same (Guest) VLAN including clients connected to the same SSID of different EAPs as well as outbound traffic from clients to private IPs in the WAN (which might be the main / home / company network where the Internet router is located).

 

Now, the point why we prefer »Client Isolation« over a »Guest Network« setting in business networks is that customers often need access to shared ressources among all VLANs while isolating clients in a guest network from each other. See following scenario as an example. I had to set this up just two days ago for a customer, it's not a hypothetical setup:

 

 

• EAPs and OC200 are inside an isolated Management VLAN 200. VLAN 10 is the private LAN, VLAN 20 the guest network, VLAN 30 a VIP VLAN. VIP clients have access to each other, but not to clients in the private network.
• Guests in VLAN 20 and VIPs in VLAN 30 need access to the OC200 if you use an OC200 portal (we don't do so; our portal runs on the router, so guests in VLAN 20 and VIPs in VLAN 30 need access to the Captive Portal on the router which is a multi-homed system and as such is present in any VLAN).
• Guests in VLAN 20 and VIPs in VLAN 30 need access to the shared printer in VLAN 10.

 

All access control rules are centralized in the router's stateful firewall. Only few (MAC) ACLs in the switch are required to prevent switching traffic from a guest in VLAN 20 on EAP1 to another guest in VLAN 20 on EAP2. IP ACLs are not enough.

 

Now, with »Guest Network« we need to exclude the IPs for the gateway and the printer in a new »Block« ACL since the »Guest Network« setting uses an invisible ACL to block IP traffic between guests. The issue is that we a) do not want to block only IP traffic between guests, but all traffic including non-IP traffic (achieved with VLANs), and b) do indeed want to allow guests to reach the gateway by its IP 192.168.20.1 in the Guests VLAN and the shared printer by its IP 192.168.10.20 in the Private VLAN.

 

If you use an OC200 portal you certainly want guests be able to reach the portal by OC200's IP 192.168.1.250 in the Management VLAN.

 

Thus, with »Guest Network« setting (which we just need to turn on to achieve »Client Isolation«) we »accidently« block the OC200, the gateway and the shared printer implicitely. To correct this, it requires the following explicit ACL in Omada Controller with appropriate »Exclude Subnets« settings:

 

 

Note that an »Allow« ACL will not work, since if set it denies access to every IP not listed in the ACL, thus denying access to the Internet.

 

So we have to document that the above ACL is just needed to compensate for the invisible ACL set implicitely by »Guest Network« setting effectively downgrading the »Guest Network« setting to a pure »Client Isolation« setting. Very confusing for our customers to say at least.

 

 

 

dpsguard wrote

But this is confusing and a customer could accidently disable whatever I set up for them and then they will make it open or break access to portal etc.

 

This is exactly what once happened when a customer, who administrates Omada Controller on his own behalf (he has an own IT department for his 10 branches), but use our portal on the gateway, did enable the »Guest Network« setting in controller v3.0.2: it blocked the portal in 6 of his 10 branches, leaving hundreds of guests without Internet access. As is usual in such cases, the customer claimed that »nothing was changed in the setup« when the error occurred (he was even right: nothing was changed in the gateway itself).

 

The setting was very new at this time, I still had not tested the new controller with our system and therefore I searched for the cause of the malfunction elsewhere for hours until I realized that their IT must have tried this setting accidently blocking the portal on the gateway.

 

It would have been so easy for TP-Link to just add the »Guest Network« setting on top of the existing »Client Isolation« and the existing ACL mechanism w/o removing the CI setting and w/o hiding the ACLs. As I always said: both options can co-exist. And if a setting sets any ACLs, they really should appear in the ACL settings menu, so one can see them.

 

We have plenty of such user-friendly one-click functions in our own software, too. We call them »Presets«. For example, we have a Preset to define an additional VIP network with a single click, which gives a group of hotspot guests free access to the Internet w/o the need for authentication through a portal. This is handy for hotel guests who stay in the hotel for months.

 

But when defining such a VIP network the admin can see a summary of each »low-level setting« modified by this one-click Preset, so it is even self-documenting and we mark those changes in the corresponding firewall, network and DHCP settings as well as in the topology map.