when the public static IP address is changed by ISP is no way you can change it on the router without factory reset and configuration wizard. On the factory reset you loose all the VPN settings.
Export /import for VPNs should be an option anyway.
You can change the static IP address and other WAN related settings after the devices has been configured by going to Settings, then Networks->WANs.
I think in this case @sandu might be referring to a scenario where the IP has been changed by the ISP before they have a chance to change the IP in the controller WAN settings. Now, I would probably argue that sort of IP change should be planned out ahead of time so it can be changed in the controller before the ISP switches the IP, but I don’t think that’s the scenario being discussed.
This is a bit off this topic, but @Alta-Jeff , are VPN settings tied to the router? I haven’t had the need to replace or reset a Route10 that has a VPN setup, so I don’t know what to expect there. Thanks!
1 Like
the IP can be changed in the controller but there is no way the router will connect to the controller with the old IP since is no active because the modem was provisioned with new IP. So the factory reset and setup wizard is the only option but all the VPNs settings are lost, without any backup.
Seems like a corner case, but if you are savvy with ssh, you can edit the /etc/config/network file manually, update the IP address there, and run /etc/init.d/network reload, and be back online without a reset.
VPN settings are tied to a specific Route10, yes. The settings will not be deleted unless you actually delete the device from the site. They will even persist through a factory reset of the device itself, so long as you do not delete it from the site. If you need help migrating to a different Route10, support can help migrate the settings, or if you use a local controller, the settings can be copied over in the raw database (services->vpn field).
What if the user its not tech savvy? I’m sorry, but it’s a legitimate question. This is another instance where one would have to literally resort to a full restore. Not acceptable.
The crucial note was that the settings are stored in the controller, and the necessary settings (including VPN) will be reprovisioned to the Route10 after clicking Setup again. It doesn’t require any additional technical expertise, unless you are explicitly trying to avoid the brief downtime of a factory reset.
what is the username and password with the permission to login and change the network?
Factory reset should never be considered a quick fix. That should be a last resort with support on the phone from a serious problem.
1 Like
You’ll need to setup SSH according to this article first.
https://help.alta.inc/hc/en-us/articles/26753020799131-How-To-Use-SSH-Keys-For-Management
last time I did factory reset VPN settings were not reprovisioned.
Then it’s an opportunity to learn a lifelong skill that is guaranteed to be useful in the future. SSH isn’t going anywhere. This is a very small corner case, and we do plan to have more options available in a local UI at some point, but security and usability for the most common use cases is our focus right now as we grow.
Then you must have deleted the device from the site. There is no other way for the settings to be deleted.
this is a big help.
I have generated the ssh key with mobaxterm added the public key to the router and able to access the router with ssh. Thank you
3 Likes
Eeek, that’s a bit of a condescending response to a reasonable question.
“but security and usability for the most common use cases is our focus right now as we grow.” We frequently hear things like this quoted, but end up with AltaBoost / XNET / Surveys on site types, etc. which, so far as I can see, have never been asked for, yet other (useful) feature requests get ignored.
As for the focus on security, I think publishing of vulnerabilities and security updates has been requested numerous times in the forums too, however all I have seen acknowledging vulnerabilties is this post CVE vulnerabilities router10 and controller - #6 by Alta-Jeff from May, in which the one security vulnerability that was accepted …
Was going to be “disabling this functionality at low priority for our next firmware release.”
There have been 3 route10 releases since then, none of which mentioned that…
1 Like
Personally, I don’t have that problem, but you’re marginalizing a large customer base of local users and potential customers out there. You’re absolutely right, SSH isn’t going anywhere, but what are users met with after successfully logging into a Route10? A BusyBox shell/syntax. What are users met with after logging into an Alta Control? Ubuntu 22.04.4 LTS GNU/Linux 5.4.213.
Where are the list of suggested/common commands specific to this platform, and of course each device to help guide the “non tech-savvy” individuals?" Let me guess, "go learn Linux if you want to use our platform and enable additional features?”
Additionally, the QR code provided in the quick set up lists SSH as an “option”, nothing of mandatory requirements in the likelihood things go astray or end users happened to be bricked out of their devices. Users are expecting both the device and UI to function and provide similar features that are generally available in the market today. They should not have to worry that when something goes wrong, they need to download putty at the minimum and start tinkering within the syntax to correct anomalies.
By the way, the quick start guide for Alta’s Control on your website points to the S8 documentation download.
1 Like
Not sure where I was condescending, there. I certainly am careful to not offend anyone here. There are plenty of feature requests that have been implemented as a direct result from forum feedback, but I’m sure you understand that it’s not possible for all to be fulfilled immediately.
We did disable ICMP Timestamp replies on the Route10 firmware in 1.4g, but did not deem it a high enough security risk to mention in release notes. CVSS score of 2.1 is very low severity, by definition.
Actually there are many of our users that highly appreciate full Linux shell access, which is rare amongst Enterprise network vendors. It’s a two-edged sword. If you wield it appropriately, it can be a powerful tool, but of course there is a learning curve just as with all technology.
The same goes for our products in general, and any piece of technology, really. There is always an associated learning curve and it’s especially steep for some corner cases like this. In our experience, static IPs from ISPs generally never change, so it’s not a use case that we’ve optimized for. It’s also something you can potentially work-around by using a local controller, instead.
And thank you for pointing out the incorrect Control QSG link!
Clearly there’s a disconnect here, and for that I apologize. What I’m trying to articulate is that the average user is going to be caught off guard with your platform. Again, you would need an active ISP connection at all times for the platform settings GUI to function, even at the local level. This was already mentioned on another post.
None of this is mentioned, let alone cautioned on your official offering page. The way I read this is that from a management perspective, we would have access to our network and devices at all time no matter the circumstance since we’re locally managed. The “On-The-Fly Changes and Scanning” is clearly misleading to the consumer reading it if there is a severed connection. I know this has been brought up countless of times, but again, how are end users supposed to deploy this platform at home or businesses that have yet to establish an ISP connection?
As a local Alta Control user, if I walk over to my Route10 at this very moment and physically disconnect my ISP connection from it’s respective WAN interface, we break DDNS and lose access to the local controller UI while tethered to the LAN. What is the point of local management control with a claimed user experience if this very issue negates that feature?
So instead, the only solution for those with an Alta Control is to login via SSH to determine what the issues or symptoms are? You’re expecting the normal consumer to know this before committing to your platform, even at the local level? The normal non-tech-savvy user should still have some form of access, even at at the local level to confirm via GUI that there’s a severed ISP connection.
This also now begs the question of which group your tailoring to. Is it “Enterprise” only moving forward? The GUI seems to be tailored for the very basic end user, so which is it?
Interesting.. As a potential new Alta Labs gear user, I would expect that a local controller would give me access to my network no matter what state the WAN is in. Don’t see the value / logic of a local controller, if I still need an SSH connection to attempt to diagnose an issue. And, for all of the non-openwrt types, where’s the list of cli commands to reference, when attempting to troubleshoot / gather information? I’m not new to CLI. I’ve used CLI on Cisco, Juniper, and Edgerouter.