19
VOIP Problem über VPN Site-to-Site Tunnel
Hallo an die Experten,
folgendes Problem tritt aktuell bei mir auf:
Ein Mitarbeiter im HomeOffice ist per VPN (Site-to-Site Tunnel, Sonicwall TZ) mit der Zentrale (Sonicwall NSA) verbunden. Der Tunnel steht, Verbindung mit dem PC ist auch ohne Probleme möglich.
Probleme gibt es (seit kurzem) aber mit dem Telefon. Dieses bekommt eine IP aus dem HomeOffice LAN der Sonicwall und erreicht die TK Anlage (über den Tunnel). Generell funktioniert diese Verbindung (Telefon ist verbunden, klingelt auch).
PROBLEM: Viele der Gespräche werden allerdings nicht vollständig aufgebaut (Telefon klingelt, Teilnehmer können sich jedoch nicht hören). Im nächsten Versuch klappt es dann wieder usw....
Ich würde mich freuen über Ansätze zur Lösung des Problems bzw. Hinweise an welcher Stelle ich suchen muss bzw. "an welcher Schraube ich drehen muss" damit das Telefon wieder dauerhaft funktioniert.
Vielen Dank im Voraus!
Gruß
Clemens
folgendes Problem tritt aktuell bei mir auf:
Ein Mitarbeiter im HomeOffice ist per VPN (Site-to-Site Tunnel, Sonicwall TZ) mit der Zentrale (Sonicwall NSA) verbunden. Der Tunnel steht, Verbindung mit dem PC ist auch ohne Probleme möglich.
Probleme gibt es (seit kurzem) aber mit dem Telefon. Dieses bekommt eine IP aus dem HomeOffice LAN der Sonicwall und erreicht die TK Anlage (über den Tunnel). Generell funktioniert diese Verbindung (Telefon ist verbunden, klingelt auch).
PROBLEM: Viele der Gespräche werden allerdings nicht vollständig aufgebaut (Telefon klingelt, Teilnehmer können sich jedoch nicht hören). Im nächsten Versuch klappt es dann wieder usw....
Ich würde mich freuen über Ansätze zur Lösung des Problems bzw. Hinweise an welcher Stelle ich suchen muss bzw. "an welcher Schraube ich drehen muss" damit das Telefon wieder dauerhaft funktioniert.
Vielen Dank im Voraus!
Gruß
Clemens
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: 287128
Url: https://administrator.de/contentid/287128
Ausgedruckt am: 22.11.2024 um 00:11 Uhr
19 Kommentare
Neuester Kommentar
Hallo,
QoS?
Gruß
QoS?
Gruß
Moin,
das sieht nach einem Problem mit den UDP-Ports aus über welche das Gespräch (Audio) dann tatsächlich läuft. Welche Ports hast Du denn freigegeben über den Tunnel?
Looser
das sieht nach einem Problem mit den UDP-Ports aus über welche das Gespräch (Audio) dann tatsächlich läuft. Welche Ports hast Du denn freigegeben über den Tunnel?
Looser
Einmal das, und... Die Firewall sollte in jedem Falle den Voice Traffic im Tunnel priorisieren egal ob die Telefone .1p oder DSCP nutzen !
Das zweite ist die Frage ob die FW auch den Traffic im Tunnel selber überwacht.
Oft wird im Tunnel bei der Einrichtug bzw. Konfiguration der FW der Kardinalsfehler gemacht den Traffic im Tunnel selber auch zu NATen also eine Adress Translation auch des Tunneltraffics zu machen.
Das ist dann für die bei VoIP involvierten Protokolle tödlich, da diese teilweise dynamische Ports verwenden die dann am NAT hängenbleiben. Niemals also den Tunnel auch NATen in so einem Design !
Da es bei dir temorär klappt ist das vermutlich nicht das primäre Problem, zeigt aber das die FW Firmware nicht richtig damit umgehen kann.
Weitere wichtige Frage ist in dem Zusammenhang ob es auf Client Seite (Home Office) schon einen Router gibt und die FW damit kaskadiert ist.
Deine ToDos:
Mit einem simplen Softphone wie Phoner: http://www.phoner.de oder eine kostenlosen VoIP App wie Zoiper http://www.zoiper.com/en kannst du das auch VoIP selber schnell mal emulieren über den Tunnel und mit dem Wireshark prüfen wo es kneift. Der Wireshark hat sehr gute VoIP Tools dafür.
Das zweite ist die Frage ob die FW auch den Traffic im Tunnel selber überwacht.
Oft wird im Tunnel bei der Einrichtug bzw. Konfiguration der FW der Kardinalsfehler gemacht den Traffic im Tunnel selber auch zu NATen also eine Adress Translation auch des Tunneltraffics zu machen.
Das ist dann für die bei VoIP involvierten Protokolle tödlich, da diese teilweise dynamische Ports verwenden die dann am NAT hängenbleiben. Niemals also den Tunnel auch NATen in so einem Design !
Da es bei dir temorär klappt ist das vermutlich nicht das primäre Problem, zeigt aber das die FW Firmware nicht richtig damit umgehen kann.
Weitere wichtige Frage ist in dem Zusammenhang ob es auf Client Seite (Home Office) schon einen Router gibt und die FW damit kaskadiert ist.
Deine ToDos:
- Update der Firewall / Router Komponenten auf beiden Seiten auf die aktuellste Firmware
- Voice Traffic auf dem lokalen LAN und auch dem Tunnel Interface unbedingt priorisieren und das auf beiden Seiten bzw. FW Komponenten.
- Checken ob NAT im Tunnel gemacht wird und das unbedingt deaktivieren
- Checken ob die Firewall den Traffic kontrolliert im Tunnel und hier ggf. prüfen das SIP und RTP richtig behandelt werden. RTP nutzt dynamische Random Ports was die Firewall erkennen muss !!
Mit einem simplen Softphone wie Phoner: http://www.phoner.de oder eine kostenlosen VoIP App wie Zoiper http://www.zoiper.com/en kannst du das auch VoIP selber schnell mal emulieren über den Tunnel und mit dem Wireshark prüfen wo es kneift. Der Wireshark hat sehr gute VoIP Tools dafür.
Mahlzeit,
zusätzlich zu den QoS Geschichten im Netzwerk und Tunnel solltest du auch die VOIP-Hardware in Betracht ziehen.
Ich hatte zuletzt ein riesiges Problem mit einer Auerswald Commander Basic II und angeschlossenen Gigaset IP Pro DECT-Telefonen.
Die Gespräche brachen fast immer nach kurzer Zeit ab.
Schuld war eine fehlerhafte Einstellung in den Basisstationen der Gigaset Telefone, die nicht manuell konfigurierbar war. Diese wurde durch den Gigaset-Support durch ein angepasstes Konfigfile behoben.
zusätzlich zu den QoS Geschichten im Netzwerk und Tunnel solltest du auch die VOIP-Hardware in Betracht ziehen.
Ich hatte zuletzt ein riesiges Problem mit einer Auerswald Commander Basic II und angeschlossenen Gigaset IP Pro DECT-Telefonen.
Die Gespräche brachen fast immer nach kurzer Zeit ab.
Schuld war eine fehlerhafte Einstellung in den Basisstationen der Gigaset Telefone, die nicht manuell konfigurierbar war. Diese wurde durch den Gigaset-Support durch ein angepasstes Konfigfile behoben.
Hallo
eine kurze Antwort
Schau dir einfach die Sprachprotokolle (Codec) an - stelle diese Testweise runter auf zb. G.729 oder auf G.723 dann sollte es gehen.
Ich denke die stehen nun auf G.711 A-Law
Solltest du im Telefon (konfig) finden sofern die Anlage das auch Unterstützt.
Auch in der Telefonanlage sollte dies zu finden sein. Bei Aastra Detewe ist es unter Telefonie->Erweitert->VoIP Profil zufinden.
Bei Aastra muss du dies auch beim Telefon eintragen.
Dann geht's wieder ohne Probleme.
Grüße
Bernhard
eine kurze Antwort
Schau dir einfach die Sprachprotokolle (Codec) an - stelle diese Testweise runter auf zb. G.729 oder auf G.723 dann sollte es gehen.
Ich denke die stehen nun auf G.711 A-Law
Solltest du im Telefon (konfig) finden sofern die Anlage das auch Unterstützt.
Auch in der Telefonanlage sollte dies zu finden sein. Bei Aastra Detewe ist es unter Telefonie->Erweitert->VoIP Profil zufinden.
Bei Aastra muss du dies auch beim Telefon eintragen.
Dann geht's wieder ohne Probleme.
Grüße
Bernhard
@goscho
Rein Interesse halber und OT... Waren diese Einstellungen auf das DECT Profil bezogen oder direkt auf VoIP ?
Wenn letzteres, weisst du zufällig was das war ? RTP Parameter ?
Rein Interesse halber und OT... Waren diese Einstellungen auf das DECT Profil bezogen oder direkt auf VoIP ?
Wenn letzteres, weisst du zufällig was das war ? RTP Parameter ?
Zitat von @aqui:
@goscho
Rein Interesse halber und OT... Waren diese Einstellungen auf das DECT Profil bezogen oder direkt auf VoIP ?
Das waren VOIP-Probleme. Regelmäßig brachen die Gespräche ab (Zeiten waren unterschiedlich) und alle DECT-Geräte dieser Basis meldeten sich ab und gleich wieder neu an.@goscho
Rein Interesse halber und OT... Waren diese Einstellungen auf das DECT Profil bezogen oder direkt auf VoIP ?
Wenn letzteres, weisst du zufällig was das war ?
Ja, mit dem Patch von Gigaset wurde ein auf den Basen hinterlegter STUN-Server deaktiviert, der wohl für das regelmäßige De-Registrar verantwortlich war.Seither keine Abbrüche mehr.
RTP Parameter ?
Kann dir keine Parameter geben, dies ist nicht manuell konfigurierbar.
Na ja STUN Server sollte man ja auch imemr selber einstellen können im Steup wenn man will. 
Danke fürs Feedback !
Danke fürs Feedback !
Zitat von @aqui:
Na ja STUN Server sollte man ja auch imemr selber einstellen können im Steup wenn man will.
Genau, aber wollte und habe ich nicht, trotzdem scheint einer hinterlegt gewesen zu sein.Na ja STUN Server sollte man ja auch imemr selber einstellen können im Steup wenn man will.
Den Fehler hatte ich bei verschiedenen Serien der Gigaset-IP-Basen.
Danke fürs Feedback !
Gerne doch. 
Hallo,
erstmal generell vielen Dank für die vielen Antworten!
Der Codec war im Telefon (Siemens Optipoint) auf G.729 eingestellt. Ich habe ihn jetzt mal auf G.723 geändert und werde es einmal testen.
@goscho: mit DECT arbeite ich (in dem Fall) gar nicht, deshalb kommt diese Fehlerquelle nicht in Betracht. Trotzdem vielen Dank für deine Hilfe!
@aqui:
Okay, am QoS arbeite ich noch, das wurde bisher auf meiner Sonicwall noch gar nicht konfiguriert / benötigt.
NAT wird im Tunnel nicht gemacht und auch an geblockten Ports kann es nicht liegen.
Ich werde das QoS mal einstellen und dann weiter testen.
Grüße
Clemens
erstmal generell vielen Dank für die vielen Antworten!
Der Codec war im Telefon (Siemens Optipoint) auf G.729 eingestellt. Ich habe ihn jetzt mal auf G.723 geändert und werde es einmal testen.
@goscho: mit DECT arbeite ich (in dem Fall) gar nicht, deshalb kommt diese Fehlerquelle nicht in Betracht. Trotzdem vielen Dank für deine Hilfe!
@aqui:
Okay, am QoS arbeite ich noch, das wurde bisher auf meiner Sonicwall noch gar nicht konfiguriert / benötigt.
NAT wird im Tunnel nicht gemacht und auch an geblockten Ports kann es nicht liegen.
Ich werde das QoS mal einstellen und dann weiter testen.
Grüße
Clemens
Zitat von @clemens-der-vierte:
@goscho: mit DECT arbeite ich (in dem Fall) gar nicht, deshalb kommt diese Fehlerquelle nicht in Betracht. Trotzdem vielen Dank für deine Hilfe!
Das war kein DECT-, sondern ein VOIP-Problem. Es handelte sich nur um DECT-IP-Telefone.@goscho: mit DECT arbeite ich (in dem Fall) gar nicht, deshalb kommt diese Fehlerquelle nicht in Betracht. Trotzdem vielen Dank für deine Hilfe!
Stand auch so explizit im Text. Tja wer lesen kann....
Hallo,
es scheint jetzt so als wäre das Problem gelöst - zumindest tritt es seit ein paar Tagen nicht mehr auf.
Folgendes habe ich getan:
Änderung des Codecs von G.729 zu G.723
Ich hoffe das es wirklich damit gelöst ist.
Vielen Dank an alle Helfer!
Gruß Clemens
es scheint jetzt so als wäre das Problem gelöst - zumindest tritt es seit ein paar Tagen nicht mehr auf.
Folgendes habe ich getan:
Änderung des Codecs von G.729 zu G.723
Ich hoffe das es wirklich damit gelöst ist.
Vielen Dank an alle Helfer!
Gruß Clemens
Eigentlich Blödsinn, denn das reduziert die Bandbreite lediglich um popelige 2 kBit/s (Kilobit !)
http://www.elektronik-kompendium.de/sites/net/0905121.htm
Zudem nimmt man eine geringere Sprachqualität in Kauf.
Das kann nicht wirklich der Grund gewesen sein, aber egal....
http://www.elektronik-kompendium.de/sites/net/0905121.htm
Zudem nimmt man eine geringere Sprachqualität in Kauf.
Das kann nicht wirklich der Grund gewesen sein, aber egal....
Hallo aqui,
du hast vollkommen recht.
Die Lösung war auch nur von kurzzeitiger Dauer... Seit einigen Tagen ist der alten Zustand wieder da.
du hast vollkommen recht.
Die Lösung war auch nur von kurzzeitiger Dauer... Seit einigen Tagen ist der alten Zustand wieder da.
Das war zu erwarten !
Du solltest dringenst was am QoS Setting machen ! Priorisiere den Voice Traffic zwingend in allen deinen Switch und Router Komponenten, dann hört das auch sofort auf !
Wie ist den dein Voice Traffic überhaupt auf der Anlage und den Telefonen priorisiert ? Mit 802.1p CoS oder mit DSCP ToS ?
Und vor allen Dingen mit welchen Settings ?
Du solltest dringenst was am QoS Setting machen ! Priorisiere den Voice Traffic zwingend in allen deinen Switch und Router Komponenten, dann hört das auch sofort auf !
Wie ist den dein Voice Traffic überhaupt auf der Anlage und den Telefonen priorisiert ? Mit 802.1p CoS oder mit DSCP ToS ?
Und vor allen Dingen mit welchen Settings ?
Schon mal ein tcpdump gemacht, um zu sehen, ob die Pakete auch wirklich durch den Tunnel gehen?
Ach und noch was habe ich gerade schmerzlich lernen müssen: Wenn Du einen SIP-Proxy verwendest, schalte den mal testweise ab.
Ach und noch was habe ich gerade schmerzlich lernen müssen: Wenn Du einen SIP-Proxy verwendest, schalte den mal testweise ab.
es geht nicht um die Bandbreite sondern um die Kodierung !
Es sollte geprüft werden ob sich die Parteien über den Austausch eines anderen Codecs genau so schwer tun.
Nicht die Bandbreite ist das Problem sondern die Kompatibilität der Endgeräte.
Ich denke jede Messung der Bandbreite wird ein Ergebnis über 64 KB bringen ! Somit liegt das Problem
an dem Codec NICHT am Netzwerkverlust.
Relevant wären die Firmware zu kontrollieren und bei Hersteller abzugleichen. Eventuell gibt es hier Probleme
mit den verschiedenen Ständen .
Es sollte geprüft werden ob sich die Parteien über den Austausch eines anderen Codecs genau so schwer tun.
Nicht die Bandbreite ist das Problem sondern die Kompatibilität der Endgeräte.
Ich denke jede Messung der Bandbreite wird ein Ergebnis über 64 KB bringen ! Somit liegt das Problem
an dem Codec NICHT am Netzwerkverlust.
Relevant wären die Firmware zu kontrollieren und bei Hersteller abzugleichen. Eventuell gibt es hier Probleme
mit den verschiedenen Ständen .
es geht nicht um die Bandbreite sondern um die Kodierung !
Um die Kodierung ?? Wohl auch nicht wirklich. Es geht einzig um eine saubere Prioritätensteuerung....!Oder was genau meinst du mit "Kodierung" ?
Wenn deine Endgeräte das Aushandeln der Codecs schon nicht verstehen hast du ein grundsätzliches Problem. Das wär so als wenn man am Auto die Reifen vergisst.
Das deine Endgeräte da die neueste und aktuellste Firmware haben sollten, sollte selbstverständlich sein.
Somit liegt das Problem an dem Codec NICHT am Netzwerkverlust.
So so.... Wie rechtfertigst du das denn ??Du hast also Einfluss auf die Bandbreitensteuerung aller Providernetze und auch deines internen Netzes indem du garantieren kannst das immer genügend Bandbreite vorhanden ist ??
Wohl eher nicht, denn sollte im Provider Backbone oder der letzten Meile bzw. deines eigenen Netzes einmal ein kurzzeitiger Engpass sein schmeissen diese Komponenten auf die du keinerlei Einfluss hast deine VPN Pakete und damit auch deinen Voice Pakete einfach weg !
Verhindern kannst du das nicht ohne eine vernünftige QoS Steuerung die bei VoIP eingentlich zwingend ist, du aber laut eigener Aussage oben gar nicht hast.
Insofern ist deine letzte Aussage eher laienhaft naiv.
Das Statement mit den Firmware Release ist daher umso wichtiger....siehe oben !
