Waarom werkt WireGuard niet op sommige publieke WiFi?

[PhilipsFan]

Mijn vraag
Ik gebruik WireGuard om altijd verbinding te hebben vanaf mijn iPhone met mijn apparaten thuis. Camera's, servers, domotica. Dit werkt goed, maar op sommige publieke WiFi netwerken is geen verbinding mogelijk. De WiFi geeft aan dat er verbinding is (sterkte maximaal) en het VPN symbool the verschijnt, maar er wil geen data door. Als ik VPN uitzet, dat werkt het wel.

Relevante software en hardware die ik gebruik
iPhone met WireGuard app als client. Raspberry Pi met WireGuard als server. UniFi UDM als router. Alle software en apparaten zijn actuele versies.

Wat ik al gevonden of geprobeerd heb
Ik heb geprobeerd om de inkomende poort op de UDM te veranderen naar 443 of 80, maar dat maakte niks uit. Hoe kan een WiFi netwerk weten dat ik niet gewoon een website bezoek? En wat kan ik doen om hier omheen te werken?

[pagani]

Verander het protocol eens. Ze kunnen vrij simpel UDP blokkeren.

[Defragging]

je hebt poorten & je hebt protocollen, waarschijnlijk blokkeren ze VPN protocollen op hun WIFI

[Cave_Boy]

Defragging schreef op woensdag 26 juli 2023 @ 07:57:
je hebt poorten & je hebt protocollen, waarschijnlijk blokkeren ze VPN protocollen op hun WIFI

Hier heb ik ook wel eens aan gedacht echter ik dacht dat ze hooguit het soort kunnen blokken. In dit geval UDP of TCP (en dan nog het oude IPX). Echter TCP wordt door veel programma's gebruikt en UDP is voor de algemene programma's niet nodig. Dan kan ik wel begrijpen dat die geblokkeerd wordt.

Heb zelf een tijdje terug bij iemand Wireguard geïnstalleerd die alleen TCP als uitgang had.
Dit heeft wel effect op de max snelheid al kwamen we er ook achter toen degene een sneller router had voor de VPN dit ook direct in snelheid omhoog ging.

https://www.procustodibus...22/02/wireguard-over-tcp/

[mash_man02]

Publieke wifi gaat vaak uit van een specifieke set met poorten en moderne firewall's hebben tegenwoordig veel meer mogelijkheden om ook appliacies te herkennen en daar dus iets van te veinden.

Het tunnelen van verkeer met een onbekende bron of achtergrond is niet iets wat je wilt toestaan als daar geen exliciete noodzaak toe is.

Wiregard is een VPN / Tunnel protocol waarmee je dus veiligheidsmaatregelen zou kunnen omzijlen en dus in beleid vaak niet zomaar toegestaan wordt.

bedenk het maar eens andersom, zou jij iemand op je netwerk willen hebben die applicaties en verkeer en dus veiligheids risico's zou kunnen introdiceren waar jij geen vat op hebt ?

Gebruik je een certificaat ? Is dit een trusted of self signed certificaat ? Een moderne firewall kijkt ook hier naar en kan er iets van vinden. Bijvoorbeeld dat ongeldige certificatien niet toegestaan worden.

Wat ook vaak gebruikt wordt is domein reputation. Welke hostnaam roep je aan en is die bekend in een reputation database, zo ja in welke klasse is die dan ingedeeld en wat vind de beheerder dat daar mee moet gebeuren ?

Ik geeft zelf een waarschuwingspagina op het moment dat een gebruiker een site zonder reputatie bezoekt. DIt zijn namelijk pop up sites die vaak voor phishing geintroduceert worden.

[ Voor 42% gewijzigd door mash_man02 op 26-07-2023 08:14 ]

[Defragging]

Btw, als je Synology of QNAP NAS oplossing thuis hebt kan jou Camera's, servers, domotica, via deze benaderen afgeschermd via Portaal (afhankelijk wat je hebt als leverancier).

