ER605 access control not working
ER605 access control not working
Hello to everyone! I am trying to create some ACL rules on my ER605 but i don't understand why it looks impossible.
I have blocked two networks from reaching themselves and it works ("Domotica" and "LAN_1").
The problem is that if i try to create a rule to block a single IP from reaching another IP it does not work.
As you see in the following screenshot i set a rule to block ALL between two IP groups "Test_pcluca" and "NAS" but it is like this rule is not there, from that pc i can see and use the NAS.
I need to make rules to allow only some machines to get to the NAS and block everything else.
I'm getting mad.
Thank you in advance
EDIT: upgraded to firmware 2.2.6 Build 20240718 Rel.82712.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
@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...
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
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
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
@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...
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
@Clive_A ,
After the OP's second post, it was clear that source and target were in the same network.
That made it a switching issue.
You kept trying to make the existing system work, leading me (and maybe the OP) to believe that it was expected to work (sufficient to handle his use case).
It only had a remote chance of working because the destination was actually hooked up to the router directly, which was cleared up later. Still a switching issue though.
IMO, it would actually be mayhem if GW LAN->LAN ACLs touched intra-LAN traffic.
The rule would only apply to traffic going through the router.
Without any logging, you'd have to ask customers for network maps to troubleshoot.
I said it before, the current lack of control on switching behavior at the router is acceptable (to me). While it may have helped the OP, the drawbacks seem to far outweigh the benefits.
In other words, we're better off with current behavior of GW LAN->LAN ACLs with regards to switching. It's more predictable.
Any control on switching behavior at the router could be done in the form of enforcing switch ACLs.
In terms of granularity of GW LAN->LAN ACLs, there have been numerous requests for it.
Broad deny LAN1->LAN2 but granular access to ServerInLAN2:Port.
Isolation of management network, yet access to the controller.
Then people try to make it work with switch ACLs and trip over their stateless nature. I know I did at the beginning...
Personally, I would prioritize logging over granular GW LAN->LAN.
I will never again use a security solution that does not provide logging. It's just too painful to troubleshoot.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 654
Replies: 18
Voters 0
No one has voted for it yet.