[Problem] SIP-Server nicht in der be.ip+ konfigurieren, sondern hinter NAT und Firewall

[bubblegun]

Liebe Wissende!
Die Anmeldung bei meinem Provider dus.net ist korrekt und funktioniert. Ich kann Anrufe entgegennehmen und Anrufe empfangen. Leider bricht jeder Anruf nach genau 30 Sekundne ab. Die Hotline machte mich darauf aufmerksam, dass da offensichtlich ein Timer abläuft, der eien falschen Port sperrt. Während von meiner Seite der Port 37259 angeboten wird, ist beim Provider der Port 379.. vorgesehen. Und damit kommt zwar ein Kontakt zustande, der aber nach 30 Sekunden unterbrochen wird. In der be.ip+ sind dafür ja die Ports 32768 - 65535 vorgesehen, über die sich der Router aber anscheinend nicht verbindet? In meiner X320 kann ich jedenfalls dazu keine Einstellungen finden. Wie kann ich den Knoten lösen?

 

[bubblegun]

Aus eigener Unwissenheit hab ich das Problem etwas verwurschtelt beschrieben, deshalb noch einmal:
Der Router meldet sich bei meinem Provider mit der richtigen IP und dem Port 32768 an. Die Telefonanlage X320 mit MGW-Karte hinter dem Router sagt jedoch sie ist auf Port 37954 erreichbar, so erklärt mir das jedenfalls die Hotline des Providers, und deshalb kommt keine Verbindung zustande bzw. bricht nach 30 Sekunden ab. Bei der Telefonanlage konnte ich keine Einstellungen dazu finden. Wie bringe ich der be.ip+ bei, dass sie sich mit dem von der Anlage bevorzugten Port beim Provider anmeldet?

 

[Joe_57]

Erfolgt ein normaler SIP-Rufaufbau nicht immer über Port 5060 bzw. 5061 und dann erst wird der RTP-Port für das Gespräch ausgehandelt?

 

[bubblegun]

Ja, wenn ich eine VOIP-Verbindung in der be.ip+ konfiguriere läuft das auch alles korrekt. die be.ip meldet sich über Port 5060 beim Provider an. Nur wenn ich die VOIP-Anmeldung über meine Gateway-Karte in der X320 (hinter der be.ip+) konfiguriere, verbiegt die be.ip+ diese Anmeldung auf Port 57xxx und der Reg.Contact läuft über meine Anmeldenummer@IP:61xxx, und da spielt mein Provider nicht mehr mit. Der Reg.Contact muss über den gleichen Port wie bei der Anmeldung laufen, ansonsten sind keine ausgehenden Gespräche möglich, eingehende Gespräche brechen nach 30 Sekunden ab.
Wie bring ich der be.ip+ bei, dass sie für ein VOIP-Device diesen Port benutzen soll. Ich bin da mit der Konfiguration schon überfordert, weil ich de Meinung war, dass regelt die be.ip+ selber. Und dass ich die X320 ohne Router und Firewall ins Netz stelle, kann ich mir wirklich nicht vorstellen.

 

[Joe_57]

Wieso hast du denn einen zweiten Thread aufgemacht?
Doppelposting sind hier im Forum nicht erwünscht!

 

[bubblegun]

Weil ich bisher nicht absehen konnte, ob das an der Telefonanlage, oder am Router liegt. Wobei bei der Telefonanlage noch ein weiteres Problem aufgetaucht ist. Mein SIP-Telefon lässt sich nicht an der Telefonanlage anmelden, hätt ich auch gerne geklärt. Wenn man immer wieder im Nebel stochert, verliert man auch leicht den Überblick, so nach "war ich da schon mal, oder kommt mir das nur so vor, oder dreh ich mich ständig im Kreis?"

 

[bubblegun]

Ich hab jetzt den Titel geändert, weil ich langsam aber sicher der Sache auf den Grund komme:
Wenn ich den SIP-Server in der be.ip+ konfiguriere, funktioniert das problemlos. Nur hab ich eben Probleme, die Anrufe von der als Telefonanlage konfigurierten be.ip+ an die dahinter liegende X320 zu leiten.
Jetzt habe ich eine MGW-Karte in der X320 konfiguriert, aber die be.ip+ verbiegt den Registrierungsport von 5060 auf 57xxx, so dass keine korrekte Anmeldung beim Provider möglich ist. Bevor ich als Unwissender in der be.ip+ unnötige Dinge verbiege meine Frage an die Wissenden:
Kann ich da einfach eine Portweiterleitung in der be.ip+ konfigurieren?
Warum ist das nicht grundsätzlich in die Anlage implementiert?
Ist das so ungewöhnlich, dass jemand seinen SIP-Server nicht in der be.ip+ konfigurieren will, sondern im Netzwerk dahinter?

 

[chrsto]

[...]
Falls es danach immer noch nicht geht, hilft nur ein Trace bzw. TCPDUMP.

[...]

 

[bubblegun]

