[GELÖST] Unitymedia => pfSense => Fritzbox 7490 => Telefon
-
Hat noch wer eine Idee, was noch fehlen könnte, damit ich auch denjenigen höre, der mich angerufen hat?
-
Da gibts einige Möglichkeiten, wie hornetx11 schon erwähnt hat, ist SIP sehr flexibel was den Standard angeht.
Grundsätzlich müsste es mit den oben angegebenen PFS Einstellungen funktionieren, aber…
Manche Voip Provider wollen Stun, die anderen nicht. Bei manchen Provider muss man andere RTP Ports verwenden.
Es gibt noch die Möglichkeit das Paket Sipproxd zu installieren. Ich hab da zwar schlechte Erfahrungen damit gemacht, aber einen Versuch ist es wert. Wobei dir da womöglich wieder das doppelte NAT in die Suppe spuckt.
Was man noch machen kannst, ist einen größeren RTP Bereich forwarden. z.b. von UDP 5100 - 11000, jedoch in der Firewall blocken und mitloggen. Dann siehst du ob was auf einem anderen Port aufschlägt.
Oder du legst dir ein anderes Modem zu das den Bridge-Mode unterstützt ;)
-
Hallo chrisi51,
zunächst entferne bitte die WAN Regel Port 5060. Das hat Parsec schon mal erläutert warum 8)
Ansonsten sahen die Regeln gut aus, Outgoing-NAT von Fritzbox-IP mit Port 5060 und statisch ist richtig/nötig. Der Ton läuft über die RTP-Ports die je nach PBX unterschiedlich sind.
Anbei der Beitrag hier im Forum sowie ein Zitat von Parsec ;D
https://forum.pfsense.org/index.php?topic=112764.0
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 -
zunächst entferne bitte die WAN Regel Port 5060. Das hat Parsec schon mal erläutert warum
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!Ähm, jein. Das kann ich so nicht stehen lassen. Pauschal zu sagen dass man die Freischaltung nicht braucht ist falsch.
Manche Provider verlangen aus eigender Erfahrung die Weiterleitung dieses Ports.Und ja, bei alten Fritzboxen oder schlecht konfigurierten Asterisk Server bestand die Möglichkeit des Missbrauchs.
Bedenkt, dass alle Fritzboxen die als Router fungieren und direkt mit dem Internet hängen, den Port 5060 auf der WAN Seite offen haben.Wenn du eine FB mit einer FritzOS Version 6.50 oder höher hast, sind seitens AVM Vorkehrungen getroffen worden, dass so ein solcher Missbrauch nicht mehr möglich ist. (Sehr zum Leidwesen Jener, die die FB als Client einsetzen und über ein Thirtparty VPN oder einem anderen Subnetz drauf zugreifen wollen)
Gruß
Rubinho -
Also 5060 offen zu halten scheint tatsächlich doch nicht notwendig zu sein … ich habe mir nun noch mal https://doc.pfsense.org/index.php/VoIP_Configuration genauer angeschaut und einfach mal try'n'error praktiziert ...
also mal von der Fritzbox kommend alles im Outbound Nat Static zu machen .... DAS bringts ... Nach bisschen hin und her kam ich dann doch noch auf eine geistreiche Idee und habe nur 7078-7110 auf der Sourcesite static gesetzt ...
also im Outbound habe ich nun:
Mappings Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port WAN 192.168.1.80/32 * * 5060 WAN address * x WAN 192.168.1.80/32 7078:7110 * * WAN address * x
=> läuft ;)
jetzt steht wohl noch ein langzeittest aus um zu schaun wie stabil es ist.
-
Ich bin immer wieder überrascht, wieviel unterschiedliche Lösungen notwendig sind, um zum gleichen Ziel zu kommen…. so viel zum Standard :/
Sei froh, dass du nur einen Voip Provider benutzt. Ich habe 7 unterschiedliche Provider mit insgesamt 20 Accounts auf meinem Asterisk-Server am laufen und einige sind richtige Zicken !
(Und nein, die Accounts sind nicht alle für mich. Ich betreibe einen Internet Gemeindschaftsanschluss incl Telefonie)Trotzdem Glückwunsch :)
-
ja ich find's auch mächtig merkwürdig … aber wer weiß, an welcher Ecke diese Abhängigkeit nun ausgelöst wird ...
Gibt ja ausreichend Angriffsfläche. ;)
-
Moin,
;D nach meiner Erfahrung heißt es bei SIP nicht try'n'error sondern try and worry ;D
Wireshark wird hier zum besten Freund. Manchmal auch mit trap.HornetX11
-
Also 5060 offen zu halten scheint tatsächlich doch nicht notwendig zu sein … ich habe mir nun noch mal https://doc.pfsense.org/index.php/VoIP_Configuration genauer angeschaut und einfach mal try'n'error praktiziert ...
also mal von der Fritzbox kommend alles im Outbound Nat Static zu machen .... DAS bringts ... Nach bisschen hin und her kam ich dann doch noch auf eine geistreiche Idee und habe nur 7078-7110 auf der Sourcesite static gesetzt ...
also im Outbound habe ich nun:
Mappings Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port WAN 192.168.1.80/32 * * 5060 WAN address * x WAN 192.168.1.80/32 7078:7110 * * WAN address * x
=> läuft ;)
jetzt steht wohl noch ein langzeittest aus um zu schaun wie stabil es ist.
Ich habe leider auch nur wenige VOIPs machen müssen/können, bisher genügte mir aber die 5060 NAT Regel. Es gibt hier übrigens eine sicherere Umsetzung mit Port 5061 bei manchen Anlagen.
Die RTP Ports müssen glaube ich nicht Outbound geNATet werden. Ich meine das es aber deswegen bei dir geht, weil NAT vor den Firewallregeln abgearbeitet wird, und du somit die Ports (hinten herum) freigeschalten hast. Ich mache das üblicherweise am Interface per Firewall-Regeln, da dies bisher genügt hat. Also einmal 5060 Outbound NAT, sowie unter Firewall RTP ausgehend und am WAN eingehend per PortForewarding NAT. Je nach Anlage sind die RTP Ports dann andere als oben angegeben.
Grüße
-
@rubinho: wenn du so viele unterschiedliche SIP Provider am Start hast (inkl Zicken :D) - was wäre denn dann bspw. eine (oder mehrere) Empfehlungen von der Konfiguration (einfach) und Funktion her, wenn man einen alternativen SIP Provider sucht? Was wären denn Empfehlungen was Leistungen etc. angeht und recht wenig zicken bei der Konfiguration macht?
Grüße
-
@JeGr
an was hast du Gedacht ?Einen Provider zum Beherbergen deiner Rufnummern oder hauptsächlich zum raustelefonieren.
Meine Rufnummern hab ich momentan gesplittet, ein Teil meiner Rufnummern liegt bei Dus.net und ein anderer bei Sipgate.
Sipgate ist aber bei mehr als einer Nummer nur zu empfehlen, wenn du einen Asterisk Server betreibst. Ansonsten kannst du bei einem Basic Sipgate Anschluss nicht unterscheiden, auf welche Rufnummer angerufen wurde, weil du nur einen Sipaccount hast. Bei Dus sind es derweilen 5.
Beide Provider verlangen für das Beherbergen der Rufnummer einmalig für das Portieren Geld. Ab dann kostet es nichts mehr.Da aber sowohl Sipgate als auch Dus nicht die günstigsten Verbindungspreise besitzen, kann ich für ausgehende Gespräche folgende Provider empfehlen…
Wer eine preiswerte Festnetz-Flat benötigt, der kann sich mal bei Toplink-Xpress umsehen. Dort kostet die preiswerteste Flat 2,90€ (Eine Leitung als Analog Ersatz), 5,80€ (Zwei Leitungen als ISDN Ersatz) und 11,60€ (4 Leitungen)Für preiswertes Telefonieren (Fest und Mobil) ohne Flat, kann ich Voip2GSM empfehlen. 3,8ct/min ins Mobilfunknetz bzw 0,8ct/min ins Festnetz. Taktung ist 30/30
Beide Provider erlauben Clip no Screening, d.h. man kann die Ausgehende Rufnummer am Endgerät festlegen. (Ein Feature das nicht jeder anbietet.)
Aber nur bei Toplink kannst du ne echte Nummer beantragen, oder portieren lassen. Falls man alles bei einem Provider haben möchte.
Zickig ist meiner Erfahrung nach hauptsächlich Dus.net (Bei eingehenden Verbindungen). Aber wenn die Konfig passt, läuft auch Dus.net problemlos.