Webdav laat finder vast lopen

[Tim__]

Neen openvpn draait standaard op poort 1194 UDP.

[Briolet]

Ik was indertijd ook al druk bezig geweest met alles uit te zoeken wat er allemaal nodig was en zag die download optie ook te laat. Je krijgt dan direct al de goede cliënt certificaten en voor de Mac laten ze je, via de readme file,  de Tunnelblick software installeren.

[Briolet]

Neen openvpn draait standaard op poort 1194 UDP.

De vraag was niet wat standaard is, maar of je het ook op TCP poort 443 moet/kunt zetten, zoals eerder geadviseerd wordt. En op de nas kun je dat als instelling gebruiken. Nodig is het alleen als de standaard poort dichtgetimmerd is.

[Briolet]

Nog een opmerking bij OpenVPN op de mac:

Normaal moet je in de config file instellen of al het verkeer via de nas moet gaan, of alleen verkeer naar je eigen netwerk.

In de helpfile staat ook:

Code: [Selecteer]

*Remove # before "redirect-gateway" to route all client traffic (including web-traffic) through this VPN Server.
Dit klopt echter niet als je TunnelBlick als VPN cliënt gebruikt. TunnelBlick heeft een eigen instelling hiervoor die de config file overruled. De instelling zit een beetje verstop onder 'geavanceerde settings' --> "Tijdens een verbinding"

Het enige wat je zelf in de config file moet aanpassen is het invullen van je eigen URL of publieke IP.

Als je ervoor kiest om al het verkeer via de nas te laten lopen (de traagste oplossing en niet nodig om alleen nas toegang te hebben) dan kun je andere problemen krijgen. Op mijn Ziggo Ubee router stond standaard ingesteld om "fragmented packages" te blokkeren. Als je het internet verkeer via de nas laat lopen, komen er een paar bytes bij elk package bij, zodat ze boven de MTU waarde komen en ze dus in tweeën gehakt worden. Internet werkt dan niet meer. Frangmented packages in de router toelaten lost dat probleem op.

[Pippin]

Ja dan zal de router ze "ompakken" in geval van IPv4.

De MTU waarde kan dacht ik evt. in de config files van server en client gewijzigd worden.
Of dat met TunnelBlick werkt weet ik echter niet.
Dan moet dat wel handmatig zoals met de URL of publieke IP.
Op de server ook of met het package Config File Editor.

[TonVH]

Ja dan zal de router ze "ompakken" in geval van IPv4.

De MTU waarde kan dacht ik evt. in de config files van server en client gewijzigd worden.
Of dat met TunnelBlick werkt weet ik echter niet.
Dan moet dat wel handmatig zoals met de URL of publieke IP.
Op de server ook of met het package Config File Editor.

MTU waarde van de NAS kun je gewoon in Configuratie --> Netwerk instellen. Geen spec. package nodig.

[Pippin]

Zeg ook niet dat er een package nodig is maar misschien knullig geformuleerd
Kun jij in Netwerk een MTU van 1492 instellen? Ik niet n.l.
Komt bij dat de VPN Server standaard MTU=1500 ingesteld is en die kun je dan niet wijziggen in DSM.
Dat heeft betrekking op wat Briolet zegt.

Mijn provider gebruikt 1492 en ik heb dat ook zo ingesteld. (Met Config File Editor)
Ja, dat heb ik in heel mijn LAN zo ingesteld behalve de Androids, die zouden dan geroot moeten worden en dat wil ik niet.

[TonVH]

Welke provider verplicht het gebruik van een specifieke MTU? Vzw is 1500 de normale/standaard waarde en 9000 als je Jumbo frames wilt hebben.

Ik had vroeger enkele apparaten op MTU=9000 staan en de rest op MTU=1500 (cq default) en dat werkt prima door elkaar.

[Pippin]

Adsl/Vdsl gebruikt 1492 hier bij de Deutsche Telekom (T-Home) en dat is ook (redelijk) standaard.

9000 werkt ook wel binnen het LAN wel te verstaan.
Maar dan wel alle aangesloten apparaten anders moet het nog omgepakt worden naar 1500 en is de router er lekker druk mee en is het voordeel voor een groot deel weer weg. Tenzij het aan een switch hangt die Jumbo Frames ondersteund.
Dit is tenminste wat ik er zo`n beetje van begrepen heb.

[Briolet]

MTU=9000 en MTU=1500 door elkaar werkt ook prima. Als MTU op MTU=9000 staat en je stuurt iets via internet, dan  kijkt de nas wat de MTU van die verbinding is en past het daar op aan.
Dat aanpassen gebeurt nu ook omdat VPN internet content binnenkrijgt en weer doorstuurt naar de cliënt. Omdat VPN er een paar bitjes bij moet plakken weet hij dat hij boven de MTU uit komt en hakt ze in tweeën om binnen de MTU te blijven. Het creëren van gefragmenteerde pakketten is een heel legitieme optie op het internet.

Het probleem is een veiligheidsinstelling in de router om dergelijke gefragmenteerde pakketten te blokkeren omdat je  met zulke gefragmenteerde pakketten ook [url=http://en.wikipedia.org/wiki/IP_fragmentation_attacks]een netwerk kunt aanvallen door wel het eerste pakket te sturen en daarna geheel andere pakketten. Gelukkig kun je die beveiliging uit zetten, maar die beveiliging zit er niet voor niets op, denk ik dan maar.

[Briolet]

9000 werkt ook wel binnen het LAN wel te verstaan.
Maar dan wel alle aangesloten apparaten anders moet het nog omgepakt worden naar 1500 en is de router er lekker druk mee …

Nee hoor. Elke verzender overlegt met de andere partij wat de MTU moet zijn en gaat er niet overheen. Als de NAS op 9000 staat en de smartphone of router kent alleen 1500  dan wordt de MTU 1500, daar komt geen fragmentatie bij kijken. Kijk maar via Wireshark naar het verkeer, dan zie je dat duidelijk.
Dus 9000 en 1500 kun je rustig door elkaar gebruiken, als de tussenliggende switches etc maar 9000 ondersteunen. Dat is omdat alleen de eindpunten en routers een MTU afspreken en ervan uit gaan dat alles ertussen wel meegaat.

[Pippin]

Haal ik nu iets door elkaar?
Ben ook geen netwerk mannetje...

Bij IPv6 is dat zo maar niet bij IPv4, toch?
Bij IPv6 zegt de server bij een te groot packet stuur maar een andere, want ik ga niet ompakken (hakken).

[Birdy]

Vond nog een Topic van Briolet over dit onderwerp inclusief tests en bevindingen.