Router-on-a-Stick vs Dedicated Firewall for a Home Lab

You've outgrown a flat network. You want VLANs to isolate lab gear from IoT devices from personal machines, and now you're facing a topology question that looks like a product question: should one gateway handle all routing and firewalling, or should you split those jobs across separate boxes?

This is not a brand decision. It's a decision about where inter-VLAN traffic crosses a security policy, where it gets routed, and what breaks when something fails. Get the topology right first, and the product choices narrow themselves.

What the Two Architectures Actually Change

Router-on-a-stick is a VLAN trunk design. Multiple VLANs ride over a single physical link (the "stick") to one gateway, and that gateway handles both inter-VLAN routing and firewall policy. Every packet that moves between VLANs crosses that trunk and gets processed by the gateway. Netgate's documentation shows this as a supported configuration—multiple VLANs terminated on a single port of a pfSense-based gateway—and it's a common way to add segmentation without buying more hardware.

The dedicated split separates two jobs that router-on-a-stick combines. A dedicated edge firewall handles WAN connectivity, NAT, VPN termination, and the security boundary between your network and the internet. Whether inter-VLAN routing also stays on that firewall, or moves to a separate Layer 3 switch, is a second decision—not an automatic part of buying a dedicated firewall.

That second decision matters because a Layer 3 switch routes traffic between VLANs in hardware, using dedicated ASICs rather than a general-purpose CPU. As TP-Link's guidance puts it, Layer 3 switches are designed for routing inside a LAN, while routers remain necessary at the edge for WAN connectivity and advanced firewall and security policies.

The critical distinction: routing is not firewall inspection. A Layer 3 switch that forwards packets between VLANs is not applying stateful firewall policy, not doing NAT, and not terminating VPNs.

So the real question is not "which box should I buy?" It's "where do I want inter-VLAN traffic to cross a security policy, and where am I willing to let it route freely?"

The Fast Answer: Which Architecture Fits Your Lab

	Router-on-a-Stick	Split Edge Firewall + Optional L3 Switch
Best for	Small labs, VLANs as isolation labels, light east-west traffic	Heavy inter-VLAN traffic, uptime during firewall maintenance, L3 learning goals
Core advantage	One box to configure, one policy domain, simpler recovery	Hardware-speed internal routing; routing can survive firewall reboots
Main tradeoff	All inter-VLAN traffic shares one trunk and the gateway CPU	Two or more devices, more configs, more deliberate policy design
Choose when	Most traffic is north-south (to the internet)	Bulk data moves between VLANs regularly
Skip when	You run storage replication or backups across VLANs	Your VLANs are mostly labels and east-west traffic is trivial

Router-on-a-stick wins when your VLAN count is small, east-west traffic is modest, and you want one box to configure and one failure story to reason about. If most of your traffic is north-south—to the internet and back—and your VLANs are mostly isolation labels keeping IoT devices away from your NAS, the simpler design is the lower-maintenance default.

The split design earns its complexity when inter-VLAN traffic is heavy, when you want internal routing to keep working while the edge firewall is down or being updated, or when you specifically want hands-on experience with Layer 3 switching.

The flip point is straightforward: if your lab mostly talks to the internet, router-on-a-stick costs you nothing in practice. If your lab mostly talks to itself, the shared path becomes the bottleneck.

Where Inter-VLAN Traffic Flows and Why It Matters

The traffic path is the mechanism that drives this entire decision.

In a router-on-a-stick design, every inter-VLAN packet crosses the trunk link and gets processed by the gateway. That means the same path handles your NAS-to-VM backups, your container-to-database traffic, and your workstation-to-internet browsing. The gateway's forwarding path and the single link are shared by all internal routing.

In the split design, a Layer 3 switch routes permitted internal traffic in hardware. The switch fabric handles Layer 2 and Layer 3 decisions at the same hardware speed, and that load never touches the firewall's CPU. The firewall only sees traffic that actually needs to cross the security boundary.

The consequence is concrete: heavy east-west traffic—NAS to VM, backup jobs, replication between hosts—can saturate a router-on-a-stick trunk or gateway CPU long before nominal port speed suggests a problem. Netgate forum users have described exactly this migration pain: moving from a standalone router to a pfSense-based router-on-a-stick and hitting throughput problems routing between VLANs. Treat those reports as configuration-specific friction, not a universal ceiling—the actual limit depends on the gateway, the switch, the rule set, and the traffic pattern.

Light east-west traffic means the shared path is rarely the bottleneck. If your VLANs mostly isolate devices that each talk to the internet, the router-on-a-stick design costs nothing in practice.

