Vodafone IP SIP-Trunk am COMmander Basic.2

[Toni76]

Eigentlich dachte ich, haben wird das "normalste" und einfachste Setup, das ich mir vorstellen kann. Wir haben bei Vodafone einen Business-IP-Anlagenanschluss bestellt, ohne irgendwelche Besonderheiten oder Sonderwünsche. Dieser Anschlusstyp müsste theoretisch schon zig-tausendfach im Umlauf sein. Das ganze Paket von Vodafone besteht aus einem ganz normalen VDSL-Internetanschluss mit einer FRITZ!Box zzgl. einer festen IPv4, die Vodafone wegen der Telefonie standardmäßig dazupackt (vgl. Infos bei meiner Anlagenkonfiguration oben). Darüber kommt man natürlich genauso ins Internet wie mit einer dynamischen IP (die man wahlweise sogar aktivieren könnte). Dazu kommt softwareseitig und prinzipiell unabhängig von diesem Internetzugang noch der VoIP-Dienst von Vodafone, also der Telefonietarif. Dafür schickt Vodafone die besagten Zugangsdaten, die eigentlich nur aus SIP-Domain, SBC-IP, Benutzername und Telefonnummer bestehen und auf Kundenseite besagte feste IP erwarten (PBX-IP). Wo der SBC sitzt - keine Ahnung, sehr wahrscheinlich irgendwo bei Vodafone. Jedenfalls laufen alle ein- und ausgehenden Verbindungen darüber.

Ich komme vom Internet schon auf die öffentliche IP. Ich hatte dazu nur geschrieben, dass ich es nicht geschafft hatte, dabei auch eine Verbindung auf Port 5060 aufzubauen, das aber nicht intensiver untersucht oder getestet habe. Es ist durchaus möglich, dass der Port trotzdem von überall erreichbar ist. Wie ich auch schon erwähnt habe, wäre es aber kein Problem, sicherheitshalber lokal noch eine Firewall dazwischenzuschalten, die alle Pakete auf 5060 blockiert, die nicht direkt vom SBC kommen. Falls damit dann alle das Port-Forwarding ok finden, mache ich das natürlich...

 

[4Halix]

Jedenfalls löst der STUN-Server anscheinend auch nicht das Problem, wie man ohne Port-Forwarding von außen reinrufen kann. Es lässt sich dafür bei Vodafone keine funktionierende Registrierung aktivieren, die irgendwas mit den STUN-Infos anfangen könnte. Evtl. habe ich SIP dafür noch nicht weit genug durchblickt, aber ich denke, dass ich es zumindest soweit verstanden habe.

Dazu folgendes: Wenn du überhaupt telefonieren kannst, dann ist die Anlage bereits angemeldet beim Provider. Für sie macht es jetzt keinen Sinn mehr, SIP Ports eingehend zu öffnen. Auch deine aktuelle IP ist dem Provider dann schon bekannt, sodass in beide Richtungen eine Kommunikation rein technisch möglich ist.

Du meinst vermutlich, dass eingehend kein Ton kam? Das würde dann ein Öffnen der RTP Ports nach sich ziehen, bzw. ein Forward zur TK. Diese Ports sind spezifisch und werden vom Provider oder den Endgeräten vorgegeben, im Zweifel eher mehr freigeben. Es sind ohnehin high-level Ports.

Wenn eingehend keine Rufsignalisierung kommt, dann ist wirklich was faul, sollte aber ebenfalls nicht mit Öffnung der SIP Ports behoben werden können.

Wenn Lust und Zeit besteht, kann man in Toni's Fall sicher eine Alternative finden zur aktuellen und mMn etwas unsicheren Variante.

Wie bereits erwähnt, will ich aber nichts pauschal madig reden. Und Eigenheiten hat man bei vielen Providern und Hardware.

 

[Toni76]

Wenn du überhaupt telefonieren kannst, dann ist die Anlage bereits angemeldet beim Provider.

Vodafone benötigt keine Registrierung und erlaubt auch keine (vgl. vorangehende Posts). Auch in der Schnittstellenbeschreibung wird eine Registrierung mit keinem Wort erwähnt.

Für sie macht es jetzt keinen Sinn mehr, SIP Ports eingehend zu öffnen.

Ohne einen offenen Port oder ein anderes, in der Schnittstellenbeschreibung aufgelistetes Verfahren ist kein Zugriff von außen auf die Anlage möglich.

Auch deine aktuelle IP ist dem Provider dann schon bekannt, sodass in beide Richtungen eine Kommunikation rein technisch möglich ist.

Ist sie natürlich, denn Grundvoraussetzung für diesen Anschluss ist eine feste IP (vgl. vorangehende Posts). Die ausgehende Kommunikation ist mit NAT-Traversal ohne Port-Forwarding möglich (vgl. vorangehende Posts).

Du meinst vermutlich, dass eingehend kein Ton kam?

Nein, der Verbindungsaufbau ist nicht möglich, Timeout nach ca. 20s.

Das würde dann ein Öffnen der RTP Ports nach sich ziehen, bzw. ein Forward zur TK.

In der funktionierenden Konfiguration sind die RTP-Ports zur Anlage geforwarded (vgl. vorangehende Posts).

