Fritzbox als SIP-Gateway hinter Linux-Router

BruderB

Neuer User
Mitglied seit
18 Feb 2006
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
Moin zusammen,

ich bin schon ziemlich lange hier Mitglied, weil das Thema VoIP immer weiter in den Alltag vordringt und sich die Fragestellungen häufen. In den vielen Threads habe ich bereits eine Menge Tipps gefunden.

Nun habe ich ein Problem, dem ich nicht Herr werde und hoffe auf Unterstützung:

Bei einem Kumpel (wirklich!!) habe ich vor einer halben Ewigkeit zwei Internet-Router etabliert, so, wie man das damals gemacht hat mit DynDNS und openVPN als Tunnel zwischen seinen beiden Wohnsitzen. Das war kurz nach der Jahrtausendwende und wir waren mit dem Aufbau 'ganz vorne'. An beiden Standorten heißt der ISP Telekom.
Irgendwann wurde ISDN abgekündigt und wir mussten auf SIP-Telefonie schwenken. Dafür hat ein anderer Techniker jeweils Fritzboxen als SIP-Gateways 'hinter' den Linux-Routern in Betrieb genommen. Auch diese Architektur hat aalglatt funktioniert.
Fahrlässigerweise haben wir die Router nie aktualisiert. Erst vor einem halben Jahr habe ich das Linux mal auf den Stand der Zeit gehoben und damit auch einen DSN-Client an den Start gebracht, der die SRV-Einträge kennt, deren Nutzung die Telekom inzwischen für ihre Telefonie obligatorisch macht. Seit diesem Tag haben wir Probleme mit der Telefonie, die sich verschieden darstellen und die ich in Summe als 'Instabilitäten' bezeichnen möchte: Manchmal können eingehenden Anrufe zwar angenommen werden, haben dann aber keine Audio-Verbindung, manchmal geht's.... Auch bei ausgehenden Telefonaten gibt es keine Zuverlässigkeit. Die Probleme lassen sich weder systematisieren noch stabil reproduzieren - total ätzend.
Vor zwei Wochen nun kam dieser Brief von der Telekom, der vermutlich inzwischen ziemlich bekannt ist: Man wolle die Telefonie auf Basis von DNS-A-Records umstellen auf SRV-Einträge. Also habe ich am zweiten Wohnsitz meines Kumpels ebenfalls das Linux gehoben mit einem dnsmasq, das nun auch mit SRV-Records umgehen kann - und habe die gleichen 'Instabilitäten' bei der Telefonie über die angeschlossene Fritzbox.

Die Fritzboxen (beide mit aktueller Firmware) sind mir ein ziemlicher Dorn im Auge. Zum Debugging haben die Dinger nicht wirklich viel beizutragen. Aber ich kenne mich auch nicht gut damit aus. Ich tendiere dazu, sie gegen eine SPA112 auszutauschen.

Bei den Linux-Routern handelt es sich um ein gehärtetes Linux mit dnsmasq und shorewall als Firewall. Ich habe keine speziellen Regeln für VoIP und kein Portforwarding für die Fritzbox hinterlegt und sehe keine Rejects oder Drops im Problemfall.

Soweit zur Situationschilderung. Ich habe das sichere Gefühl, dass es irgendeines 'Tricks' bedarf, um die Sache wieder in Funktion zu bringen, aber ich weiß nicht wirklich, wo ich ansetzen soll. Nun bin ich gespannt auf kundige Statements. Sicherlich sind meine Ausführungen nicht präzise bis ins letzte Detail. Ich kann natürlich jede Beschreibung nachliefern.....

Dank und Grüße,

Boris
 
Zuletzt bearbeitet:
Wenn auf beiden Seiten FritzBoxen existieren, warum nicht das Setup vereinfachen und Internet/VPN/Telefonie durch die Boxen erledigen lassen und das Linux abklemmen?
 
Moin Moin


Die Fritzboxen (beide mit aktueller Firmware) sind mir ein ziemlicher Dorn im Auge. Zum Debugging haben die Dinger nicht wirklich viel beizutragen. Aber ich kenne mich auch nicht gut damit aus.
Dann mal bitte Zeitnah, wenn die Probleme auftreten, auf http://fritz.box/support.lua einloggen und die Support-Daten erstellen.
Die Datei dann in einen Webbrowser ziehen ( Drag'n'Drop ;) ) und nach "SIP Log" und "SIP INVITE Log" suchen.
Bildschirmfoto vom 2020-10-16 18-55-52.png
Da sollte dann der SIP Verkehr äußerst detailiert auftauchen.
 
Zuletzt bearbeitet:
Moin chrsto,

die Linux-Boxen leisten noch andere hübsche Dienste und sind schlicht die gewünschten Geräte.

