SF und SIP Transformation bei einer Starface in der Cloud

  • Virtuelle Starface in der Cloud (Angebot von Starface GmbH) <---> Firewall <---> eine Menge Telefone


    Was genau möchte die Starface Anlage im Bereicht SIP Transformation von mir?


    17-03-_2018_23-56-58.jpgBildquelle: Studerus KDB Eintrag zum Thema SIP


    Wäre die Starface als Appliance bei mir im LAN, dann wäre die Antwort klar. SIP-Transformation nicht aktiv! Das ist was die meisten (wenn nicht alle) Provider empfehlen. Schliesslich sind sie wohl alle mit einem SBC ausgerüstet.
    Dies ist übrigens auch immer der Fall welcher in den Hilfedateien besprochen wird. Dort steht dann immer kategorisch: Ausschalten...



    Aber mit einer virtuellen Starface im Internet und den Telefonen im LAN, ist die Situation anders.


    Es stellt sich also die Frage, soll ich SIP-Transformations in diesem Fall generell einschalten oder ausschalten?



    Daniel





    Ich habe absichtlich nicht die "übliche" Abkürzung gewählt weil die automatische Antwort dann immer lautet "ausschalten" ohne dass der Rest gelesen wird.
    Zur Erklärung ein Ausschnitt aus dem sehr informativen Studeruns KDB Eintrag, welcher ebenfalls nur den Providerfall berücksichtigt:
    "Empfiehlt der Provider den SIP-ALG zu deaktivieren, bezieht sich diese Vorgabe ausschliesslich auf die Option zur Übersetzung der IP-Adresse im PaketHeader (→ SIP Transformation). "



    Es funktioniert übrigens in beiden Fällen.

  • Wo hat die STARFACE denn einen Bereich "SIP Transformation"?
    Meinst Du die Einstellung "Hinter NAT"?


    Beides hat aber nichts damit zu tun, ob SBCs eingesetzt werden oder nicht.


    Dein Bild zeigt einmal eine private IP-Adresse im Via- und Contact-Header und einmal eine Öffentliche.
    Das ist genau das, was die Einstellung "Hinter NAT" in der STARFACE macht: Sie ersetzt eine meist private IPv4-Adresse durch eine angegebene IP-Adresse (in der Regel eine öffentlich erreichbare Adresse) im SIP-Header, damit der Gegenüber weiß, wohin die Antwortpakete gehen sollen.


    Im letzten Abschnitt schreibst Du noch etwas von SIP-ALG. Ein Anwendungsfall von SIP-ALG kann sein, zwischen STARFACE und Peer unter anderem genau diese SIP-Header-Anpassungen vorzunehmen.
    Da die korrekten Einstellungen von verschiedenen Faktoren abhängen (wird einfaches NAT gemacht oder gibt es explizite Port-Forwardings? Werden Verbindungen zwischen TK-System und Peer oder zwischen Peer und Endgerät unterstützt und ausgehandelt? Gibt es unter Umständen mehrere Interfaces am TK-System? Gibt es weitere NAT-Router? Soll Transportverschlüsselung eingesetzt werden?), machen SIP-ALGs selten alles richtig und sorgen eher für Probleme, weshalb die allgemeine Empfehlung lautet, sie abzuschalten.
    Stattdessen verwendet man lieber die Option "Hinter NAT" "Ja/Nein" und richtet bei "Ja" und korrekt angegebener externer IP-Adresse Port-Forwardings ein.


    Aber es ist im Grunde immer das selbe, wenn jemand weiß, was sein SIP-ALG macht und diesen korrekt konfiguriert, kann man auch damit nützliche Dinge tun und SIP-Header darüberhinaus manipulieren (Rufnummern, CallerID-Presentation, uvm.). Leider sind die Tools, die gängige Firewalls standardmäßig bereitstellen ziemlich kastriert, können kaum anständig konfiguriert werden und treffen eben irgendwelche Annahmen, die stimmen können, aber nicht müssen.

  • Hallo Fabian,


    Danke für deine Erklärung.
    Ich denke ich war wieder mal nicht genau genug mit meiner Frage. Ich versuche es noch einmal.



    • Mir geht es NUR und ausschliesslich um die Einstellungen des Firewalls auf der Seite des Kunden.
    • Im LAN des Kunden befinden sich NUR Telefone.
    • Die Starface Anlage ist jene vom Cloud Angebot von Starface. Sie befindet sich also irgendwo im Internet.
    • Es geht mir ausschliesslich um die Verbindungen zwischen den vielen Telefonen im LAN des Kunden, und der Starface im Internet



    Diese Situation ist anders als allgemein verstanden wird. Ohne bis ans Ende zuzuhören wird dann einfach gesagt dass SIP ALG abgeschaltet werden muss (aus diesem Grund habe ich "SIP ALG" in meinem Artikel bewusst nicht bis zum Schluss erwähnt).
    Das Abschalten von SIP ALG ist meiner Meinung nach in der von mir beschriebenen Situation nicht unbedingt richtig. Ich möchte einfach eine Bestätigung dass das was ich einstelle entweder komplett falsch ist, oder richtig.


    Jeder Starface Knowledgebase Artikel und fast jeder Beitrag im Forum zum Thema Firewall geht von einer anderen Situation aus. Nämlich dass eine Starface Appliance im gleichen LAN wie die Telefone steht und sie nur mit dem Provider über den Firewall spricht (ich lasse mal externe mobile Clients für den Moment weg).
    So wie ich die Einstellung "Hinter NAT" bei der Starface bisher verstanden habe ist sie nur relevant wenn ich sie als Appliance im lokalen LAN des Kunden platziert habe. In der Einstellung "Ja" würde die Starface den SIP Header entsprechend umschreiben, wie du das erklärt hast. Das würde dann aber auch bedingen dass ein richtiges Port Forwarding konfiguriert ist.


    Ich gehe jetzt aber von diesem "klassischen" Fall wieder weg und wende mich meiner Situation zu: Viele Telefone im LAN, getrennt von der Starface im Internet durch eine Firewall. Hier sieht es anders aus.


    Port Forwarding steht hier nicht zur Debatte. 20 SIP Endpunkte würde 20 Portforwards bedeuten. Funktioniert so nicht.



    (Wenn ich jetzt irgendwas falsches schreibe, dann bitte ich um Korrektur. Danke.)


    Es gibt im Wesentlichen zwei Möglichkeiten den Firewall zwischen den Telefonen im LAN und der Starface im Internet zu betreiben (vereinfachte Darstellung):

    • UDP Session Timeout
    • SIP ALG


    (Ich wiederhole: Telefone und Starface NICHT im gleichen LAN. Telefone im LAN <----> Firewall <----> Starface im Internet)


    1 - UDP Session Timeout:

    • Das Telefon registriert sich bei der Starface. Dabei wird auf dem Firewall eine UDP Session erstellt und offen gelassen.
    • Nach einem bei den meisten Firewalls einstellbaren Timeout wird diese UDP Session geschlossen, es sei denn es läuft Verkehr über diese Session.
    • Das Telefon (z.B. T46) sendet dazu ein NAT Keep-Alive alle 30 Sekunden (kann eingestellt werden, aber 30 Sekunden sind beim T46 der Default)
    • Die Starface ihrerseits sendet auch ein SIP OPTIONS request, alle 60 Sekunden (wo das eingestellt werden kann ist mir unbekannt), welcher über die immer noch offene UDP Session an das richtige Telefon weitergereicht wird.
    • Mit diesem gemeinsamen Effort sollte die UDP Session eigentlich immer offen bleiben
    • Der SIP Header wird in diesem Fall nicht angetastet. Im SIP Header steht also eine andere IP Adresse als im UDP Packet. Die Starface kommt aber damit zurecht.


    Je nach Firewalltyp (1) funktioniert diese Methode recht gut.


    Vorteil: Der default UDP Session Timeout reicht bei den allermeisten Fällen aus. Das bedeutet dass am Firewall absolut nichts eingestellt werden müsste. Diese Methode eignet sich vorzüglich für ein Telefon im Homeoffice.
    Nachteil: Befinden sich am betreffenden Standort mehr als ein bis zwei Telefone, ist der Firewall oft überfordert. Die entsprechenden UDP Sessions werden nicht offen gehalten. Als Resultat sind nur die Telefone von der Starface erreichbar, welche sich zuletzt re-registriert haben. Mit der Erhöhung des UDP Session Timeouts kann dieses Problem nur begrenzt behoben werden. Auch die Anpassung des NAT Keep-Alive hilft eher selten. Ich nehme an dass die Anzahl der offenen UDP Sessions begrenzt ist.


    (1) Viele heutige Firewalls haben immer weniger Probleme mit dieser Methode. Es kann gut sein dass es Consumer Firewalls gibt welche mehrere UDP SIP Sessions problemlos verwalten können. Meine Erfahrung in der Schweiz zeigt dass kleinere KMU zu oft einen Consumer Internetanschluss für ihre Firma benutzen. Der erste Schritt hier ist zu einem anständigen Business Internet Anschluss zu migrieren.



    2 - SIP ALG
    Im Wesentlichen von der Idee her identisch mit den offenen UDP Sessions. Allerdings wird der SIP Verkehr erkannt und eine "spezielle" UDP Session offen gehalten.
    Ich beziehe mich hier auf meine Erfahrungen mit Zyxel USG Firewalls (bitte keinen Religionskrieg...)


    • Das Telefon registriert sich bei der Starface. Dabei wird auf dem Firewall eine SIP Session erstellt und offen gelassen.
    • Nach einem einstellbaren Timeout wird diese SIP Session geschlossen, es sei denn es läuft Verkehr über diese Session.
    • Das Telefon sendet weiterhin ein NAT Keep-Alive alle 30 Sekunden. Dies wird aber soweit ich weiss in diesem Fall nicht beachtet, weil NAT hier absolut keine Rolle spielt.
    • Die Starface ihrerseits sendet alle 60 Sekunden einen SIP OPTIONS request, welcher über die offene SIP Session an das richtige Telefon weitergereicht wird.
    • Bei (Zyxel) SIP ALG kann der entsprechende "SIP Signaling Inactivity Timeout" nur für SIP eingestellt werden. Zusätzlich gibts einen "SIP Media Inactivity Timeout" welcher auch eigestellt werden kann.
    • Die Firewall kann auch eine SIP-Transformation durchführen (2).


    (2) Wenn SIP-Transformation eingeschaltet, wird die SIP-Client-IP Adresse der WAN Adresse angeglichen. Wenn SIP-Transformation ausgeschaltet, dann wird die SIP-Client-IP innerhalb des SIP Headers nicht angerührt.


    18-03-_2018_12-28-12.jpg



    Mit diesen Grundlagen wiederhole ich meine Frage:


    Die Starface in der Cloud kommt mit SIP-Transformation ON und SIP-Transformation OFF auf dem Firewall vor den Telefonen gleichermassen zurecht.


    Aber was ist die Präferenz der Starface für diese Firewall Einstellung in dieser Situation?



    Daniel




    Zur Erklärung warum ich diese grundlegenden Fragen stelle, siehe ein anderer Artikel: Internet Backup Leitung, Starface in der Cloud, https://support.starface.de/fo…6112&viewfull=1#post36112

    Edited once, last by DanielH ().

  • Ok, ich verstehe...


    Der von dir genannte "Nachteil" in Bezug auf UDP-Session-Tracking, ist so jedoch nicht ganz richtig.
    Firewalls oder NAT-Router sind in der Regel nicht aufgrund mehrerer Endgeräte überfordert. Für jede Verbindung wird ein individueller Port am NAT-Router ausgewählt, damit ist das maskierte Gerät bestimmbar.


    Die eigentlichen Probleme sind a) das korrekte Zuordnen einzelner UDP-Pakete zu einer aktiven Session in der Stateful Firewall, da UDP zustandsfrei ist und b) das Aufrechterhalten der UDP-Port-Mappings zu einer Session.
    Es ist bei UDP im Gegensatz zu TCP nicht erkennbar, wann eine Verbindung beendet wurde. Das löst man, indem die Firewall und der NAT-Router die Session verwirft, wenn nicht regelmäßig Pakete erkannt werden, die augenscheinlich zur Session gehören.
    Die Anzahl der Sessions, die die Firewall tracken kann, ist eher selten das Problem. Das wäre trivial dadurch zu lösen, indem einfach nur die ältesten Sessions gelöscht werden, wenn eine neue Session angelegt wird. Dadurch würde sich also nicht erklären, warum Sessions nach definierten Zeiten abgebaut werden.


    Im Szenario "STARFACE Cloud" wäre das Einfachste, eine TLS-verschlüsselte Verbindung mit den Endgeräten herzustellen -- die ist TCP-basiert und läßt sich zuverlässig tracken.
    Darum funktioniert der Mobile Client auch so zuverlässig in den verschiedensten Szenarien.


    Wenn man bei UDP bleiben möchte, muß man entweder dafür sorgen, dass der Session-Timeout der Firewall und das UDP-Port-Mapping des NAT-Routers lang genug ist um die Verbindung nicht vorzeitig zu beenden oder man sorgt dafür, dass UDP-Pakete in regelmäßigen Abständen versendet werden, um die Sessions "offen" zu halten (siehe qualify-Option).


    Üblicherweise liegen UDP-Session-Timer zwischen 15 Sekunden und einer Minute. Bei TCP kann die Session auch leicht mal eine Stunde offen bleiben, ohne dass Pakete durchgehen.


    SIP-ALGs ändern an dem oben genannten erstmal gar nichts und sind deshalb auch nicht die Lösung für dieses Problem. Es läßt sich dadurch weder leichter tracken noch stünden plötzlich mehr Ressourcen für Session-Tracking zur Verfügung. Die Anwendungsfälle sind andere... hauptsächlich geht es darum, allgemeine Probleme von SIP und NAT zu lösen.


    Um nochmal deinen Fall mit der STARFACE Cloud aufzugreifen:
    Das SIP-ALG hilft hier gar nichts, da die STARFACE (oder genauer der Asterisk) ebenfalls, wie die meisten Provider, einfach eine Fallunterscheidung macht:

    • Steht in der Contact URI eine private Adresse, werden IP und Portangabe aus dem IP- und UDP-Header verwendet. Die hat der NAT-Router geändert und kann die dortige UDP-Portangabe einer Sitzung zuordnen.
    • Steht in der Contact URI eine öffentliche Adresse, werden IP und Portangabe aus dem SIP-Header verwendet.


    Im Detail hängt es noch von den NAT-Traversal-Einstellungen des Clients und des Asterisks ab (nat=yes/no in sip.conf), aber das geht zu weit...
    Wenn es dich trotzdem interessiert, findest Du eine ausführliche Erklärung unter https://www.voip-info.org/wiki/view/Asterisk+sip+nat


    Das obige Verhalten funktioniert relativ zuverlässig in den meisten Fällen. Probleme gibt es dann, wenn die ALGs ins Spiel kommen und meinen Dinge zu "verbessern", denn dann stimmen die obigen Annahmen nicht mehr zwingend und Pakete werden unter Umständen an Ports zurückgesendet, die gar nicht mehr auf das richtige Endgerät forwarden.

  • Hallo Fabian,
    Vielen Dank für die Erklärungen.


    Ok, ich verstehe...
    Der von dir genannte "Nachteil" in Bezug auf UDP-Session-Tracking, ist so jedoch nicht ganz richtig.
    Firewalls oder NAT-Router sind in der Regel nicht aufgrund mehrerer Endgeräte überfordert. Für jede Verbindung wird ein individueller Port am NAT-Router ausgewählt, damit ist das maskierte Gerät bestimmbar.


    Meine Erfahrung ist es dass die gängigen Firewall/Router hier in der Schweiz Probleme machen, sobald mehr als 2-3 Telefone im lokalen LAN im Spiel sind. Bitte beachten dass wir im klein-KMU Bereich tätig sind. Da kann es passieren dass ein Kunde einen Consumer Internetanschluss hat. Beispielsweise geht der grösste Anbieter in der Schweiz (Swisscom) dann davon aus dass ihr Router auch die VOIP Funktion übernimmt was zu allerlei lustigen Problemen führen kann. Deshalb ist der erste Schritt einen vernünftigen Internet Anschluss zu erstellen.



    Im Szenario "STARFACE Cloud" wäre das Einfachste, eine TLS-verschlüsselte Verbindung mit den Endgeräten herzustellen -- die ist TCP-basiert und läßt sich zuverlässig tracken. Darum funktioniert der Mobile Client auch so zuverlässig in den verschiedensten Szenarien.


    Wie kann ich das als Starface Cloud Admin einstellen? Ich habe keinen ssh Zugang und im Admin GUI habe ich bisher nichts in diese Richtung gesehen. Wäre natürlich toll wenn das konfigurierbar wäre.



    Wenn man bei UDP bleiben möchte, muß man entweder dafür sorgen, dass der Session-Timeout der Firewall und das UDP-Port-Mapping des NAT-Routers lang genug ist um die Verbindung nicht vorzeitig zu beenden oder man sorgt dafür, dass UDP-Pakete in regelmäßigen Abständen versendet werden, um die Sessions "offen" zu halten (siehe qualify-Option).


    Üblicherweise liegen UDP-Session-Timer zwischen 15 Sekunden und einer Minute. Bei TCP kann die Session auch leicht mal eine Stunde offen bleiben, ohne dass Pakete durchgehen.


    SIP-ALGs ändern an dem oben genannten erstmal gar nichts und sind deshalb auch nicht die Lösung für dieses Problem. Es läßt sich dadurch weder leichter tracken noch stünden plötzlich mehr Ressourcen für Session-Tracking zur Verfügung. Die Anwendungsfälle sind andere... hauptsächlich geht es darum, allgemeine Probleme von SIP und NAT zu lösen.


    Die Cloud Starface wendet soweit ich aus dem Artikel schliessen kann den du angegeben hast die qualify=yes option an. Sonst würde ich nicht alle 60 Sekunden die SIP OPTIONS message sehen.
    Dass SIP ALG nichts ändert sehe ich anders. SIP ALG in der Zyxel Implementation ändert sehr wohl etwas, weil ich spezifisch für SIP/UDP die Timeout Werte setzen kann. Bei Zyxel heisst SIP ALG übrigens nicht automatisch auch SIP Transformation.



    SIP ALG in der Zyxel Implementation ist nicht identisch mit SIP-Transformation. Vielleicht sollte Zyxel dies umbenennen damit nicht Verwirrung herrscht.


    Ich versuchs mal:

    • Zyxel SIP ALG (aus) = normaler UDP Session timeout kommt zum tragen, SIP wird nicht speziell beachtet
    • Zyxel SIP ALG (ein) = Anpassung der SIP/UDP Session Timeouts, also im Wesentlichen identisch mit dem üblichen UDP Session Timeout mit dem Unterschied dass SIP separat eingestellt werden kann.
    • Zyxel SIP-Transformation (ein) = SIP ALG (ein) im üblichen Sprachgebrauch, also das Umschreiben der SIP Header Informationen
    • Zyxel SIP-Transformation (aus) = SIP ALG (aus) im üblichen Sprachgebrauch, also kein Umschreiben der SIP Header Informationen



    Trotzdem hast du mir schon eine gute Antwort gegeben. Es scheint mir dass es der Starface (Asterisk) lieber ist wenn SIP-Transformation ausgeschaltet ist.


    Wahrscheinlich ergeben sich die Unklarheiten rein aus der Abkürzung SIP ALG die für diverse Hersteller nicht unbedingt genau das gleiche bedeuten.


    Danke


    Daniel

  • Hallo Daniel


    Es gibt auch hier in der Schweiz ein Cloud-Angebot für die STARFACE von der mobile4business.


    Vielleicht sprichst Du mal mit denen.


    Eventuell wäre statt der Nutzung der Cloud-Variante auch eine STARFACE in einem virtuellen Rechenzentrum eine Möglichkeit, wo Du dann die Kontrolle über die Anlagen hättest ?

    Gruss
    Thomas


    hertli ¦ IT
    hertli Informatik+Treuhand


    eMail: mail ( a t ) hertli.ch
    Internet: www.hertli.ch


    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security

  • Quote

    Eventuell wäre statt der Nutzung der Cloud-Variante auch eine STARFACE in einem virtuellen Rechenzentrum eine Möglichkeit, wo Du dann die Kontrolle über die Anlagen hättest ?


    Thomas: sehe ich auch so - damit hat man automatisch die komplette Kontrolle über die Anlage (und was davor passiert) ... und das funktioniert auch sehr gut. :)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!