i've replaced my Netgear WAX214 with a Cudy WR3000S running openwrt 24.10 in "dumb AP" mode. the only purpose of the cudy is to bridge wifi to my wired network.
my router (opnsense) is handling vlans and everything else.
on the old netgear ap i could enter a vlan id per ssid, clients connected to that ssid could only access this vlan.
is something simple like this possible in openwrt?
i've found many vlan tutoriqls for openwrt, but they dont seem to work in my particular case.
i've created two new devices (br-lan.10 and br-lan.20 for the guest and camera network) and attached them to the ssids, if i connect to the network i dont even get an ip address.
firewall and dhcp services are currently disabled on the cudy.
I have a roughly similar set up to yours (but I use OpenWRT as my firewall with OpenWRT APs scattered around the house). I think you're very close, as it sounds like you've done almost exactly what I've done. I think you're only missing one step.
Your access point has a managed switch in it. I would check that Bridge VLAN Filtering is on for br-lan. Once this is on, you'll be able to configure the VLANs tagged on each port like you would on a typical switch, and I'd bet things will start to work how you want them to.
i've removed all vlan devices and interfaces and started over, in the br-lan device i've checked "Enable VLAN Filtering", added ID 10 and 20, set lan1-4 to Untagged and clicked apply.
OpenWRT is not applying the settings, after clicking Save & Apply its not reachable and after a timeout it says settings could not be applied and were reverted
Did you untag VLAN 10 and 20 on all ports? This is likely your first footgun. You probably want to remove the wan interface, and add the wan device to your br-lan bridge. Then you can connect the OPNsense machine to the WAN port on the AP and tag 10 and 20 on that port only. You most likely don't want the other ports to be untagged.
Also make sure you create VLAN 1 and set it as untagged, otherwise it definitely will boot you like you described
Let's get some additional information so we can get it working:
What is immediately upstream of the OpenWrt AP? Is it a managed switch? the router itself? or an unmanaged switch (if unmanaged, stop here -- this won't work)?
What is the upstream configuration in terms of VLANs on the port? Specifically, what VLAN IDs are on the trunk, and are all of them tagged, or is there an untagged VLAN being used here?
What VLAN is considered the management VLAN (i.e. which network will be used to manage the AP)?
What address do you want the AP to take on that management network (or do you want it to get the IP via DHCP)?
What physical port on your AP is used as the uplink?
What do you want the other ports to do (i.e. port-VLAN membership)?
And let's take a look at your config:
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
I don't know if this helps, but this is a rough accounting of the steps I took when setting mine up (tweaked for your described setup). It assumes that your OPNsense uplink is attached to the WAN port. Some of these steps are redundant if you disable those 3 services, but I did them anyways so there isn't misleading settings for DHCP and firewall if I go back later to troubleshoot something (and so I don't break my network if I accidentally enable one of those services).
Disable and stop the following services (as they're not necessary in a dumb AP)
dnsmasq
odhcpd
firewall
Delete all firewall zones
Delete the default WAN interface
Add the wan device to the br-lan bridge
Enable Bridge VLAN Filtering for br-lan and create VLANs 1, 10, and 20 (configuring them as desired) -- DON'T HIT SAVE AND APPLY YET or you'll get booted
Reasonable defaults:
VLAN 1:
wan: untagged
lan1: untagged
lan2: untagged
lan3: untagged
lan4: untagged
VLAN 10:
wan: tagged
VLAN 20:
wan: tagged
Create a new device for VLAN 1 (e.g. br-lan.1), then switch the LAN interface's device from br-lan to br-lan.1 -- You may now apply, and if you did it right, you should still have access
Re-configure the LAN interface as follows
General Settings
IPv4 Address: (click plus) your desired AP address/mask here
IPv4 Gateway: your OPNsense interface IP
Advanced Settings
Custom DNS servers: use OPNsense recursive resolver address if enabled, otherwise use whatever upstream DNS you prefer
DNS search domains: if you have an internal domain configured on OPNsense, use that
Firewall Settings
Zone: Unspecified
DHCP Server
General Setup
Ignore Interface: Checked
IPv6 Settings
RA-Service: disabled
DHCPv6-Service: disabled
Create 2 more interfaces, one for guests and one for cameras
Set both interfaces to unmanaged, as the AP only needs to operate at layer 2 in those networks, and thus should not have an IP.
Set the device to your VLAN device. For example, if the guest network is VLAN 10 you'll want to select br-lan.10
Create your SSID's as desired and attach them to the appropriate networks. Then you're done.
If you wish to have a seperate management network instead of it living on your LAN, you only need minor tweaks:
Tag a new VLAN for management on br-lan
Create the VLAN device for your new VLAN
Perform step 7 above, but on the new interface instead of LAN
Switch the LAN interface's protocol to unmanaged to match the others.
Do note these steps may vary depending on your answers to @psherman's questions, however the general idea should be roughly the same.
I used to think the same thing, but this is not always true. I've found most unmanaged switches will pass VLAN tags without mangling them. When I moved into my new apartment, I attempted this on a TL-SG108 (non-E) before I could get my grown-up switch out of storage and I was surprised to see that it handled it just fine. Tried it on a few other assorted cheap switches at work out of curiousity and they all were (shockingly) able to do it as well. Only thing you can't do is configure untagged ports, but that may not be the end of the world for this application. For connecting VLAN-aware devices, they work just fine in my experience.
This is also true, but I don't know if I would say "most" because there are a lot of unmanaged switches out there. The behavior will depend on the age of the device, the switch chip in use, and how the device was configured when it was developed (i.e. the firmware and hardware config that is not mutable post manufacture). I have, out of curiosity, tested a few unmanaged switches with VLANs and all of the ones I ever tested did, in fact, pass all the frames unmangled. However, I've also helped enough people on the forums that have run into very serious network issues when using unmanaged switches with VLANs.
It's important to remember that the behavior of VLANs through an unmanaged switch is undefined. That is to say it might be fine, or it might mangle things. It could strip all the tags and make everything untagged, causing mahem. It could refuse to pass the tagged frames, but work find with the untagged ones, etc.
Well, basically whatever is on one port is on all ports... there is no ability to control anything. You obviously cannot take a tagged network and make it untagged on another port (i.e. to make an access port), but you also cannot change the port-vlan membership... that is to say all VLANs are available on all ports. Yes, the downstream equipment would need to be configured to be VLAN aware with the correct VLAN IDs... but this does constitute 2 other risks... since it's not possible to limit the port-VLAN membership, this can cause a security risk since it's easy enough to then join any VLAN as long as your system can be configured with that VLAN ID. And, this also runs the risk of a downstream device that is not VLAN aware choking on the tags and then doing bad things to the network as a whole.
With all of that in mind...
There is too much nuance and a world of undefined behavior that may or may not be problematic. This is why I simply say "it won't work" -- better to avoid all of that.
I appreciate the insightful response. I guess given the nuance, I see why you'd say that. Still, I personally have been in financial situations where having to purchase another device (like a managed switch) would end the project, so I'd rather know that there is a slight possibility of it working vs having to give up entirely. Maybe I should've said that "it might work, but YMMV" instead.
In your own home environment where it's just you (and maybe your family or other cohabitants), the risk is presumably low and easily mitigated when something comes up. (although it does depend on how much of a fit those other people might have when the internet doesn't work...lol).
But, if you're doing this for a business or even a home as an IT professional (as an employee or other paid position), this could be very risky both for you and the project 'owner' from a network security and stability standpoint. And it could even damage your professional credibility.
Although there are many entry level managed switches that are terrible for one reason or another, they are not all that expensive -- think $25 for a basic 5-port unit. Obviously they can get expensive as the performance, features, and port count increase, but sometimes it's possible to augment the network with a small managed switch such that tagged frames never hit any unmanaged switches.
Yeah... but, IMO, just advise against it unless the risks are fully understood and you are absolved of any further resopnsibility.
There are regularly opportunities to find good (not entry level, but gs1900-, DGS-1210-, HPE 1920 series) managed switches on the second hand markets. These are business devices and generally not sexy, so they often fly under the radar and get sold for rather cheap (15-25 EUR is quite possible (~40-50 EUR is a more regular going rate) for 8-48 ports, PoE however is a different price range (and so would be anything beyond 1 GBit/s ports), not regularly, but if you are patient and persistent you will see good opportunities). …and that's before even looking at the whole market, including devices with fans or non-OpenWrt capable ones.
Please consider a managed switch for all the reasons I described above. Yes, your GS108 is working to pass the VLANs without issue currently, but there are additional reasons that a managed switch can be important (all detailed above).
But, in the end, what matters is that your setup is working now... glad it's functioning as desired!
