Securely Chaining WiFi Routers (2022)
supernetworks.org
supernetworks.org
If your systems supports VLAN tagging per SSID there is an option to make the single Router setup more secure. This will most likely only apply to companies and home labs. For example at my company we have Zyxel gear were we can tag WLAN connections with a VLAN based on the SSID.
Beware, simplified description ahead. We have a Guest SSID. All connections from this SSID get tagged with a dedicated VLAN on the Access Points. The traffic is then routed to our Firewall and from there to the internet. All switches in between use the VLAN to prevent Guest connections from reaching any other devices on the LAN.
The decision diagram and conclusion below, applies to any pair of OSS or vendor routers in the "guest" and "secure" roles.
Guest Router First, Secure Router Second
Option #1 is the recommended and accepted best practice. The guest network connects directly to the internet, and the secure router plugs into the guest Router.
Open-source SPR can place each wireless client device in its own VLAN, with a unique WPA3 passphrase for every client.
This allows granular, per-device rules for routing and filtering, instead of dumping all devices into one-VLAN-per-SSID.
I still don't see a usecase for a unique PSK per guest, and even that can be achieved with most guest portal implementations.
What SPR seems to lack is backing and therefore trust. Pushing a product aggressively on HN is not the way to build that trust.
https://news.ycombinator.com/item?id=35990030
The post in the link does not pertain to the user PSK but it is about the difficult trade offs that users have when they need to chain routers together.
Imagine someone has a router that they want to put all the IOT stuff that does not get security updates and has poor code quality compared to the rest of a network.
Should that router be the first router that has access to the internet? Or should it be connected to the router that does. The answer is not so simple and that's what the blog post discusses.
In SPR we provide users a mechanism to block upstream RFC1918 addresses by default and selectively enable them.
We have also found numerous flaws in Guest WiFi systems that totally break isolation between the Guest Network and the main network. This affects many routers on the market today, in particular when a medium is bridged between wired and wireless, but also in general.
As seibol commented -- VLAN tagging per SSID is a valid approach as well if a router supports it. Thats a lot stronger than how many routers implement their guest isolation.
As for Multi-PSK -- the use case is creating micro-segmentation in a network with zero-trust, where the identity on the network is rooted in that password.
Without Multi-PSK, if it's not clear, every device that has the WiFi password can sniff encrypted traffic with WPA2, make a Rogue AP to attack WPA3 in case its in use, and can perform ARP spoofing on the network to interfere with other devices.
WPS sort of tried to cover this use case, but WPS is a disaster.
My approach is just setting proper firewall rules on a dedicated ESSID with a dedicated VLAN. A device on a restricted VLAN shouldn't be able talk to anything. The downside is its more work, but the plus side is it can be done on trusted firmware (OpenWRT) and not something that would require an entire code audit to determine if there are any logic flaws.
(Also, “push the button” is a bit of an awkward concept with multiple APs.)
edit: it’s also a disaster due to a proliferation of crappy client devices that more or less require it.
(It would be really nice if the actual 802.11 standards specified a way for an AP to delegate management to a separate device so that any vendor’s AP could join such a network. Oh well.)
SPR does support mesh nodes with backhaul which is currently for PLUS members -- however, we have not explored supporting multiple independent routers with micro-segmentation.
Would love to hear your use case, we have an API which should already make it possible for users to automate and code up what they need to sync up disparate SPR instances on distinct routers, for example.
For affecting the 802.11 spec that's out of scope for our reach today.
> An unspoofable device identity is established with a MAC address and Per-Device Passphrase for WiFi (or a VPN Public Key for Remote Devices). From there, each device gets its own /30 subnet to exist on. Hardening and strict firewall rules block network spoofing and impersonation, and routing rules redefine connectivity between devices and to the internet.
https://kb.netgear.com/30186/What-is-double-NAT-and-why-is-i...
You can't put guest router in bridge mode since then guest/IoT devices can't get IPs. You'd have to put "secure" router in bridge or AP-only mode.
By that time, just get something that does all this for you without any hassle or configuration to learn, like Eero.
Unless you want to be a WiFi geek, just get Eero and let it do WiFi right for your whole household.
I would like to wholeheartedly un-recommend getting an Eero. Eero broke port forwarding in an update and didn't fix it for a while, with no ability to roll it back myself. You can't control your updates at all. Eero had functionality as basic as port forwarding break for days and just left their customers entirely in the dark about it. Now I just use my Eeros in bridge mode and have a router running OPNsense, which works great, despite just being a computer I found off the curb with a networking card slapped in it.
I'm not the kind of Linux whose uncompromising priority is to be able to control every single corner of my computer, even at the expense of ease-of-use. I know that using proprietary software that's easier at the cost of fewer options is totally valid for most people. But if a product just breaks core functionality like that, with no way to fix it besides waiting for Amazon to get their shit together, then I could hardly recommend it to the most tech-illeterate people I know, much less to the HN crowd.
I assume anything leaving the LAN is insecure, and why I prefer secure protocols. However, this is often impractical for many devices and projects on the LAN side.