Hoe detecteert men eigenlijk een vpn?

[on4bam]

Hi,

Door TV te kijken in het buitenland kwamen we op een vervelend maar interessant probleem. Al jaren gebruiken we "weg van huis" een VPN verbinding naar de Fritzbox (of Synology met openVPN) thuis. Op die manier kijken/luisteren we ook naar VRT vanuit andere continenten en dat geeft nooit problemen.
Nu merkten we dat via de VTM website naar een programma kijken niet werkte (Macbook + Chrome + FB VPN) vanuit Spanje. Er werd een VPN verbinding gedetecteerd en blijkbaar mag je zo niet kijken.
Ik snap best dat IP ranges van veel VPN providers bekend zijn en op die manier geblokkeerd worden maar ik ging er altijd van uit dat wanneer men een verbinding op zet met thuis, en dus je bijna-vaste IP gebruikt, dat niet als VPN herkend wordt.
Iemand een idee hoe dit werkt? Is dat de reden waarom, zoals ik ergens las, bv. geen Linux, Firefox e.d. toe laat om DRM content te bekijken?
We hebben het niet getest maar zou het faken van de user-agent deze block kunnen vermijden?

Bij VRTmax (app en webite) en NPO (website) hadden we met Android/Firefox geen problemen maar daar hebben we ook geen VTM op gekeken.

[Sasuke]

Dat is altijd zichtbaar in de headers van het IP pakket. Wil je dat onzichtbaar maken zou je eigenlijk met een lokale proxy (e.g VPN -> Proxy -> VTM) of een extra NAT translatie inlassen (maar dat kan de Fritzbox niet).

[on4bam]

OK, bedankt voor de snelle reply.
Nu kan ik wat verder gaan zoeken, misschien is er dan wel een oplossing voor op de Synology (zonder docker) of is een RPi wel een mogelijkheid.

[raf1]

DPG Media (VTM) gebruikt Akamai Enhanced Proxy Detection: https://www.akamai.com/blog/performance ... -detection
Je zal dus een behoorlijk geavanceerd detectie-algoritme moeten verslaan.

[on4bam]

Eigenlijk blokkeren ze er de legitieme kijker mee. Er werd gekeken met "ons" thuis IP (en een device ID zullen ze ook wel checken) en hoewel we binnen de EU zaten zou de uitzending ook zonder VPN moeten bekeken kunnen worden (ik denk dat het De Verraders was). De VPN dient vooral om niet zichtbaar op het open hotelnetwerk te zitten.
Lukt het niet dan zal er wel gewacht worden tot thuis, dat is geen ramp.

[philippe_d]

Het was mij ook al opgevallen dat bepaalde programma's wel (vb VTM Nieuws) en andere programma's niet (vb: Sturm der Liebe) vanuit het buitenland kunnen bekeen worden.
Als ik vanuit Spanje (Mallorca) TV kijk, dan gebruik ik de Chromecast met Google TV. Hierop staan de Belgisch TV Apps VRTMax, VTMGo, GoPlus ...
En ook de Wireguard VPN App waarmee ik met de Fritz!Box thuis verbind.
Tot nu toe nog geen problemen ondervonden op deze manier.

Als je een mobiel toestel gebruikt met de VTMGo App kan het misschien gebeuren dat ze de locatie weten van het toestel (GPS, zendmasten, ...) en op die manier weten dat je vanuit het buitenland kijkt?

Vroeger, jaar of 10 geleden, voor we al die streaming diensten kenden, gebruikten we de Slingbox (EOL sinds Novmeber 2022)
Deze was verbonden met de Video uitgang van de decoder, en er waren IR zendertjes gericht op het IR oog van de decoder
Zodat je vanop afstand TV kon kijken (live, en opnames) en de afstandsbediening kon simuleren

Het analoge tijdperk had zo ook zijn voordelen

[CCatalyst]

Dat is altijd zichtbaar in de headers van het IP pakket. Wil je dat onzichtbaar maken zou je eigenlijk met een lokale proxy (e.g VPN -> Proxy -> VTM) of een extra NAT translatie inlassen (maar dat kan de Fritzbox niet).

Kan je toch wat verder uitleggen hoe VPN "altijd" zichtbaar is in de headers van het IP pakket? Als je als client verbindt met de VPN server, en je vraagt iets op dat de server forward, dan stript een goede VPN server alles wat de VPN zou verraden... Mocht dit niet het geval zijn dan zou het voor China wel makkelijk zijn om alle VPN's te blokkeren, niet?

Enige header waar je het wel kan zien (niet altijd) is in de headers het feitelijke TCP pakket.

Iemand een idee hoe dit werkt?