Ik heb zelf QNAP > QNAP portal gekoppeld met 2FA. Naar mijn ervaring veel efficenter omdat de aanvallen direct naar mijn router (DNAT) vermeden worden omdat alles via de QNAP portaal loopt.

Zodoende heb ik toegang tot mijn NAS die beetje als Super computer functioneert en alle componenten bereikbaar zijn. Oh ja deze is vanuit elke punt van de wereld voor mij benaderbaar (private). Zonder gedoe webbased pagina dus

[ Voor 32% gewijzigd door Defragging op 26-07-2023 08:33 ]

[Ben(V)]

Heel veel public wifi laat alleen de poorten 80 en 443 door, dat zal wel het probleem zijn.
Kun je niet poort 433 gebruiken voor die wireguard verbinding?

[ Voor 10% gewijzigd door Ben(V) op 26-07-2023 10:08 ]

[Hann1BaL]

Een ander probleem kan de interne IP range zijn waardoor de routing het heeft even niet meer weet.
Ik gebruik ook Wireguard en krijg problemen als ik op een netwerk zit waarbij in de interne IP range hetzelfde is als thuis (omdat ik te lui ben om alles thuis te hernummeren want veel werk.)

Dat zou ook een oorzaak kunnen zijn van het niet werken.
Ik adviseer sowieso om het op op poort 443 (en niet 433 @Ben(V) ) te configureren indien poorten geblokkeerd worden.

[Defragging]

Ben(V) schreef op woensdag 26 juli 2023 @ 09:17:
Heel veel public wifi laat alleen de poorten 80 en 433 door, dat zal wel het probleem zijn.
Kun je niet poort 433 gebruiken voor die wireguard verbinding?

Lees hierboven, Wanneer de WIFI Firewall geconfigureerd is met filters om jou VPN-specifieke pakketten te blokkeren, dan maakt het niet uit of je op poort 433 of 80 "cruised"

[Hann1BaL]

mash_man02 schreef op woensdag 26 juli 2023 @ 08:08:
Publieke wifi gaat vaak uit van een specifieke set met poorten en moderne firewall's hebben tegenwoordig veel meer mogelijkheden om ook appliacies te herkennen en daar dus iets van te veinden.

Het tunnelen van verkeer met een onbekende bron of achtergrond is niet iets wat je wilt toestaan als daar geen exliciete noodzaak toe is.

Wiregard is een VPN / Tunnel protocol waarmee je dus veiligheidsmaatregelen zou kunnen omzijlen en dus in beleid vaak niet zomaar toegestaan wordt.

bedenk het maar eens andersom, zou jij iemand op je netwerk willen hebben die applicaties en verkeer en dus veiligheids risico's zou kunnen introdiceren waar jij geen vat op hebt ?

Gebruik je een certificaat ? Is dit een trusted of self signed certificaat ? Een moderne firewall kijkt ook hier naar en kan er iets van vinden. Bijvoorbeeld dat ongeldige certificatien niet toegestaan worden.

Wat ook vaak gebruikt wordt is domein reputation. Welke hostnaam roep je aan en is die bekend in een reputation database, zo ja in welke klasse is die dan ingedeeld en wat vind de beheerder dat daar mee moet gebeuren ?

Ik geeft zelf een waarschuwingspagina op het moment dat een gebruiker een site zonder reputatie bezoekt. DIt zijn namelijk pop up sites die vaak voor phishing geintroduceert worden.

toon volledige bericht

Hoewel je goede punten maakt: Indien VPN gebruikt wordt, kun je stellen dat je eigenlijk weinig veiligheidsrisico’s introduceert op je netwerk, omdat het verkeer via een ander netwerk verloopt. Dus dat geen vat hebben is niet zo’n groot probleem tenzij je bijvoorbeeld de Chineze overheid bent natuurlijk Ik zie dat zelf niet als een probleem.

Volgens mij is het op de meeste netwerken nog simpel: Poortranges die geblokkeerd worden is de grootste oorzaak van het niet werken.

[Tazzios]

zie ook: Wireguard op Fritzbox werkt alleen op sommige netwerken

[Hann1BaL]

Defragging schreef op woensdag 26 juli 2023 @ 09:23:
[...]

