Messages

Hi Uwe,

beim Abgleich mit meinen Regeln ist mir Folgendes aufgefallen:

NAT, ausgehend: ich benutze die Schnittstelle des LANs, was bei Dir anscheinend nicht funktioniert. Allerdings setze ich den NAT-Port, welcher bei Dir auf "*" steht. Sieht sonst aber vergleichbar aus:

Code Select Expand


Schnittstelle     Quelle                     Quellport         Ziel   Zielport NAT Adresse             NAT Port Statischer Port Beschreibung
ToTelekom         Bri1MainDevices Netzwerk   udp/ 10000:10100  *      udp/ * Schnittstellenadresse 10000:10100 JA                      Ausgehendes RTP/RTCP festnageln 
ToTelekom         Bri1MainDevices Netzwerk   tcp/ 5060         *      tcp/ * Schnittstellenadresse 5060         JA                      Ausgehendes TCP:5060 für SIP festnageln


Meine TCP-Regel für SIP ist wohl hinfällig. Das ist eine Altlast aus UDP-Zeiten, aber SIP über UDP ist bei der Telekom eh nicht zu empfehlen. Entweder nehme ich TCP-Port 5061 noch hinzu, oder ich nehme sie komplett raus. Mal schauen.

Deine UDP-Portrange für RTP/RTCP ist in der Tat 7078-7097. Wichtig ist Deine ausgehende statische Regel (die Du bereits hast). Die eingehende Regel ist nicht essentiell; gegebenenfalls prallen ein paar der ersten eingehenden UDP-Pakete ab, solange die Assoziation noch nicht von innen geschaltet worden ist. Ob man das merkt sei dahingestellt, ich habe sie bei mir aktiviert um da erst gar nicht ein Fass aufzumachen.

Viele Grüße,
Florian

Hallo nochmals,

hier ist noch ein kleiner Knackpunkt, über den ich gerade gestolpert bin. Es gibt unter

System -> Einstellungen -> Allgemein

den Punkt "DNS-Server Einstellungen", wobei der Unterpunkt "Verwenden Sie den lokalen DNS-Dienst nicht als Nameserver für dieses System" vielleicht angekreuzt werden muss.

Ohne diese Option zeigt bei mir die /etc/resolv.conf als ersten Eintrag "nameserver 127.0.0.1". Damit greift jedoch der DNSmasq abermals wieder auf Unbound zu... und die Katze beißt sich in den Schwanz.

Nun... dennoch scheint es zu funktionieren. Vielleicht wird die Loop erkannt und unterbrochen, sodass die anderen Einträge aus der /etc/resolv.conf (stammen von der Telekom ) doch noch greifen.

Weiterhin würde die oben genannte Option bewirken, dass die OPNsense selbst (alle Dinge auf der OPNsense) nicht mehr über Unbound auflösen würde. Das wäre blöd. Da es "anscheinend" trotzdem funktioniert (oder nur scheinbar?)... vielleicht hat ja Jemand Einblick was bei dieser "Loop" passiert und wieso es bei mir doch zu klappen scheint.

Viele Grüße,
Florian

Schönen Guten Abend,

ja Uwe, Du hast fast Alles korrekt wiedergegeben. Nur, der Eintrag in die /etc/resolv.conf erfolgt meines Kenntnisstandes nach durch den PPP-Daemon (ggf. ist da noch ein Wrapper drum). Im zweiten Schritt steht es nun jedem Resolver frei, Einträge aus der lokalen /etc/resolv.conf zu benutzen. Unbound soll dies nicht tun (man will ja nicht über die DNS-Server des Providers gehen) aber DNSmasq tut dies.

Da meine Systeme im LAN als DNS-Server auf den UDP-Port des Unbound-Servers zeigen (Port 53) findet die Namensauflösungen generell ohne Zugriff auf /etc/resolv.conf statt. Nur für SIP-basierte Telefonie brauche ich eine Ausnahme, was ich mit der Delegation in Richtung des lokalen DNSmasq löse.

Theoretisch kannst Du auch Deine Fritzbox direkt auf den DNSmasq leiten. Dann kannst Du Die die Weiterleitung wie in Unbound sparen, musst allerdings den DNSmasq-Port an der Firewall öffnen und dafür sorgen, dass die Fritzbox auch den UDP-Port des DNSmasq erhält und diese Adresse zur Namensauflösung nutzt.

Viele Grüße,
Florian

Hallo Uwe,

ich habe gestern ein ähnliches Problem hier bei mir lösen müssen. Vielleicht hilft es Dir ja.

Auch ich bin bei der Telekom (allerdings ohne statische IPv4-Adresse) und erhalte die Telekom-DNS-Server per PPP zugewiesen. Im Gegensatz zu Dir habe ich besagte Option allerdings nicht angekreuzt, und lasse die Adressen der zugewiesenen DNS-Server immer brav in die /etc/resolv.conf schreiben.