Volgens mij niet obv headers die zouden lekken, zoals Sasuke zegt, maar misschien begrijp ik verkeerd wat hij eigenlijk bedoelt.

Er zijn verschillende methodes, zaken als Akamai doen een grading obv signalen, hierbij enkele voorbeelden:
- wat de waarde van de MTU op de verbinding is is een ongelofelijke giveaway, MAAR niet op zichzelf, je moet ook het IP adres evalueren (specifiek wat de provider ervan is) om meer zekerheid te hebben. Als je bv altijd een hoge MTU had thuis op je thuis IP, en plots is dat lager op hetzelfde IP, mag je uitgaan van VPN.
- hetzelfde geldt ook voor latencies, als die plots hoger worden dan gebruikelijk is dat een signaal, evenwel zwakker dan MTU
- niet alle VPN implementaties zijn even goed, zo kan de mediaplayer DNS queries doen naar unieke hostnames die soms uw echte locatie verraden (DNS gaat niet altijd door de tunnel); hetzelfde kan men proberen met IPv6
- daarnaast kan men ook werken obv machine learning en signatures van het verkeer, met grote datasets van VPN traffic

Wat je eens zou kunnen doen is je internet fingerprint nemen wanneer je thuis bent, en dan ook nog eens wanneer je op VPN zit, en checken voor verschillen

Is dat de reden waarom, zoals ik ergens las, bv. geen Linux, Firefox e.d. toe laat om DRM content te bekijken?

Nee, is omdat die geen Fairplay of Widevine ondersteunen.

We hebben het niet getest maar zou het faken van de user-agent deze block kunnen vermijden?

Zal het waarschijnlijk enkel maar erger maken.

Als je een mobiel toestel gebruikt met de VTMGo App kan het misschien gebeuren dat ze de locatie weten van het toestel (GPS, zendmasten, ...) en op die manier weten dat je vanuit het buitenland kijkt?

Als je locatiepermissie geeft gaan ze idd je echte locatie weten, ongeacht wat de VPN zegt.

[on4bam]

Het ging om een MacBook met Chrome (omdat Safari niet werkt voor VTM), locatie wordt nooit gedeeld.

[CCatalyst]

Het ging om een MacBook met Chrome (omdat Safari niet werkt voor VTM), locatie wordt nooit gedeeld.

Ja, maar ik zal uw vraag wat dan feitelijk de oorzaak was helaas niet kunnen beantwoorden. Ik zou uw pakketten moeten analyseren daarvoor. Hierboven heb ik enkele van de vaker voorkomende redenen opgesomd (DNS leak, IPv6 leak), maar het is ook niet alles.

Ik kan wel zeggen dat ik bv Hulu kan bekijken in de VS, die ook enorm hard aan VPN detectie doen, obv een goed geconfigureerde tunnel die niets lekt van echte locatie, en een residentieel IP adres in de VS. Die mechanismes zijn dus zeker en vast nog steeds om de tuin te leiden.

[edwin.d]

In het buitenland, aan de onderkant van de wereld, kijk ik meestal via de TVV app zonder VPN.
Nog geen problemen tegen gekomen.

Kunnen ze ook niet het IP adres opvragen van het toestel waarop de speler staat.
Als die antwoord met een buitenlands IP adres weten ze het ook.

Mvg

[CCatalyst]

Een WebRTC leak (STUN) is nog zo ene waar je voor moet opletten.

https://browserleaks.com/webrtc

Kunnen ze ook niet het IP adres opvragen van het toestel waarop de speler staat.
Als die antwoord met een buitenlands IP adres weten ze het ook.

Niet echt, bij IPv4 >99% kans dat het feitelijk IP van het toestel een privaat IP is, en dan qua extern IP kent de browser ook alleen maar het adres waar de VPN naar toe leidt (mits tunnel goed geconfigureerd is).

[dupondje]

Kunnen ze ook niet het IP adres opvragen van het toestel waarop de speler staat.
Als die antwoord met een buitenlands IP adres weten ze het ook.

99% van de gevallen zal dat gewoon een intern IP zijn natuurlijk.

Veel kans dat het gewoon een DNS leak is inderdaad. En zo achterhalen ze dat je VPN gebruikt.

[on4bam]

Voorlopig is het niet meer aan de orde... 't is wachten op de volgende trip en, of er dan iets is dat gekeken wordt op VTM en of er tijd is/zal zijn. Meestal is tijd sowieso beperkt tijdens vakanties, behalve bij korte tripjes wanneer het korte dagen zijn.
Laatste 3 nachten was het trouwens te slechte wifi (max 2.7Mbit maar meestal minder) zodat VRT in horten en stoten van 1sec ging. Net genoeg om te surfen, mailen en radiostream) Maar dat is een andere discussie.

