OpenVPN '#redirect-gateway def1' werkt niet met gecomprimeerde data-overdracht

[Babylonia]

Bij een connectie bij een kennis naar diens NAS via OpenVPN, maak ik gebruik van de functie om alleen connectie met de server te leggen, maar al het andere internetverkeer gewoon via mijn eigen vaste internet aansluiting naar buiten te laten plaatsvinden.

In het OpenVpn configuratiescherm plaast je dan een  #  voor de functie  redirect-gateway def1  (of je haalt de regel weg).

# If redirect-gateway is enabled, the client will redirect it's
# default network gateway through the VPN.
# It means the VPN connection will firstly connect to the VPN Server
# and then to the internet.
# (Please refer to the manual of OpenVPN for more information.)

redirect-gateway def1
#redirect-gateway def1


Heb tevens (t.b.v. gebruik door die kennis zelf) een VPN-profiel gegeven om wel al het internetverkeer via de thuis-aansluiting te laten verlopen. Met verschil in benaming kun je dan zelf kiezen welke soort verbinding je wilt gebruiken.

Opvallend genoeg kreeg ik dat bij mijn eigen VPN-server thuis, waar ik die keus ook wilde inzetten, en bij mijn ex NIET werkend ingesteld.
Typisch connectie van "alleen connectie met de VPN-server" de rest van het internetverkeer via de eigen aansluiting, bleek niet te werken.
Alleen het profiel met "alle verkeer" via de VPN-server was mogelijk. Wat ik ook controleerde aan de instellingen. Ik kreeg het niet gedaan.
Niet bij gebruik van de VPN-server op de Synology router, niet bij de VPN-server op mijn NAS, of die bij mijn ex.

Een groot raadsel !!

Totdat ik een klein maar belangrijk punt als verschil in de setup opmerkte.
Bij die eerste kennis waar dat wel gewoon werkt, gebruiken we geen compressie van de data-overdracht.

Bij alle andere profielen WEL.
Heb als test toen de profielen van mijn andere connecties daarop bijgesteld om ook geen compressie toe te passen.
Toen bleek bij alle andere VPN-servers het ineens WEL correct te werken.

- GEEN compressie toepassen bij de OpenVPN-server zelf.
- GEEN compressie toepassen bij de instellingen van het OpenVPN configuratiebestand.

comp-lzo
Juiste instelling:
#comp-lzo


Iets om in het achterhoofd te houden als je zelf daarmee aan de gang gaat !!

Het werkt als zodanig (of juist niet als je wel compressie gebruikt) bij:
- Gebruik van de VPN-server op de Synology router
- Gebruik van de VPN-server op de Synology NAS  ---->  DSM 5.0  ---->  DSM 6.1
- Met gebruik van VPN Client onder Windows 8 + 10,  en Android op tablet en smartphone.  (iOS niet geprobeerd).

Met nog een kleine extra opmerking aangaande de werking bij Android (tablet).
- Via een "normale" WiFi verbinding van een "vaste" internet-verbinding, (aansluiting internet thuis), werkt het als zodanig correct.
- Via verbinding van de tablet met mobiele WiFi hotspot van smartphone en dan G4, met profiel van "alleen server"
  heb je wel contact met de server, maar verder geen normaal internetverkeer via een webbrowser "via de mobiele telefoon".
  Alleen contact met de server (De NAS en evt. andere apparaten thuis).
  Het andere profiel om alles via de VPN-tunnel te laten lopen (inclusief web-browsing) werkt wel als zodanig correct.


Misschien dat er via verdergaande uitbreidingen met de instellingen meer is te bereiken, maar dat heb ik niet uitgeprobeerd.
(Misschien dat  @MMD  daar meer info over weet?).

[Briolet]

Ik heb iets vergelijkbaars meegemaakt maar dan met de firewall settings in de router.

In de router had ik staan om gefragmenteerde pakketten te blokkeren. (gefragmenteerde pakketten zijn normaal niet nodig en vormen een veiligheidsrisico). Voor PPTP en L2TP was dat geen probleem, maat OpenVPN maakte de data-pakketten van re-directed verkeer groter dan mijn MTU waarde, waardoor ze gefragmenteerd werden om te kunnen doorsturen. De firewall in de router blokkeerde dit verkeer dan. Gelukkig viel dit probleem snel op toen ik in het routerlog keek.

Het blokkeren van gefragmenteerde pakketten staat sindsdien uit in mijn router. Waarschijnlijk was dit ook op te lossen geweest door de MTU waarde van een OpenVPN verbinding lager in te stellen.

[Babylonia]

Oh, heeft het daar mee te maken (pakketgrootte)?
Nu heb ik net wel even gekeken of ik in de Open VPN-server de MTU kan wijzigen, maar zie daar geen opties staan.
Dus laat het maar zo.

Bij die kennis hadden we compressie standaard uit staan omdat het vaak als overdracht van een filmpje wordt ingezet om te streamen.
Maar aangezien filmbestanden toch al gecomprimeerd zijn, is een extra compressieslag alleen maar ballast.  Je wint er netto niets op.
Hooguit bij trage internetverbindingen en Office achtige data die sterk gecomprimeerd kan worden zou je er voordeel bij kunnen hebben.
Maar daarbij is de data-omvang van bestanden doorgaans zodanig klein, dat je toch weinig merkt van die compressie.

Een eerdere "Jip & janneke" uitleg m.b.t. gecomprimeerde data-overdracht bij VPN, zie bericht / draadje < HIER >

[Pippin]

Voor goed functioneren dienen server en client(s) beide dezelfde compressie instelling te hebben.
Zo te lezen is dat ook zo.