Lees hierboven, Wanneer de WIFI Firewall geconfigureerd is met filters om jou VPN-specifieke pakketten te blokkeren, dan maakt het niet uit of je op poort 433 of 80 "cruised"

Klopt helemaal hoor, maar hij maakt wel een goed punt, want de meeste publieke Wi-Fis zijn niet zo “modern” dus los je nog steeds een hoop problemen op door wel poort 443 te gebruiken.

[Hann1BaL]

Tazzios schreef op woensdag 26 juli 2023 @ 09:26:
zie ook: Wireguard op Fritzbox werkt alleen op sommige netwerken

Ik heb ook WireGuard op mijn FB aangezet om te testen:
Ook ik heb dan netwerkproblemen.

Maar ik heb ook een Wireguard server draaien op hetzelfde netwerk en die draait wel op 443 en die werkt gewoon uitstekend. Dus 2x wireguard server, zelfde client (iPhone) en de FB 7590 werkt inderdaad slecht en de server werkt eigenlijk altijd.

[MarcoC]

Defragging schreef op woensdag 26 juli 2023 @ 09:23:
[...]

Lees hierboven, Wanneer de WIFI Firewall geconfigureerd is met filters om jou VPN-specifieke pakketten te blokkeren, dan maakt het niet uit of je op poort 433 of 80 "cruised"

De meeste firewalls zijn niet geconfigureerd om bepaalde protocollen wel of niet door te laten, dat gaat 9 van de 10x over poorten.

[biomass]

Maar wat doe je dan als je 443 en 80 open hebt staan voor Let's Encrypt updates? Dan kun je daar toch geen VPN server op draaien?

[Ben(V)]

Defragging schreef op woensdag 26 juli 2023 @ 09:23:
[...]

Lees hierboven, Wanneer de WIFI Firewall geconfigureerd is met filters om jou VPN-specifieke pakketten te blokkeren, dan maakt het niet uit of je op poort 433 of 80 "cruised"

Er is bijna geen enkele betaalbare firewall die het verschil tussen encrypted https verkeer en encrypted VPN verkeer kan maken.
Daar heb je bijzonder dure firewalls voor nodig die deep packet inspection kan doen en het is heel erg onwaarschijnlijk dat public wifi zo'n firewall heeft.
Dus probeer gewoon poort 443 en dan gaat het vast lukken.

[Defragging]

Ben(V) schreef op woensdag 26 juli 2023 @ 09:55:
[...]


Er is bijna geen enkele betaalbare firewall die het verschil tussen encrypted https verkeer en encrypted VPN verkeer kan maken.
Daar heb je bijzonder dure firewalls voor nodig die deep packet inspection kan doen en het is heel erg onwaarschijnlijk dat public wifi zo'n firewall heeft.
Dus probeer gewoon poort 433 en dan gaat het vast lukken.

Meh, een beetje moderne ER / firewall is het te doen, en hoeft niet heel duur te zijn Ubiquiti EdgeRouter X kan dat al en kost maar 59,29 incl. btw

[Ben(V)]

biomass schreef op woensdag 26 juli 2023 @ 09:30:
Maar wat doe je dan als je 443 en 80 open hebt staan voor Let's Encrypt updates? Dan kun je daar toch geen VPN server op draaien?

Volgens mij gebruikt letsencryp cerbot voor z'n update process en is er enkel een outbound port 443 nodig.
Dus dat zou geen probleem moeten zijn.

[Hann1BaL]

Ben(V) schreef op woensdag 26 juli 2023 @ 10:03:
[...]


Volgens mij gebruikt letsencryp cerbot voor z'n update process en is er enkel een outbound port 433 nodig.
Dus dat zou geen probleem moeten zijn.

443
443
443

Typ het eens 10 keer
Niet 433..

[Ben(V)]

Defragging schreef op woensdag 26 juli 2023 @ 10:01:
[...]

Meh, een beetje moderne ER / firewall is het te doen, en hoeft niet heel duur te zijn Ubiquiti EdgeRouter X kan dat al en kost maar 59,29 incl. btw

