@tekneon 

Yes I agree, it is directly embarrassing that tp-link does not have this in place in this solution, in stand alone there are several ACL options in 1.1.1. firmware so I wonder if it will not come in omada V5 but I have not been confirmed. but a business firewall without this is not a firewall.

It is also not possible to create rules from WAN to LAN

Now we have to create firewall rule in switch, and this is a nightmare to do with very limited  option/function.

@shberge 

This feature has been requested a bunch of times. It is a big glaring issue with the omada environment. Without this there is no true firewall function in the system. The other major issue is the lack of IPv6 support beyond basic routing. It isn't supported in acls, "firewall" functions, or the management network.

Hi,

I am new user of the omada ecosystem (router, switch, ap) and I was very unpleasantly surprised that this feature is missing. All reviews I managed to go through said this system is a 1-1 copy of unifi features but sadly it is not. 

This is very needed for clean home network segmentation (secure lan vs IoT devices), please add this to your roadmap. 

I agree with everyone here. This is probably the largest lacking item of the routing/firewall capabilities within Omada. There is no workaround, and it creates a security hole when trying to properly segment devices on your network (Home and Business). I know that there are several users here that use the Omada devices in their homes (so do I), so everyone makes requests on behalf of thier home setup (i.e. IoT device sementation from the secure LAN). But TP-LINK seems to be missing the fact that, businesses as well are adopting IoT devices within thier corporate networks. For instance, utilizing a DNLA or casting/streaming device to handle presentations within a conference/training room. We don't want these casting/streaming/projection/display devices on the secure LAN, so we segment them to an IoT VLAN. But in order for them to work properly (especially AirPlay devices), you need a rule that allows for established/related connections. There are other instances where this is needed, but this is low hanging fruit.

This also ties into another large gaping hole in Omada routing... mDNS, or should I say, lack there of. Now, this does have a workaround, setup the Avahi daemon with reflector enabled on a single use linux device/vm that has VLAN trunking properly setup at the switch and on the device. Assign the device an IP in each VLAN you want mDNS broadcasting through, and allow the proper ACL rules within each VLAN to access the device on TCP port 5353, but allow the mDNS device (on each IP) full access back to each VLAN (again with establised/related ACL rules causing potential security holes). This wouldn't be necessary if the Omada gateway/routers had mDNS reflector control for each gateway IP address. mDNS has a place across a ton of devices, not just multimedia casting/streaming. Most printing devices utilize mDNS broadcasting for zero-config end-user connections. I have personally ran into several other small internet connecting products that utilize mDNS protocols to esablish connections to an end-user device/app, and I don't want these devices on my secure LAN, god knows what infromation they collect and send home about your network and connected devices.

Instead TP-LINK wastes time and resources on Facebook authentication against WiFi access. This is marketed as a business device, Facebook is a dying consumer level service that has a proven lackluster security framework multiple times throughout recent history. I would never enable Facebook authentication against any of my corporate services, or even home level services for that matter. TP-LINK needs to pay attention to their competition and compete against business devices (you know who the competition is, I don't need to repeat their names). These services should be easily developed into existing firmware. If you need to remove a process/service or 2 from the devices to enable the storage/memory/processing requirements, then remove the consumer level fringe services (like Facebook authentication) that no business should ever implement and make your product compete in the real world.

I've now hit a wall with this issue as well.   Is there anything about this on the roadmap?  I'd hate to have to rip all this gear out and start over with something else because of something that 'should' be implemented as part of a basic firewall configuration.

  Really need this feature as well, I upgraded my network specifically to segment my network into VLANs - with some inter-VLAN routing possible. So far, no way to properly set it up. Is it already on the development roadmap? Would be really nice to hear something back from TP-Link at least to know whether it's worth the wait or should we switch...

  @tekneon 

I can confirm this is now working on latest update. 

  @pduchnovsky 

Same discussion under different thread:

https://community.tp-link.com/en/business/forum/topic/252860?replyId=1152394

This works on Gateway level and not switch level