AdGuard maakt moeilijk detecteerbaar eigen vpn-protocol opensource

AdGuard heeft zijn eigen vpn-protocol opensource beschikbaar gemaakt. Het protocol heet nu TrustTunnel en moet concurreren met bijvoorbeeld OpenVPN en WireGuard, maar is volgens AdGuard moeilijker te detecteren voor externe diensten. AdGuard publiceert de technische specificaties en maakt de broncode beschikbaar voor hergebruik.

AdGuard schrijft dat het zijn eigen vpn-protocol algemeen beschikbaar maakt en ook meteen een nieuwe naam geeft. Dat heet nu TrustTunnel, dat inmiddels een eigen website heeft. TrustTunnel is volgens AdGuard vergelijkbaar met andere openbare vpn-protocollen, waaronder OpenVPN of WireGuard.

Het grote verschil zit in de manier waarop TrustTunnel moeilijker kan worden gedetecteerd. AdGuard zegt dat verkeer via HTTP/2 en HTTP/3 wordt verzonden en met TLS wordt versleuteld. Iedere verbinding werkt volgens AdGuard met datastromen, waardoor het moeilijker zou zijn voor diensten om TrustTunnel-verkeer te herkennen, maar waarmee de normale snelheid wel behouden blijft.

De tool is voornamelijk in Rust geschreven en is opensource beschikbaar. Dat betekent in de eerste plaats dat AdGuard documentatie online heeft staan over het gebruik van het protocol, zoals installatie-instructies.

Verder is de broncode beschikbaar onder een Apache 2.0-licentie. Daarmee kan iedereen de code inzien, maar ook aanpassen, hergebruiken en, mogelijk het relevantst, gebruiken in andere commerciële producten. Daarmee is het goed mogelijk dat er in de toekomst meer vpn-opties op de markt komen die het protocol ondersteunen, buiten AdGuard zelf.

De tool is beschikbaar via de commandline op Windows, macOS en Linux. Verder maakt AdGuard losse apps beschikbaar voor iOS en Android.

Reacties (81)

[laurxp]

Mullvad heeft al een tijdje QUIC obfuscation, waarmee je ook via een standaard protocol UDP over HTTP/3 kan tunnelen. Cloudflare doet hetzelfde voor hun "Zero-Trust WARP". D'r zijn ook al mensen die iets vergelijkbaars aan het DIYen zijn met een compleet open software stack.

Wat maakt AdGuard's nieuwe protocol zó bijzonder dat het de moeite waard is om het wiel opnieuw uit te vinden?

[Reactie gewijzigd door laurxp op 23 januari 2026 17:50]

[kimborntobewild]

Irritant van Mullvad is dat je maar een licentie voor 1 jaar per keer kunt kopen. Ze hebben geen zin in support geven aan mensen die problemen hebben met een licentietermijn langer dan 1 jaar.

[Overheid]

Dit kun je ook zelf hosten, mocht je geen zin hebben in Mullvad: https://docs.amnezia.org/documentation/amnezia-wg/

[bcome]

In mijn tijd noemden we dat gewoon een proxy. Heeft weinig met Virtual Private Networks te maken.

[lenwar]

Nee, dan snap je niet wat een proxy (of een VPN) is.

Heel kort door de bocht:

Een proxy (Grieks voor 'gevolmachtigde') is een systeem dat namens de client een verzoek doet. (de proxy is dus volledig bewust van wat er wordt gevraagd). (de browser (of ander stuk software) doet een verzoek aan de proxy, om namens hem een webpagina op te halen.)
Een VPN 'verbind twee netwerken aan elkaar' met een (virtuele) tunnel. De VPN 'weet niet' wat voor verkeer er doorheen gaat. (er moet dus een netwerkroute worden gedefinieerd om het verkeer er doorheen te laten lopen.)

Nogmaals. Heel kort door de bocht, want aan beiden kunnen haken en ogen zitten die overlap kunnen creëren.

Het gebruikte protocol (https/wireguard/iets anders) heeft er in elk geval niets mee te maken.

[GertMenkel]