Theoretisch heeft dat ding DPI aan boord maar hij heeft zo weinig cpu en die software is zo krakkemikkig dat effectief het volkomen onbruikbaar is.

[eric.1]

Zijn er geen logs beschikbaar of komen er geen foutmeldingen tevoorschijn? Indien het VPN-symbooltje wel normaal wordt getoond zonder te morren dan lijkt het me niet een standaard poort-probleem eerlijk gezegd, dan verwacht ik eerder dat er helemaal niets tot stand komt.

[Ben(V)]

Hann1BaL schreef op woensdag 26 juli 2023 @ 10:05:
[...]


443
443
443

Typ het eens 10 keer
Niet 433..

Iets met spijkers en laag water.

[Hann1BaL]

Ben(V) schreef op woensdag 26 juli 2023 @ 10:07:
[...]


Iets met spijkers en laag water.

Joh, jammer dat je de humor er niet van kan inzien zeg Gemiste kans

[Hennie-M]

Al dit soort applicaties hebben een fingerprint, die een L7 firewall herkent en daar mee aan de gang kan gaan (Pass/Block/Monitor etc).

Dus een beetje Fortigate (500,-) kan dit verkeer filteren en blokkeren, ongeacht welke poort er gebruikt wordt.

[ThinkPad]

Ik draai al jaren m'n thuis VPN op poort 443 UDP en dat werkt eigenlijk 99% van de tijd. Zelden gehad dat ik er buitenshuis niet mee kon verbinden. Voorheen met OpenVPN en tegenwoordig Wireguard.

Poort 53 UDP (DNS) zou ook nog kunnen, maar dat valt wel meer op dan 443 als daar grote hoeveelheden data langs gaan.

[ Voor 41% gewijzigd door ThinkPad op 26-07-2023 11:37 ]

[Raven]

Hann1BaL schreef op woensdag 26 juli 2023 @ 09:23:
Een ander probleem kan de interne IP range zijn waardoor de routing het heeft even niet meer weet.
Ik gebruik ook Wireguard en krijg problemen als ik op een netwerk zit waarbij in de interne IP range hetzelfde is als thuis (omdat ik te lui ben om alles thuis te hernummeren want veel werk.)

Dat zou ook een oorzaak kunnen zijn van het niet werken.

Dan is de vraag, wat is de minst voorkomende lokale IP-range die je zou kunnen gebruiken? 172.16.*.*?

[mash_man02]

Hann1BaL schreef op woensdag 26 juli 2023 @ 09:26:
[...]


Hoewel je goede punten maakt: Indien VPN gebruikt wordt, kun je stellen dat je eigenlijk weinig veiligheidsrisico’s introduceert op je netwerk, omdat het verkeer via een ander netwerk verloopt. Dus dat geen vat hebben is niet zo’n groot probleem tenzij je bijvoorbeeld de Chineze overheid bent natuurlijk Ik zie dat zelf niet als een probleem.

Volgens mij is het op de meeste netwerken nog simpel: Poortranges die geblokkeerd worden is de grootste oorzaak van het niet werken.

Dat kunnen we met elkaar eens of oneens zijn feit is wel dat beleid in bepaalde organisties daar anders naar kijken dan jij en ik, ook gestaafd door de constateringen van de topicstarter en daar dan ook in dat kader gepaste maatregelen voor nemen ter voorkoming.

Mij intententie is niet om dat, of jouw visie op deze zaken ter discussie te stellen maar om uit te leggen waarom de door de topicstarter beschreven functionaliteit soms niet toegestaan wordt en ter dege op andere gronden dan het gebruikte protocol en poort nummer beoordeeld kan worden.

[PhilipsFan]

Ik denk niet dat de beheerder van een publieke WiFi zich druk met om beveiligingsproblemen op de clients. Vermoedelijk is het inderdaad dat UDP wordt geblokkeerd, want WireGuard gebruikt UDP. Ik zie echter geen eenvoudige mogelijkheid om dat te veranderen. Er bestaan wel manieren om UDP verkeer in http op te sluiten, maar dan heb je een volledige computer nodig op de client, ik heb alleen een iPhone.

