Need some help with my setup, specially the vlans (graph included)

[mj_diamond]

Hello!

First of all, please excuse my ignorance, it's my first time using OpenWRT and i'm struggling a bit

This is the network layout that i designed and intend to deploy:

Please feel free to make any suggestions for improvements and point out errors

Couple of questions:

1. I have doubts about the lan configuration on the raspberry, i'm creating 5 vlans with their own firewall zones, should i delete the original LAN interface and its firewall zone? keep it as it is (br-lan or eth0)? or use it for Management instead of Vlan10?

2. Can i keep all the network devices on the Management vlan as intended? IPs being 10.10.10.0 to 4, or is this not possible?

3. Should i disable forwarding to the wan zone on that Management vlan? i understand that this is safer but correct me if i'm wrong, and could this cause issues in the network?

4. As you can notice, the third dumb AP (port 4 on the switch) does not support OpenWRT, or any custom firmware really, since is realtek based (hence, it's a really dumb AP ), so my plan is to untag everything coming from it to the Guest vlan and use MAC based vlan filter to redirect packages to Home, IoT and Security respectively, is this the correct and best approach? i know that this is a security flaw but i'll upgrade that AP in the future (all of them really, i want to deploy a mesh wireless network), this is a temporary fix

Thank you so much for reading, any help will be appreciated

[riodoro]

Hi,

I would use the LAN interface as the management Interface and leave it untagged for conveniance in case of misconfigurations.

2. 10.10.10.0 is not valid in case of a subnet mask 255.255.255.0
   Use 10.10.10.1-5 instead.

3. Then you're not able to update your Routers.

4. I would use static DHCP leases and create IP Firewall rules.

[psherman]

Your diagram looks generally okay, but there are some issues. First, though, I'll try to answer your direct questions:

@mj_diamond

I have doubts about the lan configuration on the raspberry, i'm creating 5 vlans with their own firewall zones, should i delete the original LAN interface and its firewall zone? keep it as it is (br-lan or eth0)? or use it for Management instead of Vlan10?

This doesn't really matter. You can modify the existing LAN interface to be tagged on the ethernet port, or you can delete it, or you can leave it there unused. I would keep it for the setup process -- if you mess things up with the other VLANs, you'll be able to use the standard LAN to connect. If you're not planning to use the standard LAN as defined, deleting it is fine once you have everything else working.

@mj_diamond

Can i keep all the network devices on the Management vlan as intended? IPs being 10.10.10.0 to 4, or is this not possible?

Yes, but...
First of all, if you are using /24 networks, you cannot use the .0 address. So you can use 10.10.10.1 - 10.10.10.254, but the .0 address is the address of the network itself and is not usable for any hosts. So renumber your addresses and you'll be okay here.
All of your VLAN aware devices can be managed on your desired management network, but the "really dumb AP" you talk about cannot participate in VLANs from your description. So that device will not be able to be part of the management network.

@mj_diamond

Should i disable forwarding to the wan zone on that Management vlan? i understand that this is safer but correct me if i'm wrong, and could this cause issues in the network?

So forwarding from management > WAN allows your infrastructure devices to reach the internet. Removing this will obviously isolate them. From a pure security standpoint, isolating them is preferable, but it will mean that those devices will not be able to easily install packages, update the time, or anything else that normally requires internet access. They also will not be useful for network diagnostics (such as checking for internet connectivity). You can always install any packages you need manually/offline, you can setup an NTP server on your main Pi router, sync with a browser, or just deal without the time on those devices. Alternatively, remove the forwarding rule and add it back if/when you need it, and then remove it again.

@mj_diamond

As you can notice, the third dumb AP (port 4 on the switch) does not support OpenWRT, or any custom firmware really, since is realtek based (hence, it's a really dumb AP ), so my plan is to untag everything coming from it to the Guest vlan and use MAC based vlan filter to redirect packages to Home, IoT and Security respectively, is this the correct and best approach? i know that this is a security flaw but i'll upgrade that AP in the future (all of them really, i want to deploy a mesh wireless network), this is a temporary fix

Nope. This won't work unless you use enterprise mode + radius authentication. The "really dumb AP" can only broadcast a single SSID. That SSID will be necessarily tied to a single VLAN. You cannot redirect those clients to another VLAN. You will want to replace that particular AP with something more capable, or just use it with a single SSID/VLAN.

Now, regarding your diagram -- I mentioned that 10.10.10.0 is not a valid IP if you are using /24 networks. This is true for all of your networks as defined in your diagram. 10.10.10.4 (your really dumb AP) can't happen because that device is not VLAN aware and is connected to a different VLAN (VLAN 30 instead of VLAN 10). Likewise, your cameras that connect to that really dumb AP cannot be on a different VLAN, either.

Finally, you have 2 USB storage devices that have addresses on the network. Because they are USB, they don't have the concept of networking included at all. If they are connecting to your OpenWrt router, they will be part of the router itself -- you'll need to install some packages for file sharing to enable network devices to access those resources. And since they will be connected to the router, they will be accessible from the router's addresses. Yes, addresses, plural. By default, it will not be limited to just the VLANs you have indicated. You'll use firewall rules to limit the access to only the VLANs of interest, but you may have difficulty making it so that the storage devices map 1:1 to the desired network.

[trendy]

Just to mention here that .0 can be a valid host address (rfc3021). Network address is practically not used anymore with classless networks.

root@magiatiko / > uci show network.guest
network.guest=interface
network.guest.proto='static'
network.guest.ip6ifaceid='random'
network.guest.force_link='0'
network.guest.ip6assign='64'
network.guest.ip6hint='17'
network.guest.ifname='eth0.2'
network.guest.ipaddr='172.17.17.0/24'
...
122: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 172.17.17.0/24 brd 172.17.17.255 scope global eth0.2
       valid_lft forever preferred_lft forever

and a successful ping from another host

PING 172.17.17.0 (172.17.17.0) 56(84) bytes of data.
64 bytes from 172.17.17.0: icmp_seq=1 ttl=64 time=1.29 ms
64 bytes from 172.17.17.0: icmp_seq=2 ttl=64 time=2.07 ms
64 bytes from 172.17.17.0: icmp_seq=3 ttl=64 time=2.59 ms
^C
--- 172.17.17.0 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.285/1.980/2.587/0.535 ms

[psherman]

While it may be true that OpenWrt will not prevent you from assigning .0 on a /24 network, this is not allowed by many other platforms. For example, I just tried this on an EdgeRouter X running the EdgeMax 2.0.9 firmware and got the following error:

All subnet calculator apps that I have ever seen also make it clear that the network address is not a host address. For example:

I would not recommend using the .0 address in any situation except for networks larger that /24.

Also, it should be noted that rfc3021 is targeting /31 networks (PTP), not /24's. As such, although it does say the the previous class based network spec that reserves the base address as the subnet ID is obsolete, it doesn't suggest that the base address should be used in networks other that /31.

EDIT: @trendy For grins, I tried making the router address .0 (on a /24) using OpenWrt 21.02. While DHCP did work and the router responded to pings, the network did not work for any external connectivity (i.e. the internet).

[mj_diamond]

Thank you all for your answers and help

@riodoro

1.I would use the LAN interface as the management Interface and leave it untagged for conveniance in case of misconfigurations.

@psherman

This doesn't really matter. You can modify the existing LAN interface to be tagged on the ethernet port, or you can delete it, or you can leave it there unused. I would keep it for the setup process -- if you mess things up with the other VLANs, you'll be able to use the standard LAN to connect. If you're not planning to use the standard LAN as defined, deleting it is fine once you have everything else working.

Got it, i'll just leave it as br-lan then, so if anything goes wrong i can unplug the switch from the Raspberry's NIC, connect my laptop instead, and access LuCi, is that correct? i may delete it in the future once i have a better understanding of this

@riodoro

2. 10.10.10.0 is not valid in case of a subnet mask 255.255.255.0
   Use 10.10.10.1-5 instead.

@psherman

2. Yes, but...
   First of all, if you are using /24 networks, you cannot use the .0 address. So you can use 10.10.10.1 - 10.10.10.254, but the .0 address is the address of the network itself and is not usable for any hosts. So renumber your addresses and you'll be okay here.
   All of your VLAN aware devices can be managed on your desired management network, but the "really dumb AP" you talk about cannot participate in VLANs from your description. So that device will not be able to be part of the management network.

Well, that exposes me as a newbie, haha

I'll change it then, 10.10.10.1 to 5 is ok, i started from 0 because i wanted the IPs on the Access Points to match their corresponding port on the switch, but that's a minor detail, no problem

As for the dumb AP, yes, i suspected that, but wasn't sure, i'll just set it to 10.10.30.5 for now

@riodoro

3. Then you're not able to update your Routers.

@psherman

3. So forwarding from management > WAN allows your infrastructure devices to reach the internet. Removing this will obviously isolate them. From a pure security standpoint, isolating them is preferable, but it will mean that those devices will not be able to easily install packages, update the time, or anything else that normally requires internet access. They also will not be useful for network diagnostics (such as checking for internet connectivity). You can always install any packages you need manually/offline, you can setup an NTP server on your main Pi router, sync with a browser, or just deal without the time on those devices. Alternatively, remove the forwarding rule and add it back if/when you need it, and then remove it again.

Oh, i haven't thought about that, that's quite a bit of inconveniences for me right now, i'll probably leave it as is and once i gain more experience i'll go with the "add when you need it" approach

@riodoro

4. I would use static DHCP leases and create IP Firewall rules.

That's a good solution, but my personal PC uses that AP and i need it to be on Home vlan (for accessing the Management vlan, SQM, and so on)

@psherman

Nope. This won't work unless you use enterprise mode + radius authentication. The "really dumb AP" can only broadcast a single SSID. That SSID will be necessarily tied to a single VLAN. You cannot redirect those clients to another VLAN. You will want to replace that particular AP with something more capable, or just use it with a single SSID/VLAN.

Now, regarding your diagram -- I mentioned that 10.10.10.0 is not a valid IP if you are using /24 networks. This is true for all of your networks as defined in your diagram. 10.10.10.4 (your really dumb AP) can't happen because that device is not VLAN aware and is connected to a different VLAN (VLAN 30 instead of VLAN 10). Likewise, your cameras that connect to that really dumb AP cannot be on a different VLAN, either.

Oh, i've read about radius authentication and it seemed a bit overkill for my setup, but then i found out about MAC based vlan filtering, and it looked like it was just what i needed, according to this guide: https://www.tp-link.com/us/configuration-guides/configuring_mac_vlan/

So, basically i'm using a single SSID on that AP, and everything connected to that WiFi (or any of the ports) goes to vlan30, BUT when a package arrives to the switch, if the device's MAC address matches one on the table, that package can be redirected to the corresponding vlan (20, 40 or 50), otherwise it stays at 30, am i missing something?

@psherman

Finally, you have 2 USB storage devices that have addresses on the network. Because they are USB, they don't have the concept of networking included at all. If they are connecting to your OpenWrt router, they will be part of the router itself -- you'll need to install some packages for file sharing to enable network devices to access those resources. And since they will be connected to the router, they will be accessible from the router's addresses. Yes, addresses, plural. By default, it will not be limited to just the VLANs you have indicated. You'll use firewall rules to limit the access to only the VLANs of interest, but you may have difficulty making it so that the storage devices map 1:1 to the desired network.

Oh, it's more complex than i thought, haha, honestly i haven't dug into this part yet, but what you are saying makes sense

I had seen this guide about achieving this using Samba but that's about it, i assume my solution is to use that in conjunction with firewall rules as you explained

Again, thank you all for your help!

[mj_diamond]

@trendy

Just to mention here that .0 can be a valid host address (rfc3021). Network address is practically not used anymore with classless networks.
...

@psherman

While it may be true that OpenWrt will not prevent you from assigning .0 on a /24 network, this is not allowed by many other platforms. For example, I just tried this on an EdgeRouter X running the EdgeMax 2.0.9 firmware and got the following error:
...

Yep, this is out of my scope, haha, but again i'll probably stick with 10.10.10.1+, to avoid any legacy and compatibility issues

Thank you!

[psherman]

@mj_diamond

So, basically i'm using a single SSID on that AP, and everything connected to that WiFi (or any of the ports) goes to vlan30, BUT when a package arrives to the switch, if the device's MAC address matches one on the table, that package can be redirected to the corresponding vlan (20, 40 or 50), otherwise it stays at 30, am i missing something?

This works with wired devices, but I don't think it will with wireless. You can try it, but I suspect it will not work.

[mj_diamond]

@psherman

This works with wired devices, but I don't think it will with wireless. You can try it, but I suspect it will not work.

Interesting

Yes, the guide talks about "laptops in a meeting room" but they don't specify if they are wired of wireless (although i would suspect the latter)

I'll try it and post the results here, wish me luck haha

[slh]

@psherman

I would not recommend using the .0 address in any situation except for networks larger that /24.

Even with larger networks, success using .0 addresses at all will vary - a lot. There are a lot of broken devices (including network infrastructure devices) which won't cope with the presence of .0 addresses at all.

--
I am using as /14 subnet myself and started out assigning (there valid) .0 addresses for devices, this works fine with OpenWrt, general purpose linux and even windows, but quite a few proprietary network devices will fail miserably.

[trendy]

Sorry for hijacking the thread, again. There is a draft for lifting the restriction of using the lowest address in a subnet for hosts regardless of the mask. Sure, we were all taught that the network and broadcast addresses are not to be used for hosts. Also before rfc3021 we were told that /31 is not meant to be used, due to this limitation.
It's expected that ip calculators and the management tools will not let you use the network address as a host, they have been programmed like that.
What I have seen is ISPs allocating public IP subnets, using the lowest address. For example the ISP had 172.29.29.0/29 as their router address, leaving .1-6 for the client.
Most likely not all devices will support it, but it will be another step to squeezing most of the available IPv4 addresses, same thing that happened with subnet zero and subnet all ones.

[psherman]

@trendy - have you tried using the 0 address for the router and actually had success with L3 connections through that router? It will not work based on my test yesterday, unless I missed something.

The 0 should just simply not be used unless there is a real reason. We have plenty of ipv4 addresses in the rfc1918 space for the context of home and small business environments, so there is no reason to even bother. On the broader scale of the internet at large, obviously it does account for many ips, but ipv6 makes it such that there is again little to bo reason to mess with the old issues on ipv4

[riodoro]

@mj_diamond

That's a good solution, but my personal PC uses that AP and i need it to be on Home vlan (for accessing the Management vlan, SQM, and so on)

You can enable the management access in the firewall rules.

@mj_diamond

Oh, i've read about radius authentication and it seemed a bit overkill for my setup, but then i found out about MAC based vlan filtering, and it looked like it was just what i needed, according to this guide: https://www.tp-link.com/us/configuration-guides/configuring_mac_vlan/

Looks interesting:

Configuration Guidelines
When a port in a MAC VLAN receives an untagged data packet, the switch will first check whether the source MAC address of the data packet has been bound to the MAC VLAN. If yes, the switch will insert the corresponding tag to the data packet and forward it within the VLAN. If no, the switch will continue to match the data packet with the matching rules of other VLANs (such as the protocol VLAN). If there is a match, the switch will forward the data packet. Otherwise, the switch will process the data packet according to the processing rule of the 802.1 Q VLAN. When the port receives a tagged data packet, the switch will directly process the data packet according to the processing rule of the 802.1Q VLAN.

May work if it is supported by your switch.

[trendy]

@psherman

have you tried using the 0 address for the router and actually had success with L3 connections through that router? It will not work based on my test yesterday, unless I missed something.

I had success using Win10 as a host.
Linux Mint didn't let me use .0 as gateway.
OpenWrt as a cascaded router allows it, but there seems to be something wrong with arp, as it doesn't respond to the main router arp requests for some reason and there is unidirectional packet flow. For example ping to some internet server, reply comes back, but isn't sent to originator.

@psherman

The 0 should just simply not be used unless there is a real reason. We have plenty of ipv4 addresses in the rfc1918 space for the context of home and small business environments, so there is no reason to even bother. On the broader scale of the internet at large, obviously it does account for many ips, but ipv6 makes it such that there is again little to bo reason to mess with the old issues on ipv4

I agree with you. At home it doesn't make any difference. The ISP scenario is a bit particular but there could be someone using OpenWrt as client side router.