Android VPN oplossing voor thuis netwerk

[marcel2104]

Ik zou mijn thuis netwerk via VPN bereikbaar willen hebben voor Android telefoons. Er zijn verschillende VPN oplossingen, ik heb momenteel een Draytek router met VPN het werkt, maar voor een mobiel is het niet echt
gebruiks vriendelijk. Ik hoop dat er wat tweakers zijn met ervaring tips op dit gebied. Een aantal punten waar ik aan denk:

• Wat voor VPN: ISEC, OpenVPN .... voor/nadelen
• Authenticatie: bij voorkeur een vorm van 2 factor authenticatie, maar wel makkelijk
• Eenvoudig in het gebruik: telefoon aan -> toegang tot thuis netwerk
• Geen aanslag op data verbruik en batterij verbruik, dus alleen data verkeer wanneer expliciet gevraagd
• Directe ondersteuning door router (voorkeur gaat uit naar een Draytek)

Tips, suggesties welkom.

[rens-br]

@marcel2104 ik kan momenteel aan je openingspost niet helemaal zien wat je zelf al gevonden, geprobeerd en gedaan hebt. Zou je dat willen voegen?

[Freee!!]

Wireguard (op een RPi, kun je meteen ook Pi-Hole draaien).

[Xenir]

Freee!! schreef op maandag 13 september 2021 @ 07:42:
Wireguard (op een RPi, kun je meteen ook Pi-Hole draaien).

Dit. Evt. Tasker zodat wanneer je je thuisnet verlaat, deze automatisch de Wireguard tunnel opzet.

[marcel2104]

Op dit moment gebruik ik de Draytek smartVPN app in combinatie met een Drayek 2925 router. Ik overweeg ook een nieuwe router, daarom wilde ik graag wat ervaringen van anderen horen. Dat maakt het orienteren iets makkelijker.

[bloobje]

wireguard en enkel je interne netwerk verkeerover de vpn laten lopen. dan gaat al de rest nog steeds via je gewone "internet" van je gsm.

Zo doe ik het en werkt perfect. Kan alle applicaties op mijn intern netwerk eender waar bereiken en al de rest gaat niet over VPN.

[ Voor 6% gewijzigd door bloobje op 14-09-2021 02:39 ]

[Faifz]

OpenVPN Access Server appliance op een hypervisor en dit in combinatie met Duo's MFA. Dit zijn wel push notificaties dat je moet goedkeuren - wat natuurlijk veel prettiger is dan die passcodes in te typen. Duo is gratis tot 10 users (met verschillende aliases per users).

https://duo.com/docs/openvpn-as

Dit vereist wel een server of een computer (met een hypervisor) die de appliance runt. Ik zou niet voor WireGuard gaan. Het klopt niet dat het veiliger is want de authenticatie methodes die je hebt bestaan bijna niet. En in de enterprise wereld, merken zoals Cisco/Fortinet, PAN etc. gaan nooit WireGuard implementeren omdat er geen geldige reden voor is.

[Thralas]

Faifz schreef op dinsdag 14 september 2021 @ 06:59:
Ik zou niet voor WireGuard gaan. Het klopt niet dat het veiliger is want de authenticatie methodes die je hebt bestaan bijna niet.

Wat bedoel je hier precies? Ik snap die zin niet.

Juist het gebrek aan allerlei (onveilige) keuzemogelijkheden maakt Wireguard 'veiliger' dan de alternatieven.

En in de enterprise wereld, merken zoals Cisco/Fortinet, PAN etc. gaan nooit WireGuard implementeren omdat er geen geldige reden voor is.

Dat is natuurlijk geen argument. IPsec is daar de gouden standaard. Werkt uitstekend als je twee apparaten dicht op het internet hebt, maar allesbehalve prima als je met apparaten achter (onvoorspelbare) NATs zit. Daarnaast blijft het een draak om te configureren.