Nein, vermutlich habe ich mich wieder etwas verkürzt ausgedrückt: Das sind zwei unterschiedliche Probleme!
Das Anmelde-Problem mit meinem SIP-Telefon habe ich nur an der X320.
Wenn ich den SIP-Provider in der be.ip+ konfiguriere meldet sich das Unifi UVP korrekt an der be.ip+ an und alles ist gut. Da es aber mit meinem bisherigen Wissensstand absolut unmöglich ist, die Rufe von der be.ip+ an die X320 weiter zu leiten, habe ich eine MGW-Karte in die X320 eingebaut. Das lässt sich auch konfigurieren, und die X320 meldet sich beim Provider an. Allerdings verbiegt die be.ip+ den Anmeldeport und den Reg.contact auf zwei unterschiedliche Ports, so dass keine korrekte Anmeldung möglich ist.
Also noch einmal kurz zusammengefasst: Ich kann einen SIP-Server in der be.ip+ konfigurieren, der sich korrekt beim Provider anmeldet und den Contact dauerhaft aufrecht hält.
Das hilft mir aber nicht weiter, weil die Weiterleitung der Rufe an die X320 nicht möglich ist.
Deshalb wurde die Media-Gateway-Karte in die X320 eingebaut, dort der SIP-Server konfiguriert, der sich aber beim Provider nicht korrekt anmelden kann, weil NAT und Firewall in der be.ip+ das verhindern.
Deshalb hatte ich hier in dem Thread nachgefragt, wie ich der be.ip+ beibringen kann, diese Anmeldung korrekt weiterzuleiten und aufrecht zu erhalten. Ansonsten muss ich halt im Nebel rumstochern!

 

[chrsto]

Meine Anfrage zum Trace/TCPDUMP im Mitel Forum bezog sich auf die Gesprächsabbrüche. Deswegen gibts da eine Leerzeile/einen Absatz und es erst danach geht es mit deinem SIP Telefon weiter.

Und btw.: Welcher Fehler ist es jetzt eigentlich? Gesprächsabbruch nach 30 sek. oder Kontaktverlust/Anmeldeprobleme mit dem Provider?

 

[bubblegun]

Wegen der Gesprächsabbrüche bei kommenden Gesprächen hatte ich mit dem Support gesprochen, der mich auf meine Anmeldedaten verwiesen hat. Dass sich jemand nicht über Port 5060 anmeldet würde er ja noch akzeptieren, aber dass der Reg.Contact dann noch einmal über einen anderen port läuft eben nicht mehr. Ich soll mein NAT und Firewall in Ordnung bringen, dann läuft alles meint der nette Herr.
Wenn ich den SIP-Server in der be.ip+ konfiguriere meldet sich der Router korrekt über Port 5060 an und hält die Verbindung über diesen Port auch. Damit kann ich telefonieren, rein und raus. Da aber keine Verbindung zwischen be.ip+ und OCX über S0 möglich ist, hilft mir diese Lösung rein gar nix! Ich muss den SIP-Server in der OCX konfigurieren und beim Provider anmelden. Und deshalb wäre mir geholfen, wenn mir einer sagt wie ich NAT und Firewall in dem Falle konfiguriere. Wenn das keiner weiß, weil das so abwegig ist, dass man hinter einem Router einen SIP-Server konfiguriert, dann muss ich halt selber im Nebel stochern!

 

[chrsto]

Und deshalb wäre mir geholfen, wenn mir einer sagt wie ich NAT und Firewall in dem Falle konfiguriere.

Das funktioniert mit der be.ip+ und X320 out-of-the-Box. Dir wurde hier im Forum ja schon geraten, die bintec neu aufzusetzen.

Da du aber getrennte Netze für Daten/Voice hast, vermute ich da einen Konfigurationsfehler. Den zu erraten gleicht aber deinem stochern im Nebel.

 

[bubblegun]

Oh sorry, ich dachte ich wäre der einzige mit be.ip+ und X320 und Media-Gateway-Karte. Ich hab jetzt im Nebel gestochert und hab die Lösung gefunden. Aber das ist ja eh uninteressant, denn es geht ja out-of-the-Box. Bei allen anderen wenigstens!
Ich hatte auch nie behauptet dass ich für Daten/Voice getrennte Netze habe. Ich habe aus einem gewissen Sicherheitsbedürfnis mehrere Subnetze konfiguriert. Die sind dann auch in der Firewall so abgeschottet, dass das Gatewaynetz nicht auf das innere Netz -in dem sich die Rechner und Speicherserver mit privaten Inhalten befinden- zugreifen kann. Denn das Gatewaynetz ist relativ löchrig, da ich von außen immer auf bestimmte Devices wie Telefonanlage, Kameras und NAS zugreifen muss.

 

[chrsto]

Prima, dass es jetzt funktioniert. Woran hat es denn gelegen, damit andere Suchende auch eine Lösung finden?

 

[bishop2k]

@ bubblegun

Thema Full Cone 1/1 NAT
Hatte ich gut zu kämpfen mit.
Kann mich da an eine letzte Firewallregel erinnern dann lief es.
Der Weg war steinig und etliche Einstellungen erforderlich.
Kannst du die Regeltabelle evtl. nochmal posten?
Meine Digibox läuft aktuell nur noch als Modem+ATA.

 

