VoIP Telekom nimmt keinen Anruf an bzw. kein ausgehender Anruf
-
Hallo Leute!
Ich beiße mir beim NAT in Kombination mit VoIP gerade die Zähne aus.
Es geht um eine VoIP-Anlage im LAN, Internetzugang macht die pfSense 2.3.1_1 und seit ca. Mittwoch letzter Woche spinnt das Telefon. Es hat aber mindestens ein halbes Jahr fehlerfrei funktioniert. Ich bin mir nicht ganz sicher ob die Probleme mit dem Update auf 2.3.1 entstanden sind, ich kann mich nicht mehr genau erinnern, wann ich auf 2.3.1 aktualisiert habe. Mit 2.3 hat es definitiv funktioniert.
Nun zum Problem:
Zu erst nahm die Telefonanlage gar keine Anrufe mehr entgegen und man konnte nicht nach "draußen" telefonieren. Da ich nach diversen Versuchen mir gar nicht mehr zu helfen wußte, habe ich alle NAT und Firewall-Regeln, die die Telefonanlage betrafen entfernt und Stück für Stück neu angelegt.Für die Daten von WAN nach LAN gilt: Ich habe jetzt eine NAT-Regel die sämtliche Pakete, die von den Telekom-SIP-Server (217.0.23/24, 217.0.16/24, 217.0.0/24) von einem beliebigen Port kommen und an den Port 5060 auf der WAN-Adresse gerichtet sind, intern an die Telefonanlage auch auf Port 5060 weitergeleitet wird. Damit konnte man schon mal wieder von außen nach innen telefonieren.
Zuerst erweckte es den Eindruck, dass jetzt alles in Ordnung sei, aber man konnte nach kurzer Zeit keine Telefonate mehr nach außen führen. Laut Netzwerk-Dump lehnt der Telekom-Server den Ruf ab.
Wenn ich erst ein Gespräch von außen nach innen führe, kann ich anschließend für einige Zeit (einige Minuten) auch von innen nach aussen telefonieren.
Und da bin ich jetzt mit meinem Latein am Ende. Das klingt für mich nach irgend welchen Timeouts in der pfSense - aber welche. Als ob die VoIP-Trunks nicht mehr bei der Telekom registriert wären.Für die Daten von LAN nach WAN gilt: LAN-Clients dürfen alles - also auch die Telefonanlage darf beliebige Verbindungen herstellen.
Für jede Idee wäre ich sehr dankbar.
Bis denn,
eweriP.S. Wie erstellt man eigentlich eine NAT-Regel, die von eine bestimmten Source-Adresse mit beliebigem Port auf die WAN-Adresse mit beliebigen Port an einen LAN-Adresse mit dem selben Port weiterleitet?
-
P.S. Wie erstellt man eigentlich eine NAT-Regel, die von eine bestimmten Source-Adresse mit beliebigem Port auf die WAN-Adresse mit beliebigen Port an einen LAN-Adresse mit dem selben Port weiterleitet?
Gar nicht. Bei einer Port-Weiterleitung - und das ist das NAT, dass du wohl meinst - muss genau das namensgebende Element (die Ports) definiert sein, sonst macht es keinen Sinn. Natürlich kann man auch platt einfach alle Ports weiterleiten, brauchbar ist es dann aber nicht mehr. Wenn das allerdings als Antwort auf eine vorhergehende Kommunikation geschehen soll, kann das ggf. ein Proxy oder Upnp bspw. möglich machen.
-
Um auszuschließen, daß das Problem bei der Telekom liegt: Kannst Du (temporär) auf 2.3 zurücksetzen?
Aber ehrlich: Das hört sich seltsam an. Normalerweise klemmt es eher von draußen nach drinnen als umgekehrt …
Wenn der Telekom-Server den Anruf ablehnt, dann ist es wohl kein Timeout-Problem und kein Problem von gefiltertem Traffic auf der pfSense. Geht es mit einem anderen VoIP-Gerät (notfalls Softphone installieren)?
Wenn es mit pfSense 2.3 funktioniert und mit einer neueren Version nicht, dann würde ich als nächstes die Inhalte des SIP-Protokolls analysieren, um zu schauen ob es hier Unterschiede gibt und ggf. welche.
-
Du kennst das Support Dokument der Telekom zu den Ports, oder?
Bei Einsatz einer Firewall oder eines Routers sind für die IP-Telefonie folgende Portfreischaltungen erforderlich:
UDP (out): Ports 5060, 30000-31000, 40000-41000, 3478, 3479
UDP (in): Ports 5070, 5080, 30000-31000, 40000-41000
TCP (out): Port 80, 443Hinweise:
Geben Sie die SIP-ID ohne Leerzeichen und Sonderzeichen ein (entspricht Vorwahl und Rufnummer)
Die Eingabe der SIP-ID und des Bildschirmnamens müssen übereinstimmen.
Den Benutzernamen bitte vollständig klein schreiben.Demnach ist 5060 ein egress Port, 5070 und 5080 sind ingress (unter anderem, s.o.).
-
Ich bin jetzt ehrlich verwundert:
Die Port-Listen der Telekom stehen im krassen Gegensatz zu allem was ich bisher weiß und was in der Erfahrung funktioniert hat und was der Anlagenhersteller sagt.Nach meinem Kenntnisstand erfolgt die Kontaktaufnahme immer über den Zielport 5060 - das heißt die Telefonanlage muss für den Telekom-Server über Port 5060 erreichbar sein. Das scheint jetzt auch immer zu klappen. Eingehende Gespräche haben kein Problem.
Abgehende Gespräche sind das Problem - wenn ich vorher ein eingehendes Telefonat habe, kann ich für Minuten abgehend telefonieren und plötzlich ist Schluss und im Netzwerk-Dump sehe ich folgendes:
Telefonanlage:5060 -> tel.t-online.de:5060 INVITE sip blah blah
und dann kommt die Antwort:
tel.t-online.de:5060 -> Telefonanlage:5060 Status 403 ForbiddenWenn ich jetzt aber erst eine eingehenden Anruf mache und lege beim ersten klingen wieder auf, kann ich problemlos ausgehend telefonieren.
Hat die Telekom ein Problem oder liegt dass an der neuen pfSense Version?
-
Ich bin jetzt ehrlich verwundert:
Die Port-Listen der Telekom stehen im krassen Gegensatz zu allem was ich bisher weiß und was in der Erfahrung funktioniert hat und was der Anlagenhersteller sagt.Nach meinem Kenntnisstand erfolgt die Kontaktaufnahme immer über den Zielport 5060 - das heißt die Telefonanlage muss für den Telekom-Server über Port 5060 erreichbar sein.
Ja, meine Erfahrungen sind ganz genauso. Ich verstehe auch nicht, wie diese Port-Liste zustandekommt. Ich kann mir nur vorstellen, daß das eine ziemlich veraltete Information ist.
Abgehende Gespräche sind das Problem - wenn ich vorher ein eingehendes Telefonat habe, kann ich für Minuten abgehend telefonieren und plötzlich ist Schluss und im Netzwerk-Dump sehe ich folgendes:
Telefonanlage:5060 -> tel.t-online.de:5060 INVITE sip blah blah
und dann kommt die Antwort:
tel.t-online.de:5060 -> Telefonanlage:5060 Status 403 ForbiddenWenn ich jetzt aber erst eine eingehenden Anruf mache und lege beim ersten klingen wieder auf, kann ich problemlos ausgehend telefonieren.
Hat die Telekom ein Problem oder liegt dass an der neuen pfSense Version?
Ich glaube nicht, daß das die pfSense-Version ist, aber das würde ich dennoch als erstes absichern.
Hast Du Telekom deswegen mal kontaktiert?
-
Wenn ich erst ein Gespräch von außen nach innen führe, kann ich anschließend für einige Zeit (einige Minuten) auch von innen nach aussen telefonieren.
Und da bin ich jetzt mit meinem Latein am Ende. Das klingt für mich nach irgend welchen Timeouts in der pfSense - aber welche. Als ob die VoIP-Trunks nicht mehr bei der Telekom registriert wären.Das Problem kenne ich :)
https://doc.pfsense.org/index.php/Static_Port
Ich hab es durch probieren herausgefunden, leider bekommt man von der Telekom keinen technischen Support (oder ich mache was falsch).
-
Der SIP Dienst der Telekom funktioniert im Prinzip wie jeder andere - dort liegt das Problem nicht.
Auch nicht in PFsense 2.3.1Eingehend Port 5060 freizuschalten ist falsch. Zumindest hast Du ihn aber auf tel.t-online.de beschränkt.
Hättest du dies nicht, könnte jeder aus dem Internet sich an deiner Telefonanläge anmelden und auf deine Kosten telefonieren.
Hat mal einen Kunden von mir 9000€ gekostet!Du brachst in der PFsense EINE ausgehende NAT-Regel mit Port 5060/UDP
Source: IP der Telefonanlage - dort MUSS der Haken bei "Static Port" sitzen
Eingehend müssen nur die RTP Ports auf diene Anlage weitergeleitet werden.
Standard RTP ist 5004/UDP und folgende.Ja nach Anlage werden aber auch gerne 10000/UDP-10100/UDP verwendet.
Gigaset DECT Stationen verwendet 5004/UDP bis 5020/UDP
Frizboxen 7078/UDP-7110/UDP -
Bei mir dient eine ältere FritzBox hinter der pfSense als ATA.
Konfiguriert nach der Anleitung:
https://sighunter.wordpress.com/2014/08/24/voip-mit-fritzbox-hinter-pfsense/
Funktioniert.
-
Eingehend Port 5060 freizuschalten ist falsch. Zumindest hast Du ihn aber auf tel.t-online.de beschränkt.
Bei Sipgate hat es bei mir ohne Port Forwarding 5060 funktioniert, aber bei der Telekom brauche ich diese zwingend.
Wieso sollte das falsch sein, anders kann man keine Gespräche empfangen.Jedoch stimme ich dir zu das man die Quelle per Alias eingrenzen sollte.
-
Ich kann wunderbar über die SIP Server der Telekom telefonieren und habe noch nie eingehend eine Port 5060 freigeschaltet, wozu auch, für Sprache werden die RTP Ports genutzt und der Client registriert sich auf dem Server und hält diese offen.
Sonst könnte man sich ja auch nicht an zwei unterschiedlichen SIP Server anmelden - man kann den Port 5060 ja nur einmal weiterleiten.
Bei schlechten Routern, die die Verbindung zu früh verwerfen ist es notwendig auf dem Client die Keep Alive Zeit zu reduzieren.
Den Port 5060 weiterzuleiten ist Extrem gefährlich, es gibt auch IP- Spoofing und dann ist die Kohle weg. Einfach mal googlen.
-
Ich kann wunderbar über die SIP Server der Telekom telefonieren und habe noch nie eingehend eine Port 5060 freigeschaltet, wozu auch, für Sprache werden die RTP Ports genutzt und der Client registriert sich auf dem Server und hält diese offen.
Evlt. hast Du die PBX anderst konfiguriert, bei mir ging es nicht.
Sonst könnte man sich ja auch nicht an zwei unterschiedlichen SIP Server anmelden - man kann den Port 5060 ja nur einmal weiterleiten.
Warum sollte das mit einem Port Forwarding nicht gehen?
-
Sonst könnte man sich ja auch nicht an zwei unterschiedlichen SIP Server anmelden - man kann den Port 5060 ja nur einmal weiterleiten.
Jetzt dämmerts mir, ich war von einer PBX ausgegangen an dem wiederrum die SIP Telefone im LAN hängen.
-
Weil du einen Port an der öffentlichen IP-Adresse nicht an zwei unterschiedliche Endgeräte im LAN weiterleiten kannst.
Du darfst ja machen was du willst, aber das Risiko bleibt auf deiner Seite und notwendig ist es definitiv nicht.
Wenn du logisch überlegst, dann ist klar, dass es nicht nötig ist.
Wenn der Client schon eine Verbindung zum Server über den Port 5060 aufgebaut hat, dann braucht der Server keine zweite aufbauen. wenn aber keine Verbindung besteht, dann weiß der Server erst gar nicht zu welcher IP Adresse er selbst eine aufbauen soll.Meist wird bei der Pfsense vergessen das Flag "Statischer Port" beim ausgehende NAT zu setzen, bezw. Ist die Regel dafür nicht oben in der Liste und kommt erst gar nicht zur Ausführung.
Das passt auch zu dem Phänomen, dass es teilweise geht und dann wieder nicht.
-
Weil du einen Port an der öffentlichen IP-Adresse nicht an zwei unterschiedliche Endgeräte im LAN weiterleiten kannst.
Ja unsere Antworten haben sich überschnitten.
@Parsec:Du darfst ja machen was du willst, aber das Risiko bleibt auf deiner Seite und notwendig ist es definitiv nicht.
Ich würde es sehr gerne vermeiden, nur mit der Telekom ist mir das nicht gelungen.
Wenn ich Sipgate nehme brauche ich in der Tat kein Port Forwarding 5060 auf den Asterisk.Wenn der Client schon eine Verbindung zum Server über den Port 5060 aufgebaut hat, dann braucht der Server keine zweite aufbauen. wenn aber keine Verbindung besteht, dann weiß der Server erst gar nicht zu welcher IP Adresse er selbst eine aufbauen soll.
Dann ist mein Asterisk falsch konfiguriert und sendet zu selten ein keep alive?
Meist wird bei der Pfsense vergessen das Flag "Statischer Port" beim ausgehende NAT zu setzen, bezw. Ist die Regel dafür nicht oben in der Liste und kommt erst gar nicht zur Ausführung.
Du meinst wie hier im Screenshot?
https://forum.pfsense.org/index.php?topic=112764.msg627825#msg627825 -
Ja wie im Screenshot
Ich habe hier noch eine Apu rumfliegen, werde mal die nächten Tagen ein Asterisk aufsetzen
Das hier geht in die RichtungSee also: bug 14367 with a documentation fix for 1.6.
If you have problems with your network connection going up and down (e.g. an unreliable cable connection) and you keep losing your sip registry, you may want to add registerattempts and registertimeout settings to the general section above the register definitions. Setting registerattempts=0 will force Asterisk to attempt to reregister until it can (the default is 10 tries). registertimeout sets the length of time in seconds between registration attempts (the default is 20 seconds).
-
Spannend, ich hab mal den Wert "defaultexpirey=600" in der sip.conf testweise auf 50 reduziert, damit brauche ich kein Port Forwarding mehr.
Edit:
Zu früh gefreut, geht leider mit dem Telekom SIP wieder nicht. -
Hallo!
Vielen Dank für alle guten Ideen - es funktioniert wieder :). Unter anderem hat der Hinweis mit der Fritzbox hinter der pfSense sehr geholfen.
So und hier nun die Lösung:
Im NAT Port 5060 weiterleiten auf die Telefonanlage (wer glaubt es geht ohne Portweiterleitung möge mir mal erklären, wie die Telekom eingehende Anrufe signalisieren soll)
und nun der entscheidende Teil:
Manuelle Portweiterleitung unter dem Reiter Outbound (Hybrid) erstellen und ganz wichtig: das Häkchen bei statischem Port setzen. Danach hat es wieder problemlos funktioniert.Komischerweise war die Outbound-Einstellung vorhanden, wurde aber vermutlich beim Update von 2.3.1 auf 2.3.1_1 nicht mehr aktiv und es war "Manuell" statt "Hybrid" eingestellt. Ich habe diese Einstellung gelöscht und neu angelegt, nach 2-3 Minuten konnte man wieder abgehend telefonieren.
Danke an alle für die Hilfe.
Bis denn,
eweri -
Schön, daß es jetzt geht!
Im NAT Port 5060 weiterleiten auf die Telefonanlage (wer glaubt es geht ohne Portweiterleitung möge mir mal erklären, wie die Telekom eingehende Anrufe signalisieren soll)
Solange das VoIP-Gerät hinter der pfSense die Verbindung zum Telekom-Rechner offen hält, funktioniert auch umgekehrt eine eingehende Verbindung.
Aber ich habe das auch so mit static port konfiguriert.
Komischerweise war die Outbound-Einstellung vorhanden, wurde aber vermutlich beim Update von 2.3.1 auf 2.3.1_1 nicht mehr aktiv
Ah, das erklärt das Problem mit der Version.
-
Im NAT Port 5060 weiterleiten auf die Telefonanlage (wer glaubt es geht ohne Portweiterleitung möge mir mal erklären, wie die Telekom eingehende Anrufe signalisieren soll)
Wie schon geschrieben, woher soll die Telekom die IP Adresse deines Routers kennen, wenn nicht schon eine Verbindung von diesem zur Telekom aufgebaut wurde. Wenn eine solche Verbindung aber schon besteht, warum soll sie Inbound eine neue eröffnen, anstatt einfach die schon bestehende zu verwenden.