Messages

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

yep, funktioniert da immer noch!

Was genau geht denn nicht?

br br

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

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

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

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

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

Br br

Das erste ist mal den Receiver aus dem Loop rauszubekommen, da ist das Thema factory reset genau richtig.

MW wird das SW Update des 401 über tftp von einem Server der Telekom durchgeführt. Insofern muss ein Zugriff per tftp auf diesen Server möglich sein. Früher gab es mal eine Lösung über einen tftp proxy.

Ich habe bei mir nichts dergleichen am Start, habe aber sowohl für ipv4 und ipv6 die Default LAN Regel 'ich darf von allen Ports überall hin' aktiv.  Oft wird die default LAN Regel 'ich darf überall hin' durch eine eigene Regel ersetzt, die restriktiver ist. Ist das vielleicht bei Dir der Fall?

Andere Artikel beschreiben, dafür muss DNS über einen Telekom DNS Server erfolgen. Ich jedenfalls habe bei einem Telekom Anschluss keinen konfiguriert, geht aber trotzdem. Insofern wäre noch interessant ob Du ebenfalls einen Telekom Anschluss verwendet oder Du Magenta TV über andere Anbieter verwendest (soll ja auch gehen mittlerweile  ;))

BR br

Thank you putting me on that topic - had overlooked it

however and other then there, in my case it affects not the LL address generation but the PUBLIC ipv6 address and I am wondering whether this needs to judged somewhat different.

From my view, the algorithm which calculates in SLACC the address ist clearly defined in RFC4293 using an modified EUI-64 method. In case that the seldom but nevertheless possible case of duplicate addresses is appearing, DAD according to RFC 7527 shall be applied.

From my understanding how the EUI-64 works, there should be no doublets appearing simply because of the fact that MAC addresses are upward counted when having several NICs on the HW. I rather assume that this is a SW item.

Could it be that due to the fact that my WAN MAC address is 00:00: .... it simply uses the wrong one from a neighbor interface when calculating the ipv6 address?

High there,

I upgraded just yesterday to 22.1 and everything went well and smooth, which once again make me very grateful for the excellent work the OPNSense team since years to make this possible. Thank you very much for that

More or less randomly I observed an issue now on the ipv6 address generation which I am not sure whether this is new or was already in the versions before:

My ISP is Telekom and I access my VDSL Dual Stack Super Vectoring access via Modem and PPPoE with configured VLAN 7 on the Sense. IPv6 Prefixes are generated out of WAN capturing with prefix IDs. With SLACC, the address (lower 64 Bits) part then is generated out of the MAC address as being specified in the RFC accordingly. So far so good.

I now observe, that in this configuration my WAN ipv6 address and my LAN IP v6 address differentiate indeed in the prefix, but the address parts are exactly the same on both interfaces. In Interfaces->Overview, the WAN MAC address ist shown as 00:00:..00; LAN MAC address corresponds to the physical one of my Hardware.

However, it seems now to be that the WAN ipv6 address generation on igb1 is using the MAC address of the LAN interface on igb0.

I am wondering whether this is intended as I consider this potentially as a security risk.

Does anyone has a similar observation?

Looking forward to your reply.

Br br

Ja es geht.

ich habe es mit 21.7.7 am laufen. Geht wunderbar. Meine Konfiguration hat ein anderes Modem (Draytek Vigor 167) und ich habe zwischen OPNsense und MR401 noch einen Netgear Switch. Diese Anleitung hat mir am besten geholfen:

https://www.heise.de/ct/artikel/MagentaTV-auf-pfSense-Co-4698826.html

Wichtig ist der letzte Satz des Artikels zu 'Allow IP Options'/'Erlaube Einstellungen'; der gilt für ALLE relevanten Regeln, also auch für die default Regel auf dem LAN!

Br br

Na ja,

Magenta TV läuft ja nicht auf der OPNsense allein sondern an einem stabilen Betrieb sind leider einige Komponenten beteiligt.

Dafür wäre es hilfreich, wenn du mehr Infos über dein geplantes Setup (wie sieht die WAN Seite aus, ggf welcher switch, VLAN oder nicht, ....) posten würdest.

Die Antwort kann ohne das nur lauten, "Ja, grundsätzlich kann man das hinbekommen"

Bei mir geht es nach zahlreichen Vorversuchen endlich über
Telekom MagentaXL ->Draytek Vigor 167 -> OPNsense mit igmpproxy -> Netgear S3300 Switch mit IGMP snooping und Multimedia VLAN -> MR401 (oder VLC)

Vorher zig Versuche mit Fritz!Box et al vor der opnsense gingen nicht ....

Br br

Hi there,

I tried to activate DDNS via the API with ionos as suggested but miserably failed yet.  ??? Might be somewhat unusual but I only want to activate DDNS for two subdomains, not my entire domain ,domain.com' (only ,sub.domain.com').

I come up to the step that I have created my update URL, the server responds with 200 properly on the Ionos API page. This should then have activated DDNS for the requested subdomains according to the doc. However there is the no entry for these subdomain on the DNS page.

When I  apply Update URL  in the opnsense dyndns config and press ,save and enforce update', my public IP is properly shown in the opnsense dyndns config page.  But still the subdomain is not shown as a DynDNS subdomain at ionos ..
as to be feared there is also no DNS with my public IP for the subdomain distributed ...

Do i miss a step ?? I am looking forward to any idea.

Br br

Thank you for your answer!

My domain Registrar is Ionos. Ionos has also a dyndns service and a dns management api and is contained in the opnsense dyndns list. I would like to leave the services of the main Domain there (mail, Webhosting) and have only the subdomains with my local dyndns based site.

Br br

Hi there,

first of all a big big thank you for this awesome and comprehensive tutorial. Very helpfull and a great contribution.

I have an additional question and I am not sure whether I suffer from a big misuderstanding.

I configured my Dyndns as suggested with dedyn.io and have now a domain.dedyn.io properly working. Your tutorial now assumes to create wildcard certificates for the *.domain.dedyn.io (in my case)

I have a main domain registered with a poster somewhere else which is domain.com. Historically I reach my dyndns based subdomains via CNAME DNS entries at my main domain provider's DNS systems, eg home.domain.com points then to home.domain.dedyn.io.

It is now possible to let the acme client generate wildcard certificates also for *.domain.com accordingly in addition/replacing the wildcard certs for *.domain.dedyn.io?

Looking forward to your reply.

Br br