Architecture starts with the traffic matrix

List the networks that talk to each other and the applications that create the largest flows. Internet traffic, backups, VM migrations, media editing and NAS access can have very different paths through the same switches.

The firewall only processes traffic that is routed through it. Knowing which flows are same-VLAN and which cross security boundaries prevents over-sizing one component while under-sizing the actual choke point.

The calculator is intentionally topology-first. It separates edge client speed from backbone speed, because ten 2.5GbE devices do not automatically require a 25GbE firewall. What matters is how many of those devices communicate simultaneously, whether the traffic stays inside a VLAN, whether it crosses OPNsense, and where high-bandwidth servers such as a NAS or hypervisor sit. This keeps the recommendation tied to routed demand rather than headline port counts.

Keep 2.5GbE at the edge when it is already enough

Many desktops and Wi-Fi APs gain useful headroom from 2.5GbE without the cost and heat of universal 10GbE. A managed 2.5GbE access layer can feed a 10GbE core cleanly.

This creates a natural upgrade path: high-demand servers and workstations move to 10GbE first, while ordinary clients remain on inexpensive copper access ports.

Future headroom is treated as a port and uplink problem as well as a bandwidth problem. A design that uses every switch port on day one can become expensive even when its forwarding capacity is adequate. Reserve space for an additional access point, a temporary troubleshooting connection and at least one growth path. When virtualization is selected, preserve an independent management/recovery route so firewall maintenance does not turn into a host-access problem.

Use 10GbE for aggregation and routed high-demand paths

A 10GbE firewall or core switch is most valuable when several slower clients converge or when one server genuinely moves multi-gig traffic. The link should be placed where it removes contention.

If all endpoints are 1GbE and internet access is sub-gigabit, a 10GbE core may still be useful for future growth but it is not an immediate performance requirement.

VLANs require management features, not more physical ports

Several VLANs can share one tagged trunk, so adding security zones does not require one NIC per network. It does require a managed switch and an unambiguous tagging plan.

The trunk speed should reflect routed traffic between those zones and the internet. A high VLAN count with little cross-zone traffic can run on modest links; a small number of server VLANs may justify 10GbE.

PoE belongs in the access-layer budget

Access points and cameras often drive PoE requirements, while the 10GbE core serves servers and firewall links that do not need power delivery. Separate those roles when it lowers cost or heat.

If one switch will do both, verify the total PoE budget and per-port standards in addition to Ethernet speed.

Choose SFP+ or RJ45 as a rack standard where possible

Standardizing the core on one media reduces spare inventory and conversion adapters. SFP+ with DAC is attractive in a rack; fiber extends that standard over longer distances. RJ45 can be simpler when compatible copper is already installed.

There is no requirement to use the same medium at the access layer. A network can be 2.5GbE RJ45 at the edge and SFP+ at the core without unnecessary conversion.

Proxmox changes the firewall failure domain

A virtual OPNsense instance can share the same high-speed NICs and switch fabric as servers, but a host reboot also reboots the firewall unless HA is provided elsewhere.

Decide whether consolidation is worth the dependency. The architecture output intentionally recommends a deployment model alongside NIC and switch classes because networking hardware cannot be separated from operations.

PCIe bandwidth belongs in the server-side diagram

A 10GbE NIC installed in a constrained slot can make a perfect switch design underperform. Check electrical lane width, shared chipset links and other high-bandwidth devices on the Proxmox or firewall host.

This is especially important for compact systems using adapters to convert M.2 slots into Ethernet expansion. Mechanical fit is not proof of sustained I/O headroom.

Management and recovery paths should be visible on the topology

Mark how administrators reach OPNsense, Proxmox and each managed switch when the main routed path is down. A console port, local management port or known access VLAN can be more valuable than another high-speed uplink.

Store the topology outside the devices it documents. During a failure, the network itself may not be available to retrieve cloud notes or internal documentation.

Design spare capacity into ports and power

Leave at least one unused switch port where practical and reserve power budget for future APs. On the firewall, spare physical interfaces can simplify migration from copper to fiber or allow temporary bypass paths during troubleshooting.

Buying one size above the exact present need is sensible when the price jump is small. Buying a huge platform for hypothetical growth is not automatically efficient.

Test routed performance, not only switch-local benchmarks

A NAS-to-workstation test in one VLAN measures the switch and endpoints. Move the workstation to another VLAN and the test now includes OPNsense routing and firewall policy. Both results are useful, but they answer different questions.

Use both tests after deployment. They show whether a bottleneck lives in the endpoint, switch fabric, firewall link or OPNsense processing path.

Turn the calculator result into a procurement and validation plan

Write down the recommended port classes, media and deployment model, then map each result to exact products. Verify the models against current documentation and order media only after both endpoints are known.

After installation, repeat the original traffic assumptions with measured tests. Update the diagram with negotiated speeds and any real bottlenecks so the next upgrade starts from evidence.