The mechanism matters here: software routing on a general-purpose CPU is not the same as ASIC-based hardware routing on a switch. A switch routes in dedicated silicon designed for line-rate forwarding. A router or firewall runs routing in software, which makes it more flexible for complex edge functions but slower for high-volume inter-VLAN routing.

Throughput Limits: What Actually Bottlenecks

Do not trust nominal port speed. The bottleneck in either design can be the trunk link, the gateway CPU, the firewall rule set, encryption, or enabled inspection features—not the port speed printed on the box.

In a router-on-a-stick configuration, the trunk link carries all VLAN traffic in both directions. That makes it a shared aggregate path: bidirectional or concurrent traffic consumes the same capacity. As a simplified example, a 1 GbE trunk carrying inter-VLAN traffic in both directions gives you roughly 500 Mbps per direction for that traffic—but real-world results depend on packet sizes, concurrent flows, the gateway's CPU, and whether hardware offload is active. Community reports on Ubiquiti and MikroTik forums both flag the trunk link as a real constraint in router-on-a-stick configs, independent of how capable the router's CPU might be.

Aggregate and east-west traffic matter more than one speed test. A lab that mostly talks to the internet may never approach the shared-link limit. A lab running backups between a NAS on one VLAN and VMs on another will hit that limit during every backup window.

VPN and inspection features change the picture regardless of architecture. Encrypted or inspected traffic consumes CPU whether it's crossing a trunk or a dedicated WAN interface. A gateway that routes 1 GbE of plain traffic can choke on far less VPN traffic if the CPU lacks hardware acceleration for encryption. Moving internal routing to a switch does not offload VPN termination or deep packet inspection.

Here's a practical way to estimate your own load:

• What crosses VLANs regularly? List the flows: NAS to VM, VM to VM, workstation to lab, IoT to anything.
• How much of it is bulk transfer? Backups, replication, large file copies, VM migrations.
• How much is light control traffic? SSH sessions, API calls, DNS queries, management traffic.

If the answer to the second question is "a lot," you have an east-west problem that router-on-a-stick makes worse. If the answer is "almost none," the shared path is not your constraint.

VLANs and the Security Boundary

A Layer 3 switch can route between VLANs in hardware, but that routing is not stateful firewall inspection, NAT, or VPN termination. This is the most common conceptual error in home-lab networking: assuming that inter-VLAN routing on a switch is equivalent to firewall enforcement.

Router-on-a-stick centralizes policy. Every inter-VLAN flow crosses the same gateway, so one rule set governs internal segmentation and the WAN edge. If you want the lab VLAN to reach the internet but not the personal VLAN, you write that rule once, on the gateway, and it applies to every path.

The split design forces a decision about which flows must cross the firewall and which can be routed locally. That's more powerful—you can let high-volume trusted traffic route at wire speed while forcing sensitive flows through inspection—but it's easier to get wrong. The failure mode is silent: you configure a rule on the firewall allowing VLAN 10 to reach VLAN 20, but the switch is routing that traffic locally, so the firewall rule never sees it. Or worse, you assume the firewall is protecting a VLAN boundary that the switch is actually routing around.

One Netgate forum user who moved from router-on-a-stick to an L3 switch plus pfSense design noted that they saw no difference in firewall states compared to their previous setup—because the traffic they expected to cross the firewall was being routed locally by the switch. That's the hidden dependency: the split design only enforces policy on traffic that actually crosses the firewall.

The tradeoff is centralized policy simplicity versus local routing efficiency with a more deliberate policy design. Router-on-a-stick makes it hard to accidentally route around your firewall. The split design makes it easy to accidentally route around your firewall without realizing it.

Failure Domains and Maintenance Burden

Home-lab builders live with these boxes 24/7. The maintenance tradeoff is often the real cost of the split design, not the hardware price.

Router-on-a-stick is one failure domain. A gateway update, reboot, or crash takes down routing and policy for every VLAN at once. When the gateway goes down, the whole network goes down—internal routing, internet access, everything. That's a simple failure story: one box to check, one config to recover.

The split design separates those domains. Internal routing can keep working while the edge firewall is rebooted or updated. If you're running a firmware update on the firewall at 2 AM and something goes wrong, your VMs can still talk to each other and your NAS is still reachable—but only if the switch is actually routing those flows locally, and only for traffic that doesn't need WAN, NAT, or VPN services. Internet access and WAN-facing services still fail. The maintenance benefit is real, but it's partial: internal reachability survives, not general network continuity.

