Looking for solutions in firmwares v1.2.0/v1.2.1 on TL-R605 v1 when using ACL rules with ! mark
Latest edit (26-10-2022):
I finally managed to set up the router on v1.2.1 firmware. Creating (bidirectional) ACL rule for each Vlan to block inter-vlan. Check this new post.
Edit (11-10-2022):
The latest firmware v1.2.1 still suffers from the same issue as v1.2.0 if both Source and Direction contain ! mark.
In standalone mode, if you have configured ACL rules (blocking something) in Firewall with ! in front of the vlan's name, the router will block everything, you can't even access to the config page, nor to WAN ports.
It's incorrectly stated at the v1.2.1 release note that this new update fixed the mentioned issue. No, it did not! Sorry.
We have to stay with the v1.1.1 again.
-------------------------------------
Unfortunately, the official thread doesn't inform you about it, so I'm compelled to create this one. I don't want others to screw their time with this nightmare I went through.
If you have an R605 router configured with ACL rules in standalone mode, the new update v1.2.0 will cause DHCP not working, leaving the device non-functioning.
Others have already reported about the issue here and someone confirmed that developers had recognized it as a bug in the new firmware.
Do not upgrade from v1.1.1 to v1.2.0!
Let's wait for the bugfix.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Dear @K_verb,
[...]
The main cause of the issue is that the 1.2.0 firmware has adjusted the ACL rules strategy, when the ACL rules created with a "!" network, it will also restrict the access to the gateway itself. That's why the clients are unable to obtain IP addresses from the DHCP after the 1.2.0 firmware update.
[...]
The 1.2.1 firmware has already corrected the ACL strategy, that is, when you use a "!" to set the Source/Destination Network to create the ACL rules, the Source/Destination Network won't include the Omada router itself anymore.
If you still have trouble using "!" to create the ACL rules, it might be a different issue, or there might be something else we overlooked. To figure out the issue, it's recommended to start a new thread with your setup (Tips for efficiently report an issue in the community) or directly contact TP-Link support team via email for further assistance.
- Copy Link
- Report Inappropriate Content
My problem is that I want any VLAN to be able to access the router for DHCP requests, but I want to be able to block access to the router management page from certain VLAN such as the guest network.
I find it really confusing that there is currently no apparent way to achieve this.
Do you know whether/how this can be done?
- Copy Link
- Report Inappropriate Content
Your statement as best answer is misleading.
I have posted my configuration on this forum long time ago and later on I asked the developers to verify and confirm with v1.2.1 that it works for them because for me it does not.
It works on v1.1.1 and after updating the firmware the router does not work.
I also tried disabling the ACL rule before updating the firmware, the router booted up then when I enabled the ACL rule again on the new firmware, after a few seconds it stopped working again.
There is ZERO tutorial on the internet (by TP-Link or by anyone else) apart from my related forum post that would hint how to isolate every vlan from each other on ER605 router in standalone mode.
The ones that exist only say how to isolate one vlan from another but in a config with 50 vlans this is not viable.
- Copy Link
- Report Inappropriate Content
Dear @K_verb,
K_verb wrote
My problem is that I want any VLAN to be able to access the router for DHCP requests, but I want to be able to block access to the router management page from certain VLAN such as the guest network.
I find it really confusing that there is currently no apparent way to achieve this.
Do you know whether/how this can be done?
In Standalone mode, there is a "Me" option for Source/Destination network, which refers to the router management page.
You can add an Allow rule then a Block rule to allow only the specific VLAN to access the router management page.
- Copy Link
- Report Inappropriate Content
Dear @Arion,
Arion wrote
Your statement as best answer is misleading.
I have posted my configuration on this forum long time ago and later on I asked the developers to verify and confirm with v1.2.1 that it works for them because for me it does not. It works on v1.1.1 and after updating the firmware the router does not work.
I also tried disabling the ACL rule before updating the firmware, the router booted up then when I enabled the ACL rule again on the new firmware, after a few seconds it stopped working again.
Thank you for the remind. I searched and found that this post has described your ACL configuration. I've added the image here for other community member's reference.
In your case, both the Source and Destination network are the same '!Vlan99', which looks a bit different from the ACL config described in this thread which was originally reported the ACL issue and it has been fixed in 1.2.1 firmware. To figure out the issue, I've reported your case to the support engineer for further investigation. If possible, could you please describe the phenomenon of the ACL not working issue in detail so that our engineer can try to reproduce the issue?
- Copy Link
- Report Inappropriate Content
Thanks for your cooperation.
Yes, I also realized that the suggested tutorials don't have the same !vlan as source and destination and I was thinking about it when @Hank21 wrote in a thread that according to the developers the new firmware fixed that issue.
I would like to find the solution for that simple case when every vlan can reach the internet but is isolated from each other.
So it would be important to have a tutorial for that (if developers don't create a one tick option for it in the management page).
Now that in ACL setup page there is the option to set "me", I could try using it instead of that phantom vlan (I just created for that purpose), so !me as source (and perhaps !me as destination as well?).
If I can't choose the same !vlan for both source and destination what else would be appropriate to choose? IPGROUP_LAN?
Soon I'll be in the router's location and will try to do some more testing.
Fae wrote
To figure out the issue, I've reported your case to the support engineer for further investigation. If possible, could you please describe the phenomenon of the ACL not working issue in detail so that our engineer can try to reproduce the issue?
As I have reported previously, after enabling that single ACL rule, the router after a few seconds becomes unreachable. No local network, no internet. Reboot doesn't help.
I've tried:
- upgrading to new firmware using the existing configuration
- reset in new firmware and restore backed up configuration from previous firmware
- reset in new firmware and reconfigure the whole network with the numerous vlans
In every situation the router stops working after enabling that ACL rule.
- Copy Link
- Report Inappropriate Content
Dear @Arion,
Arion wrote
As I have reported previously, after enabling that single ACL rule, the router after a few seconds becomes unreachable. No local network, no internet. Reboot doesn't help.
I've tried:- upgrading to new firmware using the existing configuration
- reset in new firmware and restore backed up configuration from previous firmware
- reset in new firmware and reconfigure the whole network with the numerous vlans
In every situation the router stops working after enabling that ACL rule.
Okay, thank you for confirming the information. The support team has reproduced the issue and escalated it to the R&D team for a fix. It's confirmed to fix the issue in the subsequent firmware update on the router.
For your case, choosing the same !vlan for both source and destination won't help if you use the 1.2.0 or 1.2.1 firmware. If you really want to set it that way but not use the old 1.1.1 firmware, I can help to get a Beta firmware (which fixes the issue based on the official 1.2.1 firmware) for you.
If you don't want to use a Beta firmware on your router, but ask for a method to isolate every vlan from each other with the 1.2.1 official firmware, you may create corresponding block ACL with LAN->LAN direction one by one. If there are 46 VLANs in your network in total, you only need to create 46 block ACL rules with LAN->LAN direction, for example, choose source VLAN10 and destination !VLAN10 (no need to add a reflexive rule), then VLAN10 network will be isolated from all other VLANs and vice versa.
Please feel free to let me know if I can be of any further help here.
- Copy Link
- Report Inappropriate Content
I don't mind using beta. So if there is one that you can provide me, I'd happily try it.
Also, I don't mind creating 46 (or so) ACL rules to block each vlan from the others but I thought it would "cost" too much resources on the router. As this amount of vlans already causes the router to boot in over 10 minutes. (however upon the boot up, the memory and CPU in normal operation still shows moderate/low usage)
Besides, in my experience in earlier firmwares until v1.1.1 (perhaps until the one before that one) one direction was not enough. In my old configuration where I used MTU-VLAN in the two easy smart switches connected and thus only had needed 3 vlans on the router, if I didn't create the blocking rule for both direction, it didn't stop inter-vlan.
- Copy Link
- Report Inappropriate Content
Dear @Fae ,
I have two discussion points:
1.
Fae wrote
[...]
In Standalone mode, there is a "Me" option for Source/Destination network, which refers to the router management page.
You can add an Allow rule then a Block rule to allow only the specific VLAN to access the router management page.
This is not entirely in accordance with my testing (using v1.2.1). I applied the following:
Result: devices outside the IPGROUP_MGMT are getting an IP (DHCP works) but cannot access the internet, tested with one Windows laptop and one Android phone. This issue is separate to the main issue in this thread, should I create a new thread with this info?
My current solution is to use the HTTP service and create a similar HTTPS servic to use for blocking each exposed router webpage port (in my case the default 80 and 443). I then used these services to create the following rules:
These rules successfully block acces to the router webpage login from any network except the MGMT VLAN, while still allowing normal internet access for all devices in the network.
2.
My rules to isolate VLANs now also work, but they appear to work bidirectionally instead of unidirectionally. If I add this rule:
I cannot acces a webpage that is hosted on the IOT network from a device on the Private network. I expected this to be possible since in this blocking rule, IOT is configured as source and Private as destination. What could be wrong here?
- Copy Link
- Report Inappropriate Content
I didn't understand your example_1 to block management page. In the image it seems you were blocking http and https for everyone outside of MGMT. If you block those ports, how can they use the web services that also require port 80 and 443?
And why didn't you create an Allow rule for Me to MGMT and then in 2. place in the list a Block rule for Me to IPGROUP_LAN?
About your 2. question (that actually is related to the 1. this way),
and it bugged me long ago when I just had to isolate 3 vlans with individual ACL rules and I realized that Source and Direction are the opposite to what we would expect and for me what would be logical.
Look at the suggestion @Fae kindly gave me above, to block VLAN10 (as Source) from !VLAN10 (as Destination). He explains it as to block VLAN10 from everything else.
It means that the one that you want to avoid reaching a specific vlan is configured as Destination and not the Source.
Now, whether it blocks bidirectionally or not, I can't tell until I get to the scene to try the new firmware. But you can check it out.
If it's really bidirectional now (and so it doesn't matter which way you set it up) and there is no other option to block just one direction, that would be a problem for many. (not for me though)
By the way, your printscreen shows beta firmware page with the watermark in the background. The official v1.2.1 is not beta.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 1
Views: 6130
Replies: 40