@EricPerl 

EricPerl wrote

  @Bmark ,

 

I sympathise with your pain.

Wouldn't it be nice if the rules enforcement subsystem produced logs (like most firewalls do)?

 

FWIW, in this thread:

ER605 switching capabilities - Business Community (tp-link.com)

The same support staff member told me that switch ACLs don't apply to the "switching ports" of an Omada controlled ER605, by design.

Yet the standalone version of the device has rules that look like switch ACLs or at least are expected to control switching behavior.

Nice!

 

Personally, I would never rely on a solution that only "works" (if/when you get it to work) because the NAS is plugged in directly in the router.

If you relocate it physically to the switch (managed or not), the rule would no longer apply unless it is relocated as well.

That seems all too fragile. Doesn't the NAS have a firewall? That would be more robust IMO.

 

In any case, this has been informative and confirms my future plans...

 

I refer to the "switching ports" as a concept which is a way you can think they are. Conceptually. If any of the LAN ports are not used for the uplink(WAN) then they can be thought of as. But they are not switch-controlled-chipset-ports from the hardware/software level so they are not gonna be effective by the SW ACL you've configured.

I think I will stop expanding the concepts and knowledge for people on the forum and I begin to do this at this moment. It is hard to explain and discuss further when you have a single-minded thinking strategy. Hope any who reads this can find somewhere else to verify and learn the knowledge that has been shared on the forum.

Hi @Bmark 

Thanks for posting in our business forum.

Bmark wrote

  @Clive_A if i try to set it to LAN-LAN it will not make me to select the ip groups but just the full networks (and those device are in the same network).
A solution could be to make separate networks, i should make a vlan for the devices that should reach the NAS (vlan5), a vlan for the NAS itself (vlan6) and a vlan for the devices that should not reach the NAS (vlan7) sinche i need to keep the devices from the ipothetic vlan5 to reach those from the vlan7 (i hope i explained myself).

But it would be way easier if the ip group would work.

 

At the moment the block rule on the ip does not work both on the devices connected directly to the router (192.168.1.16 for example) and for those connected to the switch (192.168.1.14) (i am editing the diagram image since those two machines were inverted).

At the same time the block between the two networks (Domotica and LAN_1) is working for both devices connected to the router or to the switch, both ways.

Thank you again!

I think you might need to wait for the future firmware that supports IP-Port Group in GW ACL. Currently, LAN > LAN cannot do it now.

Hi @Bmark 

Thanks for posting in our business forum.

Bmark wrote

Hi  @Clive_A ,
thanks again!
In this situation you would suggest to get a switch or wait for the firmware?
I would not wait too much since in this situation the LAN is not safe for us.
Not a problem for me to get a switch, i just would be sure about which one has IP ACL

If you tend to keep the Omada solution, that'd be best. The Omada future is promising with newer updates. ER605 would last longer than its first-gen(V1).

Switch ACL can offer some versatile functionality. You can get one and try it to see if it can meet your network setup.

Hi @EricPerl

EricPerl wrote

  @Bmark ,

 

Don't wait, because I would not be surprised if this future release does not handle your scenario.

While many people will welcome more granular control on LAN->LAN, I suspect it will only work when source and destination are not in the same network.

 

He never admitted it, but Clive thought the existing system would be sufficient but it is not...

At least this makes it consistent with the Omada version. No intra-LAN control on the router/gateway.

 

When dealing with switch ACLs, keep in mind that they are stateless, meaning that they only look at source and destination of packets. Your intra-LAN use case is simple enough though. A simple block from "not-allowed-to-access-NAS" to "NAS" will do. I'm not sure I would bother with the opposite direction because the NAS is unlikely to initiate communication to these clients and the reply traffic will be blocked by the first rule...

These ACLs are tricky when you try to workaround the current limitations of GW ACLs. For example if you block IOT->VLAN1, accessing an IOT device from VLAN1 fails (replies are dropped). You need a finer grained exception ACL at the port level...

 

 

TBH, I did not think it was sufficient in my opinion. What's sufficient, I think, my personal view and point, is when it introduces the iptables so that people can wisely configure based on the iptables commands. Not sure if this can ever be considered.

But it should require more hardware resources I think and way more knowledge. At this moment, Omada is providing an entry-level, taste of the business product.

What I think is the current system offers the basic ACL with the Omada solution. Omada not only provides products to home users, it also has many more partnerships with larger companies and condos bound by the contracts. The ACL has been updated several times but no major changes based on the feedback from them. The major feedback like that comes from sporadic users on the market. Our contract users have not seriously complained about its granularity.

That could be an "enough or sufficient" tone you might interpret from existing situations I am telling you. I did not say it is granular enough for everyone's unique setup but it is for the majority of regular users if with a full solution.

I am also about the Openwrt and iptables as I have my own projects at home and with LINUX. The system is not enough but good enough for most regular people.

If you ask me if this is the best choice for very granular control, nope. Definitely not the best one. I'd pick up an open-source or LINUX instead of a pre-built router. 

This is not to say that we don't think the sporadic suggestion/feedback from the market is not important. But we are still open to suggestions and feedback.

But as for the business users who are more professional and the forum where we can expand and discuss the topic, if there is a more constructive positioning and illustration of the ACL you or anyone else could provide and expect, be specific and provide details. I surely can prepare a report for the dev to further notice about the market feedback and consider it.

IP-Port Group in GW ACL was reported some time ago and was considered in future versions as the request is clear, obvious, and making sense.