Choosing a UniFi Gateway: Routing, Throughput, IDS/IPS

The UniFi gateway is the one device whose sizing mistakes affect everything, because it routes, firewalls, and connects you to the internet. People pick it by line speed or by which model looks nicest in the rack, and then wonder why enabling security features tanks throughput. This guide is the reasoning for choosing a UniFi gateway by its real limits — and for honestly asking whether UniFi should do your routing at all.

You do not have to route with UniFi

Start with the question people skip. UniFi is modular: you can run UniFi access points and switches behind a non-UniFi router or firewall and never own a UniFi gateway. The controller manages the APs and switches; the gateway is optional.

So the first decision is architectural, not which model:

• UniFi gateway: routing, firewall, VLAN inter-segment control, and (on capable models) IDS/IPS all integrated into the same UniFi OS experience. The reason to buy in is that integration — one system, one interface, VLAN segmentation and firewall rules managed alongside the rest.
• Keep your existing router/firewall (including a dedicated firewall OS) and run UniFi APs/switches behind it. Right when you already have a router you trust, want routing independent of the UniFi ecosystem, or want firewall capabilities UniFi doesn’t focus on.

Buying a UniFi gateway is choosing integration and a single pane of glass. It is not mandatory for a UniFi Wi-Fi network. Decide that before comparing models — it changes the whole shopping list.

The number that matters is throughput with your features on

Here is the sizing mistake that survives everything else: choosing a gateway by raw routing/NAT speed, then enabling IDS/IPS (deep packet inspection) and watching effective throughput drop sharply.

The principle, true of essentially all gateways across vendors:

• Plain routing/NAT is comparatively cheap; most gateways move basic traffic fast.
• Deep packet inspection (IDS/IPS) is expensive. Inspecting every packet for threats consumes far more processing than forwarding it. A gateway’s throughput with IDS/IPS enabled is materially lower than its plain-routing number — and the inspected number is the one that matters if you intend to run that feature.

So the real questions are:

1. Will you run IDS/IPS or other deep-inspection features? If yes, size against the gateway’s inspected throughput, not its headline routing figure.
2. What does your connection plus your feature set actually demand at peak? A fast internet line and full inspection is the demanding combination people under-provision for.

Picking by the big marketing number and then enabling inspection is exactly how a gateway becomes the bottleneck for the entire network. Match the gateway to throughput in the configuration you’ll actually run, not in its most flattering one.

”Cloud Gateway” vs “Dream Machine” vs gateway-only: pick by role

UniFi sells gateways in distinct shapes. Without quoting specs that change by model and revision, choose by role:

• All-in-one console gateways (Dream Machine family). Gateway plus a built-in console running the Network Application (and on some, more), often with onboard Wi-Fi or storage depending on model. Strong default when you want one box to be router, controller, and sometimes AP/NVR. Fewer pieces, one thing to manage — the path of least resistance for many homes/small offices.
• Cloud Gateway line. Gateway with an integrated UniFi OS console, generally without trying to also be the access point — pair it with separate UniFi APs/switches. A clean “router + brain” core for a network whose Wi-Fi comes from dedicated APs.
• Gateway-only / larger gateways. For builds wanting a dedicated routing/security appliance with the controller hosted elsewhere, or higher capacity than the all-in-ones target.

The selection logic is role and scale, not the spec sheet: do you want one box to also be the controller and maybe the AP, or a dedicated gateway with the controller hosted separately (controller hosting options)? Decide the role; the model follows.

The gateway is also your controller host — that’s a coupled decision

On the all-in-one and Cloud Gateway models, the gateway is the UniFi OS console hosting the Network Application. That couples two decisions people make separately:

• Choosing the gateway also chooses your controller host (and its resilience, storage, and remote-access story).
• If that device fails, you’ve potentially lost both routing and management at once — restore from backup to a replacement is the recovery, exactly the scenario in backups and disaster recovery.

This is usually a good trade (fewer devices, integrated remote access), but make it knowingly: an all-in-one gateway concentrates routing + management + sometimes Wi-Fi/NVR into one box. That’s elegant and also a single point whose failure is broad. The mitigation isn’t avoiding it — it’s the backup discipline that makes restoring to a replacement an afternoon.

Don’t forget WAN, multi-WAN, and what you actually need

Sizing isn’t only internal throughput:

• WAN/internet capability. The gateway must comfortably handle your connection at peak, with whatever features you enable — see the IDS/IPS point; this is where it bites first.
• Multi-WAN / failover. If a second internet connection or failover matters, that’s a model capability to confirm up front, not a setting you can wish into a gizmo that doesn’t support it.
• Honest feature need. Many homes run perfectly without IDS/IPS. Don’t buy a gateway sized for full inspection and then not use it — or, worse, buy one not sized for it and enable it anyway and blame “UniFi is slow.” Match purchase to intended configuration.

Choosing the gateway without overspending or under-building

1. Decide if UniFi routes at all. Existing trusted firewall + UniFi APs/switches behind it is a legitimate, sometimes better choice. A UniFi gateway is for integration, not obligation.
2. Will you run IDS/IPS / deep inspection? If yes, size against inspected throughput; the headline routing number is not your number.
3. Pick by role: one box as router+controller(+AP/NVR) → Dream Machine family; router+brain with separate APs → Cloud Gateway; dedicated routing with controller elsewhere → gateway-only/larger.
4. Acknowledge the coupling: an all-in-one is also your controller host — accept that and pair it with solid backups.
5. Confirm WAN/multi-WAN needs as model capabilities before buying, not after.
6. Match the purchase to the configuration you’ll actually run, at peak, with features on.

Get the gateway right and it quietly routes and protects everything else. Get it wrong — sized for marketing throughput, then asked to inspect every packet on a fast line — and it’s the bottleneck for your entire network at once. For the segmentation and controller decisions tied to this, see VLAN segmentation, controller hosting options, and the rest of our UniFi guides.