Moin koyaanisqatsi,

danke für den Tipp. Das werde ich mal veranlassen und sehen, ob ich daraus schlau werde.

Boris
 
Ich musste mich neulich mit einem ähnlichen Fall beschäftigen.

Eine klare Lösung scheint es dafür nicht zu geben. Manche sagen, dass man dazu Port-Weiterleitungen benötigt, machen sagen das Gegenteil.
Die Ports, die dabei weitergeleitet werden sollen, unterscheiden sich je nach Quelle.

Probiere mal am besten erstmal, was AVM dazu sagt.

Mir war das alles zu wackelig, so dass ich die eine FB zum IP-Client des Routers (be.IP+; beinhaltet auch eine TK-Anlage) degradiert habe. Im zweiten Standort konnte ich die FB komplett eliminieren (=ersetzen). Das ist mir bei FB immer noch die liebste Variante. Vor allem, wenn die Anlage geschäftlich genutzt wird.
 
Moin _tms,

danke für Deinen Beitrag.
Ja, die Unklarheiten überwiegen. Tragisch.
Ich habe die FB als IP-Client hinter dem Router, aber auch das ist instabil.
Inzwischen habe ich den Verdacht, dass der Telekom'sche SIP-Dienst instabil und/oder nicht vernünftig dokumentiert ist.
Ganz offensichtlich wird gegenwärtig im großen Stil daran geschraubt, was man an dem DNS-Change erkennen kann. Man will wohl die Telefonie im Festnetz und im Mobilfunk vereinheitlichen. Tatsächlich habe ich in letzter Zeit auch mit meinem mobilen Telefon (mit rosa Vertrag) gelegentlich die Situation, dass die Verbindung steht, aber kein Audio transportiert wird.

Die support-Files von der FB herzustellen fällt momentan schwer, weil die Box vorübergehend zu Testzwecken außer Betrieb ist. Mal sehen, wann ich damit weiter komme.....
 
Was für Telefone habt ihr an der FB?

Ganz ehrlich?
Ich würde die FB entweder gleich rausschmeißen oder nur noch als DECT (VoIP-Registrierung macht de be.IP+, an der FB werden "nur" die einzelnen Nebenstellen eingerichtet und den Telefonen zugewiesen) und WLAN nutzen.
Schau' die die be.IP+ (oder die Digitalisierungsbox Premium) an.
Die be.IP+ hat zwei S0 (für ISDN-Telefone) und 4 analoge Anschlüsse. Ansonsten ist die Anzahl der Benutzer/Endgeräte durch die Lizenz begrenzt, kann aber erweitert werden.
Sind auch nicht viel teurer als eine neue FB, dafür hast du dann was vernünftiges. Die TK in der be.IP+ kann alles, was man so braucht.
Ich habe bei keinen Kunden bisher eine Anforderung bekommen, die damit nicht lösbar gewesen wäre.

PS: Die Lösung, die ich beim dem Kunden umgesetzt und oben beschrieben habe, läuft seit dem Installationstag anstandslos und völlig stabil.
 
Moin _tms,

vielen Dank für Deine Idee. Ich habe mit die be.IP+ etwas angesehen - ist ja ein recht teurer Spaß....
Ich bin ehrlich gesagt nicht bereit eine Hardware zu entsorgen, solange ich deren Fehler nicht kenne.
Die Telekom ist scheinbar nicht willens, ihre Protokolldefinitionen zu beschreiben. Was nützt mir der Ist-Zustand, wenn ich den Soll-Zustand nicht kenne?
Und die FB scheint in fast allen Anwendungsfällen zu funktionieren, sonst wären doch die Reklamationen laut hörbar, oder?

Boris
 
Ich finde die be.IP+ nicht teuer.
Insbesondere, weil man dafür einen echten Router (FB ist nach wie vor "nur" ein einfaches "NAT"-Device) mit einer ganzen Menge an zusätzlichen Features bekommt.
Ich habe inzwischen etliche be.IP+ bei Kunden im Einsatz. Bisher keinen einzigen Ausfall und 100% Stabilität. Das ist das Geld allemal wert.

Die Digitalisierungsbox (ist ja eigentlich eine be.IP+) habe ich mir noch nicht genauer angesehen. Die gibt es aber gebraucht in der Bucht für ganz kleines Geld.
Vielleicht ist das eine Option für dich.
 
Bei den Linux-Routern handelt es sich um ein gehärtetes Linux mit dnsmasq und shorewall als Firewall. Ich habe keine speziellen Regeln für VoIP und kein Portforwarding für die Fritzbox hinterlegt und sehe keine Rejects oder Drops im Problemfall.

