Seems like an advert for their Product SPR: Secure Programmable Routers. I don't know their system, so don't see the rest of my comment as a critique.
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.
> we have Zyxel gear were we can tag WLAN connections with a VLAN based on the SSID
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.
An "advert" for a BSD-licensed open-source codebase? Pointers to a comparable OSS networking project, implemented in memory-safe golang or rust, would be appreciated. There is https://router7.org, but for a narrow use case.
Lack of usable support from a lot of access points and management systems. Do any of the major multi-AP systems support it? UniFi has no support. I don’t think any of the Ruckus products support it.
(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.
I see. I'm using a normal router in bridge mode as an extender and that's been working well enough and comes with WPS built in so for instance, I can turn it on there if the printer is closer but of course it would be nice to turn it on in one place and have all the extenders have it on as well.
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.
This doesn’t isolate the devices from each other, though. (Well, maybe if you have isolation set up on the AP and the devices are all connected to the same radio or isolation happens to work across radios and no one exploits any of the myriad ways in which Ethernet, on the same broadcast domain, is not a secure protocol.)
Hi -- this is the SPR team, we actually did not push this on ycombinator and are happy to see it being discussed. We've previously made one post about SPR here, under Show HN:
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.
> 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.
Should probably throw away the computer and stick to subsistence farming, just to be sure. Avoid talking to other people as well, as they may not have your best interests at heart.
I mean wifi really doesn't have a good track record for security. It's best defense is probably the short range, making searching for weak targets somewhat difficult. And I'm not even going to talk about spoofing, deauth attacks, etc. Only the newest versions have actually secure crypto, but lots of routers don't even support them (for some reason these secure features are branded as "enterprise"). This is very different from the type of security we've come to expect from high level protocols like SSL, SSH, etc.
While there is some merit in having a secure LAN, I see where you’re coming from.
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.
I really wish developers of OSS systems like this would design them, from the ground up, for multiple access points. None of the required changes are rocket science, but IMO all of the features should be pleasant to use with more than one AP, and the network architecture should support it. OpenWRT, for example, handles fast roaming in a way that is IMO quite miserable to configure.
(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.)
Would love to hear from you if you'd be interested in chatting you can find us on the discord or outreach [at] supernetworks.org. I assume your comment is about SPR's micro-segmentation and not the blog post if I understand?
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.
Hmmm I have an ASUS router connected to my CenturyLink modem/router combo because it gets better range and allows me to have better access controls/monitoring. I guess I'm using double NAT. I don't have those issues, but there's been times where after a month or so the internet performance drops considerably and I end up rebooting everything to get it back to normal.
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.
27 comments
[ 2.4 ms ] story [ 74.6 ms ] threadIf 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.
> we have Zyxel gear were we can tag WLAN connections with a VLAN based on the SSIDOpen-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.
WPS sort of tried to cover this use case, but WPS is a disaster.
(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.
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.
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.
> 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.
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.
(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.
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.