[Ubiquiti-Netwerkapparatuur] Ervaringen & Discussie - Deel 4

[mediumdry]

Maarten60 schreef op zondag 31 augustus 2025 @ 11:19:
Ik heb mijn USG-pro vervangen door UCG-MAX. DHCP loopt via unifi en ik gebruik pihole (statisch adres) voor het afhandelen van DNS verkeer.
[...]
Binnen mijn netwerk zijn een aantal devices (bv Chromecast) die werken met een hard coded DNS adres en op die manier mijn pihole ontwijken. Als je het directe DNS verkeer blokkert, nemen die devices de DHCP DNS setting dan over en gaat het verkeer alsnog via mijn pihole.
Op de pro kan je met een JSON script dit directe DNS verkeer blokkeren, waarna het device alsnog de pihole gebruikt.
Ik ben al dagen bezig om dit op de UCS-Max (v9.3.45) voor elkaar te krijgen, maar dat lijkt (nog) niet mogelijk. De trigger om het DNS te blokkeren, behalve voor mijn pihole krijg ik niet werkend

DNS gebruikt poort 53, TCP en UDP. DoT (DNS over TLS) gebruikt poort 853, TCP. Die zijn dus redelijk simpel te blokkeren voor alles in iedereen behalve je pihole. (hoewel ik je aanraadt om een volledige DNS server te gebruiken, pihole is dat *niet*. Probeer Technitium bv eens, heeft ook blocklists)

Het grote probleem (in more ways than one) is DoH (DNS over HTTPS), want dat gebruikt poort 443, die kan je moeilijk voor iedereen afsluiten, tenzij je geen webbrowser gebruikt.