Hoewel ik het Cisco nog niet zie doen, gaat een vendor als Fortinet of iedere andere vendor met appliances die Linux draaien het op termijn echt wel toevoegen. Ze krijgen de implementatie namelijk min-of-meer gratis bij een recente Linux-kernel.

marcel2104 schreef op zondag 12 september 2021 @ 19:09:
• Wat voor VPN: ISEC, OpenVPN .... voor/nadelen

Net als de 3 hierboven zeg ik: Wireguard.

IPsec is onnodig complex en heeft afhankelijkheden die in de praktijk niet altijd even lekker werken als je een onvoorspelbare interneteverbinding hebt.

OpenVPN werkt opzich prima, maar eet je batterij op om de verbinding levend te houden, of zal de verbinding telkens opnieuw moeten opbouwen. Enig voordeel: het werkt ook over 443/tcp.

Wireguard is het (technisch) simpelste van allemaal en heeft die nadelen niet.

• Authenticatie: bij voorkeur een vorm van 2 factor authenticatie, maar wel makkelijk

Deze komt vaker terug, en is interessant genoeg om er even uit te pikken.

Stelling: een VPN op een telefoon heeft impliciet 2FA als je een passcode of fingerprint op je lockscreen hebt.

Alternatief: een deugdelijke VPN gebruikt keys en heeft geen wachtwoorden die men kan raden. Om de key (eventueel) te kunnen inzien moet iemand dus toegang hebben tot je telefoon. Als iemand bij die keys kan, kan hij ook bij al je Whatsappjes, foto's en emails. Wat staat er op je thuisnetwerk dat zo interessant is?

[Faifz]

Thralas schreef op dinsdag 14 september 2021 @ 09:02:
[...]

Wat bedoel je hier precies? Ik snap die zin niet.

Juist het gebrek aan allerlei (onveilige) keuzemogelijkheden maakt Wireguard 'veiliger' dan de alternatieven.

De huidige implementatie van WireGuard voldoet niet aan een zero-trust security model.

https://www.infradata.com...-zero-trust-architecture/

Ja je hebt een kleinere bereik aan security vulnerabilities omdat de code aanzienlijker kleiner is dan OpenVPN, maar dit is niet eens relevant en je baseert uw security niet rondom dat idee.

Met GlobalProtect heb ik de mogelijkheid om met HIP profiles te werken. Om een voorbeeld te geven; als de Windows Firewall op de client zou uitstaan - wordt de connectie geweigerd. Je kan zelfs nagaan of de systemen wel up-to-date zijn en de connectie weigeren op basis daarvan.

Dat is natuurlijk geen argument. IPsec is daar de gouden standaard. Werkt uitstekend als je twee apparaten dicht op het internet hebt, maar allesbehalve prima als je met apparaten achter (onvoorspelbare) NATs zit. Daarnaast blijft het een draak om te configureren.

Dit is natuurlijk een mooi voorbeeld van 'geen argument'. Je geeft geen reden waarom IPSEC problematisch is achter NAT. Wat moet onvoorspelbare NAT voorstellen? Of je nu OpenVPN, WG of IPSEC gebruikt als protocol - je zit altijd achter NAT.

IPSEC is enkel alleen maar de standaard voor site-to-site tunnels. SSL based VPN is zowat de keuze voor remote access VPN omdat elk systeem een public key pair (TLS/SSL) al heeft.

Hoewel ik het Cisco nog niet zie doen, gaat een vendor als Fortinet of iedere andere vendor met appliances die Linux draaien het op termijn echt wel toevoegen. Ze krijgen de implementatie namelijk min-of-meer gratis bij een recente Linux-kernel.

PAN en Fortinet hebben hun eigen implementatie van SSL VPN waar ze miljoenen in hebben geïnvesteerd en ze hebben hun eigen cloud-based solutions zoals Prisma Access dat integreert met PANOS. Of het nu in de linux kernel zit of niet, ze moeten het verder implementeren in hun platform. Ze gaan het nooit implementeren tenzij er een geldige reden voor is.

