Beta Software ER605 V2_2.1.5 Build 20231024 Beta Firmware for Omada Controller V5.11 (Released on Oct 26th, 2023)
![](https://static-community.tp-link.com/icon/d992b79227f44913ac92e1d95b8e517c.jpeg)
This Article Applies to
ER605(UN) V2 2.1.5_Build 20231024 (Beta)
Release Notes:
New Features & Enhancements:
1. Add ACL support for IPv6 data.
2. Add support for IPv6 RA (Router Advertisement) configuration for LAN.
3. Add support for configuring multiple IP addresses on the WAN port.
4. Add support for monitoring session limits in controller mode.
5. Add support for configuring the MSS (Maximum Segment Size) of WAN port.
6. Add support for Gateway Tools in Controller mode.
- Ping.
- Traceroute.
- Terminal.
7. Add support for the ability to download device info of Gateway in Controller mode.
8. Add support for Location Group in Gateway ACL.
9. Add support for white list of MAC filtering in Controller mode.
10. Add support for tagging same VLAN ID on different WAN port.
11. Increased security of communication between Gateway and Controller.
12. Add support for DNS cache, which can improve domain name resolution speed by handling recent address resolutions locally before sending request to Internet .
13. Add support for DH 14 and DH 15 for PFS.
14. Add support for 0.0.0.0/0 IP range of local network when using IPsec IKEv2 for Client-to Site VPN.
15. Add support for DDNS custom intervals (1~60 minutes).
16. Add support for link-local addresses of IPv6 DNS on the LAN side.
17. Log Enhancements.
- Show the source IP address of TCP no-Flag /ping of death attacks.
- Show the log of link backup switching.
- Show the log of DDNS update.
- Logs can be saved when the device is down. You need to short-press the reset button within 5s, and after releasing the reset button, the sys light will be on for 3 seconds to indicate that the downtime log is saved successfully.
Bug Fixed:
1. Fix the bug that ICMP type 13 packets cannot be intercepted.
2. Fix the bug that VPN Client cannot access the other side through IPsec when the device act as a PPTP/L2TP/OpenVPN Server and also establishes IPsec VPN with other devices.
3. Fix the bug that VPN client cannot proxy Internet access when VPN IP Pool and LAN IP are in the same network segment.
4. Fix the bug of CPU abnormality caused by enabling more VLAN Interface.
5. Fix the bug of high latency in ISP Load in Controller mode.
6. Fix the bug of frequent reconnection with Omada Controller.
7. Fix the bug that the VLAN configuration of IPTV is affected by the VLAN configuration of WAN port in Controller mode.
8. Fix the bug that the device does not support proxy internet access as Wireguard VPN client.
9. Fix the bug that Port Forwarding does not take effect under multiple WAN ports.
10. Fix the bug that new clients might lose Internet when bandwidth control is configured.
11. Fix the bug that Internet/DNS resolving might not work when using OpenVPN Connect App/Software to connect to the Router’s OpenVPN Server.
12. Fix the bug that the device as an OpenVPN client failed to make all the Internet traffic be routed through the VPN tunnel.
13. Fix the bug that remote IP error displayed in the OpenVPN Tunnel interface when the device connects successfully as an OpenVPN Client.
14. Fix the bug that after the device connects to the Server as a WireGuard VPN Client, the peer cannot access the device via WireGuard Interface IP.
15. Fix the bug of command injection vulnerability in the login page.
16. Fix the bug that the device may not start.
17. Fix the bug that when DOH/DOT used with DNS cache, modifying the TTL value of DNS cache will cause the client to be unable to access the Internet.
18. Fix the bug that port forwarding probabilistically did not work.
19. Fix the bug that when the device is used as an OpenVPN client, the VPN tunnel cannot be reconnected automatically when it times out.
Firmware Download
Before the Upgrade
(1) Please be sure you have read the Beta Test Agreement before upgrading the Beta firmware!
(2) You may follow the following guide to upgrade your Omada devices. How to Upgrade/Downgrade Omada Gateways
Firmware Download Link
ER605(UN) V2_2.1.5_Build 20231024 (Beta)
Notes:
(1) The above firmware is applied to ER605 V2/2.6.
(2) Your device’s configuration won’t be lost after upgrading.
Additional Information
All feedback is welcome, including letting us know about successful device upgrades.
If somehow you encounter an issue during or after the ER605 router upgrade, it's suggested to contact us with the following info:
- Omada Controller version
- Device Firmware version with Build number (previous and current)
If your ER605 router gets bricked during the firmware upgrade, you may follow the guide below to recover the firmware.
How to use the Emergency Mode to recover the firmware for Omada Gateways
Update Log
Nov. 20th, 2023:
Update the format and incorrect description in the release note.
Oct. 26th, 2023:
Post the ER605 V2 2.1.5_Build 20231024 (Beta) firmware for early access.
Recommended Threads
Get the Latest Firmware Releases for Omada Routers Here - Subscribe for Updates
Get the Latest Omada SDN Controller Releases Here - Subscribe for Updates
Experience the Latest Omada EAP Firmware - Trial Available Here, Subscribe for Updates!
Current Available Solutions to Omada Router Related Issues [Actively Updated, Post for Subscription]
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
![](https://static-community.tp-link.com/icon/d992b79227f44913ac92e1d95b8e517c.jpeg)
Hi @mhoam
Thanks for posting in our business forum.
mhoam wrote
Can you please confirm the default ACL rules applied to IPv6 packets in this beta release?
After updating to this firmware in order to implement security on my IPv6 connection, I am unable to establish an IPv6 connection to my ISP.
The IPv4 connection is working fine but the ISP is NOT seeing any DHCPv6 requests from my connection.
Thanks
What kind of ACL Direction?
What's your ACL config scheme? Do you enable IPv6 in your involved LANs?
Please specify your issue clearly.
Note that all outgoing traffic should be fine as your devices initiate the connection which is not blocked by the NAT or firewall by default. Now, the traffic from WAN(IPv6) cannot initiate the connection to the LAN. This is a security improvement.
I also need you to identify the traffic flow and symptoms. If you can use the Wireshark to capture, let me know which direction and your symptoms.
- Copy Link
- Report Inappropriate Content
Thanks for the prompt response.
I have NO ACL entries at all so far, for either IP4 or IP6
As you can see from the attached screen shot, the outbound DHCPv6 connection is timing out. The "Solicit/Discover" timeout occurs a number of times and then the DHCPv6 process itself times out.
My ISP is a small organisatuion and I have talked to their technical team who have confirmed that they can see my IP4 connection, which is working correctly, but they detect NO IPv6 packets at all.
I believe I have configured the IPv6 LAN settings correctly, using SLAAC/RDNSS to distribute the IPv6 addresses and DNS servers to the clients.
- Copy Link
- Report Inappropriate Content
![](https://static-community.tp-link.com/icon/d992b79227f44913ac92e1d95b8e517c.jpeg)
Hi @mhoam
Thanks for posting in our business forum.
mhoam wrote
Thanks for the prompt response.
I have NO ACL entries at all so far, for either IP4 or IP6
As you can see from the attached screen shot, the outbound DHCPv6 connection is timing out. The "Solicit/Discover" timeout occurs a number of times and then the DHCPv6 process itself times out.
My ISP is a small organisatuion and I have talked to their technical team who have confirmed that they can see my IP4 connection, which is working correctly, but they detect NO IPv6 packets at all.
I believe I have configured the IPv6 LAN settings correctly, using SLAAC/RDNSS to distribute the IPv6 addresses and DNS servers to the clients.
If you say so, how do you configure your WAN? Is your ISP requiring dual-stack? I am confused. Please share more info instead of a screenshot of the log. It seems the WAN fails to conenct to their IPv6 server.
- Copy Link
- Report Inappropriate Content
Thanks for the response, I have ruled out the possibility that any implicit IPv6 ACL rules are causing my failue to connect via IPv6. I created a wide open (anything in and anything out) IPv6 ACL rule. This rule did not affect my issue so I have started to look elsewhere.
As you say, it looks like the Router Advertisment and DHCP Solicit packets are not reaching the ISP's servers for some reason.
Regarding your last comment that not all Omada routers support dual-stack IP, I am assuming that my ER605 DOES support dual stack (IP4 and IP6) transmission at the same time.
- Copy Link
- Report Inappropriate Content
![](https://static-community.tp-link.com/icon/d992b79227f44913ac92e1d95b8e517c.jpeg)
Hi @mhoam
Thanks for posting in our business forum.
mhoam wrote
Thanks for the response, I have ruled out the possibility that any implicit IPv6 ACL rules are causing my failue to connect via IPv6. I created a wide open (anything in and anything out) IPv6 ACL rule. This rule did not affect my issue so I have started to look elsewhere.
As you say, it looks like the Router Advertisment and DHCP Solicit packets are not reaching the ISP's servers for some reason.
Regarding your last comment that not all Omada routers support dual-stack IP, I am assuming that my ER605 DOES support dual stack (IP4 and IP6) transmission at the same time.
Please reply with the backup of your ER605. I'll send it over to the test team for reproduction. I reported it to the test team and they say they don't experience any issues with the IPv6 dialing.
Ticket number: TKID231111189
- Copy Link
- Report Inappropriate Content
Further to my previous posts regarding my inability to obtain an IPv6 address, please note that I have now corrected my configuration and the IPv6 connection to my ISP is now working.
I failed to select the option to utilise the same PPoE session for IPv6 as used for IP4, hence the IPv6 connection did not work.
Please thank your developers for the interest but, sadly, it was user error :-(
Regards
mhoam
- Copy Link
- Report Inappropriate Content
![](https://static-community.tp-link.com/icon/d992b79227f44913ac92e1d95b8e517c.jpeg)
Hi @mhoam
Thanks for posting in our business forum.
mhoam wrote
In my original post, I asked about any default/implicit ACL rules for IPv6 in this beta release.
In a different thread, you replied to @cakemix with the comment :-
"Any incoming traffic is blocked by default settings when you upgrade to V2.2.2 or V2.1.5 beta. This was a security risk before so the dev patched this.
If you initiate an IPv6 connection, that should not be blocked at all."
So can you confirm that these releases (2.2.2 and 2.1.5) that implement an IPv6 Firewall via ACL rules also contain an implicit deny all for new incoming Ipv6 connections?
This sems to be the case as you can see from the attached screenshot from ipv6scanner dot com. This was taken before I created any IPv6 ACL rules.
This is a very sensible addition to the firmware, however can you ensure this important behaviour is documented in the Release Notes, in the latest version of the manual and in the in-built help behind the "?"
regards
mhoam
Supposedly, the firewall should block from WAN to LAN. Not from the LAN to WAN.
And this should be the way it is. And quite normal that this is blocked while the dev is working on implementing more IPv6-related stuff.
I am not able to confirm if this is achieved by an implicit rule in the ACL. But I can tell you this should be the way it is as the test team told me this is a security patch.
So I am confused if there are complaints about this. When there was no firewall, people were complaining IPv6 was dangerous. While we add this to secure the network, it becomes another complaint.
I am not sure why the dev did not add it to the note. I am not writing the release note because I am unaware of what the dev updates or not. But will report your concern to them.
Update:
Your OP is not the same thing. You are talking about the WAN to the ISP. This should be not blocked. If this is blocked, how do you even start a connection?
So, it is not about the ACL. I've sent it to the dev and waiting for a reply.
Test team told me that they using the same firmware in the lab environment and did not see any error like that. IPv6 dialing out works fine. You seem to be the only person now who runs into this error and WAN issue. I am also waiting for others to share their experience with this beta.
- Copy Link
- Report Inappropriate Content
Thanks for the update,
Firstly, please let your dev team know that I have solved my IPv6 connection issue. It was a user error :-( My ISP uses PPoE for both IP4 and IP6 and when configuring the IP6 WAN settings I failed to choose the option to utilise the same PPoE for IP6 as IP4. My apologies for the mistaken post!
Secondly, to be clear, I believe the implicit "deny all" for new incoming IP6 connections is a correct addition to the firmware.
However, this undocumented feature has caused confusion simply because it was not mentioned in the Release Notes, alongside the addition of ACL rules for IPv6.
Thank you for referring the lack of documentation on this feature back to your dev team. Hopefully when the next version (2.2.3?) is released, this useful feature will be fully explained. It should be mentioned in the Release Notes, the revised manual and the on-line Help text included within the formware.
Your assistance and patience is greatly appreciated.
Regards
mhoam
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
I found a bug: When adding OpenVPN client, the remote server field only accepts IP, not domain name.
- Copy Link
- Report Inappropriate Content
![](https://static-community.tp-link.com/icon/d992b79227f44913ac92e1d95b8e517c.jpeg)
Information
Helpful: 0
Views: 12399
Replies: 59
Voters 0
No one has voted for it yet.