Je kan traffic captures maken om te zien welke DoH servers gebruikt worden, of je kan de DoH servers die bekend zijn blokkeren. ( https://github.com/DNSCrypt/dnscrypt-resolvers )

Het gaat hier dus om Firewall rules die je moet aanmaken.

[Maarten60]

@The Eagle ik wil geen sites blokkeren, maar ik wil dat ze mijn DNS (pihole) gebruiken, zodat ik reklame kan blokkeren.

mediumdry schreef op zondag 31 augustus 2025 @ 15:17:
[...]
DNS gebruikt poort 53, TCP en UDP. DoT (DNS over TLS) gebruikt poort 853, TCP. Die zijn dus redelijk simpel te blokkeren voor alles in iedereen behalve je pihole. (hoewel ik je aanraadt om een volledige DNS server te gebruiken, pihole is dat *niet*.

Ik gebruik pihole als filter om reclame te blokkeren en dat doet zij op basis van DNS requests en block lists. Dus ja, is geen DNS maar hooguit een cache.
Je staat de spijker op zijn kop, ik wil een rule maken die uitgaand verkeer naar port 53 blokkeert behalve voor mijn pihole. DoT, port 853, kan ik wel blokkeren

Het grote probleem (in more ways than one) is DoH (DNS over HTTPS), want dat gebruikt poort 443, die kan je moeilijk voor iedereen afsluiten, tenzij je geen webbrowser gebruikt.

Klopt maar ik wil eerst het normale verkeer blokkeren

Je kan traffic captures maken om te zien welke DoH servers gebruikt worden, of je kan de DoH servers die bekend zijn blokkeren. ( https://github.com/DNSCrypt/dnscrypt-resolvers )

Ik kan nog niet direct vinden hoe ik dat moet doen, maar stap voor stap en eerst 53 oplossen.

Dus als iemand een voorbeeld voor de regel die port 53 uit blokkeert behalve mijn pihole, graag
Het gaat hier dus om Firewall rules die je moet aanmaken.

[Theetjuh]

Je kunt eventueel dns hijacken, dus mocht een apparaat google dns voor gedefineerd hebben, kun je dit rerouten naar je pi-hole, heb ik ook gedaan en werkt perfect.

Mocht je zoiets willen doen, zou je naar de volgende YT’s kunnen kijken:

[ Voor 46% gewijzigd door Theetjuh op 31-08-2025 17:45 . Reden: Toevoeging van YT video’s ]

[The Eagle]

@Maarten60 helpt dit:
https://community.ui.com/...e3-4408-b6ae-da73d28cda99
https://community.ui.com/...9b-4011-be78-60633e8721e2

Al vraag ik me af waarom je dan wilt blokkeren, en wat. Heb zelf ook een CG ultra, Pihole draaien en een Chromecast Ultra maar op die laatste echt nooit reclame oid. Enige wat ik er naar doe is casten vanaf telefoon of tablet. Ads worden er al bij het castende device uitgefilterd

[ Voor 32% gewijzigd door The Eagle op 31-08-2025 18:19 ]

[Vliegvlug]

The Eagle schreef op zondag 31 augustus 2025 @ 18:17:
@Maarten60 helpt dit: Heb zelf ook een CG ultra, Pihole draaien en een Chromecast Ultra maar op die laatste echt nooit reclame oid. Enige wat ik er naar doe is casten vanaf telefoon of tablet. Ads worden er al bij het castende device uitgefilterd

Je castende device doet toch helemaal niets meer met de stream, die wordt rechtstreeks door de chromecast opgehaald dus hoe kan die nog enige invloed hebben op het blokkeren van ads?

[mediumdry]

Maarten60 schreef op zondag 31 augustus 2025 @ 17:36:
Dus als iemand een voorbeeld voor de regel die port 53 uit blokkeert behalve mijn pihole, graag
Het gaat hier dus om Firewall rules die je moet aanmaken.

Op mijn UCG-Fiber in Settings, Policy Engine/Policy table, daar kan je een nieuwe policy aanmaken.

• Create Policy => Firewall
• geef het een naam
• Source zone: Internal
• Any
• Port Any
• Action Block
• Destination Zone => External
• Any
• Port => List
• Create New
• Add Multiple Network List Values => 53, 853
• IP version => Both
• Protocol => TCP/UDP
• Connection State All
• Schedule Always

Voor het toelaten naar de pihole:

• Create Policy => Firewall
• geef het een naam
• Source zone: Internal
• IP => IP address van de pihole machine. (dit heeft helaas tot gevolg dat je voor IPv4 en IPv6 aparte rules moet aanmaken, als je allebei gebruikt.
• Port Any
• Action Allow
• Destination Zone => External
• Any
• Port => List
• Create New
• Add Multiple Network List Values => 53, 853
• IP version => IPv4 of IPv6, afhankelijk van het pihole adres
• Protocol => TCP/UDP
• Connection State All
• Schedule Always

Dat zou voor DNS en DoT genoeg moeten zijn. Er is, als je in plaats van Destination Any voor App kiest, dan is er wel de optie om te kiezen voor DNS, DNS over TLS *en* DNS over HTTPS. Misschien blokt dat al het verkeer in 1 keer, maar dat zou je moeten testen. Het openen voor pihole is beter om 53 en 853 gewoon open te zetten naar buiten toe.

Ben benieuwd of het makkelijk gaat!

[Will_M]

@mediumdry In plaats van een 'block' geef je een firewall beter een 'drop' actie op..... Je mag zélf gaan uitzoeken waarom ik dat nu zeg

[ Voor 3% gewijzigd door Will_M op 31-08-2025 20:54 ]

[servies]

Will_M schreef op zondag 31 augustus 2025 @ 20:52:
@mediumdry In plaats van een 'block' geef je een firewall beter een 'drop' actie op..... Je mag zélf gaan uitzoeken waarom ik dat nu zeg

Vertel...
Voor inkomend verkeer snap ik het, maar uitgaand zie ik dat pluspunt niet.

[Will_M]

servies schreef op zondag 31 augustus 2025 @ 21:17:
[...]

Vertel...
Voor inkomend verkeer snap ik het, maar uitgaand zie ik dat pluspunt niet.

Jij 'kent' alle gebruikers en de gebruikte applicaties op een beheerd bedrijfsnetwerk ?

[servies]

Will_M schreef op zondag 31 augustus 2025 @ 21:37:
[...]


Jij 'kent' alle gebruikers en de gebruikte applicaties op een beheerd bedrijfsnetwerk ?

En nu is er een legitieme applicatie die om wat voor reden dan ook ergens hardcoded 8.8.8.8 als nameserver gebruikt. Met een drop krijg je waarschijnlijk geen foutmelding, alleen een timeout met mogelijk de melding in de software dat het internet (in het algemeen) het niet doet. Met een block krijg je dan waarschijnlijk een foutmelding dat hij de nameserver niet kan bereiken.
Daarnaast met een pihole als nameserver mag ik toch verwachten dat het een thuisnetwerk is.

[Will_M]

servies schreef op zondag 31 augustus 2025 @ 21:54:
[...]

En nu is er een legitieme applicatie die om wat voor reden dan ook ergens hardcoded 8.8.8.8 als nameserver gebruikt. Met een drop krijg je waarschijnlijk geen foutmelding, alleen een timeout met mogelijk de melding in de software dat het internet (in het algemeen) het niet doet. Met een block krijg je dan waarschijnlijk een foutmelding dat hij de nameserver niet kan bereiken.
Daarnaast met een pihole als nameserver mag ik toch verwachten dat het een thuisnetwerk is.

Ook zo'n thuis netwerk tuig je alléén op met dit soort apparatuur als je jezelf er in interesseert én je het jezelf liever té moeilijk dan gewoon gemakkelijk maakt (om daarmee uit te zoeken óf de door je zelf opgestelde 'rules' werken op de manier dat je verwacht, bijvoorbeeld?).

[mediumdry]

Will_M schreef op zondag 31 augustus 2025 @ 20:52:
@mediumdry In plaats van een 'block' geef je een firewall beter een 'drop' actie op..... Je mag zélf gaan uitzoeken waarom ik dat nu zeg

In de Unifi interface heb je de keuze uit Block, Allow of Reject. Block dropt het verkeer, Reject laat de originator van de verbinding weten dat de verbinding niet opgebouwd kan worden. ubiquiti heeft nog een behoorlijke weg te gaan naar "professioneel netwerk" bedrijf. Wat dat ook moge zijn

Persoonlijk til ik zwaarder aan het negeren dan wel als ondergeschoven kindje behandelen van IPv6 en dat ik geen network objects kan bouwen met zowel IPv4 en IPv6 adressen zodat ik niet allemaal dubbele firewall regels loop te bouwen. Ik heb een handvol services op verschillende adressen, met een /48 IPv6 en /29 en /32 aan legacy IP. Zit inmiddels aan 99 rules in m'n zone firewall. Het loopt snel uit de hand met verschillende zones (nu external, lab, lan (aka internal) en DMZ, en ik gebruik dus nog niet eens VPN en Hotspot ook niet de guest en IOT zones die ik eigenlijk graag zou willen gebruiken. Dan wordt het echt onoverzichtelijk/veel werk.

Anyway, edgerouter gaat niet verder dan 1gbps en er is niets dat ook maar in de buurt komt van de UCG Fiber als je 10gbps verbindingen wil voor het routen (de WAN verbinding is minder van belang, daar ben ik voorlopig nog blij met de 1gbps verbinding)

En om voor een klein homelabje nu meteen 2 routers te gaan opzetten met static routes danwel een IGP gaat me echt ff te ver. Dan ga ik liever eerst over op SDN voor m'n proxmox cluster als ik eens rustig m'n setup wil verkloten.

[mediumdry]

servies schreef op zondag 31 augustus 2025 @ 21:54:
En nu is er een legitieme applicatie die om wat voor reden dan ook ergens hardcoded 8.8.8.8 als nameserver gebruikt.

De app is dan wellicht "legitiem", maar is zeker malicious. Het verplicht een eindklant ongewenst data naar google te sturen of de app niet te gebruiken.

Kortom, blokkeren van DNS is eigenlijk noodzakelijk om dit soort coding practices af te straffen. </rant>

[servies]

mediumdry schreef op zondag 31 augustus 2025 @ 22:49:
[...]

De app is dan wellicht "legitiem", maar is zeker malicious. Het verplicht een eindklant ongewenst data naar google te sturen of de app niet te gebruiken.

Kortom, blokkeren van DNS is eigenlijk noodzakelijk om dit soort coding practices af te straffen. </rant>

Even ter duidelijkheid: Bij mij zijn er 2 computers die voor DNS naar buiten mogen en die staan ook in de DHCP aangegeven. En toen kwam ik erachter via m'n logs dat er 2 apparaten toch hun DNS vragen direct naar buiten probeerden te gaan. Om precies te zijn ze probeerden 8.8.8.8 als nameserver te gebruiken. 2x raden wat voor apparaten dat waren...
Om even duidelijk te zijn: ik zie het voordeel er niet van in om bij dit INTERN -> EXTERN verkeer een DROP te gebruiken ipv een REJECT. Het blocken op zich wel.

[mediumdry]

servies schreef op zondag 31 augustus 2025 @ 21:17:
Vertel...
Voor inkomend verkeer snap ik het, maar uitgaand zie ik dat pluspunt niet.

je snapt niet waarom je DNS verkeer naar buiten toe niet zou willen beheren? Er zijn een veelheid aan redenen, maar een paar voorbeelden zijn:

• ik wil logging van alle DNS queries die gedaan worden, waarbij ik gebruik kan maken van blocklists. (bijvoorbeeld domeinen geregistreerd in de laatste 30 dagen, het gros daarvan is snel weer weg en alleen in gebruik voor kwaadwillenden.
• ik wil geen DNS tunnels toestaan waarbij verkeer in en uit mijn netwerk gaat zonder dat ik daar controle over heb (je kan VPN over DNS doen, in de meeste gevallen heeft een netwerkbeheerder het niet door)
• ik wil nette resultaten van reverse DNS voor alle devices in mijn netwerk dus host ik dat zelf. Alle apparaten die door wat voor misconfiguratie dan ook niet de interne DNS gebruiken kunnen niet bij die data. (want ik krijg IANA en de RIRs nog niet ver RFC1918 ruimte naar mijn servers te delegeren en mijn ISP doet nog niet mijn IPv6 subnet naar mij delegeren)
• ik ben "properly paranoid"(tm) en wil dus zelf bepalen waar en hoe queries uit mijn netwerk het Internet op gaan
• ik wil een willekeurig extern domein (niet onder mijn beheer) met andere data hebben, voor wat voor reden dan ook. Dat kan alleen gedaan worden als DNS queries via *mijn* resolvers draaien. (beetje a la reverse DNS)
• ...
• profit!

DNS is een ander soort protocol dan vrijwel alle andere. Door de distributed manier van data verzamelen zijn er allerlei cornercases die aanvallers en andere kwaadwillenden mogelijkheden geven. Tegelijkertijd, aanvallers gaan vaak voor de simpele oplossingen. Als je https naar de buitenwereld volledig open hebt staan heeft het weinig meerwaarde een VPN via DNS op te zetten, sterker nog, dat zou langzamer zijn.

Maar hoe beter een netwerk dichtgetimmerd zit, hoe interessanter het wordt DNS te gebruiken, omdat zelfs de meeste netwerkspecialisten DNS niet echt goed beheersen. (iets dat de netwerkspecialisten overigens gemeen hebben met veel DNS specialisten!)

ik zelf weet genoeg van DNS dat ik weet dat ik niet zo veel van DNS weet, al weet ik meer dan menig ander.

[mediumdry]

servies schreef op zondag 31 augustus 2025 @ 23:02:
Om even duidelijk te zijn: ik zie het voordeel er niet van in om bij dit INTERN -> EXTERN verkeer een DROP te gebruiken ipv een REJECT. Het blocken op zich wel.

Het grote voordeel wat security betreft van een drop boven een reject/block is voor zover ik weet dat het de boel voor de aanvaller nogal vertraagd. Moeten wachten op een timeout duurt natuurlijk veel langer dan direct een "nope" melding terug te krijgen.

Voor legitieme, maar slecht gecodeerde apps is het dus beter om expliciet te rejecten/blocken, omdat je bij gebruik van die app anders als eindgebruiker zit te wachten op de timeout voordat de app als fallback wellicht de lokale DNS gaat proberen.

Het hangt volgens mij dus af van wat voor aanvallen je in je netwerk verwacht. En als een bedrijf een eigen DoH server opzet voor de hun netwerk hebbedingetjes dan is de kans groot dat je dat toch niet kan blokkeren.

[outlandos]

Ik ben vandaag van een Pixel 8 Pro naar een Pixel 10 Pro gegaan. Alles goed en wel, maar wat ik niet snap is waarom ik in speedtest op wifi "slechts" 550 haal terwijl op op dezelfde plek met mn Pixel 8 altijd rond de 900 zit.

Allebei staan verbonden met PHY 802.11be

Iemand enig idee waar het verschil in kan zitten?

[Jboy1991]

Hoi allen!

Wij hebben een dreammachine pro. En daar draait een vpn op zodat ik extern zaken intern kan beheren.

Nu heb ik op mijn iPhone wireguard en alles werkt prima totdat ik met de hotspot van mijn auto verbonden ben.

Met elk ander soort hotepot werkt het prima maar niet met die van lynk en co. Heeft iemand een idee hoe dit kan?

[Will_M]

Jboy1991 schreef op maandag 1 september 2025 @ 00:07:
Hoi allen!

Wij hebben een dreammachine pro. En daar draait een vpn op zodat ik extern zaken intern kan beheren.

Nu heb ik op mijn iPhone wireguard en alles werkt prima totdat ik met de hotspot van mijn auto verbonden ben.

Met elk ander soort hotepot werkt het prima maar niet met die van lynk en co. Heeft iemand een idee hoe dit kan?

Het interne hotspot netwerk(je) van je mobiele Chinees zal het waarschijnlijk niet helemaal eens zijn met ongecontroleerde VPN verbindingen, net zoals dat het in China gebruikelijk is voor alles wat daar 'lokaal' dient te blijven?

[outlandos]

outlandos schreef op maandag 1 september 2025 @ 00:03:
Ik ben vandaag van een Pixel 8 Pro naar een Pixel 10 Pro gegaan. Alles goed en wel, maar wat ik niet snap is waarom ik in speedtest op wifi "slechts" 550 haal terwijl op op dezelfde plek met mn Pixel 8 altijd rond de 900 zit.

Allebei staan verbonden met PHY 802.11be

Iemand enig idee waar het verschil in kan zitten?

Toevoeging: in de settings van mn telefoon ben ik wel 1 verschil tegengekomen: op de 8 Pro staat bij Frequency enkel 6 GHz, terwijl op de 10 Pro staat 5 Ghz, en 6GHz, zie:





Zou het verschil hieronder kunnen komen dat ik op mn oude Pixel 8 constant een stuk hogere snelheden haal in de speedtest, omdat die alleen op 6GHz staat? Valt hieraan nog iets te doen? Voelt namelijk als een downgrade dit... Terwijl het juist een upgrade zou moeten zijn.

[ Voor 3% gewijzigd door outlandos op 01-09-2025 01:46 ]

[servies]

mediumdry schreef op zondag 31 augustus 2025 @ 23:07:
[...]

je snapt niet waarom je DNS verkeer naar buiten toe niet zou willen beheren? Er zijn een veelheid aan redenen, maar een paar voorbeelden zijn:

Dat snap ik wel. Het ging mij om de DROP versus REJECT.
Als je goed leest kun je zien dat ik zelf ook eigen DNS servers draai

[The Eagle]

Jboy1991 schreef op maandag 1 september 2025 @ 00:07:
Hoi allen!

Wij hebben een dreammachine pro. En daar draait een vpn op zodat ik extern zaken intern kan beheren.

Nu heb ik op mijn iPhone wireguard en alles werkt prima totdat ik met de hotspot van mijn auto verbonden ben.

Met elk ander soort hotepot werkt het prima maar niet met die van lynk en co. Heeft iemand een idee hoe dit kan?

Dat heeft niks met Ubiquiti te maken, want dat werkt gewoon goed zoals je zelf al aangeeft
Maak even een eigen topic zou ik zeggen
Sowieso: waarom zou je op een auto hotspot willen verbinden als je gewoon een telefoon met eigen data abo hebt?

[servies]

The Eagle schreef op maandag 1 september 2025 @ 08:56:
[...]

Dat heeft niks met Ubiquiti te maken, want dat werkt gewoon goed zoals je zelf al aangeeft
Maak even een eigen topic zou ik zeggen
Sowieso: waarom zou je op een auto hotspot willen verbinden als je gewoon een telefoon met eigen data abo hebt?

Omdat de data van die autohotspot mogelijk gratis is en de telefoon een beperkt abonnement heeft?
Maar goed dit heeft dus verder zoals al gezegd niets met Ubiquiti te maken.

[Jboy1991]

The Eagle schreef op maandag 1 september 2025 @ 08:56:
[...]

Dat heeft niks met Ubiquiti te maken, want dat werkt gewoon goed zoals je zelf al aangeeft
Maak even een eigen topic zou ik zeggen
Sowieso: waarom zou je op een auto hotspot willen verbinden als je gewoon een telefoon met eigen data abo hebt?

Lang leven apple carplay draadloos die wifi verbinding verplicht. Hij maakt dus automatisch verbinding met de hotspot en gebruikt data daarvan.

Ik heb idd liever niet dat het over hun eigen dns enz gaat. Maar met vpn heb ik dus geen data met als resultaat dat Waze geen wijzigingen meer binnenhaalt denk aan files, afsluitingen snz

[BiG-GuY]

outlandos schreef op maandag 1 september 2025 @ 01:46:
[...]


Toevoeging: in de settings van mn telefoon ben ik wel 1 verschil tegengekomen: op de 8 Pro staat bij Frequency enkel 6 GHz, terwijl op de 10 Pro staat 5 Ghz, en 6GHz, zie:

[Afbeelding]

[Afbeelding]

Zou het verschil hieronder kunnen komen dat ik op mn oude Pixel 8 constant een stuk hogere snelheden haal in de speedtest, omdat die alleen op 6GHz staat? Valt hieraan nog iets te doen? Voelt namelijk als een downgrade dit... Terwijl het juist een upgrade zou moeten zijn.

Precies mijn ervaring met MLO. Die heb ik dus niet aangezet op mijn netwerk. Heb 1 SSID met advanced op Auto en alles wat 6Ghz kan, verbind daar prima op met 1200-2000Mbps snelheid, afhankelijk van het apparaat en afstand tot AP.

MLO zorgt over het algemeen voor een lagere performance. Het kan op papier meer snelheid geven, maar 5Ghz is zelden schoon genoeg in een appartement of rijtjes huis in NL en als je base band dan 5Ghz is ipv 6Ghz is je snelheid en stabiliteit gewoon slechter.

De Pixel 8 heeft afhankelijk van de regio andere wifi specs, maar heeft dus waarschijnlijk niet de volledige Wifi 7 spec met MLO.

[ Voor 8% gewijzigd door BiG-GuY op 01-09-2025 13:04 ]

[The Eagle]

Jboy1991 schreef op maandag 1 september 2025 @ 12:47:
[...]

Lang leven apple carplay draadloos die wifi verbinding verplicht. Hij maakt dus automatisch verbinding met de hotspot en gebruikt data daarvan.

Ik heb idd liever niet dat het over hun eigen dns enz gaat. Maar met vpn heb ik dus geen data met als resultaat dat Waze geen wijzigingen meer binnenhaalt denk aan files, afsluitingen snz

Nogmaals, geen Ubiquiti of VPN probleem, maar CarPlay ding. Je kunt die ook forceren op een wired verbinding, probeer dat eens. Scheelt ook batterij gebruik

[ASS-Ware]

The Eagle schreef op maandag 1 september 2025 @ 19:44:
[...]

Nogmaals, geen Ubiquiti of VPN probleem, maar CarPlay ding. Je kunt die ook forceren op een wired verbinding, probeer dat eens. Scheelt ook batterij gebruik

Mijn iPhone behoudt gewoon zijn Wireguard VPN tijdens carplay.

[outlandos]

BiG-GuY schreef op maandag 1 september 2025 @ 13:00:
[...]

Precies mijn ervaring met MLO. Die heb ik dus niet aangezet op mijn netwerk. Heb 1 SSID met advanced op Auto en alles wat 6Ghz kan, verbind daar prima op met 1200-2000Mbps snelheid, afhankelijk van het apparaat en afstand tot AP.

MLO zorgt over het algemeen voor een lagere performance. Het kan op papier meer snelheid geven, maar 5Ghz is zelden schoon genoeg in een appartement of rijtjes huis in NL en als je base band dan 5Ghz is ipv 6Ghz is je snelheid en stabiliteit gewoon slechter.

De Pixel 8 heeft afhankelijk van de regio andere wifi specs, maar heeft dus waarschijnlijk niet de volledige Wifi 7 spec met MLO.

Goede tip, thanks. MLO nu uitgezet en haal 930 op mijn Pixel 10P... Wat met kpn via wifi zo'n beetje de max is.

[BiG-GuY]

outlandos schreef op dinsdag 2 september 2025 @ 23:05:
[...]


Goede tip, thanks. MLO nu uitgezet en haal 930 op mijn Pixel 10P... Wat met kpn via wifi zo'n beetje de max is.

Als je ook een Unifi Gateway hebt, kan je via Wifiman op lokaal netwerk niveau testen naar de Gateway.

Dan ben je niet gelimiteerd tot je internetsnelheid, maar je netwerk snelheid. Als je interne netwerk ook 1Gbps is, zal dit idd de max snelheid zijn.