SDWAN begint wel hard op te komen in de enterprise wereld en het gebruikt IPSEC als protocol. Hier ga je nooit WireGuard in terug vinden omdat het gewoon niet klaar is en veel te veel features mist.
.

Wireguard is het (technisch) simpelste van allemaal en heeft die nadelen niet.

Heb je dan een web-portal dat je een client laat downloaden die automatisch de config files voor je installeert? Nee. Als je het hebt over gebruiksgemak, schiet WG echt wel te kort. De OpenVPN appliance heeft dit dus wel en je kan alle VPN settings via de web-interface veranderen. MFA implementeren gaat ook hoor.

De protocol dat WG gebruikt is simpeler, maar dit is niet van belang voor de normale users. Zij willen gewoon een client downloaden met een vooraf geïnstalleerde config. Een tijdje geleden had ik eens WG geprobeerd en het opzetten ging redelijk snel als je wist wat je moest doen met de private/public key. De config file was niet zo heel ingewikkeld om bv split-tunneling te doen. Maar ik zie geen normale user dit doen hoor. Het is gewoon niet gangbaar, tenzij je zelf iets implementeert zoals user-based authentication.

Dit artikel geeft je meerdere reden waarom je WG niet zou moeten gebruiken: https://blog.ipfire.org/post/why-not-wireguard

[Thralas]

Faifz schreef op dinsdag 14 september 2021 @ 17:34:
Ja je hebt een kleinere bereik aan security vulnerabilities omdat de code aanzienlijker kleiner is dan OpenVPN, maar dit is niet eens relevant en je baseert uw security niet rondom dat idee.

Natuurlijk is dat wel relevant. Je tunnel moet veilig zijn, of dat nu IPsec, Wireguard of OpenVPN is.

Bij IPsec en OpenVPN kan de gebruiker keuzes maken die het onveilig maken of uiteindelijk (theoretisch) minder veilig. Wireguard geeft geen keuze en biedt maar een optie: veilig.

Met GlobalProtect heb ik de mogelijkheid om met HIP profiles te werken.

Dat zero trust verhaal en allerlei checks die je daartoe implementeert zijn enorm relevant als je een groot enterprise netwerk beheert, maar dat staat helemaal los van of het nu IPsec, Wireguard of een proprietary SSLVPN als tunnel gebruikt en is bovendien irrelevant voor TS.

Dat jij er nu met enkel Wireguard niet bent voor je enterprise deployment snappen we hier ook wel.

Dit is natuurlijk een mooi voorbeeld van 'geen argument'. Je geeft geen reden waarom IPSEC problematisch is achter NAT. Wat moet onvoorspelbare NAT voorstellen? Of je nu OpenVPN, WG of IPSEC gebruikt als protocol - je zit altijd achter NAT.

Geen uitleg geven maakt het niet 'geen argument'.

IPsec wordt gedropt door veel NAT-implementaties omdat ze het niet ondersteunen voor connection tracking. Daar is natuurlijk IPsec NAT-T voor bedacht, maar dat is een beetje bolted on ipv. de basis van het protocol.

OpenVPN en Wireguard hebben geen bijzondere traversal nodig maar werken 'gewoon' over een enkele poort. Pluspuntje voor OpenVPN omdat dat zelfs over tcp werkt - in sommige gevallen kan het handig zijn om dat achter de hand te hebben.

Heb je dan een web-portal dat je een client laat downloaden die automatisch de config files voor je installeert? Nee. Als je het hebt over gebruiksgemak, schiet WG echt wel te kort.

Wireguard heeft minder opties dan OpenVPN of IPsec. Namelijk geen. Dat is technisch simpeler - niet voor niets zette ik dat tussen haakjes.

Qua gebruiksgemak: als je Wireguard instellen lastig vindt kun je Tailscale overwegen. Dat is nog simpeler dan OpenVPN AS - het enige nadeel kan zijn dat je het niet helemaal zelf in beheer hebt.

[Faifz]

