De hoofdconclusie van de audit van vanmiddag houdt stand: IDS/IPS op de UDM-Pro is inderdaad de rem op je download. Uitzetten levert gemeten +75% op.
Maar er zit een belangrijke correctie in. De audit suggereerde tussenvormen, bijvoorbeeld alleen detectie of inspectie beperken tot bepaalde netwerken. Die zijn nu gemeten en ze leveren nul op. Het is aan of uit, er is geen tussenweg. En een nieuwe UDM-Pro lost helemaal niets op, want dat is dezelfde chip.
De audit van vanmiddag baseerde de diagnose op één meting per machine. Dat is te weinig, want de spreiding op deze lijn blijkt enorm: twee metingen achter elkaar, met exact dezelfde instellingen, gaven 688 en 1.074 Mbps. Wie daar één van pakt, meet ruis.
Daarom is elk scenario meerdere keren gemeten, allemaal vanaf dezelfde machine (M5 Max op de kabel, 2.500Base-T), tegen dezelfde server (KPN Amstelveen, Ookla-server 61186), met niemand anders die tegelijk aan het testen was. Tussen elke wijziging zat 45 tot 50 seconden zodat de UDM zijn configuratie kon uitrollen en suricata op gang kwam.
Tegelijk is op de UDM zelf elke 5 seconden de belasting gelogd, zodat we konden zien wat de router deed in plaats van het te vermoeden.
| Instelling | Download per run (Mbps) | Gemiddeld | Upload | Winst |
|---|---|---|---|---|
| IPS aan, beide netwerken jouw huidige situatie |
688 · 1.074 | 881 | ~1.690 | basislijn |
| IDS alleen detectie, geen preventie |
967 · 839 · 692 | 833 | ~1.745 | geen |
| IPS alleen op IoT-VLAN Default-netwerk niet geïnspecteerd |
913 · 955 · 860 | 909 | ~1.900 | geen |
| Volledig uit | 1.192 · 1.746 · 1.689 | 1.542 | ~1.630 | +75% |
Upload schommelde in alle scenario's tussen 1,4 en 2,0 Gbps en wordt dus niet geraakt. Dat bevestigt het beeld uit de audit: de inspectie hangt aan het binnenkomende verkeer.
Dit is de belangrijkste nieuwe bevinding, en hij is contra-intuïtief. Je zou verwachten dat inspectie beperken tot alleen het IoT-VLAN je pc's vrij spel geeft. Dat gebeurt niet: 909 Mbps, statistisch gelijk aan volledige inspectie.
De verklaring is dat de rem niet zit in welk verkeer je laat inspecteren, maar in het feit dat suricata draait. Zodra IDS of IPS aanstaat, vervalt de hardwareversnelling van de UDM voor al het routeerbare verkeer en moet elk pakket door de processor. Of die processor vervolgens één netwerk of twee netwerken tegen de regelset houdt, maakt voor de doorvoer nauwelijks uit.
Er valt hier niets te finetunen. Categorieën uitzetten, netwerken uitsluiten of terugschakelen naar alleen detectie geven je je bandbreedte niet terug. De enige knop die werkt, is de aan/uit-knop.
De richting van de audit was goed, maar twee onderbouwingen houden geen stand. Dat is geen detail: op basis van precies die onderbouwing lag er een hardware-aankoop op tafel.
De audit stelde: "een load van 6,78 op 4 cores betekent dat de router 170% overbelast was, daar loopt de processor op vast." Tijdens de metingen hierboven is de load van de UDM continu meegelogd. Met IPS aan liep hij op naar 6,0. Met IPS uit, precies toen het netwerk het snelst was, liep hij op naar 8,01.
Load meet hoeveel pakketten er in beweging zijn, niet waar de flessenhals zit. Hoe sneller het netwerk, hoe hoger de load. Het cijfer klinkt als bewijs en is het niet.
De voorspelling "van circa 400 Mbps naar ruim boven de 1 Gbps" is gebouwd op enkele metingen. Met inspectie gewoon aan is in deze sessie 1.074 Mbps gemeten, dus de voorspelde eindsituatie werd al gehaald in de situatie die het probleem zou zijn.
De echte winst is er wel, maar hij loopt van ~880 naar ~1.540, niet van 400 naar 1.000.
De kern van de audit was raak en is nu hard bewezen: de gateway is de flessenhals, niet de pc's, niet de bekabeling en niet de lijn. De vaststelling dat upload wel volloopt en download niet was de juiste aanwijzing. En de fix op de RTX5090 (energiebesparing op de netwerkkaart) staat helemaal los van dit alles en was terecht.
Zelfde quad-core Cortex-A57, zelfde 4 GB geheugen, zelfde grens. Dat is weggegooid geld voor dit probleem.
| Apparaat | Processor | RAM | Claim met IDS/IPS | Prijs |
|---|---|---|---|---|
| UDM-Pro (huidig) | Quad Cortex-A57 @ 1,7 GHz | 4 GB | 3,5 Gbps | in bezit |
| UDM-Pro-Max | Quad Cortex-A57 @ 2,0 GHz | 8 GB | 5 Gbps | €654,80 incl. |
| EFG / UXG-Enterprise | Enterprise-klasse | — | 12,5 Gbps | $1.999 |
Ubiquiti claimt voor je huidige UDM-Pro 3,5 Gbps met IDS/IPS aan. Gemeten: 0,88 Gbps. Dat is een factor 4 verschil, omdat die labcijfers zonder PPPoE tot stand komen en KPN nu eenmaal PPPoE vereist.
Schaal je de geclaimde 5 Gbps van de Max op dezelfde manier terug, dan land je rond 1,2 tot 1,5 Gbps met inspectie aan. Een duidelijke verbetering ten opzichte van 0,88, maar geen 4 Gbit. Wie 4 Gbit én inspectie wil, zit in de EFG-klasse.
Tijdens de metingen kwam iets aan het licht dat in geen enkel rapport stond. De UDM-Pro heeft 3.946 MB geheugen, waarvan tijdens normaal gebruik nog 173 MB vrij is, terwijl er 646 MB in swap staat. Een router die naar swap uitwijkt, is een router die krap zit.
Bovendien staat in de IPS-configuratie de vlag memory_optimized = true. Dat is UniFi's eigen signaal dat het apparaat met een uitgeklede regelset draait omdat het geheugen niet toereikend is. Je betaalt dus de volle prijs in doorvoer, maar krijgt niet de volle bescherming. De 8 GB van de Max pakt precies dat aan.
Ter aanvulling: suricata stond bij een verder rustig netwerk al op 62,5% processorgebruik. Dat is de basislast, nog voor er iemand iets downloadt.
Ook met inspectie volledig uit kwam de meting niet boven 1.746 Mbps. Of de rest tot 4 Gbit de PPPoE-grens van de UDM is, of gewoon de grens van één Ookla-server, is niet getest. Er is dus geen garantie dat welke gateway dan ook je 4 Gbit oplevert zolang dat niet apart is uitgezocht. Dat is met een meting over meerdere verbindingen tegelijk vast te stellen.
De alinea hieronder stelde dat de alarmenlijst leeg was. Dat klopte niet. Ik keek naar rest/alarm via de API en naar het veld last_alert_id, en dat waren allebei de verkeerde plek. De meldingen staan in de database van de gateway onder de sleutel THREAT_BLOCKED_V3: 58 stuks in de afgelopen maand. Het getal uit mei 2025 is de markering van het laatst gelezen alarm, niet van het laatste alarm.
De volledige uitwerking staat in het eindrapport van 21 juli, inclusief wat die 58 blokkades werkelijk waren.
Voordat er iets uit gaat of iets gekocht wordt: wat heeft die IPS in de praktijk eigenlijk tegengehouden?
De alarmenlijst via de API is leeg, en de markering van het laatst gelezen alarm wijst naar 29 mei 2025, ruim een jaar geleden. Dat is geen sluitend bewijs, want die historie kan gerouteerd of opgeschoond zijn, dus dit hoort in de interface onder Security nagekeken te worden.
Blijkt daar weinig tot niets te staan, dan is de afweging niet langer "veiligheid tegen snelheid" maar "45% van je download tegen een logboek dat leeg blijft". Daar komt bij dat NextDNS al op DNS-niveau filtert, dus vóórdat er überhaupt een pakket binnenkomt. Een flink deel van waar mensen IPS voor denken nodig te hebben, wordt daar al afgevangen.
ips, beide netwerken, alle 18 categorieën, veld voor veld gelijk aan de back-upbackups/2026-07-21_pre-ipstest_setting-ips.json in de unifi-repositoryJe netwerk staat dus exact zoals het vanmorgen stond. Er is niets blijvend gewijzigd aan de beveiliging.
Wil je je download terug zonder iets te kopen, dan is dat één handeling en heb je ongeveer 660 Mbps extra. Wil je inspectie houden én sneller worden, dan is de UDM-Pro-Max van €655 een reële stap, vooral vanwege het geheugen, maar reken op iets van 1,2 tot 1,5 Gbps en niet op 4. Wil je allebei helemaal, dan is dat een gateway van rond de €2.000, en dan is de vraag gerechtvaardigd of het inspectiewerk dat waard is voor een thuisnetwerk waar het alarmlogboek leeg lijkt te staan.
Terugzetten kan altijd binnen enkele seconden, in beide richtingen. Dat maakt dit een omkeerbare beslissing, en die hoort niet zwaarder gemaakt te worden dan hij is.