[CCatalyst]

Neem iig eens uw internet fingerprint van https://www.amiunique.org/fingerprint en bewaar de resultaten. Doe ze dan nog eens wanneer je in het buitenland zit met VPN en vergelijk. Het zal misschien al een indicatie geven van de oorzaak.

Deze fingerprint doet (beperkt weliswaar) ook een meting van verbindingsparameters, wat een VPN detectie algoritme ook zou doen maar dan meer uitgebreid. Zo zijn de gegevens die ik bij 46 - Connection zie (als enige) volledig veranderd nadat ik een VPN activeer en een nieuwe fingerprint neem, ook al verraadt deze VPN zichzelf niet.

De andere fingerprint tool van EFF meet dit niet, dus is waardeloos in dit geval.

Noot: deze fingerprint zal geen leaks vaststellen a la DNS, IPv6 of WebRTC, daarvoor zijn er andere tools.

[DiffieHM]

Wordt er ook niet gewoon een check gedaan op source IP? Ranges van de grote VPN aanbieders zijn in principe toch gekend?

[dupondje]

Wordt er ook niet gewoon een check gedaan op source IP? Ranges van de grote VPN aanbieders zijn in principe toch gekend?

Waarschijnlijk. Maar hier is het een VPN naar huis. Dus naar buiten toe heb je gewoon je thuis IP.

[ITnetadmin]

Normaal gezien zou je aan een IP packet toch niet mogen zien dat die door een VPN is gegaan?
Als je zelf een site-to-site-VPN zou opzetten tussen twee netwerken (bv je netwerk thuis en een portable routertje), zou een pakketje dat daarna je thuisnetwerk verlaat niks meer mogen verraden van het feit dat het door een VPN is gegaan.

Ben je zeker dat *alle* traffic door de VPN tunnel wordt gestuurd, en niet alleen de traffic die bestemd is voor je thuisnetwerk (een split systeem)?
Zit je op een app of programma dat mss ook aan GPS gegevens kan, en dus mss rapporteert dat hij zich niet bevindt waar je beweert te zijn?
Ik denk eerder ook aan een leak ergens.

[CCatalyst]

Vraag me idd nog altijd af wat @Sasuke bedoelt met dat het in de headers "altijd" zichtbaar is.

Tussen de twee VPN endpoints is dat natuurlijk wel zo - ook al zal dat verkeer >90% van de tijd wel versleuteld zijn - maar dat is niet wat pakweg VTM ziet. VTM ziet pas verkeer dat voorbij de VPN server gaat en geforward wordt in hun richting, en elke normale VPN server stript dan toch netjes het "bewijs" van de VPN.

[Sasuke]

@CCatalyst , ik wou hier nu niet over discussieren omdat het je puur om je gelijk te doen is (zoals altijd), maar mijn reactie was enkel maar om, in lekentermen, te duiden dat je het gebruik van een VPN altijd wel kan detecteren (of assumptie maken dat ...) op basis van IP header info. In het IP pakket zitten genoeg aanduidingen om te weten dat de originele connectie niet van het gedecteerde source IP komt. Er zijn in dit topic al genoeg voorbeelden gegeven hoe men dit kan vinden. Mijn eerdere reactie ivm. de VPN detectie was misschien wat kort door de bocht, maar deed an-sich geen afbreuk aan de originele vraag.

Als hij de detectie wil omzeilen zal er gebruik moeten gemaakt worden van extra zaken bovenop de VPN e.g. ook de DNS forwarden door de tunnel of een proxy of ...

[on4bam]

Ik zal moeten navragen hoe de DNS settings zijn op de MacBook. Bij mij staat de DNS in elk geval ingesteld om de settings van de Fritz!box te gebruiken en niet van de provider waar ik op dat ogenblik mee verbonden was.

[yaris]

Ik volg dit topic met veel interesse. Ik ging er altijd vanuit dat als je connecteert met een toestel of router bij je thuis via vpn dat je dan via nat van je router naar buiten gaat en ze niet kunnen zien dat je initieele connectie via vpn verloopt.

[devilkin]

DNS leakage, webrtc leakage, ipv6 adres leakage, browser fingerprinting (iemand die voor/na met dezelfde fingerprint plots van een compleet ander IP komt), ...

[Sinna]

Ik zal moeten navragen hoe de DNS settings zijn op de MacBook. Bij mij staat de DNS in elk geval ingesteld om de settings van de Fritz!box te gebruiken en niet van de provider waar ik op dat ogenblik mee verbonden was.

