I eventually decided to go through the effort of taking control of my
Internets: I purchased a brand new router (APU2E0 from Teklager),
and went through the exploration of OpenWRT.
# tio /dev/ttyUSB0
[tio 21:56:56] tio v1.32
[tio 21:56:56] Press ctrl-t q to quit
[tio 21:56:56] Connected
BusyBox v1.30.1 () built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 19.07.6, r11278-8055e38794
-----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
tl;dr - Mostly good things, little annoyances here and there, and twice the network throughput as result. 10/10 would buy again.
And now for the longer version:
Good things!
1. The OpenWRT system is lean.
I appreciate minimalism in general, but especially on a piece of equipment that is meant to be exposed to the Open Internet.
2. The web configuration is completely optional
As a command line person I'm very efficient on textual terminals. Also I'm not very fond of browsers in general. I find it quite annoying when advanced features are only available through some graphical/web configuration facility, while the corresponding operation from the command line is full of hindrances. With OpenWrt it is fortunately not the case.
The LuCI web interface is built on the top of the UCI configuration system, which is command-line friendly.
3. Excellent documentation
The User Guide had an answer for each of my questions so far. This is just great: kudos for the maintainers!
Bad things, but not so bad.
Nothing bad so far, to be honest! I'm definitely happy with my purchase. There are some nitpicks that I should mention.
1. Web configuration
Before attaching the router to the broadband socket, I decided to do a quick verification on the device. For instance: what services are exposed? Is there something I can turn off?
To begin with, I don't see the point of having the web-based
configuration server bound on [::]. Sure, the firewall prevents it from
being reached via WAN, but reducing the scope of things is always good:
multi-layered security for the win!
Changing the binding address to [::1] requires a trivial modification to
/etc/config/uhttpd. The idea was to have it reachable via ssh port
forwarding (ssh -L), but later on I simply decided that service uhttpd
disable, is even more effective. The web configuration turned out to
be completely optional, after all.
2. The firewall is iptables
Which sounds to me quite old, especially after the time and skill points I spent learning nft.
I find nft to be much more usable than iptables, as one might expect from a more modern tool. It is however worth mentioning that:
The intended firewall configuration tool is UCI, which acts as a front-end to iptables.
Installing nftables is a viable option, although only practical for command line users (so it's fine in my case).
I see no obvious drawback in using iptables, for the moment: it just works. On the long run it might be interesting to migrate to nft, although it would be more of an exercise, than of an actual need.
3. Deprecation?
Where's ss(8) gone? The venerable netstat(8) is available, but it is deprecated under GNU/Linux. At least iproute2 is avaiable out of the box, together with the ifconfig(8) (also deprecated).
4. What about ed25519?
Speaking of security, I'm not a big fan of remote password-based authentication. As for any other system I administrate, one of the first things I did is to replace it with key-based authentication.
That's how I found that the Dropbear binary shipped with OpenWrt is not compiled with ed25519 support. Come on! $CurrentYearArgument! The proposed solution is to recompile Dropbear.
On the top of it I wasn't able to bind the ssh server on the internal interfaces, as I initially did with the web configuration.
I found the overall Dropbear experience somewhat annoying. It comes with no surprise that some users allegedly decided to drop the bear in favour of the regular sshd.
Half good, half bad:
UCI is well documented and command-line friendly, but the covered scope is too broad. It reminds me of a certain god-like configuration tool I've been using at $dayjob.
From the system design perspective, I think it would be better if the configuration of each daemon was independent from any other. On the other hand that there's something reensuring about having a tool that orchestrates things properly. I find this valuable from the security standpoint, as it is way too easy to forget about some pesky detail.
I like the UCI configuration for how it is consistent in the syntax, and for how it is fairly easy to grasp. But on the other hand this prevents the user (me) from trivially learning how to operate the more general tools the system is constructed upon. Of course I can dig deeper.
In conclusion
In conclusion (as by tl;dr), the upgrade turned out to be a great choice.
I can now exercise a complete control over my network, with no obscure (or even backdoor-ish!) services running on my router. Besides, my throughput literally doubled, hitting the maximum allowed by my ISP.
Yep, the old router was the bottleneck.