Hi. My setup is the following. I have a router with two dumb access points for wifi(every client is wifi based). Everything is running via OpenWRT. AP have an unmanaged poe network switch.
I need to separate traffic between IOT devices and users. This is more of a homelab project. But I encounter a problem that I am failing to understand.
I’ve created a Vlan device, br-vlan.5 lets call it. I added the interface with this device. Now I want the dhcp server to assign specific static lease clients to this new Vlan interface. This just doesn’t happen. I assign them to a different interface and that static lease just gets completely ignored. I understand that the proper way to do it is via a radius server or separate SSIDs(can’t do that btw, APs won’t let me) and Mac addresses are easy to spoof, but I am just trying to understand my mistake. Its probably something simple that I am missing, I am hoping someone with more knowledge can point it out. Logically it should work, but for some reason static lease gets completely ignored and the client gets assigned to the lan network.
If you need authentic addresses you need other measures.
Besides that. As usually it goes: please post your network and dhcp and wifi config of your router and AP. Without that nobody can effectively help you.
To do this properly you need a managed switch. Some unmanaged switches will pass VLAN tagged packets transparently and some will drop them. If you have the first kind you could use it, but all VLANs will appear on all ports so you can’t implement a lot of security with it.
An AP running OpenWrt can have multiple SSIDs fed by multiple VLANs on the same Ethernet cable. This is the typical setup. There is also a post about how to put different users of the same SSID into different VLANs based on the pre-shared password they use to connect. I have not actually tried that.
Once you have the different classes of users segregated into different VLANs on the Ethernet, the main router will have a network Interface for each VLAN and different addresses and firewall rules for each one.
This would be ideal but unfortunately the choice is very limited for which switches can run Openwrt. They’re either not available or not fully supported. I understand VLAN is a standard not just Openwrt tech but I’d rather not use a proprietary solution at all, its just a personal preference.
I am aware of this solution. It is certainly a good solution, however for my particular situation it is not ideal.
Yes this is done via a Radius server. It will assign clients to their designated VLANS securely. That is a correct and ideal solution. I will be doing this next.
What I am trying to understand now is why a straightforward basic insecure solution refuses to work. Not sure how DHCP assignments just get ignored since the client is not assigning a static address it is contacting a DHCP server and the server issues a wrong address on the wrong interface. My thoughts so far are that maybe each interface requires its own DHCP server, which, while possible, still for some reason shares the static lease rules between and nothing happens (the test device is still on 192.168.1.xx and not on 10.10.20.xx)
You do not need a switch that can run OpenWrt. Any managed switch that uses the industry standard 802.1q tags (this would be essentially all of them) will work. Some of them are really inexpensive, too (although I would avoid the entry level TP-Link TL-SG1xxE series and the Netgear equivalent as they have bad firmware implementations).
Also, consider that you could simply get an old all-in-one router that supports OpenWrt -- then you can run it as a managed switch on OpenWrt even though it's technically a router.
I understand VLAN is a standard not just Openwrt tech but I’d rather not use a proprietary solution at all, its just a personal preference.
[/quote]
There are a few supported switches, but many other switches just use a basic web/ssh management interface with their vendor firmware. While the vendor firmware is clearly not OpenWrt, you don't need to buy into a large proprietary system like Unifi or Omada or the enterprise stuff from Cisco/Arista/etc.
You still have a bunch of additional problems with your config.
This is wrong.... delete it.
Instead, create a new bridge using direct dotted notation:
config device
option name 'br-iot'
option type 'bridge'
list ports 'eth0.5'
Then edit your iot network which also has another issue:
The address is invalid and will cause major issues. Your network should look like this, instead (note the changes -- last octet of the address changed from 0 to 1 and the device is now br-iot):
both of the SSIDs you've created are referencing the lan interface. this means that they're not linked with the iot network at all and will thus never give out an IP on that network.
Beyond that, 802.11r should not be used unless you have multiple APs. And, assuming you do, it's still not a good idea to enable this method unless you have an actual demonstrated need for it. Usually it causes more harm than good.
Beyond the earlier comment about the unmanaged switch -- for now, just bypass the switch and connect the router directly to the AP. But, it does appear that you've got the AP on a different device. Did you configure that for VLANs? You didn't share the relevant files.
For both devices, let's see:
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 understand. Its just a personal preference. I am trying to understand the principle, and my error in this particular setup. With a managed switch this should become a very straightforward setup. But I think it is also useful to get this resolved because it would generally be very representative of a regular home setup. A router and 2-3 APs, and there are no topics like that on the forum and its not well referenced in the documentation. I saw some topics that are similar but they deviated form the original goal and found a substitution.
This was created via LuCi automatically, it this is indeed wrong someone should probably file a bug report. It is, however, consistent with the documentation on OWT wiki in driver level VLANs, but there they use devices directly, so I thought maybe? I am more than willing to try this config though, I did manually create vlan devices before with similar effect though.
Yes, sorry, I was quickly creating the config on the fly, that was a typo on my behalf, it still doesn’t(and didn’t) work with a valid address.
They sort of do, so long as it is not a VLAN interface. If I just create a separate interface named IOT on the router and assign a static lease, the router will move the client of an AP into that network. My thought process was that since a br-lan.xx is a derivative of the bridge device anyway, the router will do the VLAN filtering and move the client of LAN into an appropriate network.
I am using it for power. You are correct I have a router (x86 old PC) and 2 netgear access points. Switches feed APs power. Its a 5 port tp link dumb switch. You think it might interfere?
I didn’t configure them for VLANs, I thought I’d use them as a VLAN unaware devices and do the sorting on the router end, I understand this isn’t secure.
I will now link config files from my APs, they’re configured identically so hopefully shouldn’t be an issue.
Network:
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
config device
option name 'eth0'
option macaddr '#############'
config interface 'lan'
option device 'br-lan'
option proto 'dhcp'
Firewall (Just the default although not sure it is necessary to even have it enabled on a dumb AP?):
config defaults
option syn_flood 1
option input REJECT
option output ACCEPT
option forward REJECT
# Uncomment this line to disable ipv6 rules
# option disable_ipv6 1
config zone
option name lan
list network 'lan'
option input ACCEPT
option output ACCEPT
option forward ACCEPT
config zone
option name wan
list network 'wan'
list network 'wan6'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 1
option mtu_fix 1
config forwarding
option src lan
option dest wan
# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
option name Allow-DHCP-Renew
option src wan
option proto udp
option dest_port 68
option target ACCEPT
option family ipv4
# Allow IPv4 ping
config rule
option name Allow-Ping
option src wan
option proto icmp
option icmp_type echo-request
option family ipv4
option target ACCEPT
config rule
option name Allow-IGMP
option src wan
option proto igmp
option family ipv4
option target ACCEPT
# Allow DHCPv6 replies
# see https://github.com/openwrt/openwrt/issues/5066
config rule
option name Allow-DHCPv6
option src wan
option proto udp
option dest_port 546
option family ipv6
option target ACCEPT
config rule
option name Allow-MLD
option src wan
option proto icmp
option src_ip fe80::/10
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family ipv6
option target ACCEPT
# Allow essential incoming IPv6 ICMP traffic
config rule
option name Allow-ICMPv6-Input
option src wan
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
list icmp_type router-solicitation
list icmp_type neighbour-solicitation
list icmp_type router-advertisement
list icmp_type neighbour-advertisement
option limit 1000/sec
option family ipv6
option target ACCEPT
# Allow essential forwarded IPv6 ICMP traffic
config rule
option name Allow-ICMPv6-Forward
option src wan
option dest *
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
option limit 1000/sec
option family ipv6
option target ACCEPT
config rule
option name Allow-IPSec-ESP
option src wan
option dest lan
option proto esp
option target ACCEPT
config rule
option name Allow-ISAKMP
option src wan
option dest lan
option dest_port 500
option proto udp
option target ACCEPT
I think that the big issue is that every solution is bespoke to some degree or another. My goals will be different than yours, and yours will be different than many other users.
That said, we have wiki articles for creating bridged APs -- this covers one or many additional APs. Adding VLANs to that equation isn't hard, but again, is somewhat specific to the hardware in use and the topology of the network.
We'd need to know the exact path you took that generated this. Keep in mind that there are many situations where a user can set something incorrectly or use the wrong tools, but it can be syntactically correct (speaking to the UCI config files). A good example is your network address for the iot network -- it was invalid for a /24, but the syntax was correct.
Can you be more specific about what you did here? This isn't exactly clear.
It might. I mean, it is your network and you can go ahead and try... sometimes the issues that can be caused are obvious, sometimes they are subtle and difficult to track down the root cause. I recommend only passing untagged frames through an unmanaged switch; use a managed switch anytime VLANs are involved.
It's not an issue of security (although that is a factor)... a non-VLAN aware AP cannot provide VLAN specific functions.
You don't have VLAN 5 defined here, so it is impossible for a device to connect to VLAN 5.
Also, please be sure to post the output of
ubus call system board
so that we can understand the specifics of the devices in use here.
True, I suppose we all just get tunnel vision and situation seems trivial.
Fair enough. Very much possible. For reference, I went into the interfaces section → devices → add device configuration → under “Device Type” “VLAN (802.1q) and base device br-lan out of the drop-down menu. The rest is default, it autogenerated the name for me after I picked VLAN number. Not sure if that is alright.
So assume I do the exact same thing, but istead of creating a vlan device in the devices section I just use br-lan and make a separate interface called IOT. I only do it on the router, now if I do a static lease for a device connected to any of my APs, the router transfers it to the correct interface (IOT). Here is the config file for what I mean. Maybe I am missing something but it does seem to work, although I am testing it and it also behaves a bit weird, doesn’t seem to be obeying its own firewall settings(preliminary test I might be doing something wrong).
Did that, doesn’t change the issue it seems. It doesn’t have an interface at all it seems, I can’t pick if to tag the frames or untag them.
But can’t the router assign the VLAN tags? Like in the case above, with a regular interface? I will try and setup those interfaces on the APs, but I am thinking, dhcp is on the router only, APs have their DHCPs disabled, so even if I do interfaces on the APs the router itself will have to assign them to a different network.
In regards, to the hardware info, here (I know the firmware is old I am on it this week, but I don’t think it is relevant to the issue)
While it's not causing your issue, you should upgrade. The versions here are quite old...
Here, you're running 23.05.0-rc3. There was an RC4, the official stable release, and then 4 subsequent maintenence releases (the current in this series is 23.05.5 and 23.05.6 is actually being tested for release, likely also EOL at that point).
However, both of your devices can run 24.10, and I would recommend upgrading.
Again, not related to the issue at hand, but you may want to consider replacing this with something more modern for energy efficiency among other things. This is great little box for OpenWrt and will do well if you've got things like ad blocking, VPNs, snort, etc... but a more recent x86 box will be much more energy efficient for all of that. If you're just using it as a basic router, you can get a 'plastic all-in-one' type wifi router that will use a fraction of the power.
Now... back to the issue at hand:
I think that what OpenWrt created is correct (it did what you told it to do), but it's the wrong method for creating a VLAN on your system (the direct dotted notation is how it should work; in fact, you can set the device directly to eth0.5 and remove br-iot entirely because it's actually not necessary to use a bridge in this system).
For the AP, there are two possible approaches. I'd recommend actually setting up bridge-VLANs as described in the DSA mini-tutorial.
Oh, I see what you've done. Yeah, that's wrong -- it'll be unstable/unpredictable, and it entirely defeats the purpose of creating VLANs in essentially all respects.
An unmanaged switch, is, by its very definition, unmanaged. Thus it has no interface, no configurations/controls available to the user, and cannot handle tagging/untagging frames in any capacity. While more nuanced than this analogy, you can think of it as a simple splitter. A managed switch, on the other hand, can properly handle VLANs and can tag/untag on each port individually as needed, based on your goals.
No. VLAN tags are a Layer 2 construct. The router is operating at Layer 3 (and, to a degree, at the interface between L2 and L3).
The idea of the 802.1q tags are to identify the ethernet frames that belong to each network. Think of it like the team uniforms at the Olympics -- each country has its own uniform to clearly differentiate them from the others.
The VLAN-aware devices (switch, AP, etc.) are responsible for handling frames accordingly. So imagine you have a switch that has 5 ports and you want to have your uplink on port 1, ports 2-3 your lan, port 4 your IoT network, and port 5 a downlink to your AP... the switch needs to be able to handle the tagging/untagging at each port and allow the port-vlan membership assignments. This is why you need a managed switch. And it's also why you must have a VLAN aware AP (yours is, but not configured properly).
Yes, DHCP lives only on the router in your config (and generally speaking, there is only one DHCP server on any given subnet). The interfaces on the AP in your case will likely be: lan used for managing the device as well as wifi, so it will have an address on that network, iot passing through transparently, so it will be unmanaged but it will be using the bridge-vlan for VLAN 5 (tagged) in order to be able to work with the VLAN you setup on the router.
First of all thanks for the effort in troubleshooting this issue.
Duly noted. I will swap it out soon enough, its just what I had lying around that I got for 20$ in the nextdoor office when they were going out of business, basically free real estate
You’re 100% correct, I remember how I was doing it in the past and I don’t think that what I did now to generate the config file is the correct way(or rather not what is suggested in the documents I read, maybe it still would work, have not idea), the bridge is created separately. I did try direct dotted notation, same effect. Unfortunately the device still doesn’t get assigned.
Yes of course, I just did it as an example to demonstrate that subnet unaware device still gets assigned correctly by the router.
Yes of course, I misread, when you said to pass untagged frames, I thought you mean to untag them. Although switches are getting weirder, the new model of what I have here has dip switches to do weird things, including tagging frames and creating port priority.
Just for context I sort of did try all the solutions above, updated everything(read bricked the router for an hour haha) just in case still the result is the same.
My thought process is the following. Pure router is L3 yes but we have hybrid devices that also work as a switch and as such a switch can assign different mac addresses a different VLAN, if I am remembering correctly Netgear had that functionality. So it could use a dumb AP completely unaware of the VLANs and assign VLANs on the correct frames, and they would reach a router in the correct state. They also have the same functionality on some of their enterprise APs(not the ones that I have) so basically MAC Vlan assignment.
In theory a switch on the router should be able to function the same way. I think. Maybe dnsmasq is the wrong tool for it? I am looking through the source code of it, maybe I can make a hacky solution just to test but I am feeling more and more I don’t know enough about networking to do that.
I will also try and do the DSA Bridge via APs and maybe play around with bridge filtering on the router.
I've never heard of this except in the context of WPA2 (or WPA3) enterprise using a RADIUS server.
Setting up your router and your AP to have VLANs that work properly is actually trivial. The problem is that your unmanaged switch may be thwarting your efforts.
Not at all. The pages I’ve read on VLANs that are distributed by OpenWRT seem fine. I’ve read the general VLAN and the DSA one. All the examples are port based though, so I would assume it all works as advertised, and I personally didn’t test this but it is a completely different mechanism, they’re assigned at the network config file so I think they should work? No reason to suspect otherwise because I am trying to do it via DHCP side and it doesn’t work.
What I said was that I did create a VLAN bridge via LuCi and it was very close to a default config and it sort of generated a weird config file. It might still work we don’t know because I can’t assign anyone to any type of VLAN in the specific way I want to.
Yes that is probably the correct way to do that(and I think it should work) and I will do that (later). I think Radius can also just straight up assign MACs to a certain VLAN without involving APs (WPA2/WPA3). I just want to try doing that without Radius right now purely as an experiment. If Radius can do it, its doable, but probably not via DHCP or maybe not via Dnsmasq
See thing is what is weird to me is that for some reason the client never is even assigned to the interface. It gets assigned an IP that contradicts the directive that I’ve given it. If it was assigned and didn’t work or couldn’t actually send or receive packets that’s understandable, all things considered. Maybe there is a failsafe in dnsmasq to prevent assignment to VLAN networks and that’s why its ignoring my attempts. Not sure, I will have to investigate it further. If I manage to get it working via DHCP I will do a writeup on it (probably not really doable because there are quite a few posts already on it and no resolutions).
Can you please elaborate how a dhcpd is able to “assign” a vlan to a client….?
I have read the last few posts and come to the conclusion that you have some huge gaps in your knowledge but that you have mixed all these parts up…
Either with or without radius, the only component which has something to do with a wi-fi client and vlan is hostapd. But to be able to move a client onto a vlan interface the vlan interface is already present or hostapd is able to create one on the fly. But in any case you need a proper network config on the AP which supports these vlan.
And yes you can use vlans with hostapd without radius but only with wpa2 and not wpa2 enterprise because that would also involve radius.
Never said anything of the sort? The initial question was why DHCP server does not assign a client prescribed ip address out of the pool of a VLAN interface even though it is directed to do so. It can clearly do so with regular interfaces.
I do not understand this sentence. General idea, lack of knowledge in networking = mixing things up? Sure, I am on a forum asking for help right? Don’t come here to show off my skills.
Thank you for the suggestion. Interesting piece of software, see how it would be useful for something else, seems it can do a lot of things but at a glance do not see it being able to assign VLAN based on MAC addresses of clients. Creating a Vlan on the fly is not necessary.
To reiterate my point. What I do not understand is why does the DHCP server ignore my static lease configuration that issues it an IP address from a VLAN interface pool. I did not ask why does a DHCP server not tag frames with a VLAN. Like I said before if it didn’t work but was assigned an IP or even not assigned an IP that would be fine, but it is assigning it a random IP and the device still functions within a network.
The DHCP server will hand out dynamic or static IPs from the network / pool of the interface the requests comes in (ignoring a dhcp-relay for now)
If you configure a static IP from the IoT network for a device, but this device requests the IP on your LAN, then the DHCP server will hand out a dynamic one from the LAN network.
Think of it as separate DHCP servers.
That’s where hostapd comes in. You can configure VLANs per MAC address, then the right DHCP server gets the request and your statically configured ip for the MAC address is in scope and can be returned by the “IoT DHCP server”
If you use one or multiple SSID / passwords or assign based on MAC address is not important for the DHCP. The important part is only which interface / VLAN it receives the DHCP request on.
Maybe not said but written in the title. Maybe something got lost in translation, but how should I interpret that statement from the threads title then?
Edit ps:
Yeah most of the time that's the root cause.
Edit2 PPS: do you even have a working network config by now? The stuff you posted looks incomplete. Maybe you did not posted all content from each file?
That was my thought process. But then I did some tests and I had doubts about it. What threw me off was this:
Creating a separate DHCP server shows static leases as shared (in LuCI in the DHCP menu add a new server). So if I did put a rule to ignore said MAC address on one server it would copy the ignore rule on the other and basically it was either one or the other.
It does assign IP addresses to a pool of a different interface, so long as that interface is not a VLAN device.
There is a tick mark for the DHCP server in LuCI as “authoritative”, marking it as the only one.
I think you’re simplifying it for me but me not understanding this is bugging me :\
Thanks a lot for this, this is very helpful and looks really promising, I wonder if I can use the same passphrase and have different entries for MAC pools. Say a pool for IOT and then the rest for the Lan. Will test this.
Though the original question remains if the request is again coming from LAN wouldn’t the “wrong” DHCP server get the request? If they’re two different servers?
-//-
I am sorry for confusion. I thought its better for the title to use less words. I laid it clearly in the OP. I will add the word interface after VLAN should clear this up.
Yes, as was the case from the beginning. The network works fine, always did. What I am trying to understand is the anomaly in the DHCP server operation.
