Backup buiten de deur met enorm verlies aan snelheid

Eén van de redenen om voor glasvezel te kiezen was dat het uploaden veel sneller zou gaan. Dit klopt als een bus, maar nu ik meer en meer -coronaproof- bij klanten op kantoor kom te zitten merk ik dat mijn OpenVPN vol-le-dig instort.

Vandaag bij een klant gewerkt waar 1Gb/s KPN glas ligt. Met mijn laptop aan een rj45 haal ik bij een speedtest -zonder vpn- gemakkelijk 800Mb/s dus de verbinding is ok.
Zodra ik mijn OpenVPN start en ik ga dan een speedtest doen, zit ik tussen de 12 en de 16 Mb/s. Als ik ga uploaden wordt het nog dramatischer; dan varieert de werkelijke snelheid tussen de 1 en de 2 Mb/s. Op deze manier heeft glas voor mij geen nut, want zelfs met 14k4 had ik dezelfde waarden :wink:

Ik heb OpenVPN op mijn Draytek 2927 draaien en maak verbinding via de officiële OpenVPN client versie 2.7; de nieuwste versie werkt niet op mijn beide laptops (Windows 10 en Windows 11).

Aan de default ovpn heb ik 1 ding veranderd; reneg-sec naar 0 omdat ik elk uur de verbinding een uur kwijt was.

mijn ovpn-file ziet er als volgt uit:

client
dev tun
proto udp
remote <knip> 443
auth sha1
cipher aes-256-cbc
resolv-retry infinite
nobind

redirect-gateway autolocal def1
auth-user-pass

persist-key
persist-tun

reneg-sec 0

Voor de backup ben ik even “gered”, want ik kan de 2 NASsen met elkaar laten verbinden ( die met 15-20 Mb/s data versturen naar elkaar), maar deze oplossing heeft niet mijn voorkeur (extra IP-range, extra openstellen om bij de webgui te komen, etc.)

Mijn Draytek 2927 zou 50 gelijktijdige VPN verbindingen moeten kunnen handelen… ik begin mij af te vragen hoe.

Bij een “collega” met een consumenten Asus router met OpenWRT en verder overeenkomstige instellingen (ook via tunnel naar internet) trok hij 300 Mb/s met OpenVPN bij dezelfde speedtest :exploding_head:
Wat doe ik verkeerd, of wat doet Draytek verkeerd?
Is er nog iets in de ovpn-file te tunen? Ik heb gekeken of ik de server side config kon vinden, maar geen idee hoe of waar…

Je hebt veel rekenkracht nodig om met OpenVPN goede snelheid te behalen. Ik vermoed dat de router het simpelweg niet trekt.

Andere protocollen al eens geprobeerd?

-toevoeging-

Ik zou IKEv2 eens proberen i.c.m. die DrayTek.

Ja, daarom draai ik ook WireGuard. Haal in een rijdende auto op 4G met een iPhone via de VPN-server thuis nog gewoon rustig 150 Mbit/s.

Die DrayTek heeft zo te zien ondersteuning voor IKEv2, dat is ook zeker het proberen waard.

De 2927 doet geen WireGuard. Kan zeker nog komen omdat WG juist ook op zwakkere broeder wel performt. Het ligt aan Draytek omdat te gaan ondersteunen.

IKEv2 zou al een verbetering zijn als je dat gebruikt.

Ja daarom de suggestie voor IKEv2. Ik denk ook dat dat een (waarschijnlijk stevige) verbetering oplevert.

Daar begin ik ook aan te twijfelen… maar deze is mij verkocht omdat ie 50 OpenVPN tegelijk zou moeten kunnen draaien. Als dat allemaal op 1 Mb/s is, dan snap ik dat dat wel lukt!

Ik ben even de boel weer aan het ombouwen, zodat ik kan zien of de cpu het druk heeft. In mijn herinnering haalt die amper de 25% in zeer uitzonderlijke situaties, maar ga dat even nakijken. Daarna zal ik gelijk een testje doen met IKEv2 eens proberen en kijken wat daar de prestaties van zijn.

WireGuard is inderdaad veelbelovend, maar voorlopig nog geen support door Synology begreep ik laatst, wel voor mijn laptop een optie als Draytek het gaat ondersteunen.

Klopt het aantal connecties zegt in dit geval niet veel. Ben benieuwd naar de resultaten.

Deel 1 van het antwoord: 1 verbinding met de maximale doorvoer van rondom de 2 Mb/s is de CPU van de Draytek 35% procent belast; niet echt dat ie staat te roken zeg maar…

Ga m nu ff ombouwen naar IKEv2

Je kan desnoods wireguard met een portforward naar een ander system op je netwerk doorzetten.
Het protocol is UDP op een poort naar keuze. Bij foute verkeer (van een andere bron wordt alles gewoon in de afvalbak gegooid).

Encryptie op CPU’s zonder hardware ondersteuning is een uitdaging. ipv. aes-256 zou je ook aes-192 of (desnoods aes-128.) kunnen gebruiken en dat is al een paar encryptie ronden minder.
Synology draait toch linux daar is al een tijdje (ruim 2 jaar) zowel een userland programma als kernel support voor.
Kijk eens op:
https://awesomeopensource.com/project/runfalk/synology-wireguard

Wireguard is heel veel vriendelijker voor alle hardware maar op telefoons scheelt het uren up-time voor de accu.