[bubblegun]

O.K. ob jetzt in den Firewall-Regeln SIP aktiviert ist oder nicht, rührt die Digibox herzlich wenig. Möglicherweise sollte man bei den Diensten bei SIP einstellen, dass sowohl der Ziel und der Quellportbereich beachtet werden sollen. Hab ich nicht, weil ich mich bei meinem Provider auch über Port knapp unter 65.000 anmelden kann. Wichtig ist nur, dass der den Reg.Contact über den gleichen Port hält, und das war ein Gewürge.
Bei "Netzwerk -> NAT -> Nat-Konfiguration" hab ich eine Regel eingehend und ausgehend auf die IP der X320 angelegt. Es ging ausgehend glaub ich auch mit "full-cone-nat", ich hab jetzt symmetrisch drin und es geht. Auf jeden Fall "Original-Port" einstellen.
Es verdreht jeder die Augen, wenn Du mit der Digi-Box oder be.ip kommst. Das Ding kann eine ganze Menge, nur verliert man leider schnell den Überblick, wenn Du das nicht jeden Tag machst. Die Firewall gefällt mir sehr gut, aber ich meine, dass das Ding als VOIP-Telefonanlage bzw. als Media-Gateway konstruiert ist. Das kann sie sicher auch gut. Aber dass dahinter ein Device ist, das selbst als SIP-Server fungieren will, da hat der ungelernte User so seine Probleme,
Gute Nacht

 

[bubblegun]

So ganz bin ich trotzdem noch nicht durch:
Eingehende Rufe werden auf die konfigurierten Endgeräte geleitet, passt so! Leitweg wird der Rufnummer vorangestellt, so dass eigentlich ein Rückruf über diese Leitung möglich sein sollte.
Allerdings ergibt sich bei ausgehenden Rufen eine Merkwürdigkeit, die bisher keiner versteht und nicht akzeptabel ist: Die Kennziffer für den Leitweg wird transparent als erste Ziffer der Rufnummer durchgereicht. Deshalb wird mir -nachdem ich die (automatische) Vorwahl beim Provider rausgenommen habe- immer "ungültige Rufnummer" angezeigt.
Das sieht folgendermaßen aus: Ich will die Rufnummer 08629-6548 über meinen SIP-Provider anrufen, dazu gebe ich am Telefon mit spontaner Amtsholung folgendes ein ** (für Externbelegung spontan aus) dann die Kennziffer 7 für den Leitweg, und dann die Rufnummer 08629-6548. Nun bekomme ich korrekt die Tarifansage, danach dann die Anzeige "ungültige Rufnummer.
Vorher, als ich die automatische Vorwahl (meines Ortsnetzes) noch in der Konfig beim Provider gespeichert hatte ergab sich dann aus der Rufnummer 08629-6548 die Rufnummer 03357-7-086296548. Der Provider erkannte die 7 für den Leitweg als erste Ziffer, da das keine 0 war wurde die Ortsvorwahl vorangesetzt und daraus die Rufnummer 03357-7086296548. Da wollt ich aber nicht hin! Wieso wird die Kennziffer meines Leitweges als erste Ziffer der von mir gewählten Rufnummer registriert? Einer eine Idee?

 

[bishop2k]

Die Konfig kenn ich natürlich nicht im Detail

** Rufnummer geht nicht ohne 7?
Kannst die 7 Evtl. wo abschneiden? Je nach Anlage in der Nst. selbst.

Die Vorwahl kann bei DUSnet gesetzt werden?
Evtl. mal einen Testaccount von easybell versuchen?
Der Support da ist mal richtig gut und eingie Tarife sehr günstig und flexibel.

 

[chrsto]

Existiert ein Leitweg mit dieser Kennzahl?

 

[bubblegun]

O.K. nachdem mich ein Aastra-Profi auf meine Fehlkonfiguration hingewiesen hat, funktioniert nun alles zu meiner besten Zufriedenheit.
Ich hatte bei "Konfiguration->Telefonie->Leitweg" die Hilfe falsch verstanden. Bei "Suffix bei Belegung " hatte ich die 7 für den Leitweg angegeben, und das war falsch. Irgendwie war ich auf dem Dampfer, dass dieser Suffix beim Rückruf dann vorangestellt wird, aber das macht die Anlage ganz alleine. Dieser Suffix wird bei der WAhl generell vorangestellt, also begannen alle meine Wählversuche mit der 7. Was dann mit aut. Vorwahl schon zu erstaunlichen Ergebnissen führte . Aber nun ist alles gut, @bishop2k: ich will meine ganze Freigabeliste nicht hier ins Netz stellen. Wenn Du da noch deutliche Konfig-Hinweise brauchst bitte per PN.
Übrigens erreicht mich grade das Schreiben der Engländer, dass mein Anschluss modernisiert wird. Ja, nun muss ich mit der mickrigen Leitung nicht nur die Daten, sondern auch noch Sprach(daten)e befördern!