Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    VOIP fritzbox zu fritzbox Problem

    Deutsch
    3
    10
    1.5k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H
      heri410
      last edited by

      Hallo,

      ich habe ein Problem mit pfsense und komme einfach nicht weiter. Deswegen hoffe ich das mir hier jemand helfen kann. Ich habe 2 WAN Schnittellen.
      Eine Telekom und eine Unitymedia Internetleitung. Auf beiden Fritzboxen sind 3 Telefonnummer Konfiguriert. Im Netzwerk hinter der pfsense steht eine weitere Fritzbox als Telefonanlage und Wifi Router.
      Ich habe in der pfsense 2 Netze eingerichtet. Ein Netwerk mich zum testen und ein LAN in dem alle anderen Geräte sind, hier ist auch die Fritzbox als IP Client eingerichtet.

      Unitymedia Fritzbox 6490 Cable
      Telekom Fritbox 7390
      Firtbox für Wlan: 7590

      Das Problem ist jetzt das die Telefonverbindung immer nur kurz nach dem einrichten in der Lan Fritzbox funktioniert und beim zweiten Versuch die Gespräche nicht mehr annimmt. Die Anrufe werden in den WAN Fritzboxen angezeigt gehen aber nicht zur LAN Fritzbox durch.

      Vor pfsense habe ich eine UTM eingesetzt und hatte keine Problme die Konfiguration funktioniert also. Ich habe in der pfsense alles erlaubt und alles was irgendwie in den Weg des Telefons kommen kann ausgeschaltet.

      Habt ihr eine Idee wo ich das Problem such muss / was für Einstellungen nötig sind damit das Telefon funktioniert.

      Vielen Dank fürs lesen.

      1 Reply Last reply Reply Quote 0
      • A
        arnog
        last edited by

        Das klingt ein wenig so, als wenn die interne FRITZ!Box die NAT-Session an der pfSense nicht offen hält.

        Schau mal auf der FRITZ!Box unter Telefonie -> Eigene Rufnummern -> Anschlusseinstellungen. Da gibt es einen Punkt Telefonieverbindung (muss man evtl. ausklappen). Dort Portweiterleitung des Internet-Routers für Telefonie aktiv halten aktivieren und den Wert auf 30 Sekunden setzen. Das sollte die NAT-Session offen halten.

        1 Reply Last reply Reply Quote 1
        • H
          heri410
          last edited by

          Vielen Dank 👍 !

          Es lag wirklich an dieser Einstellung. Ich hatte es vorher höher eingestellt gehabt und jetzt funktioniert es wie es sollen.

          1 Reply Last reply Reply Quote 0
          • A
            arnog
            last edited by

            Als Ergänzung: Mit pfctl -s timeoutskann man sich die Timeouts auf der pfSense anschauen. Für VoIP sind die Werte für UDP interessant. Die Standardwerte mit Firewall Optimization Options auf Normal sind:

            udp.first    60s
            udp.single   30s
            udp.multiple 60s
            

            Zur Bedeutung von first, single und multiple siehe dort: https://docs.netgate.com/pfsense/en/latest/book/config/advanced-firewall-nat.html#state-timeouts bzw. https://docs.netgate.com/pfsense/en/latest/book/monitoring/firewall-states-gui.html#monitoring-states-interpreting.

            1 Reply Last reply Reply Quote 0
            • JeGrJ
              JeGr LAYER 8 Moderator
              last edited by

              Wenn man an den Optimization Options schraubt würde ich aber konkret nur den Wert erhöhen, der benötigt wird (in den entsprechenden Form Feldern unter System / Advanced ganz unten) und von "Normal" auf "Conservative" stellen, da sonst auch etliche andere Verbindungen wesentlich länger gehalten werden, als sie müssen. Im Zweifelsfall besser, das mit der Keepalive Funktion in der FB offen zu halten, anstatt zu riskieren, dass die pfSense dann bei einem UDP based DOS in den Seilen hängt, weil jemand meint, er muss mit DNS/UDP-Paketen Tontauben spielen :)

              Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

              If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

              1 Reply Last reply Reply Quote 0
              • A
                arnog
                last edited by

                Sehe ich genau so wie @JeGr. Wollte auch nicht implizieren, dass man an den Werten rumschrauben sollte. War nur dazu gedacht zu zeigen, wo man nachschauen kann, wenn man ein ähnliches Problem hat. :-)

                1 Reply Last reply Reply Quote 0
                • JeGrJ
                  JeGr LAYER 8 Moderator
                  last edited by

                  Alles gut - hatte ich auch nicht so aufgefasst. Da sowas aber gern mal nachgeschlagen wird und dann schnell jemand denkt, "oh hab keine FB aber wenn man einfach die Werte da anpasst, Bingo!" wollte ich die Warnung noch mit anbringen. Ja, das verlängert den State Timeout dann bspw. bei UDP Paketen, aber das heißt im Umkehrschluß auch, dass jemand mit udp-bullshit-bingo (kleine/0Byte-UDP-Pakete von extern in Masse als DOS aufs Interface geschossen) es natürlich noch leichter hat, die State Table zu überladen. Darum lieber auf VoIP/Anlagen-Seite schauen, was das Problem ist.

                  Zudem: Im Normalfall sollte der Keepalive gar kein Problem sein, da der eigentlich nur getriggert wird, wenn die Kommunikation von außen fehlschlägt. Somit denke ich eher, dass da die Kommunikation mit dem VoIP ISP nicht sauber konfiguriert ist und was fehlt. Dann wäre der UDP Holepunch/Timeout gar nicht notwendig :)

                  Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                  If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                  A 1 Reply Last reply Reply Quote 0
                  • A
                    arnog @JeGr
                    last edited by

                    @JeGr Wenn Ports geöffnet und weitergeleitet sind, stimme ich dir da auch zu. Da sollte es keine Problem mit dem Timeout geben. Wofür auch - schlägt da ja gar nicht zu. :-)

                    In meiner Konfiguration habe aber ich an der pfSense keinen Port für VoIP geöffnet und weitergeleitet, weil die Telekom symmetrisches RTP macht und mein Gigaset SL450A Go die "Verbindung" offen hält. Das klappt wunderbar.

                    1 Reply Last reply Reply Quote 0
                    • JeGrJ
                      JeGr LAYER 8 Moderator
                      last edited by

                      Jep, kann durchaus klappen. Muss auch nicht direkt "falsch per se" sein. Meistens ists aber so, dass die Systeme das nur als Fallback machen und bei korrekter Konfig von <src> -> <intern>:5060/5061/udp/tcp dann ohne Probleme funktionieren weil sie von extern damit getriggert werden können statt sich ständig aktiv zu halten. Push vs Pull :)

                      Daher das nur als Überlegung und Grundlage :)

                      Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                      If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                      A 1 Reply Last reply Reply Quote 0
                      • A
                        arnog @JeGr
                        last edited by arnog

                        @JeGr In der VoIP-Schnittstellenbeschreibung der Telekom ist Symmetrical RTP mandatory. Außerdem steht da auch noch drin, welche Pakete das UE schicken soll, um die NAT-Pinholes offen zu halten. Insofern sehe ich zumindest bei diesem Anbieter nicht die Notwendigkeit, das anders zu machen. Finde es auch deutlich einfacher. Wie du ja geschrieben hast, muss man halt nur die Timeouts im VoIP-Equipment entsprechend setzen, dass sie zu den pfSense-Werten passen. Und STUN muss bei mir deaktiviert sein. :-) https://www.telekom.de/hilfe/downloads/1tr114.pdf (Seite 52 & 55)

                        Aber stimmt schon, dass das nicht bei allen Providern Standard ist.

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.