u/uncmnsense

UniFi IPS/DPI kills livestreams and video calls every 5-10 minutes — root cause found and workaround

If you've ever had YouTube streams, Teams calls, or Zoom meetings drop every 5–10 minutes on a UniFi gateway with IPS or DPI enabled, I found the root cause and a workaround.

The problem:

UniFi gateways run Suricata for both IPS (Threat Management) and DPI (Traffic Identification). The Suricata config ships with stream.memcap: 16mb — a tiny buffer for tracking TCP streams. When this fills up, Suricata enters "emergency mode" and starts killing flows using a 100-second timeout. Your livestream or video call is the biggest flow, so it gets evicted first.

Key findings from my testing on a UXG-Lite:

• With IPS+DPI on: stream drops every 5–10 minutes like clockwork
• Disabling IPS alone doesn't help — Suricata stays running for DPI
• Disabling both IPS and DPI: zero drops for 45+ minutes
• The UI's "Allow List" for IPS only suppresses alerts — Suricata still tracks and evicts the flow
• The same 16 MB memcap is used on ALL UniFi gateways regardless of RAM, which is why the UDR7 (3 GB RAM) has the same issue

The fix:

Add a BPF filter to exclude your streaming/calling machine from Suricata's packet capture. Create this script on your gateway via SSH:

/data/fix-suricata.sh:

#!/bin/sh
IFACE_CFG="/run/ips/config/iface.yaml"
EXCLUDE_IP="10.99.0.140"  # change to your IP

[ ! -f "$IFACE_CFG" ] && exit 0
grep -q "$EXCLUDE_IP" "$IFACE_CFG" && exit 0

sed -i "s|not net 169.254.254.0/24|not net 169.254.254.0/24 and not host $EXCLUDE_IP|g" "$IFACE_CFG"
kill $(cat /run/suricata.pid 2>/dev/null) 2>/dev/null
logger "fix-suricata: excluded $EXCLUDE_IP from Suricata capture"

Then:

chmod +x /data/fix-suricata.sh
echo "* * * * * root /data/fix-suricata.sh" > /etc/cron.d/fix-suricata

The cron runs every minute and only patches if needed. IPS/DPI keeps working for every other device. The excluded host still has firewall and NAT protection, just not Suricata deep packet inspection.

To persist across reboots, also create /data/on_boot.d/fix-suricata-cron.sh:

#!/bin/sh
[ ! -f /etc/cron.d/fix-suricata ] && echo "* * * * * root /data/fix-suricata.sh" > /etc/cron.d/fix-suricata
/data/fix-suricata.sh

And chmod +x it.

The real fix Ubiquiti needs to make: scale the stream.memcap based on available RAM, increase the emergency-established timeout, or give us a proper UI option to exclude hosts from Suricata flow tracking (not just alert suppression).

Tested on UXG-Lite, UniFi OS 5.0.12. Should work on any UniFi gateway running Suricata (UDM, UDM Pro, UDR, UCG, UXG, etc).

UPDATE:

Further testing showed the BPF filter workaround reduces but does not eliminate drops on the UXG-Lite (1 GB RAM). With the BPF filter active, drops went from every 5 minutes to every 10–25 minutes. We confirmed the BPF filter works — Suricata only processed 120K packets in 33 minutes vs the ~1.2M the stream alone would produce — but Suricata's ~300 MB memory footprint on a 1 GB gateway causes periodic forwarding stalls during system housekeeping, regardless of whether it's inspecting the affected traffic.

What actually works:

• Disabling both IPS and Traffic Identification (DPI): zero drops confirmed over 45+ minutes
• BPF filter exclusion: reduces drop frequency but doesn't eliminate them on 1 GB gateways

The same issue is reported on the German UniFi forum: https://ubiquiti-networks-forum.de/board/thread/12795-problem-mit-intrusion-detection-and-prevention-ids-ips-bei-ms-teams/ — suggesting Ubiquiti ships the same undersized Suricata config across all gateways.

Conclusion: On the UXG-Lite, the only reliable fix is disabling IPS/DPI. Gateways with more RAM (8 GB like the UDM Pro Max) would likely handle it, but Ubiquiti should scale their Suricata stream.memcap and emergency-established timeout based on available hardware resources.