De oplossing die @Briolet beschrijft, blokkeren van gefragmenteerde pakketten uitschakelen in de router, kan een oplossing zijn. Een andere oplossing zou dan kunnen zijn om een lager cipher, b.v. AES-128-CBC i.p.v. AES-256-CBC te kiezen. Dan is de "OpenVPN-interne overhead" ook lager.

Had eens een tekeningetje gemaakt, packet-flow:

[Babylonia]

Die cipher staat bij de NAS van mijn ex al erg laag, want die draait nog onder DSM 5.0   Daar valt (nog) niets aan in te stellen.
Dat geldt tevens voor instelling van OpenVPN in de Synology router.  (Of je moet overgaan op het VPN Plus package).
Alleen de NAS met DSM 6.1 en bijbehorende "hogere" versie VPN-server app biedt meer mogelijkheden om aanpassingen te doen.
(Standaard had ik die op de waarde BF-CBC en SHA-1 laten staan zoals het reeds was vóór ingevuld).

Maar het verbaast me hierbij wel, dat het probleem van die compressie alleen speelt bij de connectie methode om alleen data-verkeer met de server (NAS) via VPN te regelen.  En het "gewone" internetverkeer rechtstreeks via de bestaande internetverbinding naar buiten (niet via de VPN-tunnel).

Bij alle internet dataverkeer via de VPN tunnel speelt het probleem NIET met toegepaste compressie.

[Pippin]

Bij kennis met compressie ingeschakeld werkt ook niet/wel?

Mogelijke oplossing van @Briolet werkt?

[Babylonia]

Bij die kennis is de compressie NIET ingeschakeld en werkt dan als zodanig correct.
Omdat het zonder compressie goed werkt, lijkt het me prima zo, om het zo ingesteld te houden.

Verder zou ik niet weten hoe de MTU waarde van een OpenVPN verbinding lager in te stellen?
Er is geen instelling in de VPN-server daarover te vinden of wat standaard in een OpenVPN configuratiebestand is opgenomen.

[Pippin]

MTU aan te passen kan alleen via SSH en moet op server en client(s) gebeuren.
Maar er is nog iets anders waar ik aan denk.
Het is mogelijk dat er een bug in de GUI zit. Wanneer je compressie inschakelen aanvinkt en die instelling wordt niet in het config bestand geschreven, faalt het ook.
Dat zou je kunnen controleren door de config te bekijken/vergelijken via SSH/WinSCP.

[Babylonia]

Wanneer je compressie inschakelen aanvinkt en die instelling wordt niet in het config bestand geschreven, faalt het ook.

Daar is specifiek op getest.   (Maar niet gecontroleerd via SSH).
Vandaar dat in alle gevallen (bij 3 verschillende VPN-server set-ups waar ik de instellingen van kon aanpassen) de test met compressie alleen negatief uitvalt bij "connectie met server only".  En dat vanuit verschillende PC's en tablets. Dus het is ook niet afhankelijk van Windows OS versie, Android, en OpenVPN GUI versie binnen die verschillende OS'sen.  Ik ga me er niet verder in verdiepen. Het probleem is getackeld, en daarbij de oplossing gevonden, die bij alle 3 de VPN-servers hetzelfde uitpakt (en bij de 4e als zodanig reeds werkte). Vind ik voldoende zo.

[Briolet]

…Toen bleek bij alle andere VPN-servers het ineens WEL correct te werken.

- GEEN compressie toepassen bij de OpenVPN-server zelf.
- GEEN compressie toepassen bij de instellingen van het OpenVPN configuratiebestand.

comp-lzo
Juiste instelling:
#comp-lzo

@Babylonia , jij hebt "comp-lzo" uitgezet om een heel andere reden, maar toen ik vandaag met een nieuwe versie van Tunnelblick wilde verbinden, kreeg ik de volgende waarschuwing:



Als ik hierop zoek op dit forum, ben jij de enige poster die op het verwijderen van comp-lzo ingaat. Maar dan vanwege een andere reden.

Ik gebruik nog een oud  configuratiebestand. Echter, als ik een nieuwe exporteer, staat die compressie optie er nog steeds in. In plaats van editen van het config bestand, lijkt het me beter de compressie optie op de nas uit te zetten. Dan blijft hij ook weg in het geëxporteerde config bestand.

De enige verandering in het nieuwe export bestand van de nas is de toevoeging van "cipher BF-CBC" (en het certificaat nu in het bestand). Daar zit een c&p fout in waardoor mijn code editor het als "cipher BF-CBCɁ" weergeeft. Na even zoeken blijkt er een 'carrige return" achter te staan, terwijl het hele document een linux opmaak heeft met alleen linefeeds. Mijn tekstverwerker negeert deze stijlfout.

[Babylonia]

Draadje is al weer even geleden geraadpleegd. 
De toevoeging die je hier beschrijft wel iets om in het achterhoofd te houden.

Laatst testte ik met OpenVPN vanuit de NAS en kwam aan foutmeldingen waarvan ik vermoedde dat het te maken zou kunnen hebben met de OpenVPN versie 2.4 en 2.5.    Maar zou dus evengoed aan die "carriage return" en "linefeed" verschillen kunnen zitten?

Ik liet het toen maar even zo, omdat ik doorgaans toch de OpenVPN server van mijn router gebruik, en niet die van de NAS.
Die via mijn router werkt wel correct.

In ieder geval bedankt voor het delen, want wil het nog een keer goed gaan uitzoeken voor de NAS.
Kan ik deze info opnieuw raadplegen.