Wenn man sein System auch zukünftig störungsfrei nutzen möchte, so gehört nach meiner Meinung das Weiterleiten der einzelnen nötigen Ports zum gewünschten SIP-Client (TK-Anlage oder zur AVM als SIP-Client), den es pro öffentlicher IP-Adresse auch nur einmal im eigenem Netz geben darf, zur Grundkonfiguration einfach dazu.

Ich selber habe vor ca. drei Monaten einfach meine TK-Anlage, die auch hinter einem ausgewachsenem Linux-Router (Microtik) hängt, die TK-Anlage der Firma Auerswald, Typ 5020 durch eine TK-Anlage der Firma Yeastar, Typ S50 ersetzt, welche bis heute noch ohne Probleme läuft.

Die K-Anlage der Firma Auerswald, Typ 5020 lief aufgrund der Portweiterleitung ca. 15 Jahre ohne Probleme auch mit dem SIP-Provider der Deutschen Telekom.

Wie man an Hand der Beschreibung gut sehen dürfte, ist es egal, welchen SIP-Client man als TK-Anlage nutzt. Sehr wichtig herbei ist nur, um einen störungsfreien Betrieb herbeizuführen, die Weiterleitung der entsprechenden nötigen Ports zum gewünschtem SIP-Client. Denn ein SSH-Dienst oder Webserver hinter einem Router, die auch auf entsprechende Ports lauschen, würden auch nicht antworten können, wenn die entsprechenden Ports zu diesen Diensten nicht weiterleitet werden würden.
 
Kannst du mal posten, welche WL du genau eingerichtet hast?

Schön, wenn die 5020 bei dir problemlos läuft. Auerswald selber sagt, dass die 5020 VoIP nicht für die aktuellen SIP-Anschlüsse der Telekom geeignet sind. Dazu hat es seitens Telekom zu viele Änderungen gegeben, die bei der 5020 nicht berücksichtigt sind. Da die 5020t schon lange abgekündigt ist, wird es da auch keine Updates mehr geben.
Was aber problemlos funktioniert ist, eine be.IP+ als MGW davorschalten. Davon habe ich auch mehrere Installationen bei Kunden laufen, die absolut stabil und problemlos ihren Dienst verrichten.
 
Wenn man sein System auch zukünftig störungsfrei nutzen möchte, so gehört nach meiner Meinung das Weiterleiten der einzelnen nötigen Ports zum gewünschten SIP-Client (TK-Anlage oder zur AVM als SIP-Client), den es pro öffentlicher IP-Adresse auch nur einmal im eigenem Netz geben darf, zur Grundkonfiguration einfach dazu.

So ein Unsinn. Mir ist mit 1&1 ein einziger Provider bekannt, bei dem eine Portöffnung ins LAN überhaupt nötig ist. Gerade mit den Anschlüssen der Telekom ist eine Portweiterleitung Router -> IP Telefonanlage nicht nötig.

Wenn eine CloudPBX Lösung der Telekom zum Einsatz kommt, würde ich mir dann gern mal den durchlöcherten "Schweizer Käse" ansehen. Was auch deinen zweiten Punkt ad absurdum führt: Selbstverständlich können pro öffentlicher IP in einem LAN mehrere SIP Clients zu Einsatz kommen.
 
Kannst du mal posten, welche WL du genau eingerichtet hast?

Also die benötigten Ports zur Weiterleitung holt man sich am besten immer bei seinem SIP-Provider.

Bei Telekom und easybell sind die benötigten Ports unter folgenden URL´s hinterlegt:
Solange die SIP-Angaben unter den genannten URL´s auch noch abrufbar sind, sollte man auch davon ausgehen dürfen, dass diese auch noch gültig neben eventuellen neueren technischen Vorgaben sind.

Schön, wenn die 5020 bei dir problemlos läuft. Auerswald selber sagt, dass die 5020 VoIP nicht für die aktuellen SIP-Anschlüsse der Telekom geeignet sind

Bei den TK-Anlagen des Herstellers Auerswald kann man als Endnutzer bei Bedarf das jeweilige Template für den jeweiligen Provider auch selber anpassen. Somit ist man auf neue und angepasste Templats des Herstellers nicht angewiesen.

Da die 5020t schon lange abgekündigt ist, wird es da auch keine Updates mehr geben.

Wenn man auf die neusten Funktionen der neueren Firmware-Versionen neuerer TK-Anlagen verzichten kann, ist es aus meiner Sicht nicht wirklich ein Problem, zumal solche TK-Anlagen meisten hinter einer möglichst aktuell gehaltenen Firewall betrieben werden.

Ich selber habe den Wechsel von der Auerswald 5020 zur Yeastar S50 nur aufgrund des Audio-Codecs G.722 durchgeführt.

So ein Unsinn. ... Gerade mit den Anschlüssen der Telekom ist eine Portweiterleitung Router -> IP Telefonanlage nicht nötig.