@Noci ja die ken ik, maar heb slechte ervaringen met programma’s installeren via de cli op Synology;
1 Update en het werkt niet meer en kan ik dagen niet werken omdat ik eerst dat probleem moet oplossen. Dat gebeurt mij geen 2e keer :wink:

Ik heb geen ervaring met IPsec / IKEv2 en ik kan op dit moment alleen bij mijn NAS op locatie. Daar kan ik niet veel aan instellen en wat ik ook probeer… hij wil geen verbinding maken.

…en nu kan ik geen verbinding meer maken met mijn NAS :grimacing:

Morgen maar even weer resetten en dan een nieuwe poging voor IKEv2

Dank zover!

iPSEC / IKEv2… zijn feitelijk 2 protocollen.
IPSEC is een transport service (met/zonder ipadressen door de tunnel). met encryptie transformaties. (= protocol 50=ESP, 51=AH)
IKEv2 is een sleutel onderhandelings protocol op UDP poort 500 en UDP poort 4500. (=protocol 17=UDP)

IKE kent 2 fasen:
1e fase; herkennen van de overkant, authenticatie en opzetten van de initiele encryptie sleutel.
2e fase; op basis van de fase1 sleutel regelmatig een nieuwe IPSEC sleutel uit onderhandelen. (en in de kernel omzetten).

Bij debuggen van verbindingen, check eerst alle parameters, vervolgens moet eerst Fase 1 op orde zijn, als die in orde is moet ook Fase 2 kloppend gemaakt worden. Het helpt als je logging van beide kanten te pakken kan krijgen en kan vergelijken.
Alle parameters aan beide kanten moeten matchen. Afhankelijk van de userinterface is dit meer of minder overzichtelijk.
Hoewel IKE KAN onderhandelen over encyrpties, hashes etc. is het verstandig om dat gewoon tot een keuze te beperken.
Belangrijk is dat beide kanten ook dezelfde Forward Secrecy aan hebben staan (DH2, DH5 etc…)

IPSEC als protocol zorgt voor een transportmedium dat voldoet aan alle IP eisen. Wireguard komt ermee in de buurt, OpenVPN over UDP daarna, vervolgens als slechtste opties Encrypted IP transports over TCP. (SSLVPN, OpenVPN over TCP). En dat komt door de retransmit die TCP al voor je doet bij packet loss, daardoor zal verkeer door te tunnel ook nog eens dubbel gaan, wat weer meer ellende veroorzaakt etc.

1 like

hmz Synology ondersteund geen IKEv2. :roll_eyes:
Ik ga maar eens een testje doen met een eigen vpn-server. Heb nog wel ergens een nuc met 16gb en een i5 8e gen. liggen.

Dan zou ik voor WireGuard gaan!

Ik heb zowel OpenVPN als WireGuard op mijn nuc geïnstalleerd gehad en dat had een nogal dramatisch effect! Ik heb de snelheid alleen op mijn telefoon (iPhone SE oud model) kunnen testen.
Met OpenVPN op de Draytek haal ik 3-4 Mb/s volgens de speedtest van Ookla.
Als ik verbinding had met WireGuard of OpenVPN op de NUC haalde ik zonder problemen 100-110 Mb/s! :astonished:

Test geslaagd zou je bijna denken, alleen ik loop tegen een aantal zaken aan, waarbij een “eenvoudige” vpn-server toch iets te beperkt is.

Vanuit de client gezien werkt de tunnel naar internet perfect. Snel vooral! Het thuis-netwerk kom je alleen op als je de ip-reeks (=vlan in mijn geval) pusht naar de client. Dat werkt, maar mijn firewall heeft er niks meer over te zeggen volgens mij en dat is niet de bedoeling.

Echter wil ik het ook andersom; dat het thuis-netwerk heeft van de vpn-clients, zoals de NASsen bijvoorbeeld. De NAS in het thuis-netwerk, moet de NAS op kantoor kunnen vinden om de data te back-uppen. Dat zou ook eventueel via een onderlinge vpn kunnen, maar dan profiteer ik niet van de snelheid van de vpn-server. Dat vraag om nog wat verder onderzoek… of zou ik dan toch naar pfsense moeten gaan kijken?

Er is ook IKEv1 de vorige versie, niet heel veel verschillend qua functionaliteit, IKEv2 is wat taaier en IKEv2 kan met x.509 certificaten overweg. (en dat kan het wat veiliger maken).

IKEv2 moet ook met IKEv1 overweg kunnen.

Ik weet niet of dat hier een probleem is maar ik heb net bij een andere klant gezien dat vrijwel alle pakketen van een WireGuard tunnel worden fragmenteert. Ik vermoed zo dat dat de performance niet ten goede komt.

Deze klant heb ik geadviseerd de MTU van zijn tunnel-interface wat te verkleinen.

Ik heb eens naar mijn config gekeken. Bij mij staat WireGuard MTU op 1420, PPPoE op 1500, interface op 1508. Zal eens controleren of ik ook last van fragmentatie heb.

Alstu!

Ik heb eens naar mijn config gekeken. Bij mij staat WireGuard MTU op 1420, PPPoE op 1500, interface op 1508. Zal eens controleren of ik ook last van fragmentatie heb.

@Eirikr Daar wordt het wel een stukje makkelijker van :slight_smile: dank!
Had onlangs al gezien dat je ook met 1 netwerkpoort (nuc) en een managed switch operationeel kunt zijn en laat ik toevallig nog een TL-SG105E hebben liggen.
Zal het nog wel even laten weten of het gelukt is!

Super! Ben benieuwd.