UniFi Threat Management: What IDS and IPS Actually Block, and What They Cost in Throughput

Have you read the IDS/IPS throughput line on your gateway's datasheet, or only the routing line? Ubiquiti publishes both figures for every UniFi gateway, and the second one is the ceiling that governs the moment you switch Threat Management into prevention mode.

That gap catches people who sized hardware against a fiber plan and then enabled every security toggle in the console. The circuit still delivers what you pay for, but the gateway no longer passes it at full rate for anything under inspection.

This guide covers what the signature engine actually sees, how the category and sensitivity controls change the rule set you are running, why deep packet inspection is bound by single-flow performance, and how to decide whether a given gateway can carry the feature at your WAN speed. If you are still choosing hardware, read it alongside how to choose a UniFi gateway.

UniFi Threat Management runs a signature-based inspection engine — Suricata, fed by the Proofpoint Emerging Threats ruleset — against traffic the gateway routes. Streams are reassembled, matched against thousands of rules, and then logged or dropped depending on the mode you selected.

Detection mode is the IDS half of the feature: a match writes an entry to the threat log and the packet continues on its way. Prevention mode is the IPS half: the match drops the offending packet and the flow behind it.

Keep in mind that the engine has no visibility inside TLS. UniFi does not perform certificate interception, so the payload of an HTTPS session, a DNS-over-HTTPS query, or a QUIC stream stays opaque to every rule in the set.

What remains visible is still worth having. The engine sees the TLS handshake and its SNI, the destination address and its reputation, connection timing and volume, and any protocol still running in the clear.

In practice, that shapes which hits are real. Command-and-control callbacks to known-bad infrastructure, port and vulnerability scans against your WAN address, exploit attempts aimed at services you have forwarded, and plaintext protocol abuse are what this engine catches reliably.

Exposed services deserve a note of their own, because they are the category of traffic the rules are best at defending. If you are forwarding ports to reach something from outside, moving that access onto a WireGuard-based remote access setup removes the attack surface entirely instead of asking the inspector to defend it.

What the engine will not catch is the phishing page a user typed credentials into over HTTPS. That failure belongs to DNS filtering, endpoint controls, and segmentation, not to a packet inspector.

Before you assume any of this is WAN-only, check which networks are in scope in the Threat Management settings. Traffic the gateway routes between internal subnets can be inspected too, and that detail drives the throughput math below.

The rule set is organized into categories, and the console exposes them as a checklist. Malware, botnet command-and-control, exploit and exploit-kit activity, network trojans, scanning, denial of service, web application attack, shellcode, attack response, information leak, peer-to-peer, adware and potentially unwanted programs, policy, and informational families each map to a slice of the Emerging Threats catalog.

The sensitivity level is a preset over that checklist. Moving between the named levels changes how many categories are enabled, from a narrow selection weighted toward high-severity, high-confidence signatures to a broad selection that also carries policy and informational rules.

Here is the step worth doing rather than reading about: pick a level, then switch the selector to the custom option and look at which boxes it actually checked. The label matters far less than the resulting category list, and that list is what determines both your alert volume and your CPU load.

The categories sort into roughly three tiers of operational value. Malware, botnet C2, exploit, trojan, and attack-response rules are high-signal and worth running in prevention mode on almost any network.

Scan, denial-of-service, and web-application rules sit in the middle. They fire constantly on any public IP address, and most of what they report is internet background radiation rather than a targeted campaign.

Policy, informational, peer-to-peer, and games categories are where false positives live. These rules flag ordinary behavior: a torrent client, a vendor telemetry beacon, a remote-support tool, a game console negotiating NAT traversal.

That said, they are not useless. On a network where torrenting or unmanaged remote access violates policy, those categories are precisely the control you want, provided you are willing to read the log they generate.

One structural detail matters when you plan this out. UniFi applies a single mode across the whole enabled rule set, so a category you cannot afford to have dropped is a category you either leave unchecked or handle with a targeted signature suppression.

Overall, the workable default on a mixed network is a tight selection of high-signal categories in prevention mode, with the noisy families added deliberately and only where someone will actually act on the alerts.

Every UniFi gateway hits its headline routing number by keeping most packets away from the CPU. A hardware offload path in the SoC learns an established flow and forwards subsequent packets without a full trip through the software stack.

Deep packet inspection is incompatible with that shortcut. A rule engine that must reassemble a stream and match it against thousands of patterns needs to see every packet, which means inspected traffic rides the CPU path instead of the accelerated one.

This is exactly why the two spec lines exist. The routing figure describes the offloaded path, and the IDS/IPS figure describes the same box doing the work in software.

The second constraint is flow affinity. Inspection is organized per flow, and a given TCP connection is handled by a single worker, so one large transfer cannot spread across every core the way a mix of connections can.

That produces a result which confuses people running speed tests. A multi-connection test, which is what most browser-based tests use, spreads across workers and reports a number near the aggregate ceiling, while a single-stream download from one server stalls lower.