De tunnel is niets anders dan een proxy die bepaalde CONNECT's anders interpreteert. Voor het TCP-gedeelte kun je net zo goed Squid (of zelfs Nginx) over HTTP2/QUIC laten draaien, mits je maar je client configureert om CONNECT te roepen naar de HTTP-proxy in plaats van GET/POST/PUT/etc.

Ik zou zelf een proxy die in staat is CONNECT af te handelen niet als VPN bestempelen, want dan houd je geen proxy's meer over sinds ongeveer HTTP 1.1. Het gedeelte van het protocol dat echt wat speciaals doet, het UDP/ICMP-gedeelte, is ook verwikkeld in een HTTP CONNECT call.

Alles wat over deze client stroomt, is technisch gezien correct HTTP-verkeer. Je zou het zelfs over HTTP 1.1 kunnen gooien. Pak het UDP/ICMP-parsegedeelte, maak er een apart stukje software van dat op poort 80 luistert, en draai die software op hostnames _udp en _icmp, en in theorie kun je Squid als TrustTunnel-server gebruiken.

Wil je er een "echte" VPN van maken, dan moet je naar mijn mening toch een L2TP/PPTP-achtig protocol toevoegen aan de VPN. Kan op zich prima natuurlijk!

[bcome]

Die definitie zou best ergens kunnen kloppen, maar volgens https://github.com/TrustTunnel/TrustTunnel/blob/master/PROTOCOL.md#5-tcp-connection-tunneling moet de client een specifiek request doen naar de server met waar het request heen moet en wat voor protocol dat moet. Wat volgens jouw definitie een proxy zou moeten zijn.

[Da_Plague]

TrustTunnel gebruikt tls over http om zijn verkeer te transporteren en maakt daarmee het VPN-verkeer bijna niet te onderscheiden van normaal https-verkeer, dus iets andewrs dan een proxy.

[Olaf van der Spek]

Ondersteunen Wireguard en OpenVPN dat niet? Je zou denken dat dat geen rocket science is.

[peggman]

Wireguard ondersteunt alleen UDP en is daarom al heel makkelijk te blokkeren, OpenVPN op TCP/443 is met een klein beetje deep packet inspection vrij makkelijk te onderscheiden van normaal browserverkeer.

[laurxp]

HTTP3 is ook UDP, dus UDP vs TCP zal geen groot verschil maken.

[keejoz]

Niet native, het kan wel via omwegen. Het is makkelijker om te switchen naar v2ray of iets dergelijk.

[GertMenkel]

Het protocol staat hier beschreven en in de basis is het wel degelijk een gewone HTTP-proxy. Voor TCP wordt een HTTP-tunnel gebruikt inderdaad, maar voor UDP en ICMP worden HTTP/2 en HTTP3-features gebruikt voor het multiplexen van de verbinding. Overigens wordt er, in tegenstelling tot ouderwetse proxies, geen GET/POST/PUT ondersteund; alleen CONNECT werkt.

Voor UDP en ICMP wordt er ge-CONNECT met een nep-host, worden pakketjes in een speciale laag gewikkeld, en worden ze door de "proxy" uitgepakt en het netwerk opgestuurd (en andersom voor het antwoord). Dat maakt het nog weer anders van een normale proxy, die in principe aan twee kanten HTTP of TCP kan praten maar meer niet.

In de tijd dat proxy's nog normaal waren, was het ook niet ongewoon om protocollen als SMTP en IMAP over HTTP-proxy's te gooien middels een CONNECT, precies zoals de TCP-stack van deze tunnel nu werkt. Dat was dan HTTP 1.1 (of zelfs 1.0), nu gebruiken ze HTTP/2 en HTTP3-over-QUIC, maar nog steeds gebruikt men de CONNECT-verb van de HTTP-standaard.

Voor het VPN-gedeelte (je IP-adressen en routering) heb je een extra protocol nodig. Je zou bijvoorbeeld L2TP of PPTP over TrustTunnel kunnen draaien, zoals je L2TP normaal over IPSec gooit om de verbinding te beveiligen. Daarvoor zul je wel client en server moeten uitbreiden, aangezien ze momenteel alleen TCP, UDP, en (voor een deel) ICMP ondersteunen.

[KillerAce_NL]

