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,
    eweri

    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?


  • Moderator

    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, 443

    Hinweise:
    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 Forbidden

    Wenn 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?



  • @eweri:

    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.

    @eweri:

    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 Forbidden

    Wenn 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?



  • @eweri:

    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.1

    Eingehend 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.



  • @Parsec:

    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.



  • @Parsec:

    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.

    @Parsec:

    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?



  • @Parsec:

    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.



  • @Parsec:

    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.

    @Parsec:

    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?

    @Parsec:

    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 Richtung

    See 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!

    @eweri:

    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.

    @eweri:

    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.



  • @eweri:

    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.



  • @Parsec:

    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.

    Ja Du hast recht, ich hab jetzt mal qualify=25000 in der sip.conf gesetzt und schon braucht man kein Port Forwarding mehr.
    Offenbar wollen das aber nicht alle Anbieter, manche SIP Endgeräte machen das automatisch sobald sie hinter NAT sind.

    Ist dieser Wert auch bei dir gesetzt?



  • Hey,

    hatte vor wenigen Tagen das Vergnügen auch meine erste VoIP TK hinter einer PF online zu bringen.

    Zunächst danke an Parsec für den Tipp mit dem Outgoing Nat!

    Port 5060 Udp mit static port und außerdem  ausgehend sowie eingehend über Forwarding die RTP Ports geleitet. Es funktioniert, kurioser Weise ist es ziemlich egal ob ich das Bündel Ports öffne wie es die Telekom empfiehlt, oder auch andere wie die aus dem Handbuch der Anlage, es geht scheinbar immer mit den  Sprachdaten.

    Ein Problem besteht allerdings in diesem speziellen Fall, von 4 gebuchten Leitungen gehen immer nur 2 parallel. Ich vermute die Anlage als falsch konfiguriert. Oder gäbe es technisch überhaupt die Möglichkeit an der PF sowas absichtlich oder aus versehen zu unterbinden?

    Mir fiel außerdem in den states auf, das die Anlage zeitgleich über den Port 5060 zu 2 IPs kontakt hat, ist das normal? Dachte je port geht dann auch nur eine IP als gegenüber?

    Grüße an alle :)



  • Welcher Tarif?



  • @sebden:

    Port 5060 Udp mit static port und außerdem  ausgehend sowie eingehend über Forwarding die RTP Ports geleitet. Es funktioniert, kurioser Weise ist es ziemlich egal ob ich das Bündel Ports öffne wie es die Telekom empfiehlt, oder auch andere wie die aus dem Handbuch der Anlage, es geht scheinbar immer mit den  Sprachdaten.

    @slu:

    Ja Du hast recht, ich hab jetzt mal qualify=25000 in der sip.conf gesetzt und schon braucht man kein Port Forwarding mehr.
    Offenbar wollen das aber nicht alle Anbieter, manche SIP Endgeräte machen das automatisch sobald sie hinter NAT sind.



  • @Parsec:

    Welcher Tarif?

    Kann leider nur sagen dass es sich um die Telekom handelt, und das die ganze Aktion verbunden war mit der Umstellung auf Vdsl :/

    Auf die Anlage habe ich leider keinen Zugriff, und der Tarif ging aus den paar Unterlagen nicht hervor.

    Grüße



  • @slu:

    @sebden:

    Port 5060 Udp mit static port und außerdem  ausgehend sowie eingehend über Forwarding die RTP Ports geleitet. Es funktioniert, kurioser Weise ist es ziemlich egal ob ich das Bündel Ports öffne wie es die Telekom empfiehlt, oder auch andere wie die aus dem Handbuch der Anlage, es geht scheinbar immer mit den  Sprachdaten.

    @slu:

    Ja Du hast recht, ich hab jetzt mal qualify=25000 in der sip.conf gesetzt und schon braucht man kein Port Forwarding mehr.
    Offenbar wollen das aber nicht alle Anbieter, manche SIP Endgeräte machen das automatisch sobald sie hinter NAT sind.

    Das wäre für mein Verständnis nicht korrekt, ohne die RTP Ports ins Forwarding einzutragen ging der Ton in keine Richtung. Ob das für den SIP Port ohne den static Port geht habe ich zugegeben gar nicht probiert, da es mir einfach gleich logisch erschien. Trotzdem danke für die Zusammenfassung. :)



  • @sebden:

    Das wäre für mein Verständnis nicht korrekt, ohne die RTP Ports ins Forwarding einzutragen ging der Ton in keine Richtung.

    Da muss ich wiedersprechen.
    Bei der Telekom zumindest geht das sehr wohl.
    Die machen ich glaube das heißt symmetric rtp (bitte nicht festnageln) sprich von dem RTP Port wo dein RTP herkommt schicken die auch wieder hin. Die Firewall macht das dann ja automatisch auf.

    Ich habe tatsächlich nur zwei Dinge in der PfSense angepasst
    1. Static Port (Bei Outbound NAT) für die IP meines Telefons so werden dann weder Signaling noch RTP Port verändern und mit der Methode von oben kommt damit alles durch
    2. UDP Timeouts so angepasst das diese höher sind also mein NAT Keepalive im Telefon dann bleibt die Firewall für eingehende Gespräche offen.

    Kein Inbound NAT weder für Signaling noch für RTP und klappt seit Jahren ohne Probleme.

    Klar kann man das auch mit Inbound NAT machen das ist dann aber immer offen.
    Bin eher ein Freund davon nur bei Bedarf zu öffnen.
    Bei Signaling ist es ja immer offen aber eben nur durch keepalive (muss ja auch kann ja immer mal was ankommen) schalte ich das Telefon aber aus ist auch das zu.



  • Hallo flix87,

    du hast also die Outbound NAT Regel für destination port "*" gesetzt statt wie ich nur für 5060 UDP?

    Grüße



  • Ja genau da ich eben wollte das auch die RTP Ports drin sind.
    Besser und genauer wäre natürlich 5060 und dann noch einen Regel mit dem RTP Ports.
    Hier war ich etwas faul  ;) aber viel mehr als Telefonieren macht das Ding ja nicht. Ab und an mal ein Update das passt aber schon.



  • @flix87:

    @sebden:

    Das wäre für mein Verständnis nicht korrekt, ohne die RTP Ports ins Forwarding einzutragen ging der Ton in keine Richtung.

    Da muss ich wiedersprechen.
    Bei der Telekom zumindest geht das sehr wohl.
    Die machen ich glaube das heißt symmetric rtp (bitte nicht festnageln) sprich von dem RTP Port wo dein RTP herkommt schicken die auch wieder hin. Die Firewall macht das dann ja automatisch auf.

    Ich habe tatsächlich nur zwei Dinge in der PfSense angepasst
    1. Static Port (Bei Outbound NAT) für die IP meines Telefons so werden dann weder Signaling noch RTP Port verändern und mit der Methode von oben kommt damit alles durch
    2. UDP Timeouts so angepasst das diese höher sind also mein NAT Keepalive im Telefon dann bleibt die Firewall für eingehende Gespräche offen.

    Kein Inbound NAT weder für Signaling noch für RTP und klappt seit Jahren ohne Probleme.

    Klar kann man das auch mit Inbound NAT machen das ist dann aber immer offen.
    Bin eher ein Freund davon nur bei Bedarf zu öffnen.
    Bei Signaling ist es ja immer offen aber eben nur durch keepalive (muss ja auch kann ja immer mal was ankommen) schalte ich das Telefon aber aus ist auch das zu.

    Das wars.  ;D

    Großen Dank an flix87 und Parsec. Telefonieren mit der Fritze klappt jetzt endlich. Alle unnötigen Regeln sind entfernt und auf der Fritz!Box unter "EigeneTelefonnummer/Anschlußeinstellung" die "Portweiterleitung des Internet-Routers für Telefonie aktiv halten" auf 30 s gesetzt.

    Jetzt habe ich meine pfSense wieder lieb.  ;D ;D ;D



  • koennen die notwendigen Einstellungen mal exakt genannt werden?
    Ich habe noch ein paar Porte inbound und wenn ich hoere, dass man diese nicut braucht würde ich sie gerne eliminieren.
    Welcher Punkt ist das mit dem Timout? Von welchen Wert auf welchen Zielwert?
    Danke!



  • Klar.
    Erstmal:

    Ich habe tatsächlich nur zwei Dinge in der PfSense angepasst
    1. Static Port (Bei Outbound NAT) für die IP meines Telefons so werden dann weder Signaling noch RTP Port verändern und mit der Methode von oben kommt damit alles durch
    2. UDP Timeouts so angepasst das diese höher sind also mein NAT Keepalive im Telefon dann bleibt die Firewall für eingehende Gespräche offen.

    Zu 1: Bild im Anhang. Die IP ist die Fritz!Box, wichtig ist der Haken bei Static Port.

    Zu 2: Das geschieht in der Config der Fritz!Box. Unter Eigene Rufnummern/Anschlußeinstellungen ganz unten. Den Refresh  auf 30 Sekunden stellen.

    Mehr brauchst nicht einstellen. Alle 30 Sekunden triggert die Fritz!Box den SIP-Server der Telekom an, dadurch bleiben alle Ports offen die Du brauchst.

    Mike

    ![pfSense.home - Firewall: NAT: Outbound - Mozilla Firefox_015.jpg](/public/imported_attachments/1/pfSense.home - Firewall: NAT: Outbound - Mozilla Firefox_015.jpg)
    ![pfSense.home - Firewall: NAT: Outbound - Mozilla Firefox_015.jpg_thumb](/public/imported_attachments/1/pfSense.home - Firewall: NAT: Outbound - Mozilla Firefox_015.jpg_thumb)



  • Ok danke, das mit dem static Port habe ich ebenfalls. Zusaetzlich habe ich allerdings noch den Destination Port auf UDP/* beschraenkt…

    In der Fritte habe ich die 30 Sek auch eingestellt.

    Was ich allerdings noch habe ist:

    Portforwarding 7078-7110 UDP auf die Fritte 7078-7110.
    Zuvor sind naemlich immer Gespraeche nach 7 oder 10 Minuten ca. abgebrochen.

    Bei Dir klappen auch laengere Gespraeche?

    Was bei mir nicht funktioniert ist, dass ausgehende Gespraeche in HD (722G) laufen. Das klappt nur bei ankommenden...



  • Moin.

    Wir nutzen den Festnetzanschluss kaum noch, und mit der pfSense in dieser Art erst seit Mitte letzter Woche. Langzeiterfahrungen fehlen hier noch, sehe gerade ein Gespräch mit 47 Minuten in der Anrufliste.

    Zum Thema HD, wir nutzen noch Mobilteile von Gigaset, da gehörte Gigaset noch zu Siemens. Nix mit HD, daher keine Probleme. :)



  • Also bei mir klappt das schon seit Jahren mit den oben genannten Einstellungen.
    Auch gespräche länger als 10 Minuten sind kein Problem.


  • Moderator

    Möchte das vielleicht jemand mal als neuen Beitrag mit [HowTo] Tag zusammenschreiben mit 2-3 begleitenden Screenshots oder Bildern (auch von der Fritzbox als Beispiel für den Keepalive)? Dann würde ichs oben anpinnen :)



  • Klar.

    Scheint bei Einigen noch nicht richtig zu funktionieren, wollen wir noch auf paar positive Feedbacks warten?

    Mike


  • Moderator

    Gerne, möchte nur ungern dass es in Vergessenheit kommt. Editieren kann man es später ja immer noch ;) Und Flix, du und andere haben da ja schon einiges an Vorarbeit geleistet.



  • Ich habe das mal gemacht.
    Ich denke auch das es wichtig ist. All over IP kommt immer mehr.
    Diese thema hatten wir schon oft im Forum auch hier im deutschen Teil. Trotzdem wird es immer wieder gefragt.
    Anpassen kann man immer noch.
    Bitte nochmals drüber lesen und ggf. ändern (Wenn der Moderator das kann) ansonsten passe ich gerne nochmal an.