My intention is to connect my Debian server to two networks (vlan ids 20 and 21, each with interfaces created). If I set the port to untagged with a single VLAN ID of 20 (so the server wouldn't handle VLANs at all) then the configuration works.
/etc/network/interfaces on the server side looks like this:
auto eno1
iface eno1 inet manual
auto eno1.20
iface eno1.20 inet static
address 10.0.20.2/24
auto eno1.21
iface eno1.21 inet static
address 10.0.21.2/24
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 (red circle; this works best in the 'Markdown' composer view in the blue oval):
Remember to redact passwords, VPN keys, MAC addresses and any public IP addresses you may have:
ubus call system board
cat /etc/config/network
cat /etc/config/dhcp
cat /etc/config/firewall
I've just noticed that pings are getting to the server from the router itself but not from other devices such as the ones on the redacted-1 network. Firewall issue? Firewall wasn't a problem when the port was untagged.
Everything looks generally fine, although I would make one recommendation:
Where you have untagged networks defined:
I would recommend explicitly specifying the untagged+PVID nature of that port by adding :u* as shown below:
list ports 'lan3:u*'
That said, each of your networks is assigned to exactly one port. I see that port lan2 has VLANs 20 and 21. They look to be properly defined.
On the other end of the cable, you need to have a corresponding configuration that expects to see VLANs 20 and 21 -- both tagged. What is connected to port lan2 and have you configured it to expect the tags?
What network(s)/VLAN(s) are used for the server?
Firewall things don't change as a function of the tagging of the networks on the ports.
I have implemented your recommendation for the untagged networks, thanks.
The server is connected directly to the port lan2. It runs Debian. You can see /etc/network/interfaces in the OP. The intention is for the server to connect to two networks: its own, server (10.0.20.2/24) and the iot network (10.0.21.2/24). If the server is connected to both of these networks, then it can connect to the Internet and personal devices on other LAN networks through the server network, and also communicate with 2,4GHz WiFi-enabled smart home devices on their own iot network, which is supposed to be isolated from the Internet via firewall zone rules (to be done).
From what I can see so far, the tagging does actually work, because I can ping the Debian server on both IPs that I have assigned to it (10.0.20.2 and 10.0.21.2) from the router; pinging from other devices, for example from those on the network redacted-1 (10.0.67.0/24) does not work. Could it then be a hardware issue, where the switch fails to forward packets from untagged to tagged? I'm not very well versed in layer 2 networking.
This is not Layer 2 networking -- it's layer 3 because routing is involved when you are crossing subnets.
readacted-1 (10.0.67.0/24) is allowed to forward to server (10.0.20.0/24) per this forward statement:
However, there is no such rule for redacted-1 to forward to the iot network/zone.
Check the local (host level) firewall on this device as it may be blocking incoming connections from the redacted-1 network (and/or all non-local subnets).
Personally, I'd use the router to handle the IoT connectivity. The general assumption is that IoT devices are untrusted. With that in mind, you don't want to give direct access to the trusted host(s) (i.e. your server) from the IoT network/devices. Therefore, allowing the server network to forward to the iot network means that your server will initiate the connections to the untrusted devices (which can then reply, but they cannot initiate the connections themselves). If you need the iot devices to be able to initiate the connection, you can create a restricted flow in the other direction with firewall rules that permit only the desired ports/services.
That said, some IoT devices ned to be able to run services via mdns or other local (non-routed) means. if that is the case, your current topology may be necessary (there are ways to forward mdns across subnets, too).
This approach is definitely more architecturally sound, I'll likely go with it. I mainly just wanted to play with VLANs for the sake of it.
Is such a rule required for connectivity if I were to ping the IP address 10.0.20.2 and not 10.0.21.2? I feel like it should go through. Not to mention, this setup worked without tagged VLANs and the iot network involved.
this setup worked without tagged VLANs and the iot network involved.
I was just pointing out that your current firewall rulesets allow redacted-1 > server, but not redacted-1 > iot. Therefore, attempts to ping 10.0.21.0/24 from 10.0.67.0/24 will fail based on the firewall config. This is fine as long as it is the intended behavior. Of course, pinging 10.0.20.0/24 will work because the firewall allows it.
The above should be true regardless of the tagging.
This is great information. Thanks for running that test.
We know that the firewall on the router allows the pings, so it comes down to the server's configuration (network settings and/or host level firewall).
