Yes, it supports VLANs and has a very good price point for 4x10GB ports ā¦
Since you want a Guest VLAN, make sure the APs support it ā¦ mesh ones will require a controller and let you configure things once (TP link deco, omada, Unifi), non mesh ones will need to be configured using the same settings but youāll probably not get seamless roaming between them ā¦
The VM will be the easier to manage option ā¦ when changing stuff in the firewall you will not impact things happening on the NAS (think applying the wrong firewall rule and cutting out access to the wrong subnet to the NAS, maybe your pc included ā¦). You will be able to test different firewall options (plain linux, openbsd, freebsd)
As for what option is best for you it really depends on how much manual config you want to get yourself into versus the time it will take to get up and running, and also how much you are willing to configure manually when you want to add services/functionality and how much you want to manually set up things
If you go the manual way, Iād suggest looking into nftables instead of iptables
If you want a middle ground, have a look at vyos, itās linux based (debian), no gui, you can still have a look at all the config files, gives you a lot of options when you grow past your current simple needs (BGP/VRRP router, IPV6, wan load balancing) but it still requires you to get into the how things are working in order to get it running properly
If you want to feel like you are cheating (and not understand fully whatās happening) then pfsense/opnsense have a nice gui an plenty of ātutorialsā
As an example, this is my current setup using Vyos (inside a Proxmox hypervisor, used to be truenas scale until two weeks ago):
vyos@vyos:~$ sh int
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
eth0 172.30.2.1/24 u/u LAN
beef:beef:beef: beef:beef: beef:beef:beef/64
eth1 192.168.101.144/24 u/u TIM-TEST
eth2 xxx.xxx.xxx.xxx/10 u/u STARLINK
beef:beef:beef: beef:beef: beef:beef:beef/64
eth3 192.168.200.1/24 u/u STORAGE
eth4 172.30.3.1/24 u/u IOT
beef:beef:beef: beef:beef: beef:beef:beef/64
eth5 172.30.4.1/24 u/u GUEST
lo 127.0.0.1/8 u/u
::1/128
wg0 10.223.220.2/24 u/u VPN-to-OCI
- 4 internal VLANS (LAN - STORAGE-IOT-GUEST)
- 2 WAN interfaces (TIM-TEST-STARLINK)
- 1 Wireguard interface to a cloud based VPS (VPN-To-OCI)
Starlink provides an IPV6 routable network, so I am using that to assign IPV6 addresses to all my internal devices that support it
Outgoing traffic is load balanced across the two WANS by default, but I ghave some policies to direct specific IPs over one or the other:
vyos@vyos:~$ sh wan
Interface: eth1
Status: active
Last Status Change: Mon Apr 17 19:54:23 2023
+Test: user Script: /config/scripts/tim_check.sh
Last Interface Success: 0s
Last Interface Failure: n/a
# Interface Failure(s): 0
Interface: eth2
Status: active
Last Status Change: Mon Apr 17 19:54:23 2023
+Test: user Script: /config/scripts/starlink_check.sh
Last Interface Success: 0s
Last Interface Failure: n/a
# Interface Failure(s): 0
vyos@vyos:~$ sh conf com | match wan
set load-balancing wan rule 20 description 'docker per packet lb'
set load-balancing wan rule 20 inbound-interface 'eth0'
set load-balancing wan rule 20 interface eth1 weight '1'
set load-balancing wan rule 20 interface eth2 weight '1'
set load-balancing wan rule 20 per-packet-balancing
set load-balancing wan rule 20 protocol 'all'
set load-balancing wan rule 20 source address '172.30.2.176'
set load-balancing wan rule 50 description 'Docker prefer TIM for DNS'
set load-balancing wan rule 50 destination address '8.8.4.4'
I still have access to all the low level information (and then some) the linux subsystem has been configured according to the Vyos cli commands:
vyos@vyos:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
S>* 0.0.0.0/0 [210/0] via x, eth2, weight 1, 00:28:50
* via 192.168.101.1, eth1, weight 1, 00:28:50
S>* 10.128.8.0/24 [1/0] is directly connected, wg0, weight 1, 00:28:50
C>* 10.223.220.0/24 is directly connected, wg0, 00:28:51
C>* x/10 is directly connected, eth2, 00:28:52
C>* 172.30.2.0/24 is directly connected, eth0, 00:28:55
C>* 172.30.3.0/24 is directly connected, eth4, 00:28:54
C>* 172.30.4.0/24 is directly connected, eth5, 00:28:55
S>* 192.168.100.0/24 [1/0] is directly connected, eth2, weight 1, 00:28:50
C>* 192.168.101.0/24 is directly connected, eth1, 00:28:54
C>* 192.168.200.0/24 is directly connected, eth3, 00:28:54