Vroeger had ik ook nog een OpenVPN verbinding als fallback, maar die heb ik een tijdje geleden geschrapt omdat ik geen problemen heb ervaren met WireGuard en die laatste veel fijner is. Misschien toch maar ergens een OpenVPN servertje installeren als reserve, want dat gaat over TCP.

[MoiZie]

PhilipsFan schreef op woensdag 26 juli 2023 @ 21:29:
Ik denk niet dat de beheerder van een publieke WiFi zich druk met om beveiligingsproblemen op de clients. Vermoedelijk is het inderdaad dat UDP wordt geblokkeerd, want WireGuard gebruikt UDP. Ik zie echter geen eenvoudige mogelijkheid om dat te veranderen. Er bestaan wel manieren om UDP verkeer in http op te sluiten, maar dan heb je een volledige computer nodig op de client, ik heb alleen een iPhone.

Vroeger had ik ook nog een OpenVPN verbinding als fallback, maar die heb ik een tijdje geleden geschrapt omdat ik geen problemen heb ervaren met WireGuard en die laatste veel fijner is. Misschien toch maar ergens een OpenVPN servertje installeren als reserve, want dat gaat over TCP.

Precies. Openvpn lekker via tcp 443 met port sharing naar je web server op 443. Werkt altijd en overal en is niet te blokkeren. Snap de wireguard hype niet zo om deze reden.

[dion_b]

In plaats van lukraak gokken wat het probleem zou kunnen zijn en dan oplossingen voor die gegokte problemen verzinnen zou het verstandig zijn om daadwerkelijk te troubleshooten exact waar het fout gaat. Als we dat weten kunnen we gericht oplossingen aanreiken (of in ieder geval een sluitende verklaring geven)

@PhilipsFan begin eens heel basic: probeer van achter zo'n publiek hotspot met netcat (nc) te verbinden met je router WAN

Zie hier voor hoe:
https://www.quora.com/Can-we-Telnet-UDP-port

Als dat goed gaat, is er inderdaad waarschijnlijk sprake van een geavanceerde layer 7 firewall oplossing. Ik verwacht echter iets simpelers, zoals alleen TCP poorten 80 en 443 doorlaten. Dan kun je niet met nc verbinden.

Hoe te controleren? Voor TCP bestaat er de host portquiz.net. Die heeft alle TCP poorten open staan, dus je kunt daarmee bepalen wat geblokkeerd wordt tussen jouw device en die host. Onder Linux gebruik je nmap, onder Windows kun je bijvoorbeeld de Zenmap GUI voor nmap gebruiken, die standaard in de nmap download zit. Doe een scan van een aantal poorten naar portquiz.net (of als je heel veel geduld hebt: alle poorten) en kijk wat het geeft. Alles wat niet STATE open heeft, is geblokkeerd tussen jou en die host. Met uitzondering van de ISP best practice poorten (dingen als 135-139 en 445) zullen dat blokkades zijn van je hotspot.

Helaas ken ik niet een dergelijke host voor UDP, dus daar moet je zelf spelen met poorten wil je dat bepalen.

[ Voor 3% gewijzigd door dion_b op 26-07-2023 22:48 ]

[PhilipsFan]

dion_b schreef op woensdag 26 juli 2023 @ 22:47:
In plaats van lukraak gokken wat het probleem zou kunnen zijn en dan oplossingen voor die gegokte problemen verzinnen zou het verstandig zijn om daadwerkelijk te troubleshooten exact waar het fout gaat. Als we dat weten kunnen we gericht oplossingen aanreiken (of in ieder geval een sluitende verklaring geven)

@PhilipsFan begin eens heel basic: probeer van achter zo'n publiek hotspot met netcat (nc) te verbinden met je router WAN

Zie hier voor hoe:
https://www.quora.com/Can-we-Telnet-UDP-port

Als dat goed gaat, is er inderdaad waarschijnlijk sprake van een geavanceerde layer 7 firewall oplossing. Ik verwacht echter iets simpelers, zoals alleen TCP poorten 80 en 443 doorlaten. Dan kun je niet met nc verbinden.