Diese Ports sind spezifisch und werden vom Provider oder den Endgeräten vorgegeben, im Zweifel eher mehr freigeben.

Es gibt dazu keine Zweifel, die Ports sind genau vorgegeben und es funktioniert bei Einhaltung der Vorgaben (vgl. vorangehende Posts).

Wenn eingehend keine Rufsignalisierung kommt, dann ist wirklich was faul, sollte aber ebenfalls nicht mit Öffnung der SIP Ports behoben werden können.

Vgl. Abs. 2.

Vielleicht ergänzend noch ein Hinweis, der nicht zur Beseitigung des Port-Forwardings beiträgt, aber evtl. zum Verständnis, wieso Port-Forwarding. Auszug aus der Dokumentation des COMmander Basic.2:

Ist der Registrar ausgeschaltet, findet kein NAT-Keep-Alive statt.
Daher kann eine Portweiterleitung für eingehende SIP-Pakete im Router auf den in der Konfiguration des VoIP-Anbieters eingerichteten SIP-Port nötig werden.

Wie mittlerweile mehrfach erwähnt, ist die Registrierung bei Vodafone nicht nötig, genaugenommen unmöglich, daher ist in der Anlagenkonfiguration der Registrar zwingend ausgeschaltet. Mit dem im zweiten Satz erwähnten "VoIP-Anbieter" wird die anlageninterne VoIP-Schnittstellenkonfiguration für die externe Schnittstelle bezeichnet.
Dass in dieser Konstellation kein NAT-Keep-Alive stattfindet, ist evtl. eine Eigenheit der Anlage. Allerdings würde das laut Schnittstellenbeschreibung vermutlich nichts helfen, denn wenn dann würden als mögliche Variante OPTION pings erwartet, was in der Anlage nach meinem Kenntnisstand aber nicht implementiert ist.

 

[4Halix]

Puh wirklich ein (aus meiner Sicht) Sonderfall.

Daher ja bereits die Einschübe, dass ich nur aus meiner Sicht spreche.

Man lernt offensichtlich nie aus, vor allem nicht bei VoIP -.-

 

[sonyKatze]

Das wiederum hatte nur den Hintergrund, dass Port-Forwarding nicht pauschal negativ zu bewerten ist. Dazu, ob es bei SIP oder einem anderen spezifischem Dienst XY ein mehr oder weniger üblicher Lösungsweg …

Drei Leute erklären es Dir … bei SIP ist Port-Forwarding nicht nur pauschal negativ zu bewerten, sondern unter allen Umständen zu vermeiden. Nutzt Du es trotzdem, hast Du keine Lösung sondern einen Workaround. Auch ist SIP kein „Dienst“ in dem Sinne, wie Du das von anderen Internet-Diensten kennst, die sich an die ISO/OSI-Architektur halten. Auch das Vertrauen-Thema ist völlig egal, denn das Produkt erhält keine Sicherheits-Updates mehr, ist also Null. Die Logik ist anders herum: Für VoIP/SIP brauchst Du kein Port-Forwarding. Entsprechend ist es zu vermeiden.

einen funktionierenden Angriffsvektor suchen und finden

Viele der Fehler auf SIP- und SDP-Ebene sind erstaunlich generisch. Oder anders formuliert: Genau das machen die SIP-Scanner den ganzen Tag. Sie suchen Einfallstore und tauschen bzw. handeln Schwachstellen. Ganz einfache Risiko-Abschätzung …

OPTION Pings über UDP oder TCP […] habe ich mit der vorhandenen Hardware nicht funktionierend konfiguriert bekommen

Dann schreibt man das. Und dass man den Hersteller angeschrieben hat. Und dass man deswegen auf Port-Forwarding ausgewichen ist. Dann weiß ein Leser, dass hier noch was im Argen ist. Das versuchte Dir 4Halix zu erklären. Tut mir Leid, wir können Deine Risiko-Abschätzung nicht teilen. Du kannst es gerne trotzdem so machen. Aber wenn wir sehen, dass nicht verstanden, dann wird erklärt. Abgesehen von dem Einfallstor noch ein anderes Problem: Die Netzbetreiber stellen immer weiter auf IMS um. Das hat zur Folge, dass man direkt mit der Gegenstelle – also dem Handy und so weiter – quasselt. Das hat zur Folge, dass das SIP und SDP entsprechend stabil sein sollte. Oder anders formuliert, man sollte nur von Vodafone getestete Produkte an solch einem Anschluss verwenden. Daher die Tipps eine Übergangsbox wie eine FRITZ!Box oder eine bintec-elmeg be.IP plus dazwischen zu schalten.

Bei diesem speziellen Vodafone-Anschluss schickt Vodafone von sich aus SIP-OPTIONS. Hast Du das abschalten lassen? Problematisch ist, dass Du bei einer FRITZ!Box als Firewall nicht so einfach Quell-IPs definieren kannst. Daher müsste die Anlage sich anfänglich kurz mit dieser IP/Port zeigen – auch wenn das fehlschlägt, damit Vodafone nachher mit seinen SIP-OPTIONS durchkommt.