You also now maintain two devices and two configs. Two firmware update schedules. Two sets of configuration to keep consistent. A more complex recovery story when something breaks—is the problem in the switch config or the firewall config? Which device has the stale route?

For a lab where the gateway is also the learning surface, a single consolidated box is easier to reason about and recover. When you break the config at 11 PM—and you will break the config—recovering one box is faster than diagnosing which of two boxes has the problem.

Consider your recovery plan before you commit: how do you get back online after a bad config? Does the architecture make that harder or easier? A router-on-a-stick with a single misconfigured VLAN interface can lock you out of the whole network. A split design can hide the problem in either device.

When the Split Design Earns Its Complexity

The split design is not inherently better. It earns its extra boxes and config under specific conditions:

Heavy east-west traffic. Storage replication, VM migration, or backup jobs that regularly move bulk data between VLANs. If your NAS lives on a storage VLAN and your VMs live on a compute VLAN, every backup and every VM migration crosses the inter-VLAN path. A Layer 3 switch routes that traffic in hardware without touching the firewall.

A desire to keep internal services up during edge firewall maintenance or a WAN outage. If your lab runs services you want available even when the internet is down—Home Assistant, media servers, internal DNS, development environments—the split design keeps those services routing while the edge firewall is offline, provided the switch handles those flows locally and their dependencies don't sit behind the firewall.

Multigigabit or faster internal links. At 2.5 GbE or 10 GbE, a single trunk or gateway CPU becomes the visible limit much faster. A Layer 3 switch with a 10 GbE backplane routes internal traffic at wire speed; a router-on-a-stick forces all of it through one CPU.

A learning goal. If you want hands-on experience with Layer 3 switching, routing protocols like OSPF, and a more enterprise-like edge, the split is the better classroom. Netgate forum users who moved to an L3 switch plus pfSense design have explicitly framed it as a learning exercise—and that's a legitimate reason to add complexity.

State the counter-case plainly: if none of these apply, the split adds boxes and config without changing your daily result. A lab with light east-west traffic and mostly north-south internet traffic gets no measurable benefit from hardware inter-VLAN routing.

Common Mistakes and Hidden Dependencies

Treating a Layer 3 switch as a firewall replacement. The switch routes; it does not inspect. VLANs you meant to isolate can reach each other if the switch is routing between them and you haven't accounted for that path in your policy design.

Assuming nominal port speed means sustained throughput. A 1 GbE trunk in a router-on-a-stick config carries all VLAN traffic in both directions. Real rules, real traffic patterns, and real inspection features all reduce what that link can actually deliver.

Underestimating the config and recovery burden of a second device. Two boxes means two firmware schedules, two configs to keep consistent, and a more complex troubleshooting story. The split design is not "set and forget"—it's a second system to maintain.

Forgetting that VPN and inspection load the gateway CPU regardless of architecture. A "fast" router can still choke on encrypted traffic. Moving internal routing to a switch does not offload VPN termination or deep packet inspection.

Not planning the recovery path before making the change. How do you get back online after a misconfigured gateway or switch? With router-on-a-stick, the answer is usually "fix the one box." With a split design, you need to know which device has the problem and how to recover each one independently.

Decision Rule: Choosing for Your Lab

Start with router-on-a-stick if your VLANs are mostly isolation labels, east-west traffic is light, and you want one box to configure and recover. This is the lower-maintenance default for most home labs. It centralizes policy, simplifies troubleshooting, and costs nothing in practice when your traffic is mostly north-south.

Move to the split when bulk inter-VLAN traffic, uptime during firewall maintenance, or a Layer 3 learning goal becomes real for you. The trigger is not "I want better security"—it's "my internal traffic is hitting a ceiling" or "I need internal routing to survive firewall maintenance."

Buy the bottleneck. If your constraint is WAN throughput or VPN performance, a different gateway may fix it without adding a switch. If your constraint is internal routing load, the split targets that directly. Do not add a Layer 3 switch to fix a WAN throughput problem, and do not buy a bigger router to fix an east-west traffic problem.

Keep product choice secondary to the topology decision. The architecture determines which products even make sense. A router-on-a-stick design needs a gateway with enough CPU for inter-VLAN routing plus firewall inspection. A split design needs a switch with capable Layer 3 hardware and a firewall that only handles edge traffic—a much lighter CPU requirement.

Before you buy anything, map your VLANs and the traffic that crosses them. Write down every flow: which VLANs talk to which, how much data moves between them, and which of those flows actually need to cross a firewall policy. That map tells you which architecture you need. The product selection comes after.