Hoe te controleren? Voor TCP bestaat er de host portquiz.net. Die heeft alle TCP poorten open staan, dus je kunt daarmee bepalen wat geblokkeerd wordt tussen jouw device en die host. Onder Linux gebruik je nmap, onder Windows kun je bijvoorbeeld de Zenmap GUI voor nmap gebruiken, die standaard in de nmap download zit. Doe een scan van een aantal poorten naar portquiz.net (of als je heel veel geduld hebt: alle poorten) en kijk wat het geeft. Alles wat niet STATE open heeft, is geblokkeerd tussen jou en die host. Met uitzondering van de ISP best practice poorten (dingen als 135-139 en 445) zullen dat blokkades zijn van je hotspot.

Helaas ken ik niet een dergelijke host voor UDP, dus daar moet je zelf spelen met poorten wil je dat bepalen.

toon volledige bericht

Normaal zou ik dat inderdaad gaan doen, maar ik ben nu met vakantie en heb geen computer bij me, alleen een iPhone en iPad. Het is ook niet zo'n ramp, ik heb ook andere mogelijkheden, bijvoorbeeld verbinden via 5G. Maar ik vroeg me gewoon af hoe een aanbieder van WiFi specifiek de VPN kan blokkeren, vermoedelijk dus door UDP.

MoiZie schreef op woensdag 26 juli 2023 @ 21:58:
[...]

Precies. Openvpn lekker via tcp 443 met port sharing naar je web server op 443. Werkt altijd en overal en is niet te blokkeren. Snap de wireguard hype niet zo om deze reden.

Nou ja, als het werkt, is WireGuard veel handiger. De WireGuard app kan zelf bepalen wanneer hij moet verbinden, daardoor heb ik (normaal gesproken, als er geen overijverige WiFi tussen zit) altijd verbinding met de servers thuis en kan ik ook PiHole onderweg gebruiken. OpenVPN is veel meer gedoe, moet je eerst naar die app om de verbinding aan te zetten, en als je thuis bent weer uitzetten. Maar ik ga het toch inrichten als fallback optie.

[dion_b]

PhilipsFan schreef op donderdag 27 juli 2023 @ 06:11:
[...]

Normaal zou ik dat inderdaad gaan doen, maar ik ben nu met vakantie en heb geen computer bij me, alleen een iPhone en iPad. Het is ook niet zo'n ramp, ik heb ook andere mogelijkheden, bijvoorbeeld verbinden via 5G. Maar ik vroeg me gewoon af hoe een aanbieder van WiFi specifiek de VPN kan blokkeren, vermoedelijk dus door UDP.

Ik vermoed eerder dat het niet een blacklist van UDP is, maar een whitelist waarbij enkel TCP poorten 80 en 443 toegelaten worden. Maar goed, als er geen gereedschap is waarmee je eea kan testen - en iOS zit zodanig dichtgetimmerd dat je dit er niet mee kunt doen - houdt het bij vermoedens op.

[...]

Nou ja, als het werkt, is WireGuard veel handiger. De WireGuard app kan zelf bepalen wanneer hij moet verbinden, daardoor heb ik (normaal gesproken, als er geen overijverige WiFi tussen zit) altijd verbinding met de servers thuis en kan ik ook PiHole onderweg gebruiken. OpenVPN is veel meer gedoe, moet je eerst naar die app om de verbinding aan te zetten, en als je thuis bent weer uitzetten. Maar ik ga het toch inrichten als fallback optie.

Eens, op beide vlakken

[Raven]

MoiZie schreef op woensdag 26 juli 2023 @ 21:58:
[...]

Precies. Openvpn lekker via tcp 443 met port sharing naar je web server op 443. Werkt altijd en overal en is niet te blokkeren. Snap de wireguard hype niet zo om deze reden.

Ook achter de great firewall of China en netwerken waar DPI in wordt gebruikt? Google noemt obfuscation met bijv. Shadowsocks als oplossing daarvoor.