Ik snap je opmerking niet, dit is heel wat anders dan een proxy, dit is wel degelijk een virtual private network.

[bcome]

Wat voor netwerk zet het op dan? Want de documentatie zegt daar niks over. Het heeft wel een `allow_private_network_connections` instellling zodat je endpoint requests naar private IP adressen door zou laten, maar dan heb je meer een bastion host dan een VPN.

[Reactie gewijzigd door bcome op 23 januari 2026 15:32]

[locke960]

Ik snap de opmerking wel. 3 minuten tussen posten nieuwsbericht en zijn comment.

[Frogmen]

Denk dat je beter moet lezen want het is echt VPN

[Jack Flushell]

Dat is wel heel erg kort door de bocht. Zo kun je heel veel dingen proxy noemen. Het lijkt qua datastromen wel op een proxy hoor, maar er zijn belangrijke verschillen, zoals extra veiligheidsfeatures en udp/icmp. Qua functionaliteit is het in elk geval een VPN.

[Frogmen]

Mooie ontwikkeling in deze tijden dat landen internet verkeer aan banden leggen. Dan is het natuurlijk fijn als je een VPN kan opzetten die niet gedetecteerd wordt.

[FreakNL]

Ik ben in 2024 zeveb weken in China geweest. Totaal 0 problemen met een WireGuard tunnel naar mijn huis. Draaide zelfs op de standaard poort van WireGuard. Ik had verwacht dat de Great Firewall wel efficiënter zou zijn ofzo…

[Pret]

Zat je op een e-sim/sim of op de wifi in het hotel. dat maakt namelijk wel wat uit.
Op een buitenlandse sim heb ik nooit problemen, maar zodra ik op een wifi netwerk wat wou doen was het afgelopen.

[FreakNL]

Wifi in hotel en op site…

op mijn mobiele internet (NL 4g) had ik sowieso minder problemen.

[Pret]

Ik krijg het nooit werkende op de wifi van een hotel, Expressvpn, OpenVPN, NordVPN alles geprobeerd niets werkt. Dit jaar maar weer nieuwe stappen ondernomen, Wireguard / OpenVPN + wat betaalde chinese VPN's in de hoop dat het nu wel werkt.

Buitenlandse sim 0 problemen idd.

[FreakNL]

Ja dat zijn allemaal commerciële diensten.

ik heb het over een VPN naar mijn eigen huis.

[Pret]

Die heb ik ook geprobeerd, openvpn naar huis. Had 2 verschillende connecties 1x Udp, 1x utp op verschillende poorten. Geen wou werken helaas.

[Barsonax]

Mijn ervaring is dat wireguard geblokkeerd is met een Chinese sim of wifi. Astril VPN werkte wel (maar is feitelijk Chinese staats vpn).

[GamesBond]

Ik kom een paar keer per jaar in China, nooit problemen met VPN naar een FritzBox die op kantoor staat of de fritzbox die in huis staat. Een grote VPN provider zal wel geblockt worden ja. En ik koop altijd een lokale (fysieke) SIM meteen in de aankomst hal van de luchthaven

[Isotope5004]

Ik heb succes met DPI omzeilen met amneziavpn, maar (nog) niet in china getest. Ze zeggen dat het wel zou moeten werken in elk geval!

[NTB_Appie]

Probeer PrivadoVPN, werkt tot nu toe als een van de beste. 10GB is volgens mij gratis, wil je meer gebruiken neem dan een abbo voor iets meer dan een euro per maand (2 jaar). gebruik de vpn ook in andere landen en in NL. Werkt goed en snel. gebruik je weinig data dan is de gratis versie al Prima. Kom er vaker en heb heel veel soorten gebruikt. Deze werkt tot nu toe als 1 van de beste samen met Astro VPN maar die is in mijn ogen extreem duur. Mocht je vragen hebben stel het gerust

[ccnl]

Misschien ben je niet belangrijk genoeg. Het is een fluitje van een cent jouw verbinding naar thuis server te detecteren. Je bent immers alleen met een ip adres verbonden, en dit is meteen verdacht, ongeacht welke protocollen je ook gebruikt.

[Jerie]

