Hallo Liste, ich habe ein Problem mit dem OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004 auf einer SuSE 9.3: die Verbindung klappt ganz wunderbar, aber nach einem einfachen "ls" (mit oder ohne optionen) hängt sich die Verbindung nach den ersten ein bis zwei Zeilen auf und dann hilft nur noch ein "kill" und neuverbinden... Allerdings taucht das Problem scheinbar nur dann auf, wenn ich mich aus einem anderen Netzwerk (über VPN) an den Server verbinde. Andere Server im selben Netzwerk wie das Problemkind sind von dem Problem nicht betroffen. Ich hab auch schon das Routing gecheckt und den SSHD sowie den kompletten Server neu gestartet - ohne Erfolg.Komisch erscheint mir halt das ich sauber verbinden kann, aber sobald es dann etwas mehr an Bildschirmausgabe wird streikt er. Ein "cat /var/log/messages" oder yast ist dabei auch schon zuviel... Hat jemand eine Vision woran das liegen könnte oder was da verbogen sein kann??? Olly
Hallo, Am Donnerstag, 23. Februar 2006 19:31 schrieb Oliver Meißner-Knippschild:
Geht denn alles andere vernünftig über das VPN? evtl. ist das ja eine MTU-Geschichte. Sowas macht sich dann eben erst bemerkbar, sobald größere Pakete verschickt werden sollen, sprich, wenn mehr Daten geschickt werden.... Mfg, Thomas
Thomas Gräber schrieb:
Hallo,
Hallo Thomas,
Der Gedanke ist nicht schlecht, allerdings wäre das auch nicht zu erklären. Der Server hat zwei Netzwerkkarten, über eth0 wird der gesamte interne und VPN-Verkehr abgewickelt, eth1 hängt direkt am DSL-Modem (via dsl0). eth0 und eth1 haben lt. ifconfig jeweils eine MTU von 1500. Das Problem scheint nicht nur SSH zu sein, denn ftp oder auch scp über den Tunnel bleiben ebenfalls hängen! Dabei tritt dasselbe Muster auf: Einige Pakete kommen an und dann steht die Verbindung. Über das DSL geht es ohne Probleme. Allerdings habe ich die scp-/ftp-Transfers aus einer SSH-Sitzung über den VPN gestartet.... Bleibt halt die Frage ob daran nun die großen FTP/scp-Datenpakete oder die SSH-Bildschirmausgabe schuld sind. Ich denke ein VPN-Problem kann ich ausschließen, denn andere Dienste zu anderen Rechnern (rdp, vnc, ftp, pcAnywhere) funktionieren einwandfrei... Olly
Hallo Oliver,
Thomas Gräber schrieb:
Also ich hatte bei mir eben dieses Problem (mit ls :) ) und ein tun-mtu 1300 in der Konfigurationsdatei vom VPN-Server hat da Wunder bewirkt. Bei mir hängt allerdings der Server hinter der Firewall und wird per Port-Forwarding bedient. Viel Erfolg, Sven
Sven Niese schrieb:
Hallo Sven, naja... die MTU runterschrauben hat schon geholfen. Allerdings funktioniert es dann mit Datenpaketen der anderen Schnittstelle (eth1 am DSL-Modem) nicht. Sozusagen tritt dann da das Problem auf, jedenfalls laufen im tcpdump diverse Meldungen von wegen Paketfragmentierung auf. ..und das sehen meine surf-wütigen Kollegen gar nicht gerne ;) Wie gesagt... das Problem würde ich innerhalb des Tunnels ausschliessen, da ja alle anderen Dienste einwandfrei funktionieren. Olly
Hallo Oliver, [jetzt noch mal an die Liste, KMail hat mir irgendwie ein Reply-To: eingefügt, kann mich nicht daran erinnern das eingerichtet zu haben!? Dann kommen die Mails bei dir/mir auch nicht mehr doppelt an :) ] Oliver Meißner-Knippschild schrieb:
So ganz kann ich jetzt nicht folgen, ich bin zwar kein Experte auf dem Gebiet aber an sich dürfen Änderungen bei OpenVPN keine Auswirkungen auf das übrige Netzwerk haben, oder laufen besagte Pakete über das VPN? Mein Netzwerk sieht so aus Internet <--> Router 192.168.0.1 (eth1) <--> Subnetz 192.168.0.0/24 192.168.1.1 (eth2) <--> Subnetz 192.168.1.0/24 Anfragen an den VPN Server werden ins Netz weitergeleitet: [VPN] <--- Port-Forward zu 192.168.1.2 --> [192.168.1.2] Am Router gibt es dann noch ppp0 und eth0 für die DSL-Verbindung. (Es hängen auch nur 5 andere Rechner dran, die beiden internen Subnetze rühren daher, dass mein Switch nur 5 Ports hat, somit hängt der letzte Rechner an einem USB-Netzwerkdevice, was noch übrig war, direkt am Router.) Ifconfig am Router: eth0 Link encap:Ethernet HWaddr 00:10:A7:1A:15:B8 inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 eth1 Link encap:Ethernet HWaddr 00:10:A7:19:69:53 inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 eth2 Link encap:Ethernet HWaddr 00:C0:26:10:14:C8 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 ppp0 Link encap:Point-to-Point Protocol inet addr: [...] UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 Die (Linux-)Rechner im Netz haben auch eine MTU von 1500 für eth0. Nur am VPN-Server musste ich das auf 1300 runterschrauben. Daher weiß ich nicht, warum es bei dir nicht funktioniert. Problematisch könnte es sein, wenn der VPN-Server das ganze Subnetz über das VPN routet. Dann kommen evtl. Pakete von einem Rechner A mit einer MTU von 1500 zum Router, welcher diese über das VPN, was eine geringere MTU hat, weiterleitet. Keine Ahnung, ob die Pakete dann automatisch neu aufgeteilt werden!? Du schriebst, dass es beim Surfen der Kollegen Probleme gibt. Wie greifen sie auf das I-Net zu? Proxy oder Direkt?
Wie gesagt... das Problem würde ich innerhalb des Tunnels ausschliessen, da ja alle anderen Dienste einwandfrei funktionieren.
Falls das obige keinen Denkanstoß gebracht hat: Poste mal bitte die Struktur des Netzwerks - von wem geht welches Paket über welche Devices/Routen. Wichtig wäre dann auch, was geht und was NICHT geht (werde da, wie gesagt, nicht schlau draus). Also bspw. Pakete von Rechner A über den Router per VPN gehen; Pakete von Rechner A über den Router ins normale Netz gehen nicht - so habe ich das bislang verstanden. Gruß, Sven
Hallo Sven (und alle anderen), Sven Niese schrieb:
ok, zugegeben... wenn ich das lesen würde, würd ich es auch nicht verstehen ;) Also folgende Situation: LAN (1) <-> FW(2) <-> FW(3) <-> FirmenLAN(4) | eth0 Linux-Server (Gateway) eth1 - dsl0 1: ist mein LAN daheim (192.168.80.0/24) 2: Watchguard Firebox SOHO 6 (auch bei mir daheim) 3: Watchguard schlagmichtot (in der Firma) 4: Das Firmen-LAN (192.168.9.0/24) Der VPN ist einzig und allein eine Sache der beiden Watchguards (2 & 3), das machen die unter sich aus (und das ziemlich gut). Innerhalb des Firmen-LANs ist also das Problemkind. Hier mal die Konfig: dsl0 Link encap:Point-to-Point Protocol inet addr:84.134.117.237 P-t-P:217.0.116.116 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:1826897 errors:0 dropped:0 overruns:0 frame:0 TX packets:1909393 errors:0 dropped:41 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:1040664674 (992.4 Mb) TX bytes:833171758 (794.5 Mb) eth0 Link encap:Ethernet HWaddr 00:11:2F:B3:13:95 inet addr:192.168.9.17 Bcast:192.168.9.255 Mask:255.255.255.0 inet6 addr: fe80::211:2fff:feb3:1395/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5613667 errors:0 dropped:38015 overruns:0 frame:413762472 TX packets:5180584 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2707440872 (2582.0 Mb) TX bytes:3314956765 (3161.3 Mb) eth1 Link encap:Ethernet HWaddr 00:03:47:96:E3:8F inet addr:192.168.99.2 Bcast:192.168.99.255 Mask:255.255.255.0 inet6 addr: fe80::203:47ff:fe96:e38f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5087611 errors:0 dropped:0 overruns:0 frame:0 TX packets:5255576 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3329489756 (3175.2 Mb) TX bytes:2700816030 (2575.6 Mb) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:5119 errors:0 dropped:0 overruns:0 frame:0 TX packets:5119 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1061451 (1.0 Mb) TX bytes:1061451 (1.0 Mb) Die Kollegen in der Firma surfen ohne Proxy. Bei einer MTU von 1500 auf eth0 habe ich im Heimnetz (192.168.80.0/24) das Problem mit zu großen Datenpaketen, aber die Kollegen können super surfen. Stelle ich an der eth0 die MTU nun auf 1300 runter, habe ich im Heimnetz keine Probleme, dafür laufen in nem Sniffer auf dem Linux-Gateway besagte Meldungen über die Paketfragmentierung auf (nur an eth1 gesnifft!) und mit dem Surfen auf größeren Seiten ists dann vorbei... Wie gesagt... weil ja die beiden Watchguards sich um den VPN kümmern und ansonsten alle anderen Dienste wie pcAnywhere/RDP usw. vom FirmenLAN in mein HeimLAN und umgekehrt funktionieren, kreise ich den Fehler mal auf dem Linux-Rechner ein... Übrigens... SSH geht auch an andere Rechner im Firmen-LAN und in die DMZ des FirmenLAN aus meinem HeimLAN und umgekehrt in allen Variationen problemlos. Ich hoffe ich hab mich nun etwas klarer ausgedrückt ;)
Hallo Oliver, aha, so schaut das also bei dir aus :) Ich habe nur Erfahrung mit einem Standalone-OpenVPN-Server, der kein komplettes Netzwerk routet. Dennoch: mein Hinweis und wahrscheinlich auch der von Thomas zielte auf die VPN-Server-Konfiguration ab. Kann man an den SOHO-Dingern was drehen? Sozusagen sollen die VPN-Pakete max. 1300 groß sein, so dass die Dinger durch die DSL-Leitung passen, immerhin kommt da ja noch mal einiges an Header hinzu und ich weiß nicht an welchem Layer die VPN-Pakete ansetzen. Im Data-Layer sollten sie ja dementsprechend aufgeteilt werden, aber sonst!? Dass es Probleme gibt, wenn einzelne Rechner in einem Netzwerk (in dem Fall die Clients) eine geringere MTU haben als andere (--> Server) ist zumindest vorstellbar. Und dass es irgendwas mit den MTU-Einstellungen zu tun hat, hat sich meiner Meinung nach gezeigt. Noch mal schematisch (Zahlen in Klammern: MTU des jeweiligen Interfaces): Netzwerk 1 (1500) <--> (1500) SOHO 1 (1300) <- VPN* -> (1300) SOHO 2 (1500) <--> (1500) Netzwerk 2 * VPN Pakete werden über das normale Netzwerk/Internet weitergeleitet, dort ist die MTU minimal 1492 (dsl0). Das könnte dann funktionieren, muss es aber nicht. Oliver Meißner-Knippschild schrieb:
Ist ja auch gar nicht so einfach :) Ciao, Sven
* Sven Niese wrote on Fri, Mar 03, 2006 at 19:07 +0100:
Wie kommst Du dann eigentlich auf ausgerechnet 1300 Byte? Ist das ein "empirischer" Wert? "Header" / Overhead bei IPSec sollte 8 Byte sein, so dass man zu 1492 Bytes für Ethernet kommt (was ja "eigentlich" 1500 mag).
Versteh ich eigentlich eher nicht... Wenn die MTU knapp kleiner ist, als die MTU vom Sender, ist das ineffizient, weil der Router / Gateway / was auch immer neu fragmentieren muss. Dann hat man z.B. ein 1492 und ein 8 Byte Paket (jeweils plus Ethernetoverhead natürlich). Kann man vermeiden, wenn man die MTU entsprechend reduziert. Aber warum es dann gar nicht gehen soll, ist mir eigentlich ein Rästsel. Ich habe jedenfalls definitiv schon SSH über VPN mit MTU 1500 machen können, ist also kein grundsätzliches Problem. Sowas mit hängenden SSHs hatte ich auch irgendwie mal... mmm... Aber da ging FTP. War am Ende eine "kaputte" Netzwerkkarte! Also PING und alles ging, ping -f hatte plötzlich schlechte Raten, SSH hing gern mal. Muss aber was anderes sein.
Die Maximum TU ist minimal 1492 :) tcpdump und strace zeigen nichts? Mit "netcat" und "ping -s" kann man gute Tests machen (Achtung, ICMP/PING wird nicht unbedingt re-fragmentiert). Da kann man im Prinzip beliebig grosse oder kleine Testdaten nehmen. Jedenfalls ein komisches, aber bekannt klingendes Problem. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hallo, Steffen Dettmer schrieb:
Probiert und ging. Da ich das VPN nur ab und zu zur Fernwartung anwerfe, habe ich das nicht weiter verfolgt. Ich glaube, dass ich die Zahl in irgendeiner Mailinglisten-Mail gefunden hatte, welche mir Google präsentiert hat.
Mir auch :) Mein Erlärungsversuch ist aber zunächst mal schlüssig und passt auf beide Probleme - falls es jetzt bei Oliver funktioniert!?
VPN mit MTU 1500 machen können, ist also kein grundsätzliches Problem.
Bei mir klappten die Anmeldung und ein echo "Hallo" aber VNC oder ls gingen definitiv & reproduzierbar nicht. Ehrlich gesagt weiß ich nicht genau warum es nicht ging, es war mir aber, als es dann funktionierte, auch egal.
Danke für den Tipp, wenn es wieder auftritt, kann ich mich ja mal damit auseinandersetzen. Ciao, Sven
Hallo, Am Wed, 08 Mar 2006, Sven Niese schrieb:
Aeh, generell ist die MTU bei DSL limitiert, IIRC auf 1492 Bytes. Wenn da aber noch ein VPN-Header und sonstwas dazukommt... ISTR, dass 1452 oder sowas passen sollten. Mit 1300 sollte es dann natuerlich auch passen, aber man verschenkt halt etwas... Ueber'm Limit verschenkt man wesentlich mehr. -dnh -- 174: Win9x-Admin Turnschuhe, feuchte Hände und ein debiles Grinsen. Unterscheidet sich vom Win9x-User allein durch die Bezeichnung (Anders Henke)
Hallo, Am Donnerstag, 23. Februar 2006 19:31 schrieb Oliver Meißner-Knippschild:
Geht denn alles andere vernünftig über das VPN? evtl. ist das ja eine MTU-Geschichte. Sowas macht sich dann eben erst bemerkbar, sobald größere Pakete verschickt werden sollen, sprich, wenn mehr Daten geschickt werden.... Mfg, Thomas
Thomas Gräber schrieb:
Hallo,
Hallo Thomas,
Der Gedanke ist nicht schlecht, allerdings wäre das auch nicht zu erklären. Der Server hat zwei Netzwerkkarten, über eth0 wird der gesamte interne und VPN-Verkehr abgewickelt, eth1 hängt direkt am DSL-Modem (via dsl0). eth0 und eth1 haben lt. ifconfig jeweils eine MTU von 1500. Das Problem scheint nicht nur SSH zu sein, denn ftp oder auch scp über den Tunnel bleiben ebenfalls hängen! Dabei tritt dasselbe Muster auf: Einige Pakete kommen an und dann steht die Verbindung. Über das DSL geht es ohne Probleme. Allerdings habe ich die scp-/ftp-Transfers aus einer SSH-Sitzung über den VPN gestartet.... Bleibt halt die Frage ob daran nun die großen FTP/scp-Datenpakete oder die SSH-Bildschirmausgabe schuld sind. Ich denke ein VPN-Problem kann ich ausschließen, denn andere Dienste zu anderen Rechnern (rdp, vnc, ftp, pcAnywhere) funktionieren einwandfrei... Olly
Hallo Oliver,
Thomas Gräber schrieb:
Also ich hatte bei mir eben dieses Problem (mit ls :) ) und ein tun-mtu 1300 in der Konfigurationsdatei vom VPN-Server hat da Wunder bewirkt. Bei mir hängt allerdings der Server hinter der Firewall und wird per Port-Forwarding bedient. Viel Erfolg, Sven
Sven Niese schrieb:
Hallo Sven, naja... die MTU runterschrauben hat schon geholfen. Allerdings funktioniert es dann mit Datenpaketen der anderen Schnittstelle (eth1 am DSL-Modem) nicht. Sozusagen tritt dann da das Problem auf, jedenfalls laufen im tcpdump diverse Meldungen von wegen Paketfragmentierung auf. ..und das sehen meine surf-wütigen Kollegen gar nicht gerne ;) Wie gesagt... das Problem würde ich innerhalb des Tunnels ausschliessen, da ja alle anderen Dienste einwandfrei funktionieren. Olly
Hallo Oliver, [jetzt noch mal an die Liste, KMail hat mir irgendwie ein Reply-To: eingefügt, kann mich nicht daran erinnern das eingerichtet zu haben!? Dann kommen die Mails bei dir/mir auch nicht mehr doppelt an :) ] Oliver Meißner-Knippschild schrieb:
So ganz kann ich jetzt nicht folgen, ich bin zwar kein Experte auf dem Gebiet aber an sich dürfen Änderungen bei OpenVPN keine Auswirkungen auf das übrige Netzwerk haben, oder laufen besagte Pakete über das VPN? Mein Netzwerk sieht so aus Internet <--> Router 192.168.0.1 (eth1) <--> Subnetz 192.168.0.0/24 192.168.1.1 (eth2) <--> Subnetz 192.168.1.0/24 Anfragen an den VPN Server werden ins Netz weitergeleitet: [VPN] <--- Port-Forward zu 192.168.1.2 --> [192.168.1.2] Am Router gibt es dann noch ppp0 und eth0 für die DSL-Verbindung. (Es hängen auch nur 5 andere Rechner dran, die beiden internen Subnetze rühren daher, dass mein Switch nur 5 Ports hat, somit hängt der letzte Rechner an einem USB-Netzwerkdevice, was noch übrig war, direkt am Router.) Ifconfig am Router: eth0 Link encap:Ethernet HWaddr 00:10:A7:1A:15:B8 inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 eth1 Link encap:Ethernet HWaddr 00:10:A7:19:69:53 inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 eth2 Link encap:Ethernet HWaddr 00:C0:26:10:14:C8 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 ppp0 Link encap:Point-to-Point Protocol inet addr: [...] UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 Die (Linux-)Rechner im Netz haben auch eine MTU von 1500 für eth0. Nur am VPN-Server musste ich das auf 1300 runterschrauben. Daher weiß ich nicht, warum es bei dir nicht funktioniert. Problematisch könnte es sein, wenn der VPN-Server das ganze Subnetz über das VPN routet. Dann kommen evtl. Pakete von einem Rechner A mit einer MTU von 1500 zum Router, welcher diese über das VPN, was eine geringere MTU hat, weiterleitet. Keine Ahnung, ob die Pakete dann automatisch neu aufgeteilt werden!? Du schriebst, dass es beim Surfen der Kollegen Probleme gibt. Wie greifen sie auf das I-Net zu? Proxy oder Direkt?
Wie gesagt... das Problem würde ich innerhalb des Tunnels ausschliessen, da ja alle anderen Dienste einwandfrei funktionieren.
Falls das obige keinen Denkanstoß gebracht hat: Poste mal bitte die Struktur des Netzwerks - von wem geht welches Paket über welche Devices/Routen. Wichtig wäre dann auch, was geht und was NICHT geht (werde da, wie gesagt, nicht schlau draus). Also bspw. Pakete von Rechner A über den Router per VPN gehen; Pakete von Rechner A über den Router ins normale Netz gehen nicht - so habe ich das bislang verstanden. Gruß, Sven
participants (5)
-
David Haller -
Oliver Meißner-Knippschild -
Steffen Dettmer -
Sven Niese -
Thomas Gräber