Thralas schreef op dinsdag 14 september 2021 @ 20:58:

Natuurlijk is dat wel relevant. Je tunnel moet veilig zijn, of dat nu IPsec, Wireguard of OpenVPN is.

Bij IPsec en OpenVPN kan de gebruiker keuzes maken die het onveilig maken of uiteindelijk (theoretisch) minder veilig. Wireguard geeft geen keuze en biedt maar een optie: veilig.

Dat ligt eerder aan de vendor zelf dat ze geen outdated cipher suites als mogelijkheid moeten geven. Heeft niks te maken met de protocol zelf.

Dat zero trust verhaal en allerlei checks die je daartoe implementeert zijn enorm relevant als je een groot enterprise netwerk beheert, maar dat staat helemaal los van of het nu IPsec, Wireguard of een proprietary SSLVPN als tunnel gebruikt en is bovendien irrelevant voor TS.

Dat jij er nu met enkel Wireguard niet bent voor je enterprise deployment snappen we hier ook wel.

Waarom zou zero trust losstaan van of je nu IPSEC, SSL of WG gebruikt? Het gaat erom dat je je identiteit kunt verifiëren en WG heeft niet eens ondersteuning voor user/pass authenticatie. Hebben we het gehad over MFA providers die geen ondersteuning bieden voor WG? Identity providers zoals Okta/Duo bieden nog altijd geen ondersteuning voor WG en dit komt meerendeels door WG zelf.

Trouwens, je hebt nog altijd geen mogelijkheid gegeven of je nu MFA kunt toevoegen aan WG - dit is wat de TS vroeg.

IPsec wordt gedropt door veel NAT-implementaties omdat ze het niet ondersteunen voor connection tracking. Daar is natuurlijk IPsec NAT-T voor bedacht, maar dat is een beetje bolted on ipv. de basis van het protocol.

NAT-T heb je enkel alleen maar nodig als je Router > Router doet en IPSEC achter de 2de router hangt. Dus bv dubbel-NAT. Dit is niet echt iets dat je ooit nodig gaat hebben voor in een thuisnetwerk. Als je Router > IPSEC gateway in een Linux VM ofzo doet - dan heb je geen NAT-T nodig.

OpenVPN en Wireguard hebben geen bijzondere traversal nodig maar werken 'gewoon' over een enkele poort. Pluspuntje voor OpenVPN omdat dat zelfs over tcp werkt - in sommige gevallen kan het handig zijn om dat achter de hand te hebben.

IPSEC gebruikt 500/UDP OF het gebruikt 4500/UDP als je NAT-T gebruikt. Is ook maar een enkele poort zoals SSLVPN of WG.

"IPSec VPN uses the IKE protocol to negotiate security parameters. The default UDP port is set to 500. If NAT is detected in the gateway, the port is set to UDP 4500."

https://docs.vmware.com/e...1E-84B5-DB507CC010AC.html

Geen uitleg geven maakt het niet 'geen argument'.

Je begreep NAT-Traversal helemaal niet. Het is niet omdat je achter NAT-T zit dat je NAT perse nodig hebt. Je zit altijd achter NAT. Altijd. Je wist ook niet dat IPSEC ook maar een enkele poort gebruikt.

Dit zijn mijn logs voor een IPSEC session en je ziet enkel alleen maar UDP/500.

Wireguard heeft minder opties dan OpenVPN of IPsec. Namelijk geen. Dat is technisch simpeler - niet voor niets zette ik dat tussen haakjes.

OpenVPN is stukken moeilijker dan WG als je van een linux host een VPN gateway wil maken, geef ik wel toe.

Qua gebruiksgemak: als je Wireguard instellen lastig vindt kun je Tailscale overwegen. Dat is nog simpeler dan OpenVPN AS - het enige nadeel kan zijn dat je het niet helemaal zelf in beheer hebt.

