When you setup your single ethernet port (let's call it eth0) as a VLAN trunk port, you'll get the ability to configure multiple virtual interfaces off of it. How many virtual interfaces you get depends on how many VLANs you want to tag traffic for. For example, if you have 2 VLANS with ids 100 and 200 (100 being your public Internet-facing traffic, and 200 being your LAN traffic), you would then have interfaces eth0.100 and eth0.200 to work with that you can then use in your firewall scripts as if they were two separate, physical interfaces.
This of course means you need a VLAN-aware switch that this single ethernet port can plug into, configured as a VLAN trunk (in Cisco terms) port. You would then want to configure one of the other switch ports as a VLAN access port assigned to VLAN 100 (untagged). This is the port you would plug your cable modem into. Then (in the simplest example) you could assign all the rest of the switch ports to VLAN 200 (untagged), and you would plug all your LAN devices into them.
Yes. You can take advantage of Netfilter's flowtable infrastructure and if you have the right hardware (NVIDIA/Mellanox ConnectX-5 or MediaTekMT7621) it will actually offload the processing of these packets to the NIC hardware. This only applies to established connections, however, but that typically accounts for like 95% of the traffic passing through.
You can still use the iptables interface for nftables rules if you'd like, but I think you miss out on things like atomic application of rulesets, ranges, lists, and variables (not shell variables).
- PCEngines APU (x86, AMD T40E) (my current router/firewall) (discontinued)
I'm also currently using an APU2 as one of my wireless access points (with hostapd).
All of these have been solid machines that have given me zero problems.
The next system I plan to use is going to be a Banana Pi R4 (ARM Cortex A73), it's a solid choice for a simple router/firewall/DNS/DHCP box. It has a built-in 4-port gigabit switch where each interface can be used as normal Linux interfaces, as well as 2 SFP+ ports that are capable of supporting up to 10 gig ethernet.
It's also one of the few systems that offers true hardware offloading for connection tracking, so things like netfilter flowtables don't have to use any main CPU processing.
I'm currently experimenting with a Banana Pi R4 as a Wifi7 access point (running Debian with hostapd), however the current state of the wifi7 module for it (BPI-R4-NIC-BE14) and Linux driver (mt7996e) is still pretty young and a bit buggy (i.e., limiting transmit power to 6 dBm without patching the driver to override it, and there's apparently a lack of RF shielding which can contribute to low SNR on the receiving end). With the proper patches in place it makes a decent Wifi 6 access point. I'm hoping these issues get ironed out in the future and I can use it as a true Wifi7 AP. frank-w is doing outstanding work to help support the open source community with this new hardware.
One suggestion though: rather than doing this all on a single LAN network and having to deal with adding exceptions for devices that still need access to the Internet during 'bedtime' periods, I suggest creating a separate VLAN for devices that need 'bedtime' enforcement and put those devices there, while leaving your 'always online' devices in your main VLAN where access to the Internet is always available. This way all you have to do is simply change your firewall rules for that VLAN to enforce bedtime, which removes the extra rules needed for exceptions.
This is also the approach I would have used - I was surprised the author didn't end up here. I used a separate VLAN to achieve same thing as author to shutdown internet access on the VLAN my kids devices use at bedtime, as well as another VLAN with no internet access at all for IoT devices, security cameras etc.
Blocking all UDP traffic by default is something I would never have even attempted for a domestic setup either. As the author discovers with Discord and Roblox, a great many common applications and games rely upon it. A UDP block on my kid's VLAN would last about 5 seconds before they attacked me for breaking their online Minecraft games.
The next(I think? It's in -CURRENT now anyway.) version of OpenBSD will be adding VLAN awareness to veb(4). Should make my OpenBSD home router experience much easier.
Unfortunately, I think that's likely the case for anyone on the younger side. Most of that came to light in 2013, 13 years ago. Anyone 20-30 years old today would've been a teenager then in high school, and likely not paying attention very closely.
It was big news for a little bit, and then the media by design quickly forgot about it barely a year later, and that is why history is doomed to repeat.
This of course means you need a VLAN-aware switch that this single ethernet port can plug into, configured as a VLAN trunk (in Cisco terms) port. You would then want to configure one of the other switch ports as a VLAN access port assigned to VLAN 100 (untagged). This is the port you would plug your cable modem into. Then (in the simplest example) you could assign all the rest of the switch ports to VLAN 200 (untagged), and you would plug all your LAN devices into them.
reply