openvpn auf 3370 - keine Datenübertragung

[Ing]

Hallo!

Ich habe eine 3370 (FritzOS 05.21) mit dem Openvpn Binary versehen (aktuell dieses hier http://www.ip-phone-forum.de/showthread.php?t=243914&p=1793505&viewfull=1#post1793505 (version 2.2.2).

Die Konfigurationsdateien sind eigentlich auch schon auf diversen anderen Boxen erprobt und liefen zuvor auf einer 7170. Ich musste halt nur das Binary austauschen.

Die Verbindung kommt auch zustande. Zu Beginn (erste 10 Sekunden) kann ich auch problemlos mit der Verbindung arbeiten, bis sie extrem langsam wird und zusammen bricht. Je mehr Datenverkehr, desto schneller bricht die Verbindung zusammen, als ob irgendein Puffer volläuft. Mache ich auf der Verbindung nur Telnet läuft's... Die gleiche Konfiguration auf einer 7390 läuft ebenfalls einwandfrei.

Hat irgendjemand eine Idee woran das liegen könnte?

 

[MaxMuster]

Ein paar mehr Infos dazu wären prima:
Die Box ist OpenVPN Server? Wie sieht die Config genau aus (z.B. TUN/TAP, cipher, lzo, Key/Zertifikate ...), wurden schon Einstellungen variiert, um das einzugrenzen (lzo, cipher, ...)?
Was bedeutet, dass "die Verbindung zusammenbricht"? Die VPN-Verbindung wird getrennt? Die Box startet durch?
Was steht dazu im Log der Box und des Client?

 

[Ing]

OK - in der Tat etwas dünn mein Text - aber wenn man den ganzen Tag 'dran 'rumgebastelt hat ist doch völlig klar, was man meint ;-).

Die Box ist Server. Zugriff via TAP (tap0 unter brinterfaces in der ar7.cfg). keine Komprimierung.
dev-node wird vorher mit mknod /var/tmp/tun1 10 200 erstellt.

Mit Zusammenbrechen meine ich, dass die Verbindung so langsam wird, dasss de facto keine Daten mehr fliessen. Aber weder Client noch Server bemerken, dass keine (kaum noch) Daten fliessen und finden im Log alles prima. Der Internetanschluss ist auf beiden Seiten auch OK (16000/1000'er ADSL auf Serverseite 50000/10000'er VDSL auf Clientseite).

Aktuelle Server Konfiguration:

script-security 2
proto udp
dev tap
port 1194
dev-node /var/tmp/tun1

mode server
tls-server
server 10.8.0.0 255.255.255.0
client-to-client

ca ca.crt
cert h.crt
key h.key
dh dh1024.pem
auth SHA1
cipher AES-256-CBC

ping 10
ping-restart 60

Client Konfiguration:

script-security 2
port 1194
proto udp
dev tap

ifconfig 192.168.50.171 255.255.255.0
tls-client
ns-cert-type server
remote <ip> 1194

route 192.168.50.0 255.255.255.0 192.168.50.4

ca ca.crt
cert T.crt
key T.key
auth SHA1
cipher AES-256-CBC

dhcp-option DNS 192.168.50.1
ping 30
ping-restart 100

 

[MaxMuster]

Also bei einer TAP-Konfiguration, bei der das VPN mit dem LAN gebrückt ist, wird die Verbindung durch jeden Broadcast im LAN belastet, ganz egal, ob was "gewollt" durch das VPN geht oder nicht. Das kann schon eine ganze Menge sein und das ist der größte Nachteil einer solchen Konfig. Schau doch mal nach, was so an Verkehr durch den Tunnel geht (z.B. die "ifconfig"-Zähler).
Ist die Box überlastet (top) oder "dreht Däumchen"?

Auch wenn das vermutlich nicht die Ursache ist:
Ist es denn gewollt, dass der Server mit "server 10.8.0.0 255.255.255.0" IPs aus dem Netz 10.8.0.0/24 hat und vergibt, der Client aber mit "ifconfig 192.168.50.171 255.255.255.0" das Netz 192.168.50.0/24 nutzt?

 