Dan kan je maar hopen dat er geen vastgecodeerde DNS-IP-adressen gebruikt worden zoals in een Google Chromecast.
De enige manier om dat te vermijden is alle uitgaande DNS-verkeer af te vangen en enkel de DNS-server op het netwerk (een Pi-Hole, AdGuard Home oid.) toegang te geven. Dit ondervangt uiteraard DoH en DoT niet, maar 't is toch een aanzet.
Ik heb met succes die blokkade kunnen opzetten met een... Fritz!Box maar weet niet meer vanbuiten hoe.

[CCatalyst]

@CCatalyst , ik wou hier nu niet over discussieren omdat het je puur om je gelijk te doen is (zoals altijd)

Het is niet "discussieren" of "gelijk hebben," het is geen politieke discussie. Ik zit beroepshalve in IT, en het laatste dat je van mij gaat horen is dat ik alles zou weten of altijd gelijk zou hebben; ik leer elke dag nog veel bij, ik merk elke dag hoeveel ik nog niet weet, en ik ben even technisch nieuwsgierig als on4bam. Ik gebruik zelf immers ook VPN, en ik denk dat ik dat goed verberg gelet dat ik nergens geblokkeerd wordt, maar ik ben nooit 100% zeker, want feedback krijg ik natuurlijk niet. Als ik dan iets lees dat ik niet wist, van iemand die er toch wel wat van kent, dan wil ik best meer weten en leren, dat is toch ook de meerwaarde van een forum...

Met je verduidelijking snap ik nu wel beter wat je bedoelt. Het is volgens mij wel mogelijk om, mits grondige en gedegen aanpak en lekken te vermijden, alle letterlijke hints in de headers weg te werken. Maar het is inderdaad altijd ook mogelijk om, zoals je zegt, assumpties te maken. Natuurlijk is dat wel niet zo eenvoudig als een header die het letterlijk weggeeft, de lagere MTU kan bv door een VPN zijn, maar kan evengoed door een legitieme mobiele verbinding veroorzaakt worden. Je moet dan verschillende gegevens combineren om een beslissing te kunnen maken. (Maar ik beweer dus niet (en nooit) dat ik gelijk heb - je correcties zijn welkom, dan leer ik ook weer bij )

Dan kan je maar hopen dat er geen vastgecodeerde DNS-IP-adressen gebruikt worden zoals in een Google Chromecast.
De enige manier om dat te vermijden is alle uitgaande DNS-verkeer af te vangen en enkel de DNS-server op het netwerk (een Pi-Hole, AdGuard Home oid.) toegang te geven.

Klopt, zeg maar zelfs dat je alle uitgaande verkeer, zonder uitzondering (behalve dan lokale private adressen) moet opvangen voor de tunnel. Anders riskeer je altijd lekken.

Ik weet niet welke exacte VPN technologie on4bam gebruikt, zelf doe ik dit met IKEv2/IPSec waar dit vrij eenvoudig kan met traffic selectors.

[on4bam]

De MacBook gebruikt de ingebouwde VPN van de Fritz!box (IPSec).
Zelf ga ik via mijn Synology met openvpn maar ik heb nog nooit een blokkering gehad op locatie (ik heb geen VTM/Vier gekeken).

[CCatalyst]

Gebruik je dan de ingebouwde VPN functionaliteit van macOS om te verbinden? Het zou me niet verbazen als die lekt, zoals de implementatie in iOS.

Op clientniveau gebruik ik AnyConnect en FortiClient, maar daar zijn ook lekken in ontdekt door Mathy Vanhoef.

Op reis gebruik ik een eigen router, de GL-X750 v2. Klein apparaatje, heeft twee WiFi interfaces, de ene verbindt met het netwerk van het hotel, de tweede creëert mijn eigen privaat netwerk. Er zit bovendien ook nog een cellular modem in (met externe antennes) in het geval het hotel WiFi op niets trekt. Op die router - die vanuit de fabriek OpenWRT/Linux draait, wel met eigen grafisch laagje erop - draai ik dan StrongSwan dewelke alles over IKEv2/IPsec stuurt obv traffic selectors. Voor zover ik weet geen lekken en niet zichtbaar in headers, heb iig nog niets gemerkt dat daarop zou wijzen.

[on4bam]

't is de Macbook van de zoon, waarschijnlijk ingebouwde functionaliteit. Ik vraag het wel eens na.

[ITnetadmin]

Voor alle duidelijkheid: ik wil idd ook niet discussieren of je gelijk hebt of niet.
Het is een technisch issue, geen politiek, en eentje waarbij je op internet heel veel onzin over kan vinden.
Dus ik wil bijleren, als er dus een of andere flag in een IP packet blijft steken van een VPN tunnel, waarvan ik niks wist, dan wil ik dat echt wel weten, want die tech blijft evolueren en je kan niet alles zelf in een lab uit blijven testen.