Jetzt benutze ich aber Unbound als DNS-Server und habe bis gestern die DNS-Server der Telekom gar nicht mehr benutzt. Das lief an sich super, hat aber an meinem Asterisk im LAN immer wieder zu VoIP-Problemen mit der Telekom geführt (Stichwörter: NAPTR, SRV, sich ändernde IP-Adressen des Registrars und Proxys, INVITEs abgelehnt wegen fehlender Proxy-Auth). Ich brauchte also ein Setup, welches quasi immer Unbound benutzt, aber für VoIP zur Telekom eine Ausnahme macht und die von der Telekom geadelten Einträge aus der /etc/resolv.conf benutzt.

Ich habe dazu als Dienst "Dnsmasq-DNS" aktiviert, diesem den unbenutzten UDP-Port 52 zugewiesen, und dann den Dnsmasq-Dienst quasi zugenagelt und nur noch für localhost erreichbar gemacht. Im Unbound konnte ich dann eine Ausnahmeregel unter "Query Forwarding" einrichten, welche alle Anfragen betreffs der Domains "tel.t-online.de" und "sip-trunk.telekom.de" an 127.0.0.1:52 deligiert.

Damit erhoffe ich mir jetzt Ruhe in Bezug auf den ewigen Ärger mit den von Dir genannten DNS-basierten Sicherheitsfeatures der Telekom. Bis jetzt siehts gut aus, und die Dnsmasq-Logs zeigen mir auch, dass immer schön (nur) Namensauflösungen aus *.tel.t-online.de stattfinden.

Hoffe Das hilft Dir! Viele Grüße,
Florian

Hi Thomas,

vielen Dank, Dein Beispiel konnte ich direkt übernehmen und es funktioniert! :-D

- Ich hatte Wildcard nicht angekreuzt, Du schon, und im alten Modul war es bei mir ebenfalls nicht an. Keine Ahnung ob das relevant ist.
- Ich hatte als Backend "ddclient", Du "OPNsense". Habe nun OPNsense. Keine Ahnung was das ausmacht.
- Und ja, der Klassiker, mein Passwort im Passwortmanager war veraltet. Im Backup der OPNsense steht zum Glück alles im Klartext. Harhar :)

Frage: wieso benutzt Du "googledomains"? Hast Du keine globale IPv4-Adresse am WAN-Interface? Hier funktioniert jetzt "Interface [IPv4]" mit Verweis auf mein PPPoE-Interface zur Telekom. EDIT: Quatsch mit CGNAT gelöscht...

Nochmals vielen Dank, und viele Grüße,
Florian

Hallo Uwe,

auch wenn es nicht genau auf Dein Fehlerbild passt, ich selbst hatte am 2. Juni einen Ausfall meines Telekomsetups (ein Asterisk im LAN hinter einer OPNSense). Der Grund lag an nicht konfigurierter Medienverschlüsselung (SRTP) im Asterisk. Die Telekom verlangt jetzt zwingend RTP/SAVP statt RTP/AVP. Ich konnte das durch Änderungen alleinig am Asterisk fixen, OPNSense war da raus. Check mal Deine Fritzbox nach vergleichbaren Settings zum Thema Medienverschlüsselung. Das Problem äußert sich in einem fehlschlagenden SIP-Sessionaufbau; man sah nicht ein einziges UDP-Paket mit Mediendaten dabei.

Zweiter Punkt (jaja ich weiß, es lief ja schon bei Dir, egal): legst Du für RTP/RTCP eine Portrange fest? Ich kann das in Deinen Bildern nicht erkennen, aber ich habe zum Beispiel eine Range von ca. 100 Ports für UDP-Mediendaten reserviert. An Deiner Fritzbox (dem "SIP-Useragent") musst Du diese Portrange für RTP/RTCP eintragen. An der OPNSense dann noch die obligatorische Regel für statisches NAT-Mapping (falls die UDP-Assoziation ausgehend initiiert wird) und die Weiterleitungsregel (falls eingehenden UDP-Pakete schneller sind).

Natürlich kann ich gerne noch helfen um unsere Konfigurationen abzugleichen... aber schnaunwaerstmal :-)

Viele Grüße,
Florian

Hallo Thomas,

bin leider auch davon betroffen und habe leider ähnliche Erfahrung gemacht wie Du. Schon vor einigen Monaten, als die Ankündigung der Abkündigung des bisherigen dyndns-Moduls angezeigt wurde, hatte ich versucht meinen selfHost-Zugang einzurichten. Bin leider grandios gescheitert.

Nach und nach sind aber weitere "Provider" zum neuen Modul hinzugefügt worden, also hoffe ich noch auf eine Lösung. Wenn das bisherige Modul allerdings tatsächlich rausfliegen sollte, ohne gleichwertigen Support für selfHost, dann wäre das echt blöd.

Viele Grüße,
Florian