Synology-Forum.nl
Packages => Officiële Packages => VPN Server => Topic gestart door: Gaffel op 17 juni 2017, 14:55:55
-
Beste mensen,
Heeft iemand enig idee waarom ik van sommige adressen niet kan inloggen met openvpn terwijl dat vanaf andere plekken wel gaat. Ik heb een DS212+. Komt dat omdat er poorten geblokkeerd staan ( bijv. Vanaf Hotels in Duitsland)
Het probleem komt voor met een laptop maar ook met een smartfoon
Groeten,
Han
-
Het is idd denkbaar dat sommige wifi netwerken belaalde poorten blokkeren
Je zou kunnen overwegen om je openvpn zodanig te configureren dat ie over poort 443 (https) loopt, die wordt vrijwel nooit geblokkeerd
Als je dat op je server niet kunt, kun je t altijd nog via port mappings in je router oplossen. In dat geval zet je t poort nr in de config file aan client zijde op 443, en doe je een portforward in je router van inkomende poort 443 naar uitgaande poort 1194 naar ip adres vj nas
-
Welk protocol?
Voor de NAS, best bet is OpenVPN op poort 443 TCP.
Wanneer echter DPI toegepast wordt, wordt het lastig.
-
Bedankt voor de snelle reactie, ik zal inderdaad de poort configuratie aanpassen.
Over enkele maanden ben ik weer in Duitsland en kan ik het uitproberen.
Groeten,
Han
-
Wat is DPI?
-
DPI = Deep Packet Inspection
Wanneer dat toegepast wordt, wordt je verkeer geanalyseerd en een admin kan dan ervoor kiezen bepaald verkeer te blokken, b.v. VPN.
Let op, detectie betekent niet dat de data die je verstuurd/ontvangt via VPN leesbaar is, dat is het niet n.l.
Het betekent dus puur detectie en aan de hand daarvan blokkeren (of niet).
-
Ter verduidelijking net een capture gemaakt met Wireshark.
Zit nu op een openbaar WiFi met OpenVPN naar de NAS.
[attach=1]
Hierboven zie je dat het geen probleem is OpenVPN te detecteren.
De data is echter versleuteld en dus onleesbaar.
-
Hartelijk dank voor de uiteenzetting,
Groeten
Han
-
Meestal worden gewoon de standaard VPN poorten geblokkeerd.
Poort 433 wordt gebruikt voor het HTPPS protocol en die staat altijd wel open.
Als je die poort dus gaat gebruiken werkt het waarschijnlijk altijd.
Ook DPI zal daar geen roet in het eten gooien want https verkeer is echt niet te onderscheiden van VPN verkeer.
Beiden zijn namelijk encrypted en ook DPI kan daar niets aan zien.
-
DPI kan het verschil zien tussen HTTPS en OpenVPN, TCP of UDP maakt niet uit.
The Great Firewall of China is daar het ultieme bewijs van.
OpenVPN is zeker geen HTTPS, het is een eigen protocol.
In landen als China wordt daarom veel gebruik gemaakt van stunnel en obfs om OpenVPN te maskeren als HTTPS.
-
Het kan hem natuurlijk ook zitten in discrepantie met IP sub-netten die vanaf een bepaalde plek en gebruik daar van WiFi toevallig overeenkomt met het IP sub-net met wat men thuis gebruikt?
Is het IP sub-net wat men thuis gebruikt wel voldoende verschillende van algemeen vaak gebruikte sub-netten?
-
Beste,
Ik krijg vpn niet via poort 443 aan de praat.
Poort 443 wordt bij mij reeds gebruikt voor https(webserver)
Heb geprobeerd om m.b.v. Toepassings portaal met reverse proxy om daar met vpn.eigen domein.nl het verkeer alsnog via poort 443 te leiden, met als bestemming poort 1194.
Tevens mijn client aangepast met vpn.eigendomein.nl 443, tevens udp gewijzigd in tcp.
Ik heb niet te vergeten mijn certificaat bij let's encrypt aangepast voor bovenstaande domein aanpassing.
Bij inloggen zie ik wel uitgaande bytes, maar geen inkomende, dus ik krijg geen echte verbinding.
Wat doe ik verkeerd?
Groeten,
Han
-
Nieuw topic is waarschijnlijk beter?
Mogelijk kan dit (https://www.synology-forum.nl/vpn-server/openvpn-kan-poort-delen/msg155100/#msg155100) je verder helpen.
-
Heb geprobeerd om m.b.v. Toepassings portaal met reverse proxy om daar met vpn.eigen domein.nl het verkeer alsnog via poort 443 te leiden, met als bestemming poort 1194.
Een reverse proxy werkt alleen met http(s) verkeer, omdat dat protocol de url in de header meestuurt. VPN verkeer werkt alleen met het IP en laat de proxy niet weten namens welke url hij dat IP adres benaderd.
Andersom zou misschien wel kunnen. De webserver op een andere poort, waardoor poort 443 vrij komt voor de vpn. Dan het webverkeer via de reverse proxy omleiden naar de nieuw web poort.
-
Welke poort komt daar dan voor in aanmerking, ik lees iets op internet van poort 8443 ??
-
Mij levert deze instelling geen probleem op. Ook ik gebruik Poort 443 voor https (webserver):
-
@Gaffel gebruikt dan waarschijnlijk TCP voor OpenVPN?
Dan UDP eens proberen.
-
Hallo MaVer,
Loop jou vpn dan öok via reverse proxy met udp?
-
Nee
-
Met mijn opmerking bedoelde ik:
Zonder proxy
Webserver op 443 TCP
OpenVPN op 443 UDP
;)
-
Welke poort komt daar dan voor in aanmerking, ik lees iets op internet van poort 8443 ??
Verkeerde vraag, omdat er duizenden zijn die allen in aanmerking komen. De vraag is meer welke niet en dat zijn de poorten die je al ergens anders voor gebruikt.
Het simpelste is wel om UDP te gebruiken, zoals boven vermeld. Maar als je voor beide TCP wilt gebruiken zul je truukjes nodig hebben.
-
Deze simpele oplossing van MMD werkt in ieder geval wel.
Kijken of dit in de praktijk werkbaar is.
Welk voordeel zou tcp geven t.o.v. udp?
Groeten,
Han
-
TCP = betrouwbaarder, heeft error correctie maar langzamer door de data controle, over en weer.
UDP = heeft geen error correctie en daardoor sneller dan TCP.
-
UDP in niet nodig voor website bezoek. Als bedrijven poorten blokkeren, heb je ook kans dat UDP over poort 443 geblokkeerd wordt.
Bij TCP is daar minder kans op. Dan moeten ze al een firewall gebruiken die de headers analyseert om non-https verkeer over die poort te weren.
-
TCP gebruiken voor een VPN verbinding is volkomen onnodig en heeft meer overhead.
UDP is een handshake-less protocol, met andere woorden pakketjes worden verstuurd en daarna wordt niet op een bevestiging van aankomst gewacht.
Bij TCP gebeurd dat wel en is normaal gesproken betrouwbaarder.
UDP wordt over het algemeen alleen binnen een Lan gebruikt waar die handshake minder noodzakelijk is.
Uitzondering hierop is een VPN verbinding, want daar wordt alles inclusief de handsake door het VPN protocol geregeld en is het volkomen onnodig om binnen die tunnel nogmaals een handshake uit te voeren, dus dan het UDP de voorkeur vanwege minder overhead.
-
Hallo allemaal,
ik heb het volgende probleem met het maken van een VPN verbinding
ik bezit 2 iPhone type 6 een zakelijk KPN en de andere privé Telfort,
de zakelijke werk perfect via WI-Fi en mobile netwerk
met exact de zelfde instellingen werk mijn privé toestel allen via mijn eigen Wi-Fi netwerk
wie heeft een oplossing?