Ik las gisteren over dit nieuws op HN. Daar las ik in het commentaar dat Chinezen doorgaans slechts een deel van hun verkeer door VPN rammen. Nooit alles want dat valt teveel op.

In die context lijkt vooral Xray-core aka v2ray gangbaar https://github.com/XTLS/Xray-core zie ook deze talk waarbij iemand allerlei (meta)data kon lekken van verkeer dat door GFW lijkt te gaan: https://media.ccc.de/v/39...ackers-breached-the-great

[_Pussycat_]

Ik had hetzelfde gedaan met een Windows-tunnel (weet echt niet meer de naam van het protocol), en dat deed het pas weer toen ik in Europa uit het vliegtuig stapte.

[codeneos]

Dan heb je geluk gehad. Ik ben eind 2025 in China geweest en op de Hotel WiFi deden standaard VPN diensten het eigenlijk allemaal niet. ExpressVPN, NordVPN lieten het beide afweten.

Wat wel gedeeltelijk werkte was een eigen ShadowSocks VPN server en dan alleen bepaalde traffic door de tunnel heen. Dus niet alles maar alleen diensten die of geblokt zijn zoals WhatsApp, Telegram en alles wat iets mer Google te maken heeft. Zo kan je langer onder de radar blijven van de GFW.

[supersnathan94]

Wireguard VPN naar je huis wordt ws meegerekend als Zakelijke VPN. China erkent wel dat het voor bedrijven een noodzakelijke beveiliging is en dus kun je enterprise VPN apps wel draaien.

Het gaat vooral om de commerciële diensten in combinatie met Chinese consumenten dingen.

[ronansoleste]

Denk vooral dat je geluk hebt gehad en dat ze mogelijk meegekeken hebben met je.
Waarschijnlijk hebben ze het prima gezien en in de gaten gehouden wat je deed.

[To_Tall]

Verkeer is end to end versleuteld. Nog voor het verkeer van je pc of telefoon het internet op zijn gegaan.

Lijkt me niet direct aannemelijk dat men heeft mee kunnen kijken. Tenzij ze jou private-keys in handen hebben gekregen.

[dutchgio]

Niet in zoverre de inhoud gezien maar als ze zien dat apparaat x een VPN opzet naar een thuisadres in Nederland is dat niet spannend genoeg om te blokkeren.

[analog_]

hongkong sim zeker

[amusedly]

Inderdaad. In de VK zal dit mogelijk populair worden i.v.m. blokkades adult content daar.

[The Zep Man]

In het VK worden (herkenbare) VPN's niet geblokkeerd. Ook lijken daar geen plannen voor te komen, want dan raak je ook bijvoorbeeld het bedrijfsleven (dat daar tegen lobbyt).

[Flex-Able]

Gelukkig is AdGuard Software Limited officieel opgericht op 1 juni 2009 in Moskou, Rusland, en dus absoluut niet Amerikaans!

Het bedrijf is later verhuisd naar Cyprus (hoofdkantoor in Limassol), maar de roots liggen duidelijk in Rusland. Perfect voor wie privacy-tools zoekt zonder Uncle Sam in de buurt.

[KillerAce_NL]

Compleet open source, dus wat wil je zeggen ? Al was het wel US software geheime backdoors zijn dan zo gevonden..

[dylan111111]

Bij open source software ga je er vaak van uit dat anderen de code grondig controleren op veiligheid en achterdeuren. Maar als iedereen denkt: ‘Dat doet wel iemand anders’, dan gebeurt het misschien helemaal niet. En juist dán kan er onopgemerkt een verborgen backdoor in de code blijven zitten.

[TEMwave]

Er hoeft maar 1 iemand over een backdoor in de code te struikelen, en het is over en uit met het vertrouwen in je product en daarmee je bedrijf. Voor een bedrijf zou het dan ook (financieel gezien) een ongelofelijk dom idee zijn om een backdoor in publieke code te zetten. Dan kan je het beter closed source houden...

[cracking cloud]

Open source klinkt mooi, maar heb je ook garantie dat de source die online staat exact hetzelfde is als wat in hun uiteindelijke product zit?

[telenut]

Als je de bron hebt kan je zelf compilen...