[Ing]

Die Box dreht tatsächlich Däumchen 98-99% idle und die Netzwerkverbindung überträgt ca. 800Byte/sek. - also auch im grünen Bereich (ca. 100KByte/sec. sollten eigentlich durch gehen, d.h. hier verschenke gerade mal 1%).

Die etwas chaotischen IP-Adressen waren mir gerade auch aufgefallen. Ist so natürlich nicht gewollt. Aber mit der vorherigen Konfiguration via "server-bridge 192.168.50.4 255.255.255.0 192.168.50.171 192.168.50.199" ging's fast noch schlechter.

Evtl. probier' ich's aber mal mit einem Tunnelinterface auch wenn ich da ein paar andere Probleme bekomme...

[edit]
So, jetzt habe ich auch das Tunnelinterface getestet. Mehr las 6-7KByte/s bekomme ich da aber auch nicht 'drüber. Das erklärt immerhin schon einmal, warum es mit TAP nicht geht: Da nehmen die Broadcasts einfach Überhand und blockieren die äusserst lahme Leitung.

Fragt sich nur: Warum ist openvpn auf der 3370 so langsam? (Die Auslastung lag auch bei Übertragung 7KByte/s nur bei ca. 0,5-1,5% für das openvpn Binary und 98% CPU idle - die CPU ist es also nicht).

 

[MaxMuster]

Diese Werte sind wirklich sehr klein und wirklich erklären kann ich mir das nicht.
Du könntest mal die MTU-Werte kleiner machen, um eine Fragmentierung und spätere Defragmentierung von Paketen zu verhindern. Das würde aber wohl auch eine höhere Last erzeugen, wenn es die Ursache wäre.
Gleiches gilt für den 256-er Cipher, der mehr Rechenzeit benötigt als z.B. Blowfish. Aber solange die CPU-Last nicht steigt...
Von wo überträgst du die Daten? Von der Box oder einem Gerät "dahinter"?

 

[Ing]

Die Daten kommen von Geräten dahinter.

Ich habe gerade mal mit den MTU Werten vom tun Interface gespielt (habe mal 1492 und 1400 probiert). Das macht allerdings keine Unterschied.

Etwas irritierend fand ich in dem Zusammenhang den MTU Wert für das ADSL Interface. Der steht auf 2000. Kann das richtig sein? Bei der 7390 steht der auch auf 1500.

 

[MaxMuster]

2000 passt nicht. Das könnte das OpenVPN zwar vielleicht "irritieren", aber fest eingestellt bringt es ja auch keine Änderung.
Diese Einstellung müsste sich aber ja auch auf alle Anwendungen auswirken, die ins Internet gehen...

Wenn die Daten von "hinter der Box" kommen, könnte auch eine falsche Duplex-Einstellung (eine Seite fest, eine auf "Auto") Ursache für eine extrem niedrige Übertragungsrate sein. Dann müsste der PC aber auch mit anderen Geräten im LAN ähnliche Probleme haben.

 

[Ing]

Ich habe noch ein wenig weiter geforscht. Bisher leider ohne zufriedenstellende Lösung.

Der MTU-Wert für die DSL-Verbindung steht in der ar7.cfg mit 0, d.h. vermutlich, dass die 2000 mit der Gegenstelle (Telekom Business-DSL) ausgehandelt sind und somit vermutlich korrekt sind.

Trotzdem scheint es irgendwie mit dem MTU-Wert (aktuell 1400 auf dem tun Interface) zusammen zu hängen:

Versuche ich "große" Pakete in das Netz zu senden (mit ping -f -l 1000) so geht dies schief (keine Antwort). Erst Pakete mit 512Byte werden zurückgesendet. Mit einem MTU Wert von nun 470 klappt die Verbindung mit VNC auch wunderbar - keine Einbrüche mehr. Für die Dateifreigaben ist das allerdings zu wenig: Da geht nun gar nichts mehr.

Irgendwie alles merkwürdig...

 

[Ing]

Ich habe das Problem leider nicht lösen können und nun eine 7390 hingestellt. Seitdem klappt alles wieder einwandfrei...