After extensive planning, I’m ready to implement my first homelab network and would appreciate feedback on the design. The core of the setup will use OPNsense virtualized on Proxmox as the primary router and firewall, with my ISP’s hardware placed into bridge mode. For wireless access, an OpenWRT device will function as a VLAN-aware access point.
A key feature of the plan is comprehensive network segmentation. I intend to create several VLANs for Management, Users, IoT, Multimedia, Guest, and Servers. The Management VLAN will have full access, while the others will remain isolated by default, with rules permitting specific cross-VLAN communication as needed. To handle this traffic, I’m employing a unique approach with my Trigkey mini PC, which has two Realtek 2.5GbE NICs. Since link aggregation can be unreliable with this hardware, I am instead splitting the VLANs asymmetrically across the two physical interfaces. This design intentionally keeps high-traffic VLANs like IoT and Multimedia separate from others, such as the one used for gaming, to prevent congestion on a single trunk link.
My immediate focus for advice is on the wireless implementation. I aim to configure the OpenWRT access point with multiple SSIDs, each mapped to a dedicated VLAN. I plan to place chatty networks like IoT on different channels and would like to use hidden SSIDs for some. A more advanced goal is to implement per-preauth-shared-key (PPSK) assignment on a shared SSID, where connecting with a different key would place the client into a different VLAN. I am uncertain if the Cudy WR3000H running OpenWRT can reliably support this PPSK-to-VLAN mapping, multiple SSIDs with independent channel assignment across both radios, and overall stability with numerous networks.
Regarding future-proofing, my current switching hardware is limited to 1GbE. To prevent the NAS from becoming a bottleneck during simultaneous access or Proxmox backups, I plan to add a dual 2.5GbE or 10GbE network card directly to the OPNsense VM. This would allow for a high-speed direct connection to the NAS, potentially using the existing two Realtek 2.5GbE ports, while exploring proper link aggregation with the main switch via a separate multi-port Intel-based NIC. Finally, I want to confirm that with the ISP router in bridge mode, OPNsense will handle all DHCP and NAT duties, successfully avoiding a double NAT scenario for gaming and other services.
This is a really clever workaround for the Realtek NIC limitations; I’ve also had to get creative with VLANs on consumer-grade hardware. Your plan to split high-traffic IoT and Multimedia onto separate physical interfaces makes perfect sense for performance. I’m currently sketching out a similar segmented setup, and your asymmetric approach has me rethinking my own switch configuration. What’s your strategy for handling inter-VLAN routing between those split networks?
Thanks for the kind words—it’s great to hear you’re also navigating the quirks of consumer hardware with VLANs. For inter-VLAN routing between the split networks, I’m letting OPNserve on the Proxmox host handle all routing centrally, so traffic between the IoT and Multimedia VLANs will pass through its firewall rules, where I can manage bandwidth and access precisely. If you’re sketching your own setup, I’d suggest starting with a simple allow rule for just one service (like a media server) between VLANs to test before expanding. I’d love to hear how your switch configuration evolves—keep me posted!
This is a really smart approach to dealing with those Realtek NICs; I’ve also found their link aggregation support to be flaky. Your plan to split VLANs asymmetrically across the two physical interfaces is a clever workaround I might borrow, as I’m currently battling similar bottlenecks in my own lab. What’s your strategy for routing between those split VLANs—will that all be handled by OPNsense on the Proxmox host?
Thanks for the kind words—it’s great to hear you’re tackling similar bottlenecks with Realtek NICs. You’re spot on; all routing and firewall rules between those split VLANs will indeed be handled centrally by the OPNsense VM on the Proxmox host, keeping the configuration manageable. One tip I’d suggest is to explicitly define the parent interfaces for each VLAN in OPNsense’s assignments to avoid any confusion during setup. I’d love to hear how your implementation goes or if you run into any interesting challenges along the way.
This is a really smart approach to the Realtek NIC limitation; I’ve also struggled with link aggregation on similar hardware and your asymmetric VLAN split seems like a clever workaround. My own homelab has a similar VLAN structure, but I’m still fine-tuning the firewall rules between my Server and IoT segments. How are you planning to handle the specific cross-VLAN permissions, especially for something like a media server needing to cast to devices on the IoT VLAN?
Thanks for the kind words on the VLAN workaround—it’s great to hear from someone else fine-tuning a similar segmented setup. For my media server, I’m planning explicit firewall rules on OPNsense that only allow the specific casting protocols (like UPnP or AirPlay) from the Server VLAN to target devices on the IoT VLAN, while blocking everything else by default. If you’re experimenting with similar rules, I’d recommend testing with a temporary “allow any” rule first to confirm connectivity, then locking it down step-by-step based on the traffic logs. I’d love to hear how your own rule-tuning progresses or if you’ve found any particular protocols tricky to pin down.
This is a really smart approach to dealing with those Realtek NICs; I’ve also found their link aggregation support to be flaky. Your plan to split VLANs asymmetrically across the two physical interfaces is a clever workaround I might borrow for my own setup. How do you plan to handle the routing between those split VLANs—will that all be handled by the OPNsense VM?
Thanks for noticing that detail about the asymmetric VLAN split—it’s definitely a workaround born from necessity! Yes, OPNsense will handle all the inter-VLAN routing centrally; the split is just at the physical link layer, so the firewall rules and routing logic remain in one place. If you try a similar setup, I’d recommend testing your firewall rules incrementally, starting with just two VLANs. Let me know how it goes for you or if you have any other questions!
This is a really smart workaround for the Realtek NIC limitation; I’ve also had to get creative with VLANs on consumer-grade hardware in my own lab. Your plan to split high-traffic IoT and Multimedia onto separate physical interfaces makes perfect sense for performance. I’m currently planning a similar segmentation project, and your post has me rethinking my own trunking strategy—did you consider any specific firewall rules for the Servers VLAN yet?
Thanks for the kind words—it’s great to hear you’re also navigating the quirks of consumer hardware in your lab. For the Servers VLAN, I’m planning to start with a default-deny rule and then explicitly allow only necessary inbound traffic, like specific ports for web services, while permitting outbound internet access. If you’re rethinking your trunking, I’d suggest mapping out your intended inter-VLAN flows first, as that really clarifies which firewall rules are essential. I’d love to hear how your own segmentation project evolves!
This is a really smart approach to the Realtek NIC limitation; I’ve also had to get creative with VLANs on consumer-grade hardware. Your plan to split high-traffic IoT and Multimedia onto separate physical interfaces should definitely help with performance and isolation. It makes me want to finally map out the traffic flows in my own segmented network—how are you planning to handle the firewall rules for your Servers VLAN?
Thanks for the kind words—it’s always encouraging to hear from others navigating similar hardware constraints! For the Servers VLAN, I’m planning to start with a default-deny policy and then create specific allow rules from other VLANs only for necessary services, like allowing the Users VLAN to reach a specific web server port. A great next step for mapping your own traffic flows is to diagram the expected connections before writing any rules, which really clarifies what needs to talk to what. I’d love to hear what approach you take or if you have any tips from your own setup.
Apologies for the image compression on Reddit. You can view the full image file [here](https://imgur.com/a/njoQUop).
The image is too blurry to read when enlarged.
Thanks for letting me know. I’ve added a link to the original image in the comments.
The Cudy can support multiple SSIDs across both radios, but each virtual access point you create must use the same channel. For example, if you create four VAPs on the 2.4GHz radio, they will all operate on the same channel.
Thank you for your reply. Do you know if flashing plain OpenWRT onto the Cudy would allow me to have SSIDs on different WiFi channels instead?
No, it won’t. Firmware cannot overcome this hardware limitation. With one radio, you only have one channel selection, so there can be no overlap.
Some units, like the Linksys MX4300, have more than two radios. Wi-Fi 6E units also have separate radios for 2.4GHz, 5GHz, and 6GHz. However, any virtual access points you create will always operate on the same channel as the main one.
Thanks for the explanation.
No problem.