Zoals je ziet bieden zij WG met MFA aan, maar het blijft nog altijd de taak van de vendor zelf om MFA te implementeren. Nogmaals, WG is geen compleet product vergeleken met OpenVPN als je MFA wil. En wanneer wij naar de enterprise wereld toegaan, wordt het alleen maar duidelijker.

Op mobiel is het wel gemakkelijker om met een OpenVPN server te verbinden dan een WG server. Want je hebt waarschijnlijk de key pair nodig op je mobiel. Het enige dat ik moet doen om met mijn OpenVPN is het IP adres ingeven + het goedkeuren via Duo (MFA).

Weet niet of de TS een hypervisor heeft of niet, maar als hij voor een router gaat - dan ga je het moeilijk hebben om een router te vinden met WG. Meestal is het toch IPSEC of OpenVPN en zo moeilijk is dit niet als ik het zo zie op mijn Synology router bv. Hangt natuurlijk af van de vendor, zoals altijd.

[Thralas]

Ik had hier een heel epos getikt waarbij ik het puntsgewijs afging, maar heb het geshiftdelete omdat het allemaal wel heel erg offtopic gaat en het niet een bijzonder productieve discussie is.

IPSEC gebruikt 500/UDP OF het gebruikt 4500/UDP als je NAT-T gebruikt. Is ook maar een enkele poort zoals SSLVPN of WG.

Jammer dat je hierna tot een persoonlijke aanval vervalt, temeer omdat het niet klopt wat je zegt. NAT-T gebruikt 4500/udp als aanvullende poort. IKE gaat over 500/udp, als daarbij NAT wordt gedecteerd schakelt pas hij over naar 4500/udp. Ze worden dan dus beide gebruikt.

IBM legt het aardig uit:

quote: https://www.ibm.com/docs/...-nat-compatible-ipsec-udp

Typically, VPN partners perform IKE negotiations over UDP port 500. However, when IKE detects NAT during key negotiation, subsequent IKE packets are sent over source port 4500

Verder ga ik het hierbij laten - tenzij TS nog opduikt.

[Faifz]

Thralas schreef op woensdag 15 september 2021 @ 09:23:

Jammer dat je hierna tot een persoonlijke aanval vervalt, temeer omdat het niet klopt wat je zegt. NAT-T gebruikt 4500/udp als aanvullende poort. IKE gaat over 500/udp, als daarbij NAT wordt gedecteerd schakelt pas hij over naar 4500/udp. Ze worden dan dus beide gebruikt.

IBM legt het aardig uit:

Excuses, alvast. En het klopte niet volledig, nee.

IKE gaat altijd over 500/UDP en switched nooit naar 4500/UDP. Als je je eigen artikel leest, gaat het over ESP. ESP (Phase 2) gebruikt IP poort 50 en hier loopt al je data over en niet over de Phase 1 (IKE). NAT-T is een feature dat ofwel uitstaat, geforceerd wordt of op automatisch staat. Wanneer je NAT-T aanzet, is het ESP over UDP met 4500 als poort en NIET meer over IP 50. IP poorten kun je niet port forwarden ofzo, enkel alleen maar UDP/TCP poorten.

Je beweert dat IPSEC problematisch is met NAT, maar dat is niet zo. De IKE gateway zal op een externe interface hangen met een publiek adres - dus zoals ik je al eerder heb gezegd dat je hiervoor geen NAT-T nodig hebt.

Ik heb je een screenshot laten zien dat 4500/UDP niet gebruikt werd omdat NAT-T overbodig was. Dit is eigenlijk de lab: https://faatech.be/configuring-ipsec-vpn-with-nsx-t/

En je ziet hier dat de 4500/udp regel niet eens 1x werd gebruikt.

[amx]

Ik vind een mooie VPN voor personen die wel de veiligheid willen van Wireguard maar niet de moeite die het echt wel kan kosten hoe rechtlijnig de documentatie ook lijkt Tailscale.

Een voor individuele gebruikers gratis dienst van enkel ex-Alphabet ontwikkelaars die een connection manager hosten voor Wireguard inclusief app met simpele setup.