OpenWrt is commonly used to breathe new (or better) life into consumer routers, but you can also run it on any x86 machine. I run it on a small, passively-cooled i5 machine* virtualized in Proxmox alongside Home Assistant. I originally ran OPNSense, then VyOS, but eventually went back to OpenWRT since it does everything I want/need with a simple interface.
Great comment, and same. Running it on Proxmox also enables running the router in a high-availability fashion quite easily too.. which is pretty neat.
I was running OpenWRT on my Xiaomi AX9000 (based on master but also IPQ807 specific forks), but everything OpenWRT is software-based so 1/ the AX9000's acceleration chips are idle & performance is quite limited (unless using one of the crazy experimental NSS builds where mostly everything is broken) 2/ the integration with the onboard switch itself is far from adequate, e.g. VLANS+batman-adv are quite broken - very few configurations yield a partially working network (e.g. randomly dropping ARPs).. and don't count of LACP to work even though it can be configured. That's forgiving the fact that we also have to manually patch the BDF files on OpenWRT for the AX9000 if you want the radios to be connectable, as OpenWRT do not want to ship with the correct BDFs for some vague legal liability reasons.
Used VyOS in Proxmox for a while too, but at the end of the day, the firewall boilerplate is quite huge (and can't easily be edited on the go in the house as necessary), tailscale is not natively supported, etc. Relatively sad to let go of IaaC and committing the configuration though, but somewhat manageable with snapshots.
Running OpenWRT directly on Proxmox on your home server is tempting but the risk to mess up from a security point of view (accidentally or not) is high.
After a quick look on OpenWRT wiki there is unfortunately not much information on what to be attentive to when running in a vm.
Hey, I do this as well with a Qotom mini PC and it is utterly fantastic. Home Assistant runs in a VM and the OpenWRT part handles WireGuard for remote access.
One problem that I have with it is that I'm running qemu-system-x86_64 in an init script which creates a tap0 interface and adds it to the br-lan interface. If I ever restart the networking these interfaces are removed from the bridge. I briefly looked for some sort of hook to run on network restart but didn't find one. I'd love to be able to run brctl after a network restart to add the interfaces back into the bridge.
I've run virtualized network applications before, and have always had trouble with the container mapping addresses into a new private IP subnet. Is this able to be worked around?
It's a confusing photo; those antennae are for that machine as a client, not an access point. I use it only as a router (i.e., it routes my LAN to the internet over gigabit fiber), and I use a separate access point for wifi.
The antennae are useless for my use case, but they came with it and if I removed them I'd just have to find somewhere else to store them...
Intel WiFi chips work as acess points only in the 2.4 GHz band. You can add an "Alfa Network AWUS036ACM" USB WiFi adapter as something that works in the 5 GHz band, but please don't expect more than 400 Mbps from it.
They are not really limited to 2.4 GHz band. All recent Intel chips have a stupid mechanism built into the firmware: instead of getting the country code from the OS, as everything else does, and then follow the local spectrum regulations, the chip tries to discover it automatically. Tries, because it's half-broken and most of the times it fails and locks the radio to just a few 2.4 GHz channels with ridicolous power limitation (the LCD of all countries laws).
It's supposed to perform a scan and then set the country that is advertised by nearby APs. The obvious problem is that it won't work if there are no other wifi networks, or if one is trasmitting the wrong country. Also you have to manually run the scan, before the radio is unlocked, but virtually all AP softwares don't know how to handle this properly and get stuck in a loop.
In any case, they're terrible in AP mode even after unlocking the 5GHz band, because are locked to a single VAP and are not dual-band (I mean, not at same time).
oh, one other thing.. upgrading openwrt on x86 isn't as nice as other devices with a squashfs root. I can upgrade packages, but I don't think that I can really upgrade it without re-installing everything.
You can actually if you didn't expand your partition and keep the default layout. Use the firmware builder to build a customized image with your needed packages.
Edit: ah I didn't see that you run openwrt on baremetal...
Hi apologies for any confusion. What i meant to say is that OpenWrt can be run on the Raspberry Pi. I did this because I had a Raspberry Pi laying around and did not want to invest in additional hardware just for experimenting with OpenWrt within my internal network. You can also run OpenWrt in a virtual environment like QEMU -- this is useful if you're aiming to connect multiple VMs to OpenWrt, effectively setting up a virtual network with OpenWrt at its core. Please see links below for more info:
Caution advised for people jumping early, the Release Candidate 4 was released only ~10 days ago and didn't have the usual long testing period (usually month). More, the devs introduced major refactors late in the release cycle.
RC4 changelog includes bump to major components, most notably: hostapd, ucode, ubus, netifd.
Is that common in OpenWrt to introduce more changes between RC versions? Usually you want to stabilize everything as much as possible until the final version been released, but seems they continue to push out RCs as standard updates...
Unfortunately, yes. On top of that, they keep adding new devices in RC, keep bumping the kernel version (minor), introducing new code base (such as the new refactor on hostapd/ucode/netifd) and sometime cherry picking commits from master which I would have not chosen (not just bug fixes but features).
Don't get me wrong though, I very happy that such project exists but OpenWrt could be more stable and reliable with a better workflow. Anytime you flash a new version, you have this small fear of bricking your device (especially the exotic ones as Openwrt mainly relies on external testers).
OpenWrt has transitioned its default cryptographic library from wolfssl to mbedtls. This shift brings several changes and implications:
* Users should be aware that mbedtls 2.28 no longer supports TLS 1.3.
Am I reading this correctly? They switched to a different tls library that doesn't support TLS 1.3?
Mandatory mention of the excellent adblocking plugins, for pi-hole-like DNS-based blocking of { ads, tracking, malicious sites, analytics, etc }, but built-in your router: https://openwrt.org/docs/guide-user/services/ad-blocking .
Featureful (or simple if you want simple and go for the simple plugin), plenty of blocklists to pick from, auto-updates, all the things! OpenWrt is awesome.
OpenWRT is great for taking bargain routers on eBay (which can be had for as little as £5 and yet have fast CPUs and support modern WiFi radios) and making them into proper homelab gateways with VPN, VLANs, DNS proxies etc. I would often do this for friends who wanted VPN access to their home network but didn't want to fork out for a router that would offer this out of the box. I would find it amusing when an ISP's stock firmware would turn out to just be an OpenWRT skin.
My goto for a while was the BT HomeHub 5A (not B variant). Just checked and these are available for £10 on eBay if you're based in the UK. I'm sure there are bargains to be had all over the world. The place to start is to look at OpenWRT's supported devices page and look for ISP branded models. These are often flogged on eBay super cheap when people move because they're basically scrap to most people. I'm sure even more just go in the bin (sadly).
I use an old Asus RT-N56U for great (Gigabit) switching performance. Wifi is only N, and you have to be careful, there are two HW revisions, that are indistinguishable from the outside. An alternative could be different TP Link devices, but I never tested these.
For more modern purposes I use a Linksys WRT32X with divested[1] image, but you could also go for the 1900 or even 1200, depending on your needs...
According to the openwrt wiki the WRT3200 and WRT32X have identical hardware [1][2]
I tried several patches but nothing helped. As I understand it it's the closed source abandoned (?) WiFi firmware that's the issue. I suspect it can't handle interference , which which is why it works great for some and horrible for others.
I see there are new commits on the driver repository [3], so maybe I'll try again but I don't have my hopes up...
While the Cudy is very cheap (40 Bucks here in Germany), I still like the Banana Pi BPI-R3 most. But until it gets really necessary, I'll stick with my 32X... for me it does work but I won't recommend it any more without that note.
I have a 32X, as CorrectHorseBat said they're the same device. WiFi is indeed unreliable. I later switched to a Belkin AX3200 (RT3200) which works much better. That Belkin is also sold as a near-identical Linksys model (the color differs and only one of them has LEDs for ethernet LAN ports).
I build my own with a Raspberry Pi CM4 I had lying around plus a dfrobot router carrier board [1] (though I suppose the reRouter [2] by Seeed Studio could also suffice). Not sure why I picked that one. Maybe I read a review on how it could saturate 1 gbit but don't pin me on it please. The reRouter could even have a better case.
I'd prefer to run OPNsense on it if I could, but it isn't available for ARM64 as of now.
I've had good results with both D-Link routers (DIR-615??, DIR-842) I've owned through the years - the DIR-615 was bought used, it lasted 8 years of constant service, was only replaced because I needed 802.11n and a better WAN port. It still works when I plug it in! Its replacement DIR-842 has been chugging happily since 2021 and was also purchased second-hand.
The biggest bargain routers I've used all come from Xiaomi, but you need to check their pages on the OpenWRT wiki very carefully, because there are very similar models with very different compatibility stories.
Flashing them is always fun, because their stock GUI is in Chinese and you do this by looking at it through one of the camera translator apps on your phone.
Check out the GL.iNet routers. They come with openwrt out of the box. Yes, it is often an older build, but the UI and services they add on top are excellent, and it has never been an issue for me in practice. Most can be upgraded to stock openwrt still.
Setting up a Wireguard VPN is way easier. They seem to backport anything that matters. They are sometimes marketed as travel routers, but they work fine as your main one. They just don’t take up a lot of space.
If you want better than that? You should use a raspberry pi 4/5, with an extra gigabit USB adapter, as your router, and setup some routers as “dumb APs”. That way you can upgrade your wireless without messing with your core network and services.
Also RP4/5 are both fast enough to software route at gigabit speeds with advanced QoS management. My latencies don’t change if my connection is loaded or not.
I recently became an openwrt user (new Dynalink $79 woot) and am happy, but it isn’t all sunshine and roses as folks tend to rave about it here.
First, the distribution is bare bones to the extreme by default. Like Linux in the 90s bones. Understood, some old routers are tiny, but it makes a RasbPi feel positively ergonomic. Lucky you can install packages pretty easily, like htop etc. Have to install the web gui of course.
Could be wrong but don’t think you can upgrade with a command like Debian. Have to save config and reflash again. Hope not.
Speaking of which, there’s all these config files like nothing you’ve ever seen before. Learning curve steep. Have to bond physical interfaces with APs manually. Odd defaults like wifi clients not allowed to talk to each other. Better get used to hunting online for settings. Fixing that required changing an obscure multicast setting, buried in the gui, not isolation. This is a home not a cafe. :-D
The wiki for my device was hard to follow, basically cut and paste from multiple forum posts with a few critical tidbits missing for a new user. I hunted them down.
I kept very good notes and intended to improve the wiki, but guess what? not editable. Oh and folks who ask questions told to read the wiki fully. I did read it twice at least and have a lot of other experience so trudged through. Had to make an account on one server and ask for account on wiki. Was ignored, got no notifications at least. Post expired.
Now it’s been two weeks… have forgotten a lot and wiki page still shiti. Not how FLOSS is supposed to work. So yeah, happy with it in general but lots of room for improvement.
You can enable ssh in the gui and then login to install packages (using opkg) or edit config files or whatever. opkg is a lot like dpkg but a bit more limited. Unfortunately the login shell is busybox so you're fairly limited in what's available.
All of this is pretty understandable since openwrt is targeted to really low specs . 4MB storage/32MB RAM was the target until 2022. It's now 16MB storage, 128MB RAM which is still pretty low.
One thing I don't see anyone mentioning here is that OpenWRT allows you to configure your router as code via config files in /etc/.
If you straddle the worlds of preferring a "normal" router to a custom built box but also want to keep your configuration history in git I think OpenWRT may be the best option.
This is one of my favorite features. Wasn't able to figure out how to set up my somewhat complicated guest + iot wifi vlan setup through the web interface, but it was pretty straightforward through the config files. And now I have it backed up in case I ever need to set it up again from scratch.
Just updated all my devices, the stable support to the Wifi 6E is a great thing. OpenWrt is the best firware with the best community and support for home network devices!
What devices do you currently run OpenWRT on? I’d like to have a good and secure home network, currently running a pair of Ubiquity UDRs, and sometimes I wish I could have more control.
Also note, that there is DD-WRT, which is a similar, but different project. Some routers might be supported by one, but not the other. I have a Netgear Nighthawk, for example, which is not supported by OpenWRT, but by DD-WRT.
I gave up on DD-WRT years ago when they started obfuscating parts of the WebUI to not have to comply with FOSS requirements (from foggy memory), moved to OpenWRT and never looked back. Trying to turn into a proprietary product something that was built by the community? Yeah no.
I once asked the main dev how to generate images for Buffalo routers, since I wanted to build from source. That particular component was not available and only he could build an image capable of being uploaded through the stock admin interface.
It wasn't the end of the world since a standard openwrt image could be loaded over tftp, but it was annoying that it was impossible to recreate the images available for download.
My USG-3P died a few months ago, so I dusted off my old Asus router and made an unplanned switch to OpenWrt. This was meant to be a temporary solution until I could get a new UniFi device, but after setting it up and getting it working the way I want I'm more than happy to make this temporary solution into a permanent one.
My Asus router, when using OpenWrt, can't keep up with my internet connection, so I'm putting (admittedly minimal) effort into finding a suitable upgrade with the intent to keep the Asus as a backup.
I've also looked at installing OpenWRT on my USG, but only the snapshot version is available and the process is fairly involved[0] so I haven't really explored this.
At this point though, I'm not likely to go back to Unifi for routing. I needed to use the config.gateway.json (I think) workaround to add some DNS config[1] to my USG, whereas with OpenWrt I can do this entirely in the UI.
Just pick up the nanopi r4s or r6s. Fairly small, but with nice specs and support in openwrt. The r6s isn't supported by openwrt 23.05 but you can get the friendly elec fork or get a community rebuild of openwrt with a later kernel that supports it. You'll get a router that can work at line speed (1Gb or 2.5Gb) even if you use features like SQM or wireguard.
Try a raspberry pi 4 with an extra gigabit USB adapter. Just make sure you use the custom firmware builder to include the USB networking packages. Easily fast enough for gigabit speed advanced QoS handling. Just don’t use it for its Wi-Fi.
I'm still on 21.02.7 because they switched to nftables syntax for custom rules ("firewall.user") in 22.03 and I have a pile of them and haven't had the time to rewrite it all. This release means 21.02 will have no more security updates.
It wasn't a pleasant task but when I ripped the band-aid off and converted my rules, I took it as an opportunity to reevaluate them and was able optimize a lot of them, converting to IPSSETs, tweaking them into CIDR ranges, pruning, etc and got a decent speed boost. Maybe that isn't applicable to you, but something to keep in mind.
I'm still on 18. I'll probably switch to 23 sometime.
The device is stable and I'm the only one using it so I didn't feel any pressing rush to deal with the hassle since a lot of "security" issues are often from the inside not the outside.
Unfortunately there's some RCE vulnerabilities and other nasty bugs between 18 and 23 that can be exploited remotely. I wouldn't feel safe running an unpatched version if it can be helped.
I don't advocate staying on an older version, but that depends on the services you have running. If you don't have any external service, you should be OK.
I tend to minimize internal services as well. I don't use OpenWRT as a general purpose server.
Still, an LTS release from time to time would be good (the effort would be the same, as there would still be only two maintained releases: the current stable and the LTS).
Syntax is the least of the problems. The main problem is the ruleset structure they've chosen which, for example, no longer includes user customizable chains. This means I'll have to rethink my rules to make sure they play nice with the default ruleset.
They seem to be forcing the use of the UI for creating rules, but that doesn't cover some that I have (part of which are generated dynamically).
Worse, I'll have to go through 22.03 because they don't support upgrading from 21.02 to 23.05.
I really want a 6E router that can run this. Only options right now are one that’s expensive and not readily available, and the other is a rebranded Zyxel one only available via a Norwegian ISP.
You can check Banana-Pi R3, which has great support from Mediatek in OpenWRT. You can add another card over PCIE bus if you really need WiFi 6E eg. some mediatek cards with mt7921 chipset will work (built-in wifi 6 with ax mode gives real 1.4Gbps speed, it is working out of the box). This router supports HW flow offloading for NAT + Wireless Ethernet Dispatch for WiFi, this means that at this speed CPU stays at 1% usage. You can also wait for BPi-R4 which will have WiFi 7 support (some patches landed already in Linux).
* https://www.reddit.com/r/homelab/comments/hzvfih/new_router_...