Both numbers are real, and which one matters depends on your workload. A household full of streaming devices and browser tabs lives in the aggregate case, while an office pushing a nightly single-stream backup to an offsite target lives squarely in the single-flow case.

There is a latency component as well, though it is usually the smaller problem. Inspection adds per-packet processing delay, but the failure that actually hurts is CPU saturation, which brings packet loss, retransmits, and a sluggish management plane on top of the throughput cap.

Be aware that internal routing draws from the same budget. A multi-gigabit NAS restore between two inspected subnets competes with WAN traffic for identical inspection headroom, which is one more reason to be deliberate about how you structure VLANs and which of them need to cross the gateway at all.

Start with the number you actually buy, in the direction that matters. A 1 Gbps symmetrical circuit needs a gateway whose published IDS/IPS figure comfortably exceeds 1 Gbps, not one that merely routes 1 Gbps.

Ubiquiti's current lineup spans a wide range on this specific line. The Express-class units, the Cloud Gateway Ultra and Max, the Cloud Gateway Fiber, the Dream Machine Pro and SE, and the Enterprise Fortress Gateway all publish separate routing and IDS/IPS throughput figures, and the second one moves substantially across that lineup.

Then leave real headroom. Treat the published figure as a ceiling measured under favorable conditions, because a gateway whose inspection number merely equals your circuit speed will be your bottleneck on a busy evening.

Packet size is the underrated variable here. Inspection cost tracks packets per second more closely than bits per second, so a VoIP-heavy or gaming-heavy network at modest bandwidth can load the engine harder than its megabit total suggests.

Dual-WAN deployments need the same math applied twice. The inspection ceiling applies to whichever circuit is carrying traffic, so a gateway that struggles on a multi-gig primary may be entirely comfortable on the backup path — worth confirming before you finalize your WAN failover design.

When the numbers do not work, you have four honest options rather than one. They include but are not limited to:

• Narrow the rule set. Fewer enabled categories means fewer patterns evaluated per packet, which reclaims measurable headroom. This is the cheapest lever available and the first one to pull.
• Scope the inspected networks. Excluding a high-volume trusted segment, such as a camera VLAN feeding an on-premises recorder or a dedicated backup subnet, removes that traffic from the inspection path entirely.
• Accept the cap. If the only traffic that would exceed the ceiling is a nightly bulk transfer, a lower peak throughput may be a fair trade for continuous inspection the rest of the day.
• Move up a model. When the circuit is well beyond the inspection figure and the traffic is genuinely there, the honest answer is a gateway with a higher published IDS/IPS number.

Note that switching to detection only does not belong on that list. The engine still reassembles and matches every packet in detection mode, so you keep the full throughput cost and give up the enforcement you were paying it for.

The first week after you enable prevention mode decides whether this feature keeps its place in your config. A rule that drops a flow your users need looks exactly like a broken network, and nobody reports it as a security event.

Work from the threat log rather than from theory. Sort by signature, find the rules firing repeatedly, and confirm what actually triggered them before you change a setting.

When a legitimate application trips a rule, suppress that specific signature instead of disabling its entire category. UniFi lets you allow-list a signature directly from the event, which keeps every other rule in that family live.

The common offenders are predictable. Torrent clients under peer-to-peer rules, remote-support and screen-sharing tools under policy and trojan rules, vendor telemetry under information-leak rules, and game consoles under NAT-traversal signatures account for most of the noise on a home or small-office network.

Keep in mind that the signature set updates on its own schedule. A rule that has never fired can begin firing after an update, so a configuration that stayed quiet for six months is not permanently quiet.

There are also cheaper controls that carry part of the same load. Country restrictions match against IP allocation lists, DNS-based content filtering resolves against category lists, and the honeypot simply listens on an unused address — none of them requires per-packet pattern matching, so none of them costs you throughput the way inspection does.

For a network that cannot afford full inspection at line rate, that stack plus disciplined segmentation and a tight inbound firewall policy is a defensible posture. Inspection is a compensating control, and it performs best layered on a network that was already segmented properly.

Here is the sequence that resolves this question in about ten minutes:

1. Write down your WAN plan speed, and note whether your heaviest transfers are single-stream or many concurrent connections.
2. Pull the datasheet for your exact gateway model and find the IDS/IPS throughput line rather than the routing line.
3. If that figure sits comfortably above your circuit, enable prevention mode with the high-signal categories and move on.
4. If it sits near or below your circuit, narrow the categories, scope the inspected networks, and re-test with both a single-stream transfer and a multi-connection speed test.
5. If it is still short and the traffic is real, price the next gateway up against what continuous inspection is actually worth on this network.

Most deployments land at step three or step four, and step four is usually enough. Cutting the noisy categories and removing a high-volume internal segment from scope often recovers the headroom a network needs without any hardware change at all.

If the answer turns out to be new hardware, start from the UniFi gateway lineup and compare the inspection figure next to the routing figure for every model on your shortlist. Sizing against the number that only applies when the feature is switched off is how this decision goes wrong in the first place.