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 @Arion,
Arion wrote
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
The beta firmware request has been submitted to the R&D team. I'll send you the beta firmware once it is available, please wait patiently.
ACL rules won't occupy CPU/memory resources on the ER605 router. But more ACL rules, more longer the router takes time to boot.
Sorry that I didn't test the previous firmware, but I can confirm that the blocking ACL rule with LAN->LAN direction is bidirectional in the 1.2.1 firmware.
- Copy Link
- Report Inappropriate Content
Dear @K_verb,
Since you've already post the detailed info, I think it's okay to continue to discuss here. But next time you may create a new thread so that other community members may have a chance to find your post and benefit from it.
For the first discussion point, you configured the Source network with exclamation mark, which should cause the same issue as that @Arion met. It's not suggested to configure it that way at present. If possible, try my earlier suggestion.
For the second discussion point, yes the block rule is bidirectional. I'm afraid that your requirement to isolate VLANs unidirectionally cannot be achieved on the current ER605 firmware.
- Copy Link
- Report Inappropriate Content
@Fae
1. I first tried to block from source: Private to destination: Me but this did not have the desired effect, I'll have to check again to see what was wrong in that case.
2. Thank you for confirming that unidirectional ACL is not possible. Is this only the case for "LAN->LAN" rules or also for rules with "ALL" direction? I did find on the support website that it is possible on the ER7206 for "ALL" direction rules, can this functionality be ported to ER605 in the next firmware release? This is required for me to implement a sort of admin network that can access multiple other VLANs but not vice-versa.
1. I was wondering the same about accessing web services on those ports, but to be honest I tested a bunch of stuff until I was able to access the internet and not able to access the management page from outside the MGMT VLAN and then kept those settings. With all these weird quirks I also don't fully understand the rationale behind it. I didn't create an allow rule because I guess that everything which is not blocked will be allowed, so it is implicit.
2. Looking at the ER7206 documentation I linked above, it seems that Source and Destination are not mixed up and are logical to what I would expect. Of course if all rules are bidirectional by default on the ER605 then it doesn't really matter...
3. I'm indeed using a beta that has a quickfix for DHCP issues which is supposed to be integrated into the next official release.
- Copy Link
- Report Inappropriate Content
Dear @K_verb,
K_verb wrote
Is this only the case for "LAN->LAN" rules or also for rules with "ALL" direction? I did find on the support website that it is possible on the ER7206 for "ALL" direction rules, can this functionality be ported to ER605 in the next firmware release?
Blocking rule with "ALL" direction is the same case on the ER605. The subsequent firmware updates will be able to meet your requirement (it's for your reference only, please refer to the final firmware release for confirmation).
- Copy Link
- Report Inappropriate Content
Following your instructions I have successfully configured the ER605 v1 in v1.2.1 firmware to block inter-vlan. Creating rules for each vlan(x) to !vlan(x). I have done some tests and it seems ok. The memory usage was not affected, either.
@K_verb
Thanks to your advice, I have also managed to create exclusive access for one vlan to the router's management page, blocking others from it.
First I tried with All Service Type (with !myvlan to Me) that unfortunately blocked the whole router and I had to push reset and reboot it. Your hint to block only http and https seems to work.
I really hope nobody on the local network will have any issue with it. It seems it doesn't affect internet traffic, I tried to test it with some apps, I don't know what should be the more appropriate to use for testing http port 80 and https port 443. (oh... I forgot to test Mail app... Have you checked it in your network?) I live far from the router's location and I got already back home.
Besides, there are still some less important bugs remaining:
- VLAN list order still misordered and we don't have the option to define ID order number for the VLANs.
- Traffic Statistics still buggy, shows inconsistent numbers and events.
And a more serious issue:
- Bandwidth Control with usage percentage configured: after any reboot or restrore it limits the bandwidth even if there is nobody else using the network, only me.
I had to turn the feature OFF and ON again in order for it to stop limiting traffic unnecessarily and changed the percentage to 90%. But it the issue reappears again, I'll have to disable it.
- Copy Link
- Report Inappropriate Content
Happy it works for you as well!
I also don't live at the site (yet... it's a renovation project). I do have a home automation system already running which regularly sends me emails, and with my phone and laptop I had no issue sending a test email today when connected to the router via VPN.
- Copy Link
- Report Inappropriate Content
Happy it works for you as well!
I also don't live at the site (yet... it's a renovation project). I do have a home automation system already running which regularly sends me emails, and with my phone and laptop I had no issue sending a test email today when connected to the router via VPN.
- Copy Link
- Report Inappropriate Content
Fae wrote
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.
Hello, just pickup one of these routers a week ago, v2 FW 2.0.1 Build 20220223. What is the status of the issues raised in this thread. I tried your above quote and it breaks the DHCP service for the source VLAN. Tried swapping the source and destination with the same result. Also interested in if/when the ACL is supposedly going back to unidirectional. I haven't tried the suggestion for blocking access to the router Web UI but expecting it to either not work or have issues as pointed out already when I do. Seems so far no one anywhere has been able to get this to work with NordVPN's implementation of OpenVPN due to a lack of somewhere to enter the credentials. Any Suggestions on that? TBH if I knew this product (V1) was released barely passing/functional as a "SMB" or "VPN" router and has had nothing but issues since I would have gotten something from another vendor. Chose it because I have been happy with my TP-Link switch.
Edit: Tried blocking the web UI and it worked fine without having to open port 80 or 443 as others stated. Another very basic/critical feature missing is the ablity to block/allow LAN>LAN comunication with IPGROUPS. Currently can only do a blanket block/allow for entire LAN's without being able to let select IP's through.
Thanks
- Copy Link
- Report Inappropriate Content
Fae wrote
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.
Hello, just pickup one of these routers a week ago, v2 FW 2.0.1 Build 20220223. What is the status of the issues raised in this thread. I tried your above quote and it breaks the DHCP service for the source VLAN. Tried swapping the source and destination with the same result. Also interested in if/when the ACL is supposedly going back to unidirectional. I haven't tried the suggestion for blocking access to the router Web UI but expecting it to either not work or have issues as pointed out already when I do. Seems so far no one anywhere has been able to get this to work with NordVPN's implementation of OpenVPN due to a lack of somewhere to enter the credentials. Any Suggestions on that? TBH if I knew this product (V1) was released barely passing/functional as a "SMB" or "VPN" router and has had nothing but issues since I would have gotten something from another vendor. Chose it because I have been happy with my TP-Link switch.
Edit: Tried blocking the web UI and it worked fine without having to open port 80 or 443 as others stated. Another very basic/critical feature missing is the ablity to block/allow LAN>LAN comunication with IPGROUPS. Currently can only do a blanket block/allow for entire LAN's without being able to let select IP's through.
Edit 2: Seems blocking the web UI is not without issues. If I block "LAN1" & "LAN3", it works as expected. If I block "!LAN2", it breaks the internet for LAN1 & LAN3.
This router has so many bugs and issues with the access control, I'm seriously wondering how I'm supposed to trust this thing. I really can't, the amount of time that would have to be spent with wireshark to be able to is not worth the $60 it cost. Out $60 and still need a functioning router that isn't still in beta.
Thanks
- Copy Link
- Report Inappropriate Content
PiGuy wrote
Another very basic/critical feature missing is the ability to block/allow LAN>LAN communication with IPGROUPS. Currently can only do a blanket block/allow for entire LAN's without being able to let select IP's through.
Edit 2: Seems blocking the web UI is not without issues. If I block "LAN1" & "LAN3", it works as expected. If I block "!LAN2", it breaks the internet for LAN1 & LAN3.
In the above printscreen you can see that I allowed access for a specific VLAN (Vlan217) to another VLAN (switch_1 and switch_2) before blocking inter-vlan communication for the rest of the local network. And blocked access outside of a specific IPGROUP (_A27_) – using ! – via http and https, in this case the source must be Me.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 1
Views: 6160
Replies: 40