Cloud/remote management possible?

I am using two different methods to access my router:

  1. OpenVPN
    2 FWknop with ssh tunneling

Both are working flawlessly and are pretty straight forward to setup (naturally you will also need to know the ip so you will need dynamic dns service such as no-ip/duckdns/etc) .

These methods don't work when the WAN port on the router you want to manage is not on a public IP. What is necessary here is some management engine on the router needs to reach out and establish a connection to a management server on the internet. You then can reach back through that connection to do things in the router.

Just completed custom firmware for a perspective, large fleet of openwrt devices (>1000), used in IoT. As a commercial project, also including certain aspects of "Remote Management", i.e. remote (re-)configuration, FW-upgrade OTA, certain system statistics. I think, all the open source tools are available, i.e. collectd for simple statistics, or zabbix, for much more covenient usage. And can be tailored to the usage case. My client even refused to use the org management system from the openwrt-compatible device, because not being reliable enough. Actually using just one openwrt device type, but this will change. Having different custom openwrt-firmware images/routers to manage this way, is not a big deal, in case still within similar capabilities. Of course, not so flexible like the UBT stuff, to be available for a vast variety of devices, but that might not be required, anyway.
OpenWISP for hotspot systems seems to be far too oversized, for my taste. I prefere aVPN-based, custom system, which can drop a lot of security features, required otherwise. I.e. via VPN, no problem to use simple mqtt or even http for management.
A general remark, anyway: I think, it is a bit far fetched, for a commercial application, like in your case, to ask for a complete open-source solution, ready to use, free of charge :slight_smile:

1 Like

You mention zabbix but something like I'm discussing here is far fetched? Does not compute, zabbix is amazing and I can't believe it's available free. On the other hand we pay for the management systems I mentioned in OP, the ones that do charge anyway as UISP is free. CT-net doesn't sound like our interests are aligned, for example we don't want WiFi on these so all that's lost on us.

Mostly I'm just feeling out what the potential directions we could go here, this thread has been educational.

For commercial, large scale installs of zabbix you will most certainly pay some bucks, for possible support, at least. Like for an insurance policy :slight_smile: Price of UISP is somewhere hidden in the cost of UBTs hardware, I suspect. Or does it also work with non-UBT stuff ?

UISP only works with the Ubiquiti equipment, and specifically only certain parts of their overall product lineup (EdgeMax and UISP, possibly a few other bits of WISP related kit, but only from UI). The cost of the USIP environment (from a development standpoint) is built into the hardware that runs on the platform, but the hardware is relatively inexpensive compared to some other vendors because UI doesn't provide much support (almost all support is volunteer/community based). Typically the stuff from other vendors that is more expensive (hardware) and/or involves paid-licensed software includes some level of official support from company reps.

Just to be clear, yes, I know.

As would the VPN, you're simply adding another "Layer of Abstraction" in your mind for connecting to all the devices. Apologies if you were only seeking a software management solution to solve the problem.

(some of the VPNs could be scripted...BTW :wink: )

1 Like

There's also nebula package, which technically can be classified as "any other VPN", but which should work behind double NAT.

I've been struggling to make it netifd-compliant tho, so for now, you can't add a nebula interface to the dropbear settings.

But it is a reasonable, simple option, combined with 'fail2ban', for example.

1 Like

That's just part of the problem as LuCI and uhttpd may not be tolerant against malicious HTTP requests.
Here's an example of the same class of vulnerability for httpd:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2021-41773

Since OpenWISP has been mentioned, I wanted to share a few screenshots of the upcoming version, which will be a major milestone of the project and satisfies many of the needs which are mentioned in this post.






A VPN is not strictly required for controlling configuration but it's required if you need to use the Firmware Upgrader and Monitoring modules, OpenWISP supports OpenVPN and can automate its provisioning (including the generation of certificates). Support for Wireguard/VXLAN has also just been recently added thanks to several sponsors which are using OpenWISP and contributing to its development and it will be included in the release (at the moment this feature is available in the 1.0.x branch of OpenWISP Controller on github.

