@RoRo7, I'm not from TP-Link, I'm just a user of this forum as any other user is. You can see that from the badge which TP-Link employees have beneath their username.

I only wrote that our VLANs deployed at several dozen customer sites still work. If you correctly set up a VLAN, it will still work with EAP225 firmware v2.6.1 as well.

If your VLAN does require untagged traffic sent to all Multi-SSIDs, the bug is in your VLAN setup, not in the EAP225 firmware.

There are only two setups I can imagine failing with Multi-SSID VLANs, namely asymmetric VLANs or VLANs over the same broadcast domain. Both types of VLANs are common in home user networks which use VLAN-unaware routers. Those types of VLANs do not isolate clients reliably.

So, again: if you request help from users here in this forum, post your setup.

@TFTCM, yes, there was something changed, you can read in post #2:

Fixed the bug that untag packets can be transferred to SSIDs with different VLANs.

If you use VLANs from your router (and DHCP server!) as well as separate broadcast domains (i.e. separate networks) through all devices up to the EAP225's SSIDs, it will work perfectly.

See my post #6 for a working setup.

RoRo7 wrote

What I have found today is that the issue is for the default VLAN1. The guest VLAN lets say 20 is working. So if the AP is not using the VLAN1 this could work without a problem?

Yes. The most mis-understood concept in VLANs is the so-called Default VLAN, which most people think »it carries untagged traffic«. That's wrong. VLAN 1 is just a VLAN as any other, inside a VLAN-aware network there is no untagged traffic. Even traffic in the Default VLAN gets tagged with a VLAN ID (often ID 1, but you could also assign VLAN ID 100 or 77 or whatever ID you define to be the »Default VLAN«).

It's just terminology.

Every switch in a network processing VLANs always uses VLAN tags, even if you use a managed switch set up as an unmanaged switch (i.e. only one common network).

But: you can indeed terminate the Default VLAN at any switch's port and send untagged traffic to the EAP (even over a trunk), which then should only reach the EAP itself, but not any SSID assigned to a VLAN – except if it has the same VLAN ID as your Default VLAN.

Tagged traffic on the trunk port from the switch to the EAP (say, VLAN 20-tagged) can be directed to the SSID only, no matter whether you send untagged or tagged traffic to the EAP itself.

The bug in earlier EAP225 firmwares was a leakage from untagged traffic to VLAN-aware SSIDs. This has been fixed in firmware v2.6.0.

Yes, you are right, other EAP's firmwares should be fixed, too.

BTW: the reason why my setup isn't affected by the bug-fix is that I never use a Default VLAN (except for assigning it unused ports) nor untagged traffic to an EAP or other VLAN-aware device, but rather use a designated Management VLAN (200 in the topology in post #6) for communication with the EAP itself. This allows to isolate the EAP itself in a subnetwork »on the other side« of a router – the company's network –, while wireless clients in a guest network are in an isolated LAN »behind« the router, so they can't even connect to the EAP itself. Trusted employess of the company can use a SSID assigned to the company network. This is a reliable, correct isolation of the networks assigned to SSIDs.

@TFTCM, you're welcome anytime. Thanks for your feedback.

@forrest @TFTCM @RoRo7 @R1D2 

Any idea on why TP-Link support is telling people to roll back to Build 20190404? 

From an email they sent me: "Please make sure that the firmware of your EAP is Build 20190404 because we change the mechanism of the VLAN in later firmware." 

Seems like they think they are making things worse with their firmware updates.