Bei mir schon, und eventuell auch beim Nutzer @BruderB, da bei mir eine ausgewachsene Firewall vor der TK-Anlage geschaltet ist und ich wissen möchte, welcher Dienst vom WAN aus her aus dem LAN kontrolliert erreichbar ist bzw. antwortet.
 
Moin zusammen,

vielen Dank für ale Beiträge.
Ich war ein paar Tage offline, habe aber 'das Interesse an der Sache' nicht verloren.....

Vielen Dank chrsto für die Links zu den Trchnischen Richtlinien. Mal sehen, ob ich damit was anfangen kann.

Deinem Beitrag, andreas00 kann ich nicht so recht folgen. Der SIP-Client hinter dem Router, sei es einfach ein SIP-Telefon oder eine TK-Anlage oder ein SIP-Gateway wie die Fritzbox stellen (im Gegensatz zu dem beispielhaft erwänten ssh- oder WebServer) keinen Dienst zur Verfügung, der vom Internet angefragt werden müsste. Ergo muss auch kein PortForwarding eingerichtet werden.
Zumindest lief die Fritzbox als SIP-Gateway ganz problemlos bis zu dem Tag, an dem ich mittels Software-Update auf dem Router erreicht habe, dass SRV-Einträge des DNS nutzbar wurden.

Der Link zur Portbeschreibung bei telekomhilft.xxx. ist ziemlich schwach. Der OP möchte Port 80 und 443 ausgehend freigeben. Telefonie über http(s)??? Wohl kaum....
Der erste Antworter versachlicht die Situation ja auch gleich: Outbound-Traffic ist auch auf meiner Firewall frei.

Verletzungen von Firewallregeln wäre außerdem reproduzierbar und man bekäme Hinweise im FW-Protokoll.

Boris
 
[...] dass SRV-Einträge des DNS nutzbar wurden.
[...]

Das ist übrigens nicht dein Problem. Die "alte" Methode funktioniert noch bis mindestens Ende November. Der in dem Schreiben genannte Termin dient nur dazu den Kunden zeitnah zum Handeln zu bewegen.
 
Puh, bist Du da gaaaanz sicher?
Dieses berühmte Schreiben, das darauf hin weist, dass man seinen Router updaten soll, um die SRV-Einträge nutzen zu können, werden ja vermutlich nicht alle T-Kunden bekommen haben, sondern nur die, die die SRV-Einträge nicht abfragen. Das kann der Rosa Riese ja sehen.
Ich gehe davon aus, dass nun, da die Telekom mich als SRV-DNS-Nutzer erkennt, ich ggfs. mit einem 'anderen' SIP-Dienst bedient werde. Vielleicht werde ich mit dem SRV-Eintrag umgeleitet auf die SIP-Plattform, auf der die Telekom gerüchteweise die Festnetz- und die Mobiltelefonie zusammenführen will....

PS: Und ja, der alte Dienst funktioniert noch. Ich habe in dem DNS-Dienst auf meinem Router ein Feature, mit dem ich die Nutzung der SRV-Einträge testweise abschalten kann:
# Uncomment this to filter useless windows-originated DNS requests
# which can trigger dial-on-demand links needlessly.
# Note that (amongst other things) this blocks all SRV requests,
# so don't use it if you use eg Kerberos, SIP, XMMP or Google-talk.
# This option only affects forwarding, SRV records originating for
# dnsmasq (via srv-host= lines) are not suppressed by it.
#filterwin2k
 
Zuletzt bearbeitet:
BruderB, ich bezweifele, dass uns in Deinem Fall die FRITZ!Box selbst irgendwelche Auskunft gibt. Das einfachste wäre, wenn Du auf der WAN-Seite der Linux-Router einen Paket-Mitschnitt machen würdest bzw. könntest. Was benutzt Du als DSL-Modem? Wenn alle Stricken reißen, kannst Du auch einen Switch mit Port-Mirroring zwischen Linux-Router und DSL-Modem packen. Dann könnten wir in Wireshark zusammen debuggen, was genau schief geht. Bei DNS-SRV setzt die Telekom Deutschland auf nicht transparentes Load-Balancing. Kennst Du diesen Artikel (Punkt 9.6; Portweiterleitungen aktiv halten)? Das macht ein SIP-Ping auf die über DNS gelernten IP-Adressen von tel.t-online.de und betrifft erstmal das Problem dauerhaft erreichbar zu sein. Welches FRITZ!OS nutzt Du?
Mir ist mit 1&1 ein einziger Provider bekannt, bei dem eine Portöffnung ins LAN überhaupt nötig ist.
Und je nach Implementierung des VoIP/SIP-Clients nicht einmal das …
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.