15
OpenVPN-Verbindung wird bei Last unterbrochen
Grüße, Admins!
Ich habe auf einer pfsense Installation den openVPN-Server aktiviert (mit Zertifikaten). Als Clients setze ich Windows 7 64bit ein. Meine Verbindung ist VDSL25, der Server steht "in der Nähe" (Deutschland) und hat eine Breitbandanbindung (Standleitung). Als Router / Firewall / VPN-Server läuft ein PCengines alix2 mit pfsense. Last durch andere Nutzer / Dienste ist auszuschließen.
Den Client habe ich zum Laufen bekommen und habe auch schon mehrmals problemlos VPN-Verbindungen mit viel "Last" herstellen können.
Nun tritt leider das Problem auf, dass die Verbindung plötzlich nicht mehr funktioniert, sobald ich irgend ein Protokoll einsetze, was etwas mehr Last als Ping & nslookup auf der VPN-Verbindung erzeugt. Konkret sind das bei mir Remotedesktop auf den Windows-Server hinter der Firewall und SCP auf einen Linux-Server.
Also: Verbindung mit openVPN herstellen klappt immer wunderbar und geht fix. Nslookup und ping sind auch kein Problem aber sobald ich eine RDP-Sitzung öffnen will oder einen SCP-Transfer initiiere, kommen keine ICMP-Antworten mehr (im Hintergrund ein ping -t).
Komisch daran: Weder im openVPN-Server noch im Client sagt das Logfile irgendetwas aus. Im Server steht gar nichts und im Client kommt irgendwann eine Timeout-Meldung und dann ein Reconnect welcher auch funktioniert. Allerdings bricht die Verbindung bei Last wieder zusammen. Das seh ich an den ICMP-Antworten, die versiegen sobald ich RDP oder SCP nutzen will.
Noch komischer: Auf meinem ersten Client hat es zunächst einwandfrei funktioniert. Plötzlich trat das Problem auf und ich richtete openVPN auf dem zweiten Client ein um das Problem einzukreisen. Da funktionierte es auch für einige Zeit problemlos, bis es dann auch nicht mehr ging. Auf beiden Clients habe ich bisher nie wieder eine fehlerfreie Verbindung bekommen. Ich könnte wetten, der 3. Client machts auf für ein paar Tage und dann ist Feierabend.
Wireshark auf dem Client bringt viele mit "TCP Window Full" markierte Pakete. Woran könnte das liegen?
Bin für sämtliche Ideen dankbar, ich bin mit meinem Latein am Ende (ist so ein blödes "ging doch mal und plötzlich nicht mehr"-Problem)
Ich habe auf einer pfsense Installation den openVPN-Server aktiviert (mit Zertifikaten). Als Clients setze ich Windows 7 64bit ein. Meine Verbindung ist VDSL25, der Server steht "in der Nähe" (Deutschland) und hat eine Breitbandanbindung (Standleitung). Als Router / Firewall / VPN-Server läuft ein PCengines alix2 mit pfsense. Last durch andere Nutzer / Dienste ist auszuschließen.
Den Client habe ich zum Laufen bekommen und habe auch schon mehrmals problemlos VPN-Verbindungen mit viel "Last" herstellen können.
Nun tritt leider das Problem auf, dass die Verbindung plötzlich nicht mehr funktioniert, sobald ich irgend ein Protokoll einsetze, was etwas mehr Last als Ping & nslookup auf der VPN-Verbindung erzeugt. Konkret sind das bei mir Remotedesktop auf den Windows-Server hinter der Firewall und SCP auf einen Linux-Server.
Also: Verbindung mit openVPN herstellen klappt immer wunderbar und geht fix. Nslookup und ping sind auch kein Problem aber sobald ich eine RDP-Sitzung öffnen will oder einen SCP-Transfer initiiere, kommen keine ICMP-Antworten mehr (im Hintergrund ein ping -t).
Komisch daran: Weder im openVPN-Server noch im Client sagt das Logfile irgendetwas aus. Im Server steht gar nichts und im Client kommt irgendwann eine Timeout-Meldung und dann ein Reconnect welcher auch funktioniert. Allerdings bricht die Verbindung bei Last wieder zusammen. Das seh ich an den ICMP-Antworten, die versiegen sobald ich RDP oder SCP nutzen will.
Noch komischer: Auf meinem ersten Client hat es zunächst einwandfrei funktioniert. Plötzlich trat das Problem auf und ich richtete openVPN auf dem zweiten Client ein um das Problem einzukreisen. Da funktionierte es auch für einige Zeit problemlos, bis es dann auch nicht mehr ging. Auf beiden Clients habe ich bisher nie wieder eine fehlerfreie Verbindung bekommen. Ich könnte wetten, der 3. Client machts auf für ein paar Tage und dann ist Feierabend.
Wireshark auf dem Client bringt viele mit "TCP Window Full" markierte Pakete. Woran könnte das liegen?
Bin für sämtliche Ideen dankbar, ich bin mit meinem Latein am Ende (ist so ein blödes "ging doch mal und plötzlich nicht mehr"-Problem)
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 158705
Url: https://administrator.de/forum/openvpn-verbindung-wird-bei-last-unterbrochen-158705.html
Ausgedruckt am: 22.12.2024 um 21:12 Uhr
15 Kommentare
Neuester Kommentar
Spontan aus dem Bauch heraus würde ich es mal mit einer reduzierten MTU versuchen.
In der client- und server-conf folgende Zeile einfügen:
tun-mtu 1400
In der client- und server-conf folgende Zeile einfügen:
tun-mtu 1400
Das wäre einen Versuch wert in der Tat. Ebenso wäre einmal interessant was die CPU Last im ALIX sagt ??
Generell kann das ALIX solche Bandbreiten problemlos verkraften, nebenbei erzeugt RDP ja nun auch nur minimalen Traffic..generell also kein Problem.
Bist du nach folgender Anleitung vorgegangen: ??
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Hast du ggf. noch einen Router VOR der pfSense ??
Generell kann das ALIX solche Bandbreiten problemlos verkraften, nebenbei erzeugt RDP ja nun auch nur minimalen Traffic..generell also kein Problem.
Bist du nach folgender Anleitung vorgegangen: ??
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Hast du ggf. noch einen Router VOR der pfSense ??
Das mit der MTU werde ich ausprobieren. Klingt einerseits vielversprechend, andererseits frage ich mich warum ich zuvor mehrfach funktionierende Verbindungen aufbauen konnte ohne die MTU zu reduzieren...
Die CPU-Last werde ich mir auch mal anschauen. Wobei ich denke, dass die Anbindung ans Internet eigentlich zu wenig Bandbreite hat, um die CPU auszulasten.
Der Anleitung bin ich in etwa gefolgt. Habe das ganze noch um eine AD-Authentifizierung erweitert (Auth LDAP Plugin).
Einen weiteren Router vor der Firewall betreibe ich nicht.
Die CPU-Last werde ich mir auch mal anschauen. Wobei ich denke, dass die Anbindung ans Internet eigentlich zu wenig Bandbreite hat, um die CPU auszulasten.
Der Anleitung bin ich in etwa gefolgt. Habe das ganze noch um eine AD-Authentifizierung erweitert (Auth LDAP Plugin).
Einen weiteren Router vor der Firewall betreibe ich nicht.
OK, ich war heut in der Firma und habe die MTU mal auf 1400 geändert. Der Test mit dem Notebook an der WAN-Schnittstelle des Routers hat auch geklappt. Da gab es allerdings auch nie Probleme. Von zu hause aus kann ich aber weiterhin keine anständige Verbindung aufbauen. Im Prinzip hat sich nichts geändert.
In der Server-Konfiguration steht in dem Feld "custom options" (pfsense GUI) nur der Eintrag zum LDAP Auth Plugin und davon mit Semikolon getrennt "tun-mtu 1400".
Die Konfiguration des Clients:
Hier mal das Log des Clients während des Verbindungsaufbaus:
Wird nun eine MTU von 1400 benutzt oder nicht? Was läuft da falsch? Was kann ich noch probieren?
In der Server-Konfiguration steht in dem Feld "custom options" (pfsense GUI) nur der Eintrag zum LDAP Auth Plugin und davon mit Semikolon getrennt "tun-mtu 1400".
Die Konfiguration des Clients:
client
dev tun
proto udp
remote XXX.XXX.XXX.XXX 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca "C:/Program Files (x86)/OpenVPN/easy-rsa/keys/ca.crt"
cert "C:/Program Files (x86)/OpenVPN/easy-rsa/keys/client2.crt"
key "C:/Program Files (x86)/OpenVPN/easy-rsa/keys/client2.key"
ns-cert-type server
comp-lzo
verb 3
auth-user-pass
push "route 192.168.70.0 255.255.255.0"
tun-mtu 1400Hier mal das Log des Clients während des Verbindungsaufbaus:
Fri Jan 21 14:41:20 2011 OpenVPN 2.2-beta3 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Sep 2 2010
Fri Jan 21 14:41:25 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Jan 21 14:41:25 2011 LZO compression initialized
Fri Jan 21 14:41:25 2011 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Fri Jan 21 14:41:25 2011 Control Channel MTU parms [ L:1442 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Jan 21 14:41:25 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Jan 21 14:41:25 2011 Data Channel MTU parms [ L:1442 D:1442 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Jan 21 14:41:25 2011 Local Options hash (VER=V4): 'a6ae7d69'
Fri Jan 21 14:41:25 2011 Expected Remote Options hash (VER=V4): '006a55ce'
Fri Jan 21 14:41:25 2011 UDPv4 link local: [undef]
Fri Jan 21 14:41:25 2011 UDPv4 link remote: XXX.XXX.XXX.XXX:1194
Fri Jan 21 14:41:25 2011 TLS: Initial packet from XXX.XXX.XXX.XXX:1194, sid=54d5ff99 3ceb2123
Fri Jan 21 14:41:25 2011 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Jan 21 14:41:26 2011 VERIFY OK: depth=1, /C=DE/ST=XXX/L=XXX/O=XXX/OU=XXX/CN=XXX/emailAddress=XXX
Fri Jan 21 14:41:26 2011 VERIFY OK: nsCertType=SERVER
Fri Jan 21 14:41:26 2011 VERIFY OK: depth=0, /C=DE/ST=XXX/O=XXX/OU=XXX/CN=XXX/emailAddress=XXX
Fri Jan 21 14:41:26 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Jan 21 14:41:26 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jan 21 14:41:26 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Jan 21 14:41:26 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jan 21 14:41:26 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Jan 21 14:41:26 2011 [openvpn_server] Peer Connection Initiated with XXX.XXX.XXX.XXX:1194
Fri Jan 21 14:41:28 2011 SENT CONTROL [openvpn_server]: 'PUSH_REQUEST' (status=1)
Fri Jan 21 14:41:28 2011 PUSH: Received control message: 'PUSH_REPLY,route 192.168.70.0 255.255.255.0,dhcp-option DOMAIN XXX,dhcp-option DNS 192.168.70.110,dhcp-option WINS 192.168.70.110,route 192.168.71.1,ping 10,ping-restart 60,ifconfig 192.168.71.6 192.168.71.5'
Fri Jan 21 14:41:28 2011 OPTIONS IMPORT: timers and/or timeouts modified
Fri Jan 21 14:41:28 2011 OPTIONS IMPORT: --ifconfig/up options modified
Fri Jan 21 14:41:28 2011 OPTIONS IMPORT: route options modified
Fri Jan 21 14:41:28 2011 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Jan 21 14:41:28 2011 ROUTE default_gateway=192.168.2.55
Fri Jan 21 14:41:28 2011 TAP-WIN32 device [LAN-Verbindung 2] opened: \\.\Global\{B7928640-66D5-49D1-96FF-7B1B4EE937B5}.tap
Fri Jan 21 14:41:28 2011 TAP-Win32 Driver Version 9.8
Fri Jan 21 14:41:28 2011 TAP-Win32 MTU=1500
Fri Jan 21 14:41:28 2011 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.71.6/255.255.255.252 on interface {B7928640-66D5-49D1-96FF-7B1B4EE937B5} [DHCP-serv: 192.168.71.5, lease-time: 31536000]
Fri Jan 21 14:41:28 2011 Successful ARP Flush on interface [23] {B7928640-66D5-49D1-96FF-7B1B4EE937B5}
Fri Jan 21 14:41:33 2011 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Fri Jan 21 14:41:33 2011 C:\WINDOWS\system32\route.exe ADD 192.168.70.0 MASK 255.255.255.0 192.168.71.5
Fri Jan 21 14:41:33 2011 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Fri Jan 21 14:41:33 2011 Route addition via IPAPI succeeded [adaptive]
Fri Jan 21 14:41:33 2011 C:\WINDOWS\system32\route.exe ADD 192.168.71.1 MASK 255.255.255.255 192.168.71.5
Fri Jan 21 14:41:33 2011 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Fri Jan 21 14:41:33 2011 Route addition via IPAPI succeeded [adaptive]
Fri Jan 21 14:41:33 2011 Initialization Sequence CompletedWird nun eine MTU von 1400 benutzt oder nicht? Was läuft da falsch? Was kann ich noch probieren?
Sieh doch einfach mal ins Log ...
Fri Jan 21 14:41:25 2011 Control Channel MTU parms [ L(ength):1442 ...
Sieht also aus das ja !
Fri Jan 21 14:41:25 2011 Control Channel MTU parms [ L(ength):1442 ...
Sieht also aus das ja !
Versteh ich nicht, sorry.
Also ich seh die Zahl da aber das sind weder 1400 noch 1500. 1500 ist doch die Standard-Einstellung oder?
Wo liegt denn jetzt der Fehler?
Also ich seh die Zahl da aber das sind weder 1400 noch 1500. 1500 ist doch die Standard-Einstellung oder?
Wo liegt denn jetzt der Fehler?
Mag sein das OpenVPN nur feste MTU Standardwerte supportet und so aufrundet auf den nächst höheren Wert. Müsste man mal in die Doku sehen ?!
Ich hab die MTU testweise noch niedriger gesetzt, brachte aber auch nix.
Habe auch den Link-MTU-Parameter mal ausprobiert, da der "einfacher" funktioniert (man muss nicht die UDP-IP-Umverpackung als Overhead abziehen, da link-mtu das beinhaltet und tun-mtu dementsprechend setzt). Habe auch den --fragment und den mssfix Schalter ausprobiert - alles ohne Erfolg. Mit Wireshark sieht man, dass Pakete, die größer als die MTU sind, einfach nicht ankommen. TCP Retransmission kommt ganz oft und am Ende TCP Window Full.
Mit link-mtu 1400 und fragment 1300 kommt im Log folgendes raus:
Ping bis 1326 Byte funktioniert problemlos, 1327 kommen schon nicht mehr an (egal ob mit oder ohne -f Schalter). Im Client-Log erscheint dann jedes mal so etwas wie:
Bin irgendwie ratlos - warum funktioniert openVPN nicht mit der Verbindung? Selbst wenn ich die MTU stark reduziere, kommt keine brauchbare Verbindung zustande. DSL (PPPoE) kann ja nich das Problem sein oder? Und die Anbindung an der Firma läuft übers DFN...
Wäre das TCP-Protokoll für openVPN eine Alternative?
Habe auch den Link-MTU-Parameter mal ausprobiert, da der "einfacher" funktioniert (man muss nicht die UDP-IP-Umverpackung als Overhead abziehen, da link-mtu das beinhaltet und tun-mtu dementsprechend setzt). Habe auch den --fragment und den mssfix Schalter ausprobiert - alles ohne Erfolg. Mit Wireshark sieht man, dass Pakete, die größer als die MTU sind, einfach nicht ankommen. TCP Retransmission kommt ganz oft und am Ende TCP Window Full.
Mit link-mtu 1400 und fragment 1300 kommt im Log folgendes raus:
Sun Jan 23 15:06:41 2011 Control Channel MTU parms [ L:1400 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sun Jan 23 15:06:41 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Sun Jan 23 15:06:41 2011 Data Channel MTU parms [ L:1400 D:1300 EF:46 EB:135 ET:0 EL:0 AF:3/1 ]
Sun Jan 23 15:06:41 2011 Fragmentation MTU parms [ L:1400 D:1300 EF:45 EB:135 ET:1 EL:0 AF:3/1 ]Ping bis 1326 Byte funktioniert problemlos, 1327 kommen schon nicht mehr an (egal ob mit oder ohne -f Schalter). Im Client-Log erscheint dann jedes mal so etwas wie:
Sun Jan 23 15:07:08 2011 read from TUN/TAP [State=AT?c Err=[c:\src\openvpn-2.2-beta3\tap_build\7600\tap-win32\tapdrvr.c/2636] #O=9 Tx=[2946,0] Rx=[3603,0] IrpQ=[0,1,16] PktQ=[0,43,64] InjQ=[0,1,16]]: Es sind mehr Daten verfügbar. (code=234)Bin irgendwie ratlos - warum funktioniert openVPN nicht mit der Verbindung? Selbst wenn ich die MTU stark reduziere, kommt keine brauchbare Verbindung zustande. DSL (PPPoE) kann ja nich das Problem sein oder? Und die Anbindung an der Firma läuft übers DFN...
Wäre das TCP-Protokoll für openVPN eine Alternative?
OK, mit 1400 klappt es einwandfrei wie du sehen kannst:
15:06:41 2011 Control Channel MTU parms [ L(ength):1400... Hier hält er also die 1400 Byte ein.
Das 1327 schon nicht mehr ankommen ist schon merkwürdig. Kann es sein das der DFN Router irgendwo eine MTU konfiguriert hat ?? Sieh dir mal das WAN Interface dazu an und ermittle den max. MTU Wert !! Das ist dann natürlich fatal wenn dort eine kleinere MTU als bei dir im Tunnel konfiguriert ist...dann kommt es zu Problemen.
Du kannst die max. MTU auch ganz einfach ermitteln:
http://www.gschwarz.de/mtu-wert-ermitteln
Der kleineste Wert der da rauskommt ist dann auch der minimalwert deiner MTU. Wenn der Tunnel Pakete mit größerer MTU schickt als ein WAN Interface auf der Strecke hat dropt der Router diese zu großen Frames:
http://www.cisco.com/en/US/tech/tk175/tk15/technologies_tech_note09186a ...
TCP macht nicht wirklich Sinn da der Overhead noch erheblich größer wird und das die Performance deiner VPN Verbindung verschlechtert. Außerdem löst das das MTU Problem auch nicht ! Das bleibt ja. Es mag aber sein das mit TCP eine MTU Path Discovery ausgeführt wird, was eigentlich immer Standard ist.
Käme auf einen Versuch an... Ist ja schnel in der Konfig Datei geändert....
15:06:41 2011 Control Channel MTU parms [ L(ength):1400... Hier hält er also die 1400 Byte ein.
Das 1327 schon nicht mehr ankommen ist schon merkwürdig. Kann es sein das der DFN Router irgendwo eine MTU konfiguriert hat ?? Sieh dir mal das WAN Interface dazu an und ermittle den max. MTU Wert !! Das ist dann natürlich fatal wenn dort eine kleinere MTU als bei dir im Tunnel konfiguriert ist...dann kommt es zu Problemen.
Du kannst die max. MTU auch ganz einfach ermitteln:
http://www.gschwarz.de/mtu-wert-ermitteln
Der kleineste Wert der da rauskommt ist dann auch der minimalwert deiner MTU. Wenn der Tunnel Pakete mit größerer MTU schickt als ein WAN Interface auf der Strecke hat dropt der Router diese zu großen Frames:
http://www.cisco.com/en/US/tech/tk175/tk15/technologies_tech_note09186a ...
TCP macht nicht wirklich Sinn da der Overhead noch erheblich größer wird und das die Performance deiner VPN Verbindung verschlechtert. Außerdem löst das das MTU Problem auch nicht ! Das bleibt ja. Es mag aber sein das mit TCP eine MTU Path Discovery ausgeführt wird, was eigentlich immer Standard ist.
Käme auf einen Versuch an... Ist ja schnel in der Konfig Datei geändert....
Ich hatte heut die Gelegenheit, mal von anderer Stelle aus die VPN-Verbindung zu initiieren und es klappt problemlos. Also liegt es zu hause am DSL-Anschluss?
Allerdings kann ich auch von hier aus (Uni-Netz, also auch DFN, ca 5 Hops zum Ziel-Server) über das VPN keine größeren Pings absenden als von zu hause. Remotedesktop und SCP ist aber kein Problem... Die verwendeten Einstellungen entsprechen den o.g. (link-mtu 1400, fragment 1300, mssfix). Theoretisch unterscheidet den DSL-Anschluss doch nur die um 8 Byte kleinere MTU (wegen PPPoE). Bei einer so geringen MTU (1300 hab ich ja auch ausprobiert) geht es aber dennoch nicht. Warum?
Allerdings kann ich auch von hier aus (Uni-Netz, also auch DFN, ca 5 Hops zum Ziel-Server) über das VPN keine größeren Pings absenden als von zu hause. Remotedesktop und SCP ist aber kein Problem... Die verwendeten Einstellungen entsprechen den o.g. (link-mtu 1400, fragment 1300, mssfix). Theoretisch unterscheidet den DSL-Anschluss doch nur die um 8 Byte kleinere MTU (wegen PPPoE). Bei einer so geringen MTU (1300 hab ich ja auch ausprobiert) geht es aber dennoch nicht. Warum?
Das ist richtig. Entweder hast du einen zu schwachen Billigrouter der einfach die Packet Forwarding Rate nicht schafft und/oder der kann nicht korrekt mit dem MTU Handling umgehen ?! Immerhin hast du VDSL 25 da spielt Paket Forwarding eine nicht unerhebliche Rolle. Hast du vor dem OpenVPN pfSense noch einen Router oder gehst du direkt ins VDSL ? http://www.heise.de/netze/artikel/pfSense-als-VDSL-Router-221500.html
Störungen auf dem DSL Link oder ein billiges Modem was damit nicht umgehen kann wären ein weiterer Grund.
Hast die die Firmware deines Zuhause Routers auf dem aktuellsten Stand ??
Ansonsten einmal testweise einen anderen Router oder Modem austesten.
Störungen auf dem DSL Link oder ein billiges Modem was damit nicht umgehen kann wären ein weiterer Grund.
Hast die die Firmware deines Zuhause Routers auf dem aktuellsten Stand ??
Ansonsten einmal testweise einen anderen Router oder Modem austesten.
Also die pfSense-Kiste ist direkt mit fester öffentlicher IP-Adresse als Gateway zum Internet eingerichtet. D.h. die Router die dazwischen liegen, sind nicht unter meiner Kontrolle. Hier zu Hause habe ich nen gemieteten Telekom Speedport W722V Typ B (Arcadyan, integr. VDSL-Modem), der zugegebenermaßen nicht ganz einwandfrei scheint (Beim Messen der WLAN-Geschwindigkeit mit iperf mehrmals abgestürzt, ein Gerät im Haushalt kommt manchmal partout nicht ins WLAN bis man den Router resettet - bzw. er tut das dann nach mehreren Verbindungsversuchen manchmal sogar von selbst und dann gehts irgendwann). Hab grad mal n Firmwareupdate (1.18) gemacht, aber das löst das Problem leider nicht. Die DSL-Verbindung ist ansonsten total in Ordnung, also von der Übertragungsrate und Latenz her... Ein alternatives Modem werde ich mir wohl mal zulegen müssen, wenn rauskommt dass der Router Schuld ist (Speedport 300HS bei ebay + irgendeinen anderen Router). Früher hatte ich ein WRAP mit m0n0wall + ADSL Modem + Switch + Access Point, diesen Gerätezoo hab ich allerdings zugunsten der "Ein-Gerät-Lösung" aufgegeben :D
Ich werde als nächsten Schritt mal bei nem Bekannten am ADSL-Anschluss die VPN-Verbindung testen...
Ich werde als nächsten Schritt mal bei nem Bekannten am ADSL-Anschluss die VPN-Verbindung testen...
Oha....und da wunderst du dich bei so einem wackeligen Router ?? Den solltest du dann als allererstes ersetzen. Scheinbar bist du nicht der einzige...es gibt dazu hunderte von Threads...
http://www.mac-tv.de/Forum/showthread.php?t=11204
http://www.mac-tv.de/Forum/showthread.php?t=11204
Ich hatte keine Ahnung, dass VPN so "besonders" ist. Habe mit anderen Diensten keinerlei Probleme - Auch nach oder während aufgebauter VPN-Verbindung. Noch dazu funktionierte die VPN-Verbindung ja anfangs problemlos mit diesem Router...
Uni-VPN (Cisco-Client mit IPsec) ist ja auch kein Problem. Was also macht openVPN so besonders?
Uni-VPN (Cisco-Client mit IPsec) ist ja auch kein Problem. Was also macht openVPN so besonders?
OK, wenn das parallel störungsfrei rennt ist das sicher nicht das Thema denn besonders ist das keineswegs..eher noch robuster als IPsec.
Dann liegt es an den speziellen Tunnelendpunkten bzw. Konfiguration der VPN Endgeräte.
Über ein Forum da jetzt aber detailiertes Troubleshooting zu machen sprengt den Rahmen, denn da müsste man mit Wireshark und anderen Tools ins eingemachte gehen.... Denn ein MTU Problem hast du, das ist nicht von der Hand zu weisen...
Dann liegt es an den speziellen Tunnelendpunkten bzw. Konfiguration der VPN Endgeräte.
Über ein Forum da jetzt aber detailiertes Troubleshooting zu machen sprengt den Rahmen, denn da müsste man mit Wireshark und anderen Tools ins eingemachte gehen.... Denn ein MTU Problem hast du, das ist nicht von der Hand zu weisen...
