LCOS 9.1RC2 und Client VPN Tunnel

[Raudi]

Hallo,

ich habe hier etwas, das mir vorher noch nicht in der Art aufgefallen ist, daher bin ich mir nicht sicher ob es ein Problem ist:

Ich habe hier einen 1781EF+ der hat diverse VPN's unter anderem zur Firma bei der ich arbeite. Über diesen VPN telefoniere ich über VoIP. Der 1781EF+ hat die AllIP Lizenziert und stellt eine Verbindung zur Swyx her, mein Snom loggt sich am LANCOM ein.

Baue ich nun einen VPN Tunnel von meinem Client zu einem Kunden auf dann klappt das zunächst wunderbar. Beginne ich aber zu telefonieren bricht der VPN weg. Ich kann auch keinen neuen Tunnel aufbauen. Beende ich das Telefonat dann kann ich auch wieder einen VPN Tunnel aufbauen.

Kann es irgendwie mit der MTU zusammen hängen? Denn die wird durch das QoS ja reduziert wenn man telefoniert.

Ich bin mir nicht sicher, ob es wirklich mit der RC2 zusammen hängt, aber ich kann mich nicht erinnern jemals ein solches Problem gehabt zu haben.

Mich würde daher mal die Meinung eines Experten aus diesem Bereich interessieren...

Viele Grüße

Stefan

[Raudi]

Ist echt gediegen:

- Mit einem Cisco VPN Client zu einer Cisco IPSEC Gegenstelle kann ich in der RDP Sitzung noch ca. 15 Sekunden weiter arbeiten, nach dem die Telefonverbindung aufgebaut ist, dann bleibt diese hängen.

- Mit dem Windows eingebauten PPTP Client zu einer Watchguard Gegenstelle per PPTP, da bleibt die RDP Sitzung schon hängen wenn ich auf wählen gedrückt habe.

- Mit dem Windows eingebauten PPTP Client zu einer LANCOM Gegenstelle per PPTP keine Probleme.

Ich habe auf dem Cisco VPN Client das Log auf höchste Stufe gestellt, aber keine Fehlermeldungen erhalten, der VPN Tunnel steht nach wie vor, Keep Alive Pakete gehen noch durch, aber eine Verbindung per RDP kann ich erst wieder herstellen wenn ich aufgelegt und den VPN einmal getrennt und wieder neu aufgebaut habe.

[cpuprofi]

Hallo Stefan,

Du kannst ja mal folgendes ändern und dann schauen was passiert. Und zwar unter:

VCM -> Erweitert -> QoS:

Abgehende Pakete bevorzugen: keine Veränderung

Ankommende Pakete bevorzug.: keine Veränderung

Damit hast Du dann die Fragmentierung der Pakete und Reduktion der PMTU ausgeschaltet.

Grüße
Cpuprofi

[Raudi]

Jep, der Gedanke kam mir auch gerade und getestet...

Keine Probleme mehr mit dem VPN Tunnel zur Cisco oder Watchguard.

[Raudi]

Habe das QoS nun mal auf abgehend "Fragmentieren" gestellt, funktioniert auch noch, mal beobachten.

Das ist dann ja echt ein Problem, da will man QoS machen um VoIP optimal zu übertragen aber dann kann dann teilweise keine VPN's mehr nutzen. Ist das von mir beobachtete Verhalten so denn korrekt?

[cpuprofi]

Hallo Stefan,

ich nutze ab 1Mbit/s Upload generell kein QoS im VCM. Auch Lancom macht das im SIP-ALG so.

Warum Lancom im VCM eine PMTU von 576 Byte vorschlägt würde mich ja mal interessieren. Denn "Backslash" empfehlt in einem anderen Thread wo es um QoS für RDP geht 512 Byte... Wobei "Backslash" bei RDP eine Mindestbandbreite 100 kBit/s pro Station empfiehlt und der SIP-ALG eine Mindestbandbreite 91 kBit/s pro Station macht (was ja für SIP inkl. Overhead auch reicht).

Grüße
Cpuprofi

[Raudi]

Moin,

ja da bin ich mit meinen 12 MBit/s im Upload ja locker drüber, wie gesagt, werde das beobachten.

Viele Grüße
Stefan

[backslash]

Hi cpuprofi,

Warum Lancom im VCM eine PMTU von 576 Byte vorschlägt würde mich ja mal interessieren. Denn "Backslash" empfehlt in einem anderen Thread wo es um QoS für RDP geht 512 Byte...

Die MTU von 576 hat einen historischen Hintergrund... Früher wurde auf langsamen Verbindungen (Modem...) von allen Betriebssystemen eine MTU von 576 eingestellt. Es gibt historische RFCs, die das mit der Mindestnutzlast von UDP begründen, doch die beträgt nur 512 Bytes - zusammen mit allen Headern kommt man dann auf 540, d.h. es fehlen noch 36 Bytes. Vermutlich sind die für irgendwelche Routing-Optionen im IP-Header reserviert. Ich empfehle die 512 Bytes, weil sie einerseits einfach zu merken ist und andererseits ist das die Grenze ab der so mancher TCP-Stack die PMTU-Erkennung abschaltet und im schlimmsten Fall eine Fragmentierung riskiert

Wobei "Backslash" bei RDP eine Mindestbandbreite 100 kBit/s pro Station empfiehlt und der SIP-ALG eine Mindestbandbreite 91 kBit/s pro Station macht (was ja für SIP inkl. Overhead auch reicht).

Das SIP-ALG oder der VCM rechnet die Bandbreite aufs Bit genau aus - das wird insbesondere bei ADSL interressant, weil dort die Pakete ja in ATM-Zellen fester Größe zerhäkselt werden. Das kann gerade bei hochkomprimierenden Codecs verwirrende Ergebnisse liefern: so kann G.723 zwar den Audiostrom auf unter 20kBit/s reduzieren, nur leider paßt das Ergenis so gerade nicht in ATM-Zellen und es müssen daher fast 60 kBit/s reserviert werden...

Auch hier sind die 100kBit/s nur ein einfach zu merkender Wert, der immer paßt - nicht mehr und nicht weniger

Gruß
Backslash

[cpuprofi]

Hallo Backslash,

danke für Deine Erläuterungen, jetzt bin ich wieder etwas schlauer...

Grüße
Cpuprofi