I have an old as dirt Ruckus 7372 and I'm looking to upgrade
- Thread starter Fritz
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
Most of the stuff on the market pushes the controller idea but, in reality they all have local admin ability. For instance I'm using a Zyxel NWA210AX and they push the whole cloud controller idea with everything they sell but, not needed. Now, if you're messing with more than a handful of APs it does make it easier but, for most of the home uses though you really only need 2-3 depending on the size / construction.
What are your goals? Speed? Capacity? Buy now and run it until it dies?
Right now I'm playing around with an M2 card as an AP to get 802.11BE for under $40 but, it's still a WIP from the driver side. The card I went with wasn't an "AP" model and they just released some firmware to enable the option this week and it's been stumbling to remain stable even with updated firmware. I expect things to firm up a bit as time passes though and hopefully unlock ~5gbps speeds from it.
For a more reliable setup you could DIY AX/E options if you find the right cards. Personally I aim for Qualcomm based cards since they tend to be more stable and less flakey than RTL / MTK and Intel doesn't do AP mode very well w/o some hacking to make it work.
What are your goals? Speed? Capacity? Buy now and run it until it dies?
Right now I'm playing around with an M2 card as an AP to get 802.11BE for under $40 but, it's still a WIP from the driver side. The card I went with wasn't an "AP" model and they just released some firmware to enable the option this week and it's been stumbling to remain stable even with updated firmware. I expect things to firm up a bit as time passes though and hopefully unlock ~5gbps speeds from it.
For a more reliable setup you could DIY AX/E options if you find the right cards. Personally I aim for Qualcomm based cards since they tend to be more stable and less flakey than RTL / MTK and Intel doesn't do AP mode very well w/o some hacking to make it work.
I've been looking for an AP that will allow me to separate wired from wireless in no uncertain terms. What I mean is no wireless client can access a wired client period. every time I've asked about this I've a ton of stupid bullshit that really has nothing to do with what I'm looking for and that is unconditional separation of wireless from wired.
I thought I found it with my current Ruckus AP but even tho the wireless clients are on a different subnet they can still access the rest of the network. I know this isolation can be done but it has to be unconditional or else I won't accept it. I'm hoping that a high end AP will allow this to happen and this is what I'm looking for.
Sorry, This has always been a sore spot with me as everyone want to spew bullshit rather that address the core issue.
It sounds like I'm in the "You're doing it wrong" camp, but I'm going to say it anyway. This is not a function of the AP. The AP does not function at layer 3 (which is where you need to control IP connections) it's a layer 2 device. That means it manages at the MAC address layer, like a switch.
You need to configure that access control into the firewall, not the AP. You can't do complete isolation of *all* wireless clients from *all* wired devices, because your Internet router / firewall is a wired device. If you were able to block all wired access, you'd end up not having Internet access (because the packets sent from wireless devices to the Internet have a "next hop" of the MAC address of the firewall or router, and the MAC is obtained using ARP - which is broadcast to everything on the same layer 2 network).
To achieve what I think you want, you have the wireless devices on a separate VLAN from wired. Let's say wired is VLAN 10, with IP subnet 192.168.10.0/24, you might make wireless VLAN 20, with IP subnet 192.168.20.0/24.
You have two interfaces on your firewall (either different physical interfaces, or VLAN interfaces) and you create firewall policies that block access between the two VLANs.
And pretty much all APs can handle that, you put your management for the AP on your management VLAN, and your SSD is matched up with a specific client VLAN (VLAN 20 above).
You need to configure that access control into the firewall, not the AP. You can't do complete isolation of *all* wireless clients from *all* wired devices, because your Internet router / firewall is a wired device. If you were able to block all wired access, you'd end up not having Internet access (because the packets sent from wireless devices to the Internet have a "next hop" of the MAC address of the firewall or router, and the MAC is obtained using ARP - which is broadcast to everything on the same layer 2 network).
To achieve what I think you want, you have the wireless devices on a separate VLAN from wired. Let's say wired is VLAN 10, with IP subnet 192.168.10.0/24, you might make wireless VLAN 20, with IP subnet 192.168.20.0/24.
You have two interfaces on your firewall (either different physical interfaces, or VLAN interfaces) and you create firewall policies that block access between the two VLANs.
And pretty much all APs can handle that, you put your management for the AP on your management VLAN, and your SSD is matched up with a specific client VLAN (VLAN 20 above).
Thanks. Tell me, how is it that a wireless client with an ip address of 192.168.40.xxx can access a wired client with an ip address of 192.168.10.xxx. This is my present dilemma.
Either you have the subnet mask set larger than the typical /24 for the 192.168 network or your router is forwarding packets between subnets. As others have mentioned, VLANs are a cleaner way to separate networks, though that won't solve router forwarding.
That's my problem, no matter how you slice and dice it, there's always exceptions that allow connectivity to happen when you think it can't. What I'm looking for is a way to configure networking that imposes restrictions that are absolute but I suspect I'm pissing in the wind.
It's pretty trivial for my network, been working fine since I got my first managed switch in 2008 or so, just configure the router as the default gateway for every device and then use firewall rules to drop packets between the subnets that should be isolated. You get fun issues with stuff like getting Google Cast whatnot working from a phone to a wired TV, but there are options to address that kind of thing.
Can you show your current network configuration / layout? You can draw a simple diagram with Draw.IO (you can take your fancy link investigation and correction, and shove it thanks XenForo!) if you don't have a preferred tool. We'd need to see the following (you can exclude any cases that are "obvious" or that don't exist):
* Firewalls and routers with labelled ports, and showing VLANs and IP addresses (you can obfuscate / hide IPs a little, though I'd suggest keeping the last two numbers unchanged)
* Switch(es) with any VLANs
* AP(s)
* One or two clients
* The access that works, and should
* The access that works, but should not
* The access that does not work, but should work
* The access that does not work, and should not
To sum it up....
You get 3 criteria to choose 2 from....
Cheap
Easy
Works
As others mentioned AP's are L2 and you get around isolation using VL's which requires at least a managed switch but, if you want more control then a L3 switch is the way to go.
One issue is by default everything thinks it's in VL1 by default.
L2 managed / VL - cheaper
L3 managed - bit more $$
The AP I'm using has the option to tie SSID's to 8 different VL's per radio (2.4/5) but, if you go all out you can probably do 3 bands with 6ghz options.
You could do the FW rules approach or you could isolate traffic as well using IPTables or some other off the shelf *sense "OS" on a PC as a router setup. There's a lot of ways to approach and engineer a working solution that hits all of your bullet points depending on how much time / money you want to invest in it. But, there's no real off the shelf option that would just work w/o some engineering going into it. Sometimes you'll find SMB clients deploying a UTM/NSA as their core device.
Let's say you have 3 subnets and in IPT that's 3 forward rules explicitly telling the packets where to go and drop otherwise. There's also some inbound from the WAN rules needed and outbound to the internet but, it's fairly easy to maneuver. My running IPT rules might be a total of 15 rules that keep everyone out and doesn't allow for leaks from the inside. There are other options you can dig into if you're willing to sacrifice speed to process the additional functions.
The ultimate is to airgap things physically that you don't want talking to anything but, it's impractical for convenience. The other option could be physically wiring the APs into separate switches w/ separate APs for different subnets.... but $$$$ and ultimately they might tie into the same ISP unless you diversify that as well.
I run a DIY setup though because I'm cheap and efficient compared to most off the shelf options. I got sick of consumer gear / firmware issues years back and just put it all inside a PC instead. All of this stuff runs on Linux anyway when you peal back the glossy GUI and look under the hood. AP/router/switch/firewall/etc.
You get 3 criteria to choose 2 from....
Cheap
Easy
Works
As others mentioned AP's are L2 and you get around isolation using VL's which requires at least a managed switch but, if you want more control then a L3 switch is the way to go.
One issue is by default everything thinks it's in VL1 by default.
L2 managed / VL - cheaper
L3 managed - bit more $$
The AP I'm using has the option to tie SSID's to 8 different VL's per radio (2.4/5) but, if you go all out you can probably do 3 bands with 6ghz options.
You could do the FW rules approach or you could isolate traffic as well using IPTables or some other off the shelf *sense "OS" on a PC as a router setup. There's a lot of ways to approach and engineer a working solution that hits all of your bullet points depending on how much time / money you want to invest in it. But, there's no real off the shelf option that would just work w/o some engineering going into it. Sometimes you'll find SMB clients deploying a UTM/NSA as their core device.
Let's say you have 3 subnets and in IPT that's 3 forward rules explicitly telling the packets where to go and drop otherwise. There's also some inbound from the WAN rules needed and outbound to the internet but, it's fairly easy to maneuver. My running IPT rules might be a total of 15 rules that keep everyone out and doesn't allow for leaks from the inside. There are other options you can dig into if you're willing to sacrifice speed to process the additional functions.
Code:
Chain INPUT (policy DROP 31850 packets, 6882623 bytes)
pkts bytes target prot opt in out source destination
36060007 33097593805 PERMIT-IN 0 -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 70 packets, 3712 bytes)
pkts bytes target prot opt in out source destination
3521360 3490087170 PERMIT-FWD 0 -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy DROP 97 packets, 5044 bytes)
pkts bytes target prot opt in out source destination
14286524 37808038655 PERMIT-OUT 0 -- * * 0.0.0.0/0 0.0.0.0/0
Chain PERMIT-FWD (1 references)
pkts bytes target prot opt in out source destination
3502128 3479806907 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
19162 10276551 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW
Chain PERMIT-IN (1 references)
pkts bytes target prot opt in out source destination
2551724 11364319419 ACCEPT 0 -- lo * 0.0.0.0/0 0.0.0.0/0
3430107 282397811 ACCEPT 0 -- br0 * 0.0.0.0/0 0.0.0.0/0
30046326 21443993952 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
Chain PERMIT-OUT (1 references)
pkts bytes target prot opt in out source destination
2551724 11364319419 ACCEPT 0 -- * lo 0.0.0.0/0 0.0.0.0/0
2120769 24175335860 ACCEPT 0 -- * br0 0.0.0.0/0 0.0.0.0/0
9183529 2226842662 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
430405 41535670 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 ctstate NEWI run a DIY setup though because I'm cheap and efficient compared to most off the shelf options. I got sick of consumer gear / firmware issues years back and just put it all inside a PC instead. All of this stuff runs on Linux anyway when you peal back the glossy GUI and look under the hood. AP/router/switch/firewall/etc.
As everyone else is saying, setting up a couple of subnets on different VLANs at your router is the way. You just set the VLAN on your AP's SSIDs & then let the router decide which packets get routed between the subnets.
But if your aim is to isolate wireless clients from each other, as well as the wired network, then you can enable Wireless Client Isolation in Ruckus unleashed - then clients only see whitelisted endpoints (e.g. your internet gateway).
Ruckus R510/R610/R710 Unleashed APs are well under $50 now, so upgrading is cheap.
But if your aim is to isolate wireless clients from each other, as well as the wired network, then you can enable Wireless Client Isolation in Ruckus unleashed - then clients only see whitelisted endpoints (e.g. your internet gateway).
Ruckus R510/R610/R710 Unleashed APs are well under $50 now, so upgrading is cheap.
Thanks all.
Just a brief summary.
Router is a Dell 5070 Extended with a SM Intel i350 dual server NIC running OPNSense latest version up to date.
I have one Avaya 4850GTS-PWR+ which I believe is a layer 3 switch.
I have another Avaya 4850GTS-PWR+ that's dormant and is run only when needed.
I have a Arista DCS-7050TX-64-F which is a 10G copper switch which I believe is also a Layer 3 switch. I'm in the process of switching part of my network over to 10G so it isn't running at all times.
Reasons why I've never done VLANS.
Cable labeling - I've yet to find a way to label network cables. All the solutions I've tried aren't permanent or are too clutsy to consider (like those tywraps with the little pads you write on which are way too small to be useful). Without labeled cables VLANs are impracticable.
To be honest how VLAN connectivity works is clear as mud to me. How does a VLAN access the Internet when there is no Internet connected to the VLAN subnet? How does one VLAN connect to another for administration purposes? And how is this connection made to be one way only?
Non of the sources I've ever found on the web cover these issues. This is basic stuff that I need answered before I can wrap my head around the rest. Why it's never mentioned, I don't know.
How do data centers handle cable labeling? Do they use a laser device that prints directly on the cable? I can't imagine a mass of cables all having little butterfly labels attached, that would be a mess.
Just a brief summary.
Router is a Dell 5070 Extended with a SM Intel i350 dual server NIC running OPNSense latest version up to date.
I have one Avaya 4850GTS-PWR+ which I believe is a layer 3 switch.
I have another Avaya 4850GTS-PWR+ that's dormant and is run only when needed.
I have a Arista DCS-7050TX-64-F which is a 10G copper switch which I believe is also a Layer 3 switch. I'm in the process of switching part of my network over to 10G so it isn't running at all times.
Reasons why I've never done VLANS.
Cable labeling - I've yet to find a way to label network cables. All the solutions I've tried aren't permanent or are too clutsy to consider (like those tywraps with the little pads you write on which are way too small to be useful). Without labeled cables VLANs are impracticable.
To be honest how VLAN connectivity works is clear as mud to me. How does a VLAN access the Internet when there is no Internet connected to the VLAN subnet? How does one VLAN connect to another for administration purposes? And how is this connection made to be one way only?
Non of the sources I've ever found on the web cover these issues. This is basic stuff that I need answered before I can wrap my head around the rest. Why it's never mentioned, I don't know.
How do data centers handle cable labeling? Do they use a laser device that prints directly on the cable? I can't imagine a mass of cables all having little butterfly labels attached, that would be a mess.
I use coloring schemes :
Red - trunk all vlans
Blue - iot
Green - normal user vlan
Yellow - VPN
And so on.
Example:
Greluma 120pcs RJ45 CAT5E CAT6 Ethernet Network Cable Strain Relief Boots Cable Connector Plugglock-Mixed Color https://amzn.eu/d/fNmdBu0
You route between vlans. It's the only way I know of to do it right.
As for labeling, that's excessively complicated. Document, make a spreadsheet, make a chart. A single cable can carry all, some or no vlans.
The only cabling labels I've seen are either inventory numbers (to refer to previous documentation), or locations codes for where they start or end
As for labeling, that's excessively complicated. Document, make a spreadsheet, make a chart. A single cable can carry all, some or no vlans.
The only cabling labels I've seen are either inventory numbers (to refer to previous documentation), or locations codes for where they start or end
I think it is a common misconception to think that devices on one network subnet ( 192.168.40.xxx) can't by default communicate with devices on another network subnet (192.168.10.xxx). Unless you have physically isolated those networks from each other or created rules to prevent communication between different network subnets, data transfer can occur.
This is why people use VLANs at all - to control the flow of data between two network subnets.
This is why people use VLANs at all - to control the flow of data between two network subnets.
Last edited:
As far as "labeling" your network, there are plenty of ways to accomplish this and the decision to use/not use VLANs really doesn't change any of that. When you do use VLANs however, a "best practice" is to assign "blocks" of ports on your switch to various VLANs instead of randomly assigning ports to a VLAN based on what it plugged into it.
For example, if you have three VLANs, perhaps switch ports 1-14 are assigned to VLAN 10, 15-27 are VLAN 20, 28-42 are VLAN 30, and 43-48 are trunk lines with all VLANs. This way you simply plug a device into an appropriate set of ports depending on what VLAN you want the device assigned to. (Obviously this port "layout" is driven by the number of devices you expect to plug into each VLAN, how many trunk ports you need, etc, etc, etc).
This is much easier to manage than assigning VLANs to random plugs based on what it plugged into it. For example, plugging a device in port 1 that is for VLAN20 and port 2 is a device for VLAN10 and port 3 is a device for VLAN10 and port 4 is VLAN 30, etc, etc, etc. That is unnecessarily hard to manage and would certainly rely on accurately labeled cables more than the first way of handling it.
Long story short, your switch's ports (via VLAN assignments) should drive where your devices are plugged in, not the other way around where your devices that are plugged into the switch drive which VLAN is assigned to each port.
Of course you should be maintaining good records about where things are patched, etc as well for future reference. My suggested method of splitting your switch's physical ports into VLAN "groups" doesn't do away with this. This can be a spreadsheet, or a notebook, etc. But this requirement is true whether you use VLANs or not. There are times when you need to know what switch port the computer in the office is plugged into - vlan or not. But when it comes to managing VLANs, just knowing that anything plugged into ports 1-14 is on VLAN 10 and everything in ports 15-27 is on VLAN 20, etc is very helpful and when you set the switch up like this, using VLANs really doesn't add to the complexity of the management/record keeping of the network.
For example, if you have three VLANs, perhaps switch ports 1-14 are assigned to VLAN 10, 15-27 are VLAN 20, 28-42 are VLAN 30, and 43-48 are trunk lines with all VLANs. This way you simply plug a device into an appropriate set of ports depending on what VLAN you want the device assigned to. (Obviously this port "layout" is driven by the number of devices you expect to plug into each VLAN, how many trunk ports you need, etc, etc, etc).
This is much easier to manage than assigning VLANs to random plugs based on what it plugged into it. For example, plugging a device in port 1 that is for VLAN20 and port 2 is a device for VLAN10 and port 3 is a device for VLAN10 and port 4 is VLAN 30, etc, etc, etc. That is unnecessarily hard to manage and would certainly rely on accurately labeled cables more than the first way of handling it.
Long story short, your switch's ports (via VLAN assignments) should drive where your devices are plugged in, not the other way around where your devices that are plugged into the switch drive which VLAN is assigned to each port.
Of course you should be maintaining good records about where things are patched, etc as well for future reference. My suggested method of splitting your switch's physical ports into VLAN "groups" doesn't do away with this. This can be a spreadsheet, or a notebook, etc. But this requirement is true whether you use VLANs or not. There are times when you need to know what switch port the computer in the office is plugged into - vlan or not. But when it comes to managing VLANs, just knowing that anything plugged into ports 1-14 is on VLAN 10 and everything in ports 15-27 is on VLAN 20, etc is very helpful and when you set the switch up like this, using VLANs really doesn't add to the complexity of the management/record keeping of the network.
Last edited:
I do VLANs with no cable labels, I just terminate everything in a patch panel and label the ports there.
OK guys, I'm rethinking all this. I broke out an old HP 1810 and plugged in most of my strictly local stuff like IPMI, etc. I'm going to play around with VLAN's using this switch and see if I can't educate myself more. I do have one more question. Can I assign a port on my main switch and plug this HP switch into it and have all the associated devices appear on that VLAN? Or do I need to assign all the ports on the HP switch to that VLAN?