Looking for solutions in firmwares v1.2.0/v1.2.1 on TL-R605 v1 when using ACL rules with ! mark
![](/avatar/avatar-5.png)
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
@Fae I sincerely hope that in this fix the devs will allow only DHCP requests from any vlan to the router but disallow access to the router management portal from blocked vlans, this is really a security feature that I have been waiting for since I first installed the ER605.
- Copy Link
- Report Inappropriate Content
The router made me mad, again, even with the firmware v1.1.1
I experienced that rebooting this router takes so long, at least 10 minutes. And as I've mentioned before, there is no "promising" communication by the leds on the device.
Only the power led is on, it doesn't even flashing to show that it's in process. It's frustrating because we can't know if it's frozen or not.
And after looking at the system log, it shows that each vlan takes 3 seconds to get its IP address/mask. Then several other steps take minutes. DHCPS initialization 30-240 seconds, and it appears several times in the log.
There are other strange things:
E.g. one of the WAN connections is PPPoE. And it has been set with MTU=1492. In the log it shows 1480
Fortunately I installed an UPS power backup for this config, otherwise any tiny power shortage could lead to a 10-15 minutes internet shortage.
Other thing still happening since the first firmware release:
Now I have two microwave connection with the same bandwidth plan. One connects with dynamic IP, the other with PPPoE.
Both are configured with the same bandwidth numbers. However, the traffic statistics shows that WAN2 had 10 times more download usage than WAN1, and the uploads are the opposite, it has sent more via WAN1.
There is something else that causes problem:
If a WAN port is disconnected (either by me clicking on disconnect in WAN setup page...), it still wants to send traffic through that, probably because of Load Balance. If in Load Balance both wan ports are marked, it doesn't look at the result of the online detection feature.
This is a serious issue, IMO.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
Please, can you tell me what this new feature exactly does that is written in the new (v1.2.1) release thread? (I wanted to avoid starting a new thread.)
Add cloud optimization support in standalone/controller mode, you can choose to enable/disable cloud connection, and update the basic cloud domain name.
I'm interested in this feature in standalone mode. Does it mean some kind of limited access via Tether app?
Or is it just how the Omada cloud service can somehow detect the device even if it's configured in standalone mode while it's connected in a Omada controlled environment?
- Copy Link
- Report Inappropriate Content
![](/avatar/avatar-19.png)
Dear @Arion,
Arion wrote
Please, can you tell me what this new feature exactly does that is written in the new (v1.2.1) release thread? (I wanted to avoid starting a new thread.)
Add cloud optimization support in standalone/controller mode, you can choose to enable/disable cloud connection, and update the basic cloud domain name.
I'm interested in this feature in standalone mode. Does it mean some kind of limited access via Tether app?
Or is it just how the Omada cloud service can somehow detect the device even if it's configured in standalone mode while it's connected in a Omada controlled environment?
This feature is mainly to provide an option to disable cloud-connection behavior and update the cloud domain name to avoid confusion, as is reported Here.
If you don't have plan to use the Omada Cloud-Based Controller to manage your Omada devices, you can disable the cloud-connection behavior as you want. Anyhow, it won't affect your access to Tether app (for home products?) or Omada App (for Omada devices).
- Copy Link
- Report Inappropriate Content
After updating to v1.2.1, the ACL rules with "!" work again as they did on v1.1.1, BUT the major security flaw is still there that the router's management portal is still accessible from any VLAN.
EDIT: I was wrong, the '!' issue is not fixed!!
- Copy Link
- Report Inappropriate Content
Please, could you describe your configuration for ACL or better post a printscreen of that page?
I keep claiming that on v1.2.1 firmware using my config with ! in ACL the router becomes unreachable after turning that ACL rule on.
Edit: now I see your edited comment.
But @Hank21 has stated that with the new firmware they tested the ! rules and works for them. I'd like to know exactly what configuration works for them.
Actually, I don't mind using v1.1.1 for longer period. And I couldn't have risked (again) to update during the (european) summer. I'd like to ask the devs that whenever they release new firmware, please test this bug and don't allege that it works because it causes many hours of interrupted local network until we figure out why it doesn't work.
- Copy Link
- Report Inappropriate Content
K_verb wrote
BUT the major security flaw is still there that the router's management portal is still accessible from any VLAN.
You are requesting an exclusive management vlan.
I have also thought about it but couldn't figure out how to do it.
There is a similar feature on EAP management page and when I tried it, "successfully" blocked myself from that page because chose my vlan but the EAP was connected on a different vlan port. It's a different story though.
On ER605 there should be this feature choosing management vlans.
- Copy Link
- Report Inappropriate Content
This seems to work when using an Omada controller but for me it does not work standalone.
Any device in any VLAN can access the router login page although the router LAN IP is in a VLAN that is fully isolated by an ACL rule.
- Copy Link
- Report Inappropriate Content
Fae wrote
[...]
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.
[...]
@Fae is there already a plan to change this in a future firmware release to where access is blocked on every service EXCEPT dhcp?
- Copy Link
- Report Inappropriate Content
![](/avatar/avatar-5.png)
Information
Helpful: 1
Views: 5709
Replies: 40
Voters 1
![voter's avatar](/avatar/avatar-21.png)