Add support for multi-hub mode of AltaConnect, with automatic BGP configuration
Improve WireGuard stability in environments with multiple WANs
Improve support for hundreds of VLANs
Update tailscale to 1.102.2
This update is being rolled out now. You can manually initiate the upgrade if you’d like, or it will automatically update overnight (if auto-updates are enabled). The complete, up-to-date changelog is available here:
If you have questions, feedback, or run into any issues, feel free to reply here or start a new topic. Including configuration details or relevant logs where possible helps us troubleshoot and respond more quickly.
after Route10 firmware 1.5f the port forwarding is not working and blocks voip registration /checking the open ports looks that port 53 is open even there is no port forwarded to any DNS
we need a way to go back. backup and restore doesn’t restore the firmware.
After factory reset and moving the router to another site and reconfigured the router is working.
Unfortunately it did / after checking with the ISP to make sure is not a problem there I replaced the router with an old draytek and everything worked temporary so that show me the problem with Alta Router I reset the router to factory default several times but it picked up the settings from the controller / I removed the router from the site , reset again and I reconfigured the router on the other site and is working now.
Is the site that had the Route10 originally still around? If so, you should still be able to access the port forward and any other configuration that would’ve applied to the Route10.
This is actually a really good data point, if port forwarding works when it’s setup on a different site, that’s an excellent indicator that there is/was something on the original site that caused the breakage.
I think this caused the issue. Before 1.5f, all LAN ports use the hardware fast lane. The VLAN/routing changes in 1.5f stops LAN Port 4 from registering with the hardware accelerator. It’s a kernel driver bug and needs another firmware update. It can’t be fixed by a script.
I suggest you don’t set auto update in your Route10 if you want to avoid issues like this.
We sincerely apologize for any inconvenience that you may have experienced as part of this upgrade. However, we are unable to reproduce anything similar to what you are seeing, based on a very similar configuration to yours. If you’d like us to investigate why this is happening, can you please invite us to your site so we can see what is different about your setup?
@sandu apologies for the delay, there was a lot to sift through as it seems there were a lot of changes made after the upgrade in a troubleshooting effort it appears, but the break of the port forwards actually kicked off 28 hours before the firmware update. And I also must apologize for the formatting, I intentionally kept it raw so you could copy/paste for log searching if so desired.
2026-08-20T16:59:44 edit nat name=‘443’ [ACCOUNT EMAIL REDACTED FOR PRIVACY] old = {“destination”: {“port”: “443”}, “translation”: {“address”: “192.168.0.5”}} new = {“destination”: {}, “translation”: {“address”: “192.168.0.8”}}
You edited the 443 rule and deleted destination.port as well as changed the translation address in the same edit (and reverted just that part at 17:03:21) — but the port was never restored. That leaves:
{“description”: “443”, “destination”: {“address”: “[PUBLIC IP REDACTED FOR PRIVACY]”}, ← no port. any port.
“translation”: {“address”: “192.168.0.5”, “port”: “443”},
“protocol”: [“tcp”,“udp”], “type”: “destination”, “zoneIn”: “wan”, “zoneOut”: “lan”}
Every port on [PUBLIC IP REDACTED FOR PRIVACY], TCP and UDP, DNAT’d to 192.168.0.5:443. A catch-all that swallows every other forward on that address.
The only unknown is why it took 28 hours to find the break. The Route10 conntrack may have played a role, but for that long? Highly unlikely.