[lenwar]

Maar heb je ook de code van de compiler gecontroleerd? 🤔

[TEMwave]

Leg me even uit welk belang de schrijvers van de rust compiler precies hebben bij het verstoppen van backdoors in adguard?

[donkerlicht]

Door wie? Vorige maand kwam ik bij een serverproject nog een backdoor tegen die er vier jaar geleden in is gezet. Niet dat ik alle code doornam, maar toevallig een bug aan het oplossen was waarbij ik alleen de betrokken code bij de bug bekeek. Dus backdoors zijn niet zomaar gevonden. Er zullen mensen moeten zijn die die code zorgvuldig doornemen, of er, zoals in mijn geval, toevallig op stuiten.

[To_Tall]

Er zijn meerdere Russische applicaties uitgebracht. Maar waar de ontwikkelaars Rusland zijn uitgegaan of zelfs gevlucht.

Paar redelijk bekende applicaties. Kaspersky, 7-zip nginx.

[Martinspire]

Ik denk dat ze met deze actie dan ook wat minder aandacht willen leggen op hun Russische afkomst. Want er waren nogal wat mensen die daar heel negatief over dachten en het idee hadden dat het verkeer dan wel afgetapt moest worden.

[Faifz]

Als het zou kloppen dat het gezien wordt als HTTPS verkeer, wordt dit gewoon gezien als SSL als applicatie op een PAN firewall. In een veilige omgeving, is het niet de bedoeling dat SSL toegelaten wordt als SSL decryption geimplementeerd is. Wanneer het decrypted is, wordt het gezien als web-browsing.

Ik durf wel niet te zeggen of een firewall dit wel kan decrypten. Als het mogelijk zou zijn om deze trusttunnel te decrypten, dan is een firewall wel in staat om dit te herkennen als VPN.

[amusedly]

Decrypten zou kunnen als de client gecompromitteerd is toch? Bijv. een speciale Windows install waarbij de browser ingesteld is om een extra CA te herkennen als vertrouwd? Dus als de AdGuard client integer gedraaid wordt, is de vraag wat die client als vertrouwde CA beschouwd. Als de client op het OS vertrouwd voor de CA lijst, zou AdGuard misschien decrypted kunnen worden door de firewall. Of zit ik er helemaal naast?

[Reactie gewijzigd door amusedly op 23 januari 2026 15:25]

[GertMenkel]

Ontsleutelen werkt alleen als je volledige man-in-the-middle werkt. Dat betekent doorgaans een CA-certificaat op het systeem met een MitM-proxy die het verkeer onderschept. In Linux zou je met een eBPF-programma nog kunnen klieren met het validatiemechanisme van OpenSSL (heel handig voor debuggen van HTTPS-verbindingen!), maar dan moet je wel software van je netwerkbeheerder als root draaien.

In de firewall-setup zoals @Faifz naar mijn interpretatie beschrijft is er geen route naar buiten die niet door de proxy gaat. Je computer accepteert MitM of je computer heeft geen internet. Op bedrijfsnetwerken (en voor korte tijd ooit in Kazachstan) wordt die opstelling nog wel eens gebruikt om het lekken van informatie tegen te houden.

Je privé-computer krijgt op zo'n netwerk gewoon geen internet en geeft een beveiligingswaarschuwing. Je WireGuard/OpenVPN/IPSec-tunnel van een traditionele VPN-client krijgt niet eens verbinding met de andere kant.

Overigens kan de firewall nog wel trucjes uithalen om de VPN te blokkeren. Aangezien de SNI-header van het TLS-protocol in principe gewoon leesbaar is, kan de firewall besluiten om verbindingen op basis van hostname te filteren. Daar kom je omheen met domain fronting, maar als je firewall ook daadwerkelijk het certificaat valideert, kan die op die manier zorgen dat je wel naar google.com kan maar niet kunt verbinden met vpn.adguard.net. Om daar omheen te komen heb je technoligieën als ECH (Encrypted Client Hello), maar dat kun je met zo'n MitM-box simpelweg blokkeren (aangezien je in zo'n setup ook DNS-verkeer zult filteren, en dus de nodige records voor ECH gewoon wegfiltert en DoT/DoH simpelweg niet toestaat).

