OPNsense Forum
International Forums => German - Deutsch => Topic started by: inkasso on March 17, 2022, 11:17:30 am
-
Bevor einer schreit: Ja - es gibt hier oben angepinnt einen Thread zum SIProxD und bestimmt wurde einiges zu dem Thema auch schon an anderer Stelle gesagt... nur je mehr ich lese, um so weniger kapier ich :-\
Eckdaten
Telekom Fiber Anschluss <-> modifiziertes HUAWEI SPF GPON ONT <-> (dummer) Medienwandler <-> Sense <-> Internes LAN <-> Gigaset Go Box 100
Es wird bei einem single WAN bleiben. Ich überlege ggf. die Telefonie in ein eigenes VLAN zu stecken, hängt aber davon ab, ob es zu viel Stress bei der Konfiguration macht.
VoIP
Ich muss über die GoBox das Telekom VoIP abbilden. Die GoBox hat selbstständig Einstellungen für den Provider Telekom (wohl vom Hersteller) gezogen und mit diesen auch erfolgreich die Rufnummern angemeldet. Anrufen ging, aber keiner hat Ton gehört, sobald man abgenommen hatte.
Zur Problemlösung habe ich mir angesehen, welche Ports für SIP und RTP in der GoBox definiert sind (man kann wählen ob zufällige Ports genutzt werden sollen -> hab ich abgeschaltet gelassen). Es handelt sich um die Ports 5060 - 5076 für SIP und 5004-5020 für RTP. Diese hab ich dann vom WAN Interface auf die GoBox geNATet. Seitdem funktioniert es mit dem Ton bei Anrufen.
Ferner habe ich von meinem Job noch ein SIP Telefon hier stehen, dass sich auf die virtuelle Telefonanlage unserer Firma verbindet (nFon AG). Das Ding kann ich nicht umkonfigurieren, muss aber weiter funzen. Es hängt ebenfalls aktuell im internen LAN und zeigt sich völlig unbeeindruckt davon, dass die Sense dazwischen hängt.
Probleme
Die GoBox hängt sich immer wieder mal auf und ich muss sie neustarten, um überhaupt wieder dran zu kommen. Ich vermute, das hat mit einer "halbgaren" VoIP Konfiguration auf der Sense zu tun, denn als sie noch hinter der Fritzbox arbeiten musste, funktionierte sie ohne Aussetzer.
Die angemeldeten Rufnummern können nach einiger Zeit plötzlich nicht mehr angemeldet werden. Auch hier hilft ein Neustart der GoBox. Ich hab was gelesen von "nicht automatische Anmeldung der Rufnummern" verwenden, sondern Zugangsdaten einrichten und hinterlegen. Ich finde aber nichts in meinem Kundencenter bei der Telekom, wie ich da Benutzername/Passwort für vergebe oder automatische Anmeldung deaktiviere...
Ich überlege, ob ich SIProxD brauche und ob ich nicht spätestens dann Probleme mit meinem IP Telefon meines Arbeitgebers bekomme.
Alles in allem herrscht also totale Verwirrung. Und in Anbetracht des Telefons meines Arbeitgebers hier bin ich auch nicht sonderlich experimentierfreudig. Wäre nett, wenn mich hier jemand an die Hand nimmt.
Gruß
Manuel
-
Hi Manuel,
Hatte eine sehr ähnliche Konfiguration, die mir schlaflose Nächte bereitet hat. Zwar kein Huawei in der Kette, aber ansonsten ziemlich ähnlich ...
Mit der Lösung, die ich hier beschrieben habe absolut stabil, musste ich nicht wieder anfassen seither ..
https://forum.opnsense.org/index.php?topic=25332.msg121994#msg121994 (https://forum.opnsense.org/index.php?topic=25332.msg121994#msg121994)
Br br
-
Hi bringha,
Danke für den Schubs!
Ich habe mir mal noch 1-2 Dinge bei dir abgeschaut.
Refresh runter auf 500 und flush states bei IP Change.
Außerdem habe ich die NAT Regel von UDP only auf TCP/UDP erweitert.
Mal sehen, wie gut/schlecht es jetzt die nächste Zeit läuft.
Und dann ist da noch eine Sache, die ich gern ändern würde, bei der ich mir aber auch nicht sicher bin. Aktuell ist die NAT Regel für Source = any. Hier würde ich das schon gern auf die entsprechenden Telekom-Server einschränken. Aktuell wüsste ich mir nur über Beobachtung zu helfen, um herauszufinden, was ich da alles für Server als "gültig" angeben müsste.
Gruß
Manuel
-
Ich habe in der NAT Regel Source auf das Telekom Netzwerk 217.0.0.0/8 gesetzt, da bist du auf der sicheren Seite.
Br br
-
Ja, das macht es zwar etwas besser, aber ~16,7 Mio IPs sind mir ungefähr 16,7 Mio zu viel. Ich hatte da eher an eine maximal dreistellige Zahl gedacht.
-
Na ja, das ist sicherlich grundsätzlich richtig, allerdings befinden sich im 217er Netz nahezu alle Adressen der Telekom für deren öffentliche Services, wie DNS, SIP, STUN, .... und diese sind dann nochmals regional aufgeteilt, d.h. Frankfurt hat einen anderen empfohlenen DNS Server als Köln etc, gleiches zB bei SIP; bei meinen endlosen Versuchen war es durchaus so, dass der Wizzard auf GoBox von Konfigurationsversuch zu Konfigurationsversuch andere Adressen für den SIP und STUN Server eingetragen hat .... Änderungen passieren zB auch bei Störungen oder Wartungsarbeiten wenn sich die GoBox dann neu verbindet.
Meine Versuche mit einem 217.XXX.0.0/16 waren jedenfalls gefühlt suboptimal ....
Ist also etwas herausfordernd, da für Deinen Ort die Richtige Kombi aus relevanten Subnetzadressen herauszufinden
Br br
-
Na ja... DNS von der Telekom nutze ich ja schon mal wegen der Zensur generell nicht ;)
Kleiner Zwischenbericht: Mit 500 Sekunden und 400 Sekunden Refresh funktioniert es bei mir schon mal nicht. Die 300 sind jetzt eingetragen - mal sehen, wie es wird.
-
Hallo,
ich trage bei den Telekom VoIP-Configs immer 217.0.0.0/13 ein - und zwar bei der Portweiterleitung (Source). Das sind zwar auch sehr viele Adressen (217.0.0.1 - 217.7.255.254), jedoch meiner Erfahrung nach gibt es keine Probleme.
Bei NAT wäre der Telekom-Bereich ja die Destination...
Leider gibt es von der Telekom keine offiziellen Ranges.
Gruß
Robert
-
Leider funktionierts selbst mit den 300 Sekunden Refresh nicht. Immer wieder sehe ich "Anmeldung fehlgeschlagen" und wenn ich dann für eine der Rufnummern die Konfiguration öffne und speicher (ohne Änderung) geht es wieder. Bin so langsam ratlos was ich noch machen soll :-/
Wenigstens stürzt die Box nicht mehr ab, aber das is so kein Zustand. Aktuell sind wir eigentlich nur noch verlässlich über Handy zu erreichen.
-
Hallo,
versuch doch mal einen Wireshark-Mitschnitt zu machen. Wenn es VoIP-Probleme gibt, ist das meist die einfachste Methode um der Lösung näher zu kommen. Ich würde, wenn möglich, auf der WAN-Schnittstelle und im LAN parallel mitschneiden. Dann kann man gut vergleichen, was von innen kommt und was von außen.
Ich weiß nicht genau, wie das unter Windows realisierbar wäre, jedoch mit Linux oder macOS kann man relativ leicht eine SSH-Verbindung zur Sense aufbauen und dann die Ausgabe an Wireshark leiten. Ich mache das unter Linux so:
ssh root@sense -p22 "tcpdump -i igb0_vlan21 -U -w - port not 22" | wireshark -i - -k
Gruß
Robert
-
Oh, das ich das von der Sense so rüber schicken kann, dass hab ich nicht erwartet.
Ein WireShark war auch meine Idee, aber gerade auf der Außenseite hätte ich nicht gewusst, wie ich das geschickt anstelle. Die Sense kann ja Mitschnitt, aber ich weiß nicht wie viel da rein gepasst hätte. Die Dumps sind danach in Wireshark einlesbar.
Gut das ich ein paar Linux Rechner hier habe. Mache ich nachher mal startklar :)
UPDATE: Nach etwas Umkonfiguriererei - root durfte sich bei mir nicht per ssh anmelden... - mache ich gerade parallel einen dump vom internen VLAN auf dem alles stattfindet und auf dem pppoe Adapter. Mal sehen, was das gibt.
-
So - hab gestern 400MB Mitschnitt über ca 2 Stunden gemacht. Natürlich sind die Telefone währenddessen nicht ausgefallen :-/
Hab sogar erfolgreich ein längeres Telefonat geführt ohne Probleme. Etwas später am Abend dann wieder Probleme. Ich rufe an, Gegenstelle nimmt ab, ich kann hören abder die Gegenstelle nicht.
Heute früh dann wieder "Anmeldung bei Provider nicht erfolgreich" im Display der Telefone.
Was ich in den Logs auffällig fand, war der REGISTER request gefolgt von einem 401 Unauthorized - nur dass es dann doch ein paar Versuche Später ein 200 OK gibt. Hab das mal als Bild angehängt.
-
Da die Telekom gerade ihre IMS Plattform umstellt/erneuert kann es helfen die SIP-Registrierung von UDP auf TCP umzustellen (Wenn es sich um einen ALL-IP Anschluss handelt, bei SIP-Trunk funktioniert eh nur TCP oder TLS)
Zum Thema DNS habe ich folgende Informationen für dich:
Damit die Telefonie Reibungslos funktioniert habe ich im, AdGuard u.g. DNS-Server für meine VoiP Geräte (2 SIP-Telefone und 1 FreePBX) als Upstream-DNS-Server hinterlegt.
DNS im VoIP-Umfeld an Telekom-Anschlüssen
Grundsätzlich soll in einem TK-System (bzw. Router) immer der DNS Server des jeweiligen Internetzugangsanbieters eingetragen werden. Bei Telekom-Anschlüssen mit PPPoE Einwahl (xDSL) werden diese automatisch bei der Einwahl vergeben. Bei CompanyConnect (CoCo)/DeutschlandLAN Connect IP (DCIP) sowie beim Business Premium Access (BPA) sind diese auf dem Kundenanschreiben hinterlegt.
DNS im VoIP-Umfeld bei Fremdaccess
Falls der Kunde einen Fremdaccess nutzt (z.B. Vodafone als Trägerleitung) sollten auch die DNS Server des Anbieters eingetragen werden. Falls diese kein eDNS und ECS unterstützen, kann der DNS-Server der BPA-Anschlüsse verwendet werden.
DNS-Server für BPA
| Standort | IPv4 Adresse | IPv6 Adresse | Reverse Lookup Name |
| Frankfurt | 194.25.0.70 | 2003:40:2000::0B9A | resolvbpa-f.t-ipnet.de |
| Hannover | 194.25.0.62 | 2003:56::0B9A | resolvbpa-h.t-ipnet.de |
| Leipzig | 194.25.0.54 | 2003:40:4000::0B9A | resolvbpa-l.t-ipnet.de |
Was passiert, wenn ich einen falschen DNS-Server nutze?
Wird beispielsweise an einem Fremdaccess oder Company Connect ein DNS-Server verwendet, der eigentlich für PPPoE-Anschlüsse der Telekom (z.B. xDSL, FTTH) vorgesehen ist, wird dieser entsprechend die SIP-Proxys (P-CSCF) zurückgeben, welche eine aktivierte Bandbreitenreservierung beherrschen. Diese Bandbreitenreservierung würde aber fehlschlagen, da das RACS (Resource and Admission Control Subsystem) beim Fremdaccess oder Company Connect keine Bandbreitenreservierung ermöglichen kann. Somit würde die SIP-Registrierung erfolgreich durchgeführt, aber keine Gespräche möglich.
Umgekehrt wäre bei einem PPPoE Anschluss und Abfrage eines DCIP-DNS Servers keine Bandbreitenreservierung möglich, da vom DCIP-DNS Server der falsche RACS zurückgegeben würde.
Eine weitere Fehlerquelle besteht darin, dass am Fremdaccess bei Verwendung eines DNS-Servers der Telekom bei einer SRV-Anfrage Server für die Nutzung von Diensten angeboten werden, die über den Fremdaccess nicht erreichbar sind.
-
... uns sollte auf der GO Box die Firmware 42.259 laufen UND der Gigaset.net Service Parallel zum Telekom Service aktiv sein, dann könnte auch das die Ursache für die verloren gehende SIP Registrierung sein: Aus was für Gründen auch immer hört dann die Box nach ein paar Stunden auf, SIP refresh's an den Telekom Server zu schicken.
Ich habe nicht ausprobiert, on das ein generelles Problem bei mehreren aktiven Telefonieanbietern auf der Box ist, jedenfalls habe ich Gigaset.net deaktiviert und nur noch Telekom aktiv und seit dem ist das ganze stabil ....
br br
-
Zunächst mal: ich nutze aktuell gar keinen DNS vom ISP. Bei mir läuft piHole mit 2 freeDNS Servern. piHole ist einziger DNS (per DHCP verteilt) und piHole schickt lokale Anfragen an die Sense weiter um die lokale Namensauflösung zu ermöglichen.
Natürlich könnte ich mir jetzt aus dem PPPoE Log raussuchen, was für DNS die Telekom gern hätte und die der GoBox per DHCP zuweisen lassen. Bin nur noch nicht so ganz überzeugt, dass es daran liegt.
GoBox Firmware ist tatsächlich 42.259, aber die Gigaset.net Dienste hab ich nicht aktiv - will ich auch gar nicht haben. Mich nervt, dass ich sie nur deaktivieren, aber nicht löschen kann.
Ich hab da allerdings noch eine Reihe von Konfigurationsparametern, die mir nichts sagen, und die ich mal googeln muss:
- DNS SRV Lookup benutzen (aktuell testweise ja - hat aber nix gebracht)
- STUN benutzen (aktuell ja, ich hörte aber auch davon, dass manche den nicht nutzen)
- Outbound Proxymodus immer/auto/nie/DHCP Option 120 "SIP Server" benutzen
Probeweise begrenze ich ihn jetzt mal auf TCP und schau, ob sich dadurch was tut.
UPDATE: Also nur TCP funktioniert auch nicht. Von 5 Rufnummern kann ich nur die ersten 2 anmelden. Die Übrigen funktionieren nicht - trotz identischer Einstellung.
-
Auf der Go Box:
stun benutzen ja, stun refreshzeit 240, NAT refreshzeit 20, DNS SRV lookup ja, wurde letztes Jahr umgestellt bei Telekom.
domain tel.t-online.de, gleiches für proxy Serveradresse und Registration server und outbound Serveradresse
Outbound proxy modus nie
Ich verwende d_magenta_de.bin als Profilversion
dann bei weitere VOIP Einstellungen: SIP Update ja, Zieladresse ableiten: aus SIP contact Header
die RTP Ports müssen sowohl eingehend als auch ausgehend denen entsprechen, die in den FW/NAT Regeln angegeben sind.
Br br
-
Ich habe zwar das Gigaset N510 IP Pro aber die Einstellungen sollten ja die gleichen sein:
DNS SRV Lookup
Lookup benutzen Ja
Allgemeine Anmeldedaten Ihres VoIP-Providers
Domain: tel.t-online.de
Proxy-Serveradresse: tel.t-online.de
Proxy-Serverport:
Registration-Server: tel.t-online.de
Registration-Serverport:
Anmelde-Refreshzeit: 600 Sek.
Allgemeine Netzwerkdaten Ihres VoIP-Providers
STUN benutzen: Nein (Wird auch nur benötigt wenn mehr wie ein mal "geNATed" wird // siehe erklärung unten)
Outbound-Proxymodus: Nie
Netzwerkprotokoll auswählen: "Automatisch"
Erläuterung zu STUN aus den TEchnischen Unterlagen der Telekom:
STUN
Die VoIP-Plattform der Telekom hat eine eingebaute automatische NAT-Erkennung.
- Hierfür muss die TK-Anlage symmetrisches RTP unterstützen, d.h. bei ein- und ausgehenden Gesprächen muss die TK-Anlage den RTP-Strom selbst als erstes aufbauen. Nach drei eingegangen RTP-Paketen erkennt die Plattform den Datenstrom und baut ihrerseits zur selben Port (und IP) eine RTP-Verbindung auf. Die Erkennung basiert auf der abgehenden IP (aus dem SIP-Paket) des angesprochenen Telekom Gateways (aus dem SDP) und den angesprochenen Gateway-IP-Ports (SDP). Weitere Angaben im SDP (insb. TK-seitige IPs und Ports) werden ignoriert.
- STUN „torpediert“ diese NAT-Erkennung, da die Plattform NAT nicht mehr erkennen kann.
- Wenn STUN zum Einsatz kommt, muss aus jeden Fall sichergestellt sein, dass eingehende RTP-Verbindungen akzeptiert werden (mit einer normalen NAT-Firewall ist dies normalerweise nicht möglich), da die Plattform kein symmetrisches RTP anwendet.
- STUN sollte daher nur in Ausnahmefällen eingesetzt werden.
- Mit symmetrischen NAT ist eine Verbindung in Verbindung mit STUN in der Regel gar nicht möglich. Einige Router (z.B. Bintec) bieten aber mittels eines Assistenten die Möglichkeit, auf "Full Cone" NAT umzustellen. Damit ist dann eine Verbindung auch möglich, wenn die TK-Anlage STUN erzwingt.
Symmetrisches RTrtP / NAT-Erkennung / STUN
Die VoIP-Plattform der Telekom hat eine eingebaute automatische NAT-Erkennung. Hierfür muss die TK-Anlage symmetrisches RTP unterstützen. STUN „torpediert“ diese NAT-Erkennung und sollte nur in Ausnahmefällen eingesetzt werden.
-
An meinem privaten VOIP Anschluss bekomme ich das ohne STUN in Verbindung mit static ports nicht ans laufen, muss also bei mir aktiviert sein;
Nach meinen Informationen braucht man STUN bei einem SIP Trunk Anschluss, zB Deutschland LAN in der Tat nicht, habe aber mangels Möglichkeit noch nicht selbst ausprobiert ...
br br
-
Habe die GoBox nun in ein eigenes VLAN gesteckt (wollte ich ursprünglich ja eh).
Die Einstellungen sind wieder auf Auto für TCP/UDP.
Ich musste eine NAT Regel bauen, damit ich auf die Oberfläche von der GoBox komme, denn sie redet wohl nur mit Geräten im selben Subnetz (was ich für ein vernünftiges Sicherheitsfeature halte).
Probleme sind immer noch da. Jetzt wo die Kiste aber ihr eigenes VLAN hat, kann ich gezielter und länger das Capture laufen lassen. Evtl kommt man dann mal dahinter wo es hakt. Heute hatte ich z.B. wieder Ton Probleme. Ich kann keine MFV Töne übertragen um bei Ansagen durchs Menü zu steuern.
-
In der 510IP gibt es unter:
Netzwerk —> IP-Konfiguration—> „Weitere Einstellungen“
Den Punkt „ Zugriff aus anderen Netzen zulassen“. Damit funktioniert dann auch der Zugriff (bei mir) aus dem „LAN“ auf die 510IP (VOIP NETZ).
@bringha
Ich habe auch „nur“ einen All IP Anschluss und keinen SIP-Trunk und dass läuft ohne STUN.
MfG
-
Hab doch glatt übersehen, dass vor meiner Antwort noch Antworten gekommen sind mit Dingen, die ich ausprobieren sollte. Keine Angst - mache ich morgen!
Aktuell läuft zumindest mal eine Aufzeichnung über die ganze Nacht, denn morgens sind die Telefone immer unregistriert und evtl. sehe ich dann mal warum.
-
Auf der Go Box:
stun benutzen ja, stun refreshzeit 240, NAT refreshzeit 20, DNS SRV lookup ja, wurde letztes Jahr umgestellt bei Telekom.
domain tel.t-online.de, gleiches für proxy Serveradresse und Registration server und outbound Serveradresse
Outbound proxy modus nie
Das hat bei mir der Einrichtungsassistent selbst alles schon so eingerichtet gehabt. Nur DNS SRV lookup hab ich manuell aktiviert - und ja das hatte ich schon gemacht bevor ich hier gepostet habe, weil ich einen Link zu einer Telekom Seite hier im Forum gesehen habe, wo erklärt wurde, was eingestellt werden sollte.
Ich verwende d_magenta_de.bin als Profilversion
Ich weiß nicht wie du das "verwendest". Bei meiner GoBox steht das nur als Profil da - wahrscheinlich das, was die Box selbst identifiziert hat und dann von Gigaset runtergeladen hat. Ich habe allerdings ein anderes Profil da stehen: d_telekom_de.bin
dann bei weitere VOIP Einstellungen: SIP Update ja, Zieladresse ableiten: aus SIP contact Header
die RTP Ports müssen sowohl eingehend als auch ausgehend denen entsprechen, die in den FW/NAT Regeln angegeben sind.
Br br
Die Einstellungen habe ich ebenfalls gleich. Wobei ich mir nicht ganz sicher bin ist, ob die NAT Regel stimmt.
Firewall => NAT => PortFoward
Interface: WAN
TCP/IP: IPv4 (IPv6 hab ich überall disabled und die Firewall dropt es auch)
Protocol: TCP/UDP
Source: any
Source Port range: any
Dest: any
Dest Port range: (Alias VoIP Ports bei from und to)
Redirect Target IP: (Alias für GoBox IP)
Redirect Target Port: (Alias VoIP Ports)
Im Alias für die VoIP Ports sind alle Ports, die auf der GoBox für SIP und RTP gelistet sind.
Also SIP 5060-5076 und RTP 5004-5020
Was mir beim Mitschnitt von heute Nacht auffällt: Ich habe ungefähr um 20 Uhr gestartet und alles läuft zunächst wie ein Uhrwerk. Ab 23:40 Uhr hatte ich dann eigentlich nur noch STUN Requests mit Antwort aber die GoBox hat keine SIPs mehr geschickt.
Um etwa 2 Uhr nachts hat die GoBox dann nach Profil-Updates bei Gigaset gesucht. Hat aber anschließend weiterhin nur STUNs geschickt und keine SIPs.
Erst als ich heute früh die Box über ein Telefon hab neu starten lassen, kam dann wieder reichlich Bewegung in die Aufzeichnung und neben Anfragen an dynreg.gigaset.net gab es dann auch wieder die normalen SIPs an die Telekom.
-
Das Magenta Profil erhältst Du im Wizzard in der Providerliste, da kommt direkt nach Telekom dann Magenta; da gibts auch noch andere der Telekom, wie t-online etc., das Profil sollte zu Deinem Vertrag passen.
Ich habe mich auch ewig mit dem standard telekom Profil abgemüht, auch wenn die Parameter von beiden äußerlich sehr ähnlich aussehen, machen sie im Hintergrund anscheinend bestimmte Sachen anders. Jedenfalls gehts bei mir mit dem Magenta Profil, mit dem Telekom nicht.
Deine NAT Regel sieht aus meiner Sicht nicht korrekt aus.
Du brauchst eine outgoing NAT Regel mit statischen Ports und aktiviertem 'Hybride Erstellung ....' Dann brauchst du drei Portforwarding Regeln, eine für SIP, eine für RTP (meine Ports sind halt andere als bei Dir) und eine für STUN (anscheinend geht das auch ohne STUN (s.o.), habe ich aber jetzt noch nicht hingebogen); siehe Bilder
Und dann noch eine Firewall Regel, um am WAN den SIP Verkehr zu Deinem Gigaset durchzulassen ... Auch wenn da im Gigaset für SIP port 5060-5076 steht wird in der Praxis offenbar nur port 5060 bei Telekom benutzt.
EDIT: Ach ja: auch bei mir haben die SIP refresh's nach ein paar Stunden einfach aufgehört, wenn mehrere Provider auf der Gobox aktiv waren (zumindest Telekom UND Gigaset.net). Mit den og Korrekturen vielleicht wirklich mal mit nur einem Eintrag bei IP probieren ....
Br br
-
Auf sowas soll man kommen :o
Wenn da Provider: Telekom steht, dann geh ich doch nicht erst aufs Dropdown, weil der Provider stimmt. Und wenn es unterschiedliche Configs je Tarif gibt, hätte ich erwartet, dass die danach im nächsten Screen abgefragt werden - halt runtergefiltert auf den gewählten Provider...
Gut. Hab Mangenta entdeckt und nun verwendet. Ist ja auch bei mir ein Magenta Zuhause.
Dabei hab ich jetzt gleich mal das STUN abgeschaltet. Mal sehen was passiert.
Wegen der FW Regel(n):
Wenn ich meine Regel richtig verstehe, hänge ich die Ports von der GoBox direkt ins Internet. Das bedeutet doch PortForwarding?
Und aus dem Handbuch zur Sense bei "NAT Outbound":
If you only have one external IP, then you leave the Outbound NAT options on automatic. However, if you have multiple IP addresses, you might want to change the settings and add some custom rules.
Also: Outbound NAT brauchts nur bei multi WAN. Da hätte es mir auch eingeleuchtet.
-
Wir haben jetzt 2 Möglichkeiten:
entweder wir diskutieren über abstrakte Ausschnitte aus Dokumentationen oder du probierst einfach mal aus, was andere gemacht haben, um VOIP zum laufen zu bringen. Ich jedenfalls HABE mich bereits erfolgreich durch den ganzen widersprüchlichen Mist zu VOIP im Netz durchgewühlt und habe am Ende ein funktionierendes Festnetztelefon.
Wenn du unbedingt weiterlesen willst, dann würde ich Dir das empfehlen:
https://forum.opnsense.org/index.php?topic=15993.0 (https://forum.opnsense.org/index.php?topic=15993.0)
Da findest Du auch den Hinweis, warum bei VOIP und Deiner Config outbound NAT wesentlich zu einem funktionierenden System beiträgt - also nix mit MultiWAN, dafür aber das Zauberwort static ports. Es mag natürlich auch noch andere Wege zum Erfolg geben, ich kann Dir jedenfalls bestätigen, dass meiner funktioniert hat.
Take it or leave it
Viel Erfolg
br br
-
Na ich will das ja auch gar nicht in Abrede stellen, dass es bei dir läuft, oder dass du dir was dabei gedacht hast.
Ich will nur verstehen, was ich da tue und warum ich es tue. Sonst hätte ich auch einfach bei ner FritzBox bleiben können ;)
Die Umstellung der Profile + das Abschalten von STUN scheinen bisher aber schon mal was gebracht zu haben. Bisher meine Meldung über nicht angemeldete Rufnummern. Außerdem kam ein Telefonat erfolgreich rein und konnte ganz normal geführt werden. Bin gespannt, wie es heute Abend und morgen früh ausschaut.
-
So... Erste Nacht ohne dass mich die Telefone mit "ich bin nicht angemeldet" begrüßen :D
Gestern Abend hab ich Telefonie Tests gemacht. Heute früh auch. Scheint alles stabil zu laufen. Ich warte jetzt mal noch 1-2 Tage, ob es so bleibt. Wenn ja, mach ich einen Haken ans Thema.
Danke an alle Mithelfer schonmal!
Gruß
Manuel
-
Soo... Das ganze Wochenende über gab es nicht einmal unregistrierte Telefone oder Probleme beim Telefonieren. Es scheint nun alles zu passen.
STUN ist aus.
Magenta Profil statt dem generischen Telekom-Profil.
PortForward ist geblieben wie beschrieben. Habe die Quelle auf 217.0.0.0/16 eingeschränkt.
Habe die GoBox in ein eigenes VLAN gesteckt, aber das sollte egal sein.
Wenn es wieder Probleme geben sollte, schau ich zuerst, ob es ggf. an der "zu engen" Beschränkung auf die Quelle liegen kann.
Danke an alle Helfer!
Gruß
Manuel