Swyx Softclients Hinter Vpn (Viprinet) / Fragmentierte Pakete / Keine Statusanzeige, Halten Oder Verbinden

[torstenk]

Hallo,

 

wir haben hier ein sehr unschönes Problem. Vielleicht hat einer von euch noch hilfreiche Tipps oder Ideen. Wir haben am Hauptstandort einen Swyx Server (Netphone / 8.1.0.257) und 4 Remote-Standorte. Im Einsatz befinden sich ausschließlich Softclients und ein paar Audiocodes. Die bisherige VPN Infrastruktur wurde am Wochenende ausgetauscht und durch Viprinet-Geräte ersetzt. Das läuft soweit auch einwandfrei, aber:

 

Seitdem haben wir mit der Swyx folgende Probleme an den Standorten:

- Keine Statusanzeige im Client

- Kein Verbinden mehr möglich

- Kein Halten von Gesprächen

- CallRouting Scripts tun nicht mehr (liegt aber vermutlich an fehlerhaften Statusnachrichten)

 

Nach derzeitigem Stand liegt das an fragmentieren Paketen. Die werden (nach RFC) nicht über die Tunnel versendet.

Fixes wie 

- "EnableMultiSubscription" Wert aendern auf 0

- "MaxSipPresenceSubscriptionSize", 10 (default:50)

führten leider auch nicht zu Erfolg. Status wird zwar teilweise wieder angezeigt, ist aber auch nicht aktuell.

 

Sind noch andere Parameter bekannt um die Packetfragmentation zu unterbinden?

 

Eine Änderungen der MTU Size am Swyx Server selbst brachte nur noch mehr Probleme mit sich. Speziell am Hauptstandort. Dies führte zu Phänomenen wie "Geprächspartner hört mich nicht" oder nicht ankommende Calls.

 

Bin für alle Tipps dankbar.

 

Gruß

 

Torsten Kohlmann

[jodost]

Keine direkte Lösung für Dein Problem, aber ein Worksround: verbinde dich über den RemoteConnector (setzt natürlich ein Update auf eine aktuelle Version voraus)

[Virikas]

Die werden (nach RFC) nicht über die Tunnel versendet.

*Verwirrt*

Welcher RFC verbietet das versenden von fragmentierten Paketen? Das wäre .. kontraproduktiv ^^

[torstenk]

Hi,

 

unglücklich formuliert. Nach RFC 3261:

The client side of the transport layer is responsible for sending the

request and receiving responses.  The user of the transport layer

passes the client transport the request, an IP address, port,

transport, and possibly TTL for multicast destinations.

 

If a request is within 200 bytes of the path MTU, or if it is larger

than 1300 bytes and the path MTU is unknown, the request MUST be sent

using an RFC 2914 [43] congestion controlled transport protocol, such

as TCP. 

 

Quelle: https://support.software.dell.com/kb/sw10958(geht da zwar im speziellen um SIP Invites, aber das Problem ist das gleiche)

---

 

Und je nach Implementierung führt das zum Verwurf der fragmentierten UDP Pakte. Kurze Recherche in Google nach "sip fragmented udp" zeigt auf, dass das auch bei anderen Routern ein scheinbar bekanntes Phänomen ist.

 

Gruß

[Virikas]

Ah ok SIP RFC

Was hindert dich daran

a) die Path Mtu bekannt sein zu lassen, dann dürfte -je nachdem wie man das Komma im RFC interpretiert - die Implementierung sich u.u. nicht dran stören.

TCP zu verwenden?

Davon ab: Sicher, dass alles was da an SIP ALGs auf den Firewalls rumschwirrt deaktiviert ist? In den Kundenimplementierungen wo der Kunde eigene Tunnel gebaut hat war in 99,9% der Fälle immer ein "übersehenes" SIP ALG die Ursache was der Meinung war im SIP rumzupfuschen.

Allerdings darf eine Änderung der MTU auf Server (UND Clientseite) auf Netzwerkebene nicht dazu führen, dass es zu den beschriebenen Problemen kommt.

Zumindest im Labor konnte ich das Adhoc eben auch nicht nachvollziehen. Selbst wenn ich die MTU auf 800byte runtersetze kann ich dann noch normal telefonieren, Stati bekommen etc.

Außerdem bin ich mir grad nicht 100% sicher, wie das zu sehen ist. Der Absatz bezieht sich ja explizit auf SIP Requests.

Rückmeldungen z.b. zum Status kommen ja aber als Response vom Swyxserver und damit von diesem Absatz ohnehin nicht betroffen.

Was genau wird denn hier in welcher Richtung von wem gedroppt? Sollte sich ja in einem Wireshark Abgleich Client <-> Server wunderbar herausfinden lassen.