The upcoming version of OpenWISP can be already installed following the instructions provided at the following link: https://github.com/openwisp/ansible-openwisp2/tree/dev#deploying-the-upcoming-release-of-openwisp (the URL to the instructions may change in the future, if in doubt ask in the OpenWISP support channels).

For any other question regarding OpenWISP there's a dedicated mailing list or chat.

1 Like

That is one heck of a sales pitch!

I do want to manage firmware and keep things up to date on field installed OpenWRT routers. If I let OpenWISP manage OpenVPN and certs will it also export useable config files to drop in the OpenWRT routers to facilitate their connection to OpenWISP?

Yes, that's the point, OpenWISP automates the provisioning of tunnels because doing it manually is error prone and time consuming.

Instructions for OpenVPN: https://openwisp.io/docs/user/vpn.html#creating-vpn-server
Instructions for Wireguard (but need the 1.0.x branch of openwisp-controller mentioned above): https://github.com/openwisp/openwisp-controller/tree/1.0.x#how-to-setup-wireguard-tunnels
Instructions for VXLAN over Wireguard (but need the 1.0.x branch of openwisp-controller mentioned above): https://github.com/openwisp/openwisp-controller/tree/1.0.x#how-to-setup-vxlan-over-wireguard-tunnels

See also the concept of Configuration Template which is quite important to understand how a number of devices can be updated easily by changing one template.

Most of the work is involves preparing the initial configurations, but once it's done, it allows to provision new devices very easily, even someone with IT experience who does not have Linux/OpenWrt experience can provision new devices by following a set of instructions.

PS: for the reasons explained above, OpenWISP makes sense only when the number of devices involved is high and hence all the time which has to be spent in setting up the system pays off in time saved later. I think for anything below 15 devices may be overkill.

Best luck with the solution you will choose!

1 Like

I don't have a commercial fleet or anything, but I'm running RPi4 devices as routers using the standard debian RPi OS and using cfengine to automate administration. Add a wireguard tunnel to a central server, and IPv6 ULAs to connect to netdata and you get a lot of flexibility, a lot of visibility, and a huge amount of CPU grunt.

Check out also

What is the current status of OpenWisp? Can somebody share latest screenshots? Is there now a list of clients that are currently connected to the Wifi like in Omada Controller?

The official videos https://www.youtube.com/channel/UCOeMZ4FGmmhwUjXUjdCgQQA/videos are about 4 years old and hopefully there is now a lot more information as @nemesis showed in the screenshots for the upcoming version.

Yes, OpenWISP Monitoring provides a list of clients.
The current status is that it's not stupid-easy to install and setup yet but hopefully with the next releases this should become easier.

Is there already some release date planned?

Currently OpenWISP seems to need a whole server as configuration, whereas Omada Controller can be installed into a single directory and has almost all required libraries and executables included. This makes it possible to run Omada Controller on Raspberry Pi out of a single directory together with other services, so no dedicated system needed for Omada Controller, see https://github.com/JsBergbau/Omada-SDN-Controller-mongodb-Raspberry-PI

I have the impression OpenWisp is intended for controlling OpenWRT on a lot of different sites and places which seems to introduce a lot of complexity which isn't needed for home systems with a few OpenWRT APs.

Is there also planed something regarding running in a single directory and targeting also OpenWRT installations with a few APs?

By the end of the first quarter 2022 I am aiming to complete the new release of OpenWISP.

The later releases will most likely bring improvements to make it easy to install and use.

And yes, OpenWISP is not designed for home users, nor it receives any kind of financial support from these kind of users, while it receives most of its support from business users which use it for thousands of devices scattered around multiple cities, so that's why the focus is that one. Hopefully with more people and organizations joining we'll be able to improve it for home users too.

3 Likes

Update: OpenWISP 22.05 is out.

2 Likes