[Faifz]

@GertMenkel heeft het wel heel goed uitgelegd en zijn uitleg is volledig correct. En dat zeg ik als iemand die bekend staat als een "nitpicker".

SSL decryption vind je alleen maar terug in een bedrijfsnetwerk waar users in een Active Directory domain zitten en die users hebben natuurlijk de root CA (certificaat) van het domain geïnstalleerd staan - en dat is standaard en automatisch zo.

Dus het enige wat je moet doen is een sub CA laten tekenen door de root CA (Active Directory). En die sub CA gooi je gewoon op de firewall. Users vertrouwen de sub CA omdat het getekend is door de root CA.

Gert heeft wel gelijk dat firewalls SNI headers gebruiken om een applicatie te herkennen, maar App-ID van Palo Alto kan eigenlijk veel meer dan enkel alleen maar naar de SNI headers te kijken.

Ik heb net AdGuard VPN geprobeerd maar de firewall herkent dit als "quic-base" en dit is zonder decrypting, dus het wordt geblokkeerd.

https://imgur.com/a/514XAu3

Wij blokkeren altijd QUIC als applicatie, en een tweede regel dat ook 443/UDP en 80/UDP blokkeert - dit wordt aangeraden omdat firewalls altijd niet evident zijn om QUIC verkeer te herkennen. Alleen Cisco ondersteunt QUIC decrypting op het moment, maar het is in een beta fase.

[lenwar]

In een sniffer zal je het verkeer herkennen als https, maar verder niet. Dit kun je uit de headers halen.

[GertMenkel]

Ik denk dat een goede firewall hier wel iets meer mee kan. Een QUIC-tunnel die urenlang up blijft en zich lijkt te gedragen als een netwerklink is niet heel moeilijk te onderscheiden van een echte HTTP-sessie. Voor HTTP/2 is dat helemaal het geval, zoveel streams openen browsers normaal helemaal niet over dezelfde verbinding.

Je zult over tijd het verkeer moeten profilen om er een beslissing over te maken, maar het is niet onmogelijk te onderscheiden van HTTPS. Ik verwacht dan ook dat China's Grote Vuurmuur snel korte metten maakt met dit protocol.

[jumbos7]

Ik dacht dat het delen van het IP adres met meerdere gebruikers de duidelijkste aanwijzing is voor VPN-gebruik. Dat los je hiermee toch niet op of zie ik iets over het hoofd?

[Sinna]

Dat hoeft helemaal niet: als je achter een CGNAT zit, dan deel je publiek ook één en hetzelfde IP-adres met tig anderen.

[jumbos7]

Dat snap ik maar de IP-reeks zal dan vaak gekoppeld zijn aan bekende ISP's die je met een IP-to-ISP database kunt uitsluiten. Maar goed dat soort databases identificeren ook VPN's, Tor exit nodes en open proxy's voor je dus ik weet niet hoeveel het VPN-protocol uitmaakt. Maar ik weet er zelf te weinig vanaf om dit op waarde te schatten.

edit:

Klopt. Maar dit gaat over het verhullen van het verkeer over het netwerk zelf. Normaal worden er aparte poorten hiervoor gebruikt waardoor het heel makkelijk is te detecteren is in bijvoorbeeld een firewall. Maar nu gaat het over HTTPS dus is het veel moeilijker te onderscheiden.

@orvintax Dat verduidelijkt de zaak voor mij, maar of het in de praktijk veel uitmaakt zal toch afhangen van de VPN-detectie technieken die gebruikt worden en hoe een VPN-provider IP adressen uitkiest.

[Reactie gewijzigd door jumbos7 op 23 januari 2026 15:47]

[GertMenkel]

Mijn IPv4-adres van een Nederlandse provider staat op Wikipedia's Open Proxy-lijst. Moet er misschien nog een keer een mailtje over sturen.

Ik zou die databases niet per se vertrouwen om de waarheid te vertellen, veel ervan bevatten verouderde records, false positives na een port scan, en andere vaagheden. Goed genoeg als je het niet erg vind om mensen als mij soms onnodig te blokkeren; niet goed genoeg als je niet wilt dat het klanten kost.

Nu dat misbruik/scrapen veelal via "residential proxies" (dat noemden we vroeger een botnet) loopt, kun je ook niet meer vertrouwen dat consumenten-ISP's vol consumenten zitten. Diverse gratis VPN's maken jouw computer een exit node voor het botnet dat aan commerciële partijen wordt verhuurd en de meeste mensen die dat gebruiken zijn daar niet van op de hoogte.

Er zijn wel trucjes om VPN's te detecteren, overigens; een ongebruikelijke MTU, afwijkend gedrag bij MSS-clamping en bepaalde latency-metrics maken het bijvoorbeeld mogelijk om een goede gok te doen of de afzender echt op de computer draait die het verkeer ook het internet op slingert. Je kunt er niet 100% op vertrouwen (want sommige mensen zitten nu eenmaal op inbelverbindingen en netwerken met bizarre MTU's) maar er zijn wel goede signalen.

[orvintax]

Klopt. Maar dit gaat over het verhullen van het verkeer over het netwerk zelf. Normaal worden er aparte poorten hiervoor gebruikt waardoor het heel makkelijk is te detecteren is in bijvoorbeeld een firewall. Maar nu gaat het over HTTPS dus is het veel moeilijker te onderscheiden.

[Niema]

Websites hebben hier misschien iets aan, maar het gaat nu vooral over verbergen voor de isp. Dat jij altijd dezelfde ip adres bezoekt kan raar zijn, maar geen bewijs. Aws, Google, Cloudflare, Oracle hebben allemaal ip adressen die over vele sites gedeeld worden. Host jij je vpn op zon service dan gaat t wss sowieso wel goed. Verbergen dat jij een vpn gebruikt voor de site die je bezoekt is een stuk uitdagender, maar lijkt niet de bedoeling te zijn. Alleen verbergen voor isp. Ik vind het vooralsnog vreemd dat logische moderne protocollen zoals vless+,reality, naiveproxy die andere sites succesvol weten te fronten nauwelijks gebruikt worden door vpn aanbieders. Zal wel iets met schaling te maken hebben en sndere beheer problemen

[ApexAlpha]

Wireguard op poort 53 werkt heerlijk in netwerken die anders dicht staan.

[ThinkPad]

Ik was een tijd terug in een vakantiehuisje in Duitsland, was daar verbonden met het gastnetwerk van een Fritz!box en die had een hele lelijke setting actief: al het uitgaande UDP-verkeer blokkeren.
Ik kreeg daar dus ook met geen mogelijkheid m'n Wireguard-tunnel aan de praat. Normaal heb ik hem over 443 lopen, maar 53 (of elke andere willekeurige poort) lukte dus ook niet (want Wireguard == UDP).

ThinkPad in "NT Kroeg v0.1"

[Reactie gewijzigd door ThinkPad op 23 januari 2026 16:50]

[houwimmie]

Moest ik de firewall beheren zou ik poort 53 toch echt niet openzetten naar andere IPs buiten dat van de DNS servers die vanaf de DHCP server worden geadverteerd.

[telenut]

En nu dus uitzoeken hoe we dit op een bedrijfsnetwerk kunnen blokkeren...

[lenwar]

Al het https-verkeer door een interne proxy forceren (man in the middle), en dan zie je dat je geen webverkeer is. Dit doen veel bedrijven nu al.

[pennywiser]

Met welke tools dan, https en Openvpn over TCP 443 is toch niet te onderscheiden? Of is dat dan de uitzondering?

[lenwar]

Een willekeurige sniffer. WireGuard is een toegankelijke tool. De gebruikte poort is niet relevant. Je kunt als je wil ieder protocol over iedere poort laten lopen. (Alleen moeten de betreffende partijen wel hetzelfde doen 😄)

[rens-br]

Het zou mooi zijn als dit ook als installeerbare docker container uitkomt, maakt installatie wel zo eenvoudig.

[synoniem]

Er is een Dockerfile aanwezig in de repository.

[pennywiser]

publiceert de technische specificaties en maakt de broncode beschikbaar voor hergebruik

En daarmee gelijk beter detecteerbaar denk ik?