Kun je je router vertrouwen? GL.iNet, OpenWrt en waar het mis kan gaan

Kun je je router vertrouwen? GL.iNet, OpenWrt en waar het mis kan gaan

Voor wie deze gids is

Voor lezers die een GL.iNet-router overwegen (of al gebruiken) en zich afvragen of “OpenWrt erop” hetzelfde is als “veilig”. Ook relevant als je een goedkope OpenWrt-achtige reisrouter op AliExpress bent tegengekomen en niet weet hoe je die moet inschatten. Deze gids gaat over hóe je vertrouwen in een merk beoordeelt, niet over “welk merk is fout.”

Wat deze gids wel en niet oplost

Dit is geen definitief oordeel over GL.iNet, en geen zwarte lijst van merken. Er bestaat geen router zonder enig risico, en niemand kan hardware- of firmwarevertrouwen met honderd procent zekerheid bewijzen. Wat deze gids wél doet: laten zien welke vragen ertoe doen, wat je zelf kunt checken, en waarom “Chinees merk” of “draait OpenWrt” allebei te simpele signalen zijn om alleen op af te gaan.

De praktische default

Voor de meeste lezers blijft GL.iNet de redelijke keuze in zijn prijsklasse — niet omdat het risicovrij is, maar omdat het de meest transparante optie is die ook nog gebruiksvriendelijk en betaalbaar is. De rest van deze gids legt uit waaróm, en waar de eerlijke grenzen van die aanbeveling liggen.

Waarom “OpenWrt erop” geen garantie is

“Deze router draait OpenWrt” wordt vaak behandeld als eindpunt van de discussie: open source, dus veilig. Dat is een misvatting. OpenWrt is de softwarelaag — maar een router bestaat uit meer lagen dan dat:

• De applicatielaag (het beheerpaneel, cloud-features, extra tooling) — dit is waar een fabrikant het makkelijkst iets toevoegt dat je niet wilt.
• De WiFi-chipfirmware — vrijwel altijd closed source, ongeacht welk besturingssysteem erboven draait.
• De hardware zelf — wat er daadwerkelijk op de printplaat zit, ongeacht welke software je erop zet.

Een router kan OpenWrt-gebaseerd zijn en toch onveilig, en een router kan gesloten firmware hebben en toch prima zijn — het hangt af van wat er in elke laag gebeurt, niet van het label. Dat is ook precies de conclusie van onze eerdere analyse van de Amerikaanse routerban-discussie: vlag en merknaam zijn zwakke shortcuts, gedrag en controle vertellen meer.

GL.iNet als casus: wat pleit vóór vertrouwen

GL.iNet is een gevestigd bedrijf (sinds ongeveer 2015/2016), verkocht via officiële kanalen met echte support — geen anonieme webshop-only naam. Een paar concrete signalen die ertoe doen:

• Een publiek beveiligingsadvies-programma. GL.iNet publiceert eigen CVE’s met datum en detail — recent onder meer een ongeauthenticeerde remote code execution via SID-bruteforce, ontbrekende input-validatie, en command injection. Dat klinkt verontrustend, maar is eigenlijk een goed teken: kwetsbaarheden worden openbaar gemaakt en gepatcht, in plaats van verzwegen. Een merk met nul ooit-gemelde CVE’s is vaker ongeauditeerd dan perfect veilig.
• Firmware gebaseerd op OpenWrt, met een eigen laag eroverheen — niet een compleet gesloten fork die niemand kan inspecteren.
• Jaren aan community-aandacht — maar per model, niet automatisch voor elk nieuw product. Dit is geen vaag signaal: SRLabs, een gerespecteerd Duits beveiligingsonderzoeksbureau, bouwt en onderhoudt blue-merle, een echt anonimiseringspakket (IMEI/MAC/BSSID-randomisatie, forensische logwissing) specifiek voor GL.iNet’s oudere 4G Mudi (GL-E750). Dat is serieuze, benoemde onafhankelijke scrutiny, geen hobbyistengeruchten. Maar de nieuwste vlaggenschip — de Mudi 7 (GL-E5800), nog maar een paar maanden op de markt — heeft die diepgang nog niet gehad: er staat een open, onopgelost GitHub-issue dat vraagt of SRLabs blue-merle ook naar de Mudi 7 wil uitbreiden. Community-vertrouwen is dus reëel voor GL.iNet als trackrecord, maar bouwt per model op — een gloednieuw product heeft die scrutiny simpelweg nog niet gehad.

De eerlijke kanttekening

Twee dingen die niet weggemoffeld moeten worden:

• GL.iNet is een Chinees bedrijf (Hongkong/VS-aanwezigheid), en valt daarmee onder China’s National Intelligence Law — die bedrijven wettelijk kan verplichten om mee te werken aan verzoeken van de Chinese staatsveiligheid. Dat is geen theoretisch punt en geldt voor elk Chinees hardwaremerk, niet specifiek voor GL.iNet.
• Een oude, nooit opgeloste discussie op het OpenWrt-forum beweerde dat GL.iNet-firmware DNS-verzoeken lekte naar Chinese domeinen (chinauos.com/uniontech.com), zelfs met DNS-over-TLS en een VPN actief. Niemand heeft dit ooit reproduceerbaar bevestigd, en GL.iNet heeft er nooit publiekelijk op gereageerd. Dat is geen bevestigd lek — maar ook geen weerlegde bewering. Onopgelost, niet ontkracht.

Kun je dit zelf verifiëren?

Ja, tot op zekere hoogte — met gelaagde methodes, waarvan geen enkele op zichzelf sluitend bewijs geeft:

1. Hash de WiFi-firmware blob en vergelijk die met de officiële release van de chipfabrikant (bijvoorbeeld via het linux-firmware-project, waar OpenWrt zelf ook uit put). Komt de hash exact overeen, dan vertrouw je nu de chipfabrikant (Qualcomm/MediaTek) in plaats van GL.iNet — dat versmalt het vertrouwensoppervlak, het elimineert het niet.
2. Monitor netwerkverkeer vanaf een apart apparaat op hetzelfde netwerksegment, met alle OpenWrt-kant features uitgezet. Dit vangt actief “naar huis bellen”-gedrag, maar niet iets dat wacht op een trigger.
3. Fysieke teardown / printplaatinspectie, idealiter tegen een gepubliceerd schema of referentie-unit — hobbyisten hebben dit al gedaan voor GL.iNet-hardware.
4. Jarenlange onbetaalde community-controle (zie hierboven) — geen technische test, maar wel een reëel signaal.

Het eerlijke epistemische punt: je kunt nooit het negatieve bewijzen. Er is geen manier om cryptografisch aan te tonen dat er géén achterdeur bestaat — je kunt alleen onafhankelijke bewijslagen opstapelen tot de resterende twijfel klein genoeg is om op te handelen. Dat past bij de kernconclusie van deze site: geen enkel merk is foutloos, sommige merken gaan alleen beter met fouten om.

Kan een backdoor via de WiFi-firmware, ook zonder GL.iNet’s eigen software?

Ja — en dit is het minder voor de hand liggende, ernstigere risico. Onderzoek van Google Project Zero (“Over The Air”, 2017) toonde aan dat Broadcom WiFi-chips via PCIe rechtstreeks konden schrijven naar het RAM-geheugen van de host — buiten het besturingssysteem om, zonder ASLR-bescherming. Dat betekent: een gecompromitteerde WiFi-firmware blob is niet “alleen de radio onbetrouwbaar,” het kan volledige overname van het apparaat betekenen, onzichtbaar voor alles wat OpenWrt zelf ziet.

Dit is precies waarom vanilla OpenWrt flashen dit gat niet dicht — de blob blijft, ongeacht wat er op de hoofdchip draait.

Vanilla OpenWrt flashen: een reële tussenstap, geen oplossing

Veel GL.iNet-modellen ondersteunen officieel het flashen van “vanilla” (originele, niet door GL.iNet aangepaste) OpenWrt in plaats van hun eigen firmware. Dat verwijdert GL.iNet’s eigen applicatielaag — de laag die het makkelijkst een achterdeur of ongewenste telemetrie zou bevatten — en vervangt die door firmware gebouwd via het eigen, publiek controleerbare proces van het OpenWrt-project.

Dit geldt niet automatisch voor elk model. De Mudi 7 specifiek — 5G plus Wi-Fi 7, allebei op Qualcomm Dragonwing-silicon — heeft op dit moment geen officiële upstream OpenWrt-ondersteuning. Het OpenWrt-forum bevestigt dat dit afhangt van of Qualcomm ooit open drivers vrijgeeft, zonder toegezegde datum. Nieuwere, complexere combo-apparaten (5G + Wi-Fi 7 in één chipfamilie) zijn dus een reëel andere situatie dan een simpeler, langer bestaand model — check per model, niet per merk, of vanilla OpenWrt daadwerkelijk beschikbaar is.

Wat het niet oplost: de WiFi-driver van GL.iNet-hardware is closed source, en dat blijft zo na het flashen van vanilla OpenWrt — de OpenWrt-gemeenschap zelf waarschuwt dat er zelfs geen garantie is dat de open driver stabiel is, laat staan auditeerbaar. Op modellen met 4G/5G-modem geldt hetzelfde voor de modemfirmware.

Conclusie: een echte, zinvolle verbetering — niet een manier om het risico naar nul te brengen.

De rode vlaggen: onbekende AliExpress-merken

Het grootste praktische risico zit niet bij GL.iNet, maar bij de anonieme “OpenWrt-achtige” reisroutertjes die je op AliExpress tegenkomt onder wisselende merknamen. Concreet om op te letten:

• Geen vindbaar bedrijf achter de naam — geen eigen website, geen supportkanaal, alleen een AliExpress-winkelpagina.
• Geen ooit gepubliceerd beveiligingsadvies — niet omdat het merk perfect is, maar omdat niemand het ooit heeft gecontroleerd of het merk niets meldt.
• Onverifieerbare firmwareclaims — “gebaseerd op OpenWrt” zonder broncode, zonder build-proces, zonder manier om dat na te gaan.
• Geen aanspreekbare rechtsmacht — als er iets misgaat, is er niemand om verantwoordelijk te houden.
• Winkelbeoordeling is geen beveiligingssignaal — een 4,8 sterren AliExpress-winkel zegt iets over verzendtijd en klantvriendelijkheid, niets over firmwareveiligheid. Dit sluit aan bij een reëel, gedocumenteerd patroon: onderzoek naar counterfeit netwerkhardware heeft herhaaldelijk hardcoded inloggegevens en niet-gedocumenteerde remote-toegang gevonden in goedkope, merkloze apparatuur.

Een echt EU-alternatief bestaat al: Turris

Als de vraag is “kan een Europees bedrijf dit oplossen door GL.iNet te rebranden” — het antwoord is: rebranding alleen is cosmetisch, tenzij het bedrijf ook de firmware zelf bouwt en controleert. Maar het sterkere model bestaat al, en gaat verder dan rebranding: Turris, gemaakt door CZ.NIC (het Tsjechische nationale domeinregister — geen anonieme leverancier, maar een gevestigde, publiek verantwoordelijke organisatie).

• Hardware daadwerkelijk gefabriceerd in Tsjechië, niet alleen ontworpen in de EU en gebouwd in China.
• Firmware (Turris OS, OpenWrt-gebaseerd) volledig open source op GitHub.
• Gepentest door het Tsjechische nationale CSIRT, geen kritieke kwetsbaarheden gevonden.
• Eigen, transparant gemelde CVE-geschiedenis (een Qualcomm WiFi-chipkwetsbaarheid, een OpenSSL-bug) — hetzelfde “echte problemen, netjes gemeld”-signaal als GL.iNet, nu met echte EU-jurisdictie en EU-fabricage erbij.

De eerlijke beperking: Turris maakt alleen thuis-/bedrijfsrouters (Omnia, Omnia NG, de modulaire MOX-lijn) — geen compacte reisrouter, en de prijs ligt duidelijk hoger dan GL.iNet’s instapsegment. Voor onderweg is er op dit moment geen volwaardig EU-gemaakt alternatief in dezelfde prijsklasse — dat is een reëel, nog onopgevuld gat, niet iets om te verbloemen.

De praktische checklist

Toepasbaar op elk merk, ook een dat wij nog niet hebben gecheckt:

• Is er een vindbaar bedrijf met een geschiedenis achter de naam?
• Publiceert het merk ooit beveiligingsadviezen/CVE’s, of is het stil?
• Is de firmware (gedeeltelijk) open source en controleerbaar?
• Ondersteunt het apparaat het flashen van onafhankelijke firmware?
• Is er jarenlange, onafhankelijke community-aandacht voor dit specifieke model?
• Waar wordt het gefabriceerd, en verandert dat de vertrouwensketen voor jouw situatie?

Wanneer de sterkere setup de moeite waard is

Voor de meeste thuisgebruikers is GL.iNet met de standaardfirmware, een sterk wachtwoord en uitgeschakelde onnodige cloud-features (zie de netwerk-dreigingsprofiel-gids) ruim voldoende. Overweeg de stap naar vanilla OpenWrt of naar Turris als:

• je een concrete, specifieke reden hebt om een leverancier niet te vertrouwen (bijvoorbeeld een beroep met een reëel geopolitiek dreigingsprofiel)
• je toch al de technische kennis en zin hebt om zelf firmware te flashen en te onderhouden
• de meerprijs en het ontbreken van een reisvariant bij Turris geen probleem zijn voor jouw gebruik

Voor de meeste lezers is dit overkill — en dat is een prima, geldige conclusie.

Volgende stap

Wil je verder gaan?

• Netwerk-dreigingsprofiel-gids — welk niveau van netwerkbeveiliging past bij jouw situatie
• GL.iNet Beryl 7 review — praktische keuze binnen GL.iNet’s assortiment
• Wat de routerban laat zien over echte routerveiligheid — de bredere discussie over merk versus gedrag