Telefonate an FritzBox hinter OPNsense brechen ab

[CoMo]

Ja, steht auf 30 Sekunden. Kann ich auch im Firewall-Log sehen, dass dieses Keepalive Paket gesendet wird.

eine Firewall als exposted host hinter der Fritzbox aufgesetzt wird

Es gibt keine Firewall hinter einer Fritzbox. Die Firewall ist die OPNsense und die hängt direkt am Internet. Die Fritzbox hat mit dem Internetanschluss überhaupt nichts zu tun.

 

[conf_t]

Diese Keepalives musst du manuell setzen, sonst gibt es sie nicht .

 

[AAS]

Unter Telefonie → Eigene Rufnummern → Anschlusseinstellungen → Telefonieverbindung → Einstellungen ändern:

• Portweiterleitung des Internet-Routers für Telefonie aktiv halten aktivieren.
• Intervall auf 30 Sekunden setzen.

Das empfiehlt auch FRITZ! ausdrücklich für den Betrieb hinter einem anderen Router.
https://fritz.com/de-ch/apps/knowle..._Gesprachspartner-horen-sich-nicht?utm_source


Das hast du gemacht?


€dit:
Evtl. zuerst den Thread lesen.

 

[Luftgucker]

Tritt das auch bei einem Telefon mit Kabel auf oder nur mit DECT? Nicht das nur das DECT der alten Fritzbox schwächelt.

 

[CoMo]

• Portweiterleitung des Internet-Routers für Telefonie aktiv halten aktivieren.
• Intervall auf 30 Sekunden setzen.

Also mein Verständnis davon ist: Die Fritzbox sendet regelmäßig ein Keepalive Paket, damit der Eintrag in der NAT-Tabelle meines Routers bestehen bleibt und der Router bei eingehenden Telefonaten weiß, wo das Paket hin muss.

Mir ist völlig unklar, was das mit bestehenden, aktiven Telefonaten zu tun haben sollte. Da der Tipp hier immer wieder kommt: Kann mir das mal jemand technisch erklären?

Tritt das auch bei einem Telefon mit Kabel auf oder nur mit DECT? Nicht das nur das DECT der alten Fritzbox schwächelt.

Gute Frage! Ich habe tatsächlich kein verkabeltes Gerät zum Testen. Aber das ist eine Spur, die ich bisher gar nicht im Blick hatte.

 

[Ranayna]

Mir ist völlig unklar, was das mit bestehenden, aktiven Telefonaten zu tun haben sollte. Da der Tipp hier immer wieder kommt: Kann mir das mal jemand technisch erklären?

Bei SIP Telefonie spielen zwei separate Protokolle eine Rolle.

Einmal SIP, welches fuer das Signaling sorgt. Also dafuer sorgt, dass der Anruf, und all die beteiligen Funktionen funktionieren. Wo der Anruf hingeht, dass das richtige Telefon klingelt, und auch die beteiligten Rufnummern werden ueber SIP uebertragen.

Der Sprachkanal ist der zweite Teil der bei SIP Telefonie eine Rolle spielt.

Ist ein Gespraech aktiv, ist der SIP part eigendlich nicht mehr beteiligt. Der Audiostream ist eine separate Angelegenheit. Dieser ist natuerlich permanent aktiv, solange man sich nicht anschweigt

SIP schickt waehrend des Gespraechses aber regelmaessig "Statusmeldungen" hin und her. Nach dem Motto: Bist du noch da? SIP weiss direkt nichts davon, dass der Audiostream aktiv ist.

Ich kenne das selber als ehemaliger Telefonieadministrator. Insbesondere NAT argert an der Stelle sehr schnell. Dann kommt ein SIP Keepalive nicht durch, und die Gegenstelle die keine Antwort bekommt knipst den Audiostream zu, weil sie davon ausgeht, dass die Verbindung weg ist.

Ungewoehnlich ist dabei aber, dass die Zeit bei dir so variabel ist. Ich kenn das eigendlich so, dass man quasi die Uhr danach stellen kann und ein Gespraech nach 15 Minuten abgebrochen wird wenn es Probleme mit dem Keepalive gibt. Aber da gibt es sicherlich Unterschiede zwischen den Providern.

 

[AAS]

Also mein Verständnis davon ist: Die Fritzbox sendet regelmäßig ein Keepalive Paket, damit der Eintrag in der NAT-Tabelle meines Routers bestehen bleibt und der Router bei eingehenden Telefonaten weiß, wo das Paket hin muss.

Mir ist völlig unklar, was das mit bestehenden, aktiven Telefonaten zu tun haben sollte. Da der Tipp hier immer wieder kommt: Kann mir das mal jemand technisch erklären?



Gute Frage! Ich habe tatsächlich kein verkabeltes Gerät zum Testen. Aber das ist eine Spur, die ich bisher gar nicht im Blick hatte.

Das Keepalive kann auch bei laufenden Gesprächen relevant sein. SIP und RTP laufen getrennt. Während RTP kontinuierlich Sprachdaten überträgt, kann die SIP-Verbindung längere Zeit inaktiv sein, wodurch der NAT-Eintrag abläuft. Möchte der Provider dann die Sitzung per re-INVITE oder UPDATE verlängern, erreicht die Anfrage die FRITZ!Box möglicherweise nicht mehr und das Gespräch wird beendet.
Das Keepalive hält also nicht die Sprachübertragung, sondern die SIP-Signalisierung erreichbar. Ob das hier tatsächlich die Ursache ist, müsste ein Paketmitschnitt zeigen.

 

[CoMo]

Danke. Aber das stand ja sowieso schon immer auf 30 Sekunden. Das wird also wohl nicht die Ursache sein.

 

[ARNOFPS]

Also die Settings sehen soweit gut aus, ich hab noch die alte 26.1 version am laufen, daher noch mit Destination NAT, du hast wahrscheinlich schon 26.7, daher nur Source NAT.

Was hast du als NAT Mode? Kannst du da irgendwo Hybrid/Manual einstellen? Nicht, dass deine manuelle NAT Regel gar nicht aktiv ist/berücksichtigt wird.

Ich hab das bei mir so:

 

[CoMo]

Hybrid Mode. Sonst würden ja gar keine meiner NAT Regeln funktionieren.

 

[ARNOFPS]

Hmmm... und du hast vorher keine andere NAT Regel, die da irgendwie reingrätschen könnte? Ist die Fritzbox NAT Regel die erste manuelle? Kannst du evtl. einen Screenshot der NAT Regel posten? Wichtig ist ja nur, dass das Interface WAN, Source IP der Fritte, NAT Adresse Interface address und Static Port aktiviert ist (wobei letzteres hast du ja geschrieben, dass das aktiv ist).

Port Weiterleitungen braucht du nicht, die 30 Sekunden hast du in der Fritzbox auch, daher sollte es theoretisch auch genau so funktionieren.

Bei mir funktioniert genau dieses Setup ohne Probleme.

Ein Multi-WAN-Setup hast du nicht, oder?

 

[CoMo]

So sieht das bei mir aus, seit ich die OPNSense in Betrieb genommen habe. Es ist die erste Regel in der Liste.

Kein Multi-WAN, nur ein einzelnes einsames VDSL-Modem.

Das Alias Fritzbox ist die MAC-Adresse der Fritzbox und löst auf alle IP-Adressen auf, die die Box hat. LAN IPv4, GUA, ULA, LLA.

 

[Der_Dicke82]

Moin moin,

ich habe meine opnsense an starlink und dahinter ein linksys pap2 für VoIP in meinem Fall via SIP.

Freigaben habe ich keine und Abbrüche gibt es immer mal wieder, aber komplett unvorhersehbar. Erst dein post hier hat mich nun wieder zum nachdenken gebracht.

 

[h00bi]

beim überfliegen nicht gefunden:

Hat dieses Setup schon mal funktioniert?
Was war die jetzte Änderung?
ISP Wechsel?
OPN Config gebastelt?
FritzOS Update kürzlich eingespielt worden?

 

[MojoMC]

Er nutzt aber ein Zyxel Modem und will die Fritzbox nicht vor der Firewall haben.

Ob er die da nicht haben WILL, weiss ich nicht. Vielleicht kannte er die Funktion "Exposed Host" einfach nur nicht.

Wenn die FritzBox Telefonie macht kann die nicht einfach durchleiten und wenn die FritzBox Einwahl macht, verliert er viele Management Funktionen der OPNSense und hat Doppel-NAT.

Klar kann die Fritzbox einfach durchleiten, mit "Exposed Host" (siehe mein Link. Und welche wichtigen Managementfunktionen würde man verlieren? Mir fällt auf Anhieb nichts ein.

Hinter den Kulissen ist es zwar technisch ein Doppel-NAT, aber mit "Exposed Host" hast du eigentlich die üblichen Doppel-NAT-Probleme (VPN, DynDNS, Portfreigaben) gelöst/umgangen, da einfach alles statisch und ungefiltert an die OPNsense-Firewall weitergeleitet werden würde.

FritzBox vor einer Firewall kenne ich nur mit Passthrough oder für getrennte Labornetze hinter einem allgemeinen Netz.

Meiner Erfahrung ist das nicht unüblich - ganz besonders nicht bei Fritzboxen, die in D weit verbreitet sind und seit Jahren die Funktion "Exposed Host" für genau dieses Szenario haben.

Es gibt keine Firewall hinter einer Fritzbox. Die Firewall ist die OPNsense und die hängt direkt am Internet. Die Fritzbox hat mit dem Internetanschluss überhaupt nichts zu tun.

Hab ich was anderes über dein Setup behauptet?

Deine Verkabelung hab ich schon verstanden.
Aber du hast mit deinem Setup Probleme, ich kenne als "best practice" die umgekehrte Variante (Internet -> Fritzbox -> Firewall als Exposed Host) und die Fritzbox hat dazu sogar eine dedizierte Funktion.

Vielleicht hattest du ja gute Gründe für deine Vorgehensweise (die meinen eigenen "best practice" Erfahrungen widerspricht und die extra eingebaute Funktion der Fritzbox für dieses Szenario nicht nutzt), aber einen Hinweis ist es wert, falls du das einfach nicht wusstest.

 

[CoMo]

Es hat schon Gründe, warum ich von Consumer Schrott auf OPNSende gewechselt habe. Jetzt eine Fritzbox davorzuhängen und mit Exposed Host eine 1:1 Portweiterleitung für 65353 Ports auf den Router einzurichten, ist die denkbar dämlichste Variante.

Hat dieses Setup schon mal funktioniert?

Kann ich nicht sagen. Ich telefoniere nicht jeden Tag stundenlang und manchmal funktioniert es ja auch stundenlang. Gut möglich, dass das Problem schon seit Tag 1 der Inbetriebnahme der OPNSense existiert.

Ergänzung (Donnerstag um 10:26)

Das mit dem Exposed Host mache ich übrigens auf meinem Hetzner Server. Da geht es aber auch nicht anders, denn da ist OPNSense eine VM auf dem Proxmox:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination        
DNAT       tcp  --  anywhere             anywhere             multiport dports !8006 to:10.0.0.1
DNAT       udp  --  anywhere             anywhere             to:10.0.0.1

Das Konzept ist mir also bekannt. Macht aber bei mir Zuhause überhaupt keinen Sinn.

 

[ARNOFPS]

Das Alias Fritzbox ist die MAC-Adresse der Fritzbox und löst auf alle IP-Adressen auf, die die Box hat. LAN IPv4, GUA, ULA, LLA.

Die NAT Regel sagt aber explizit nur IPv4.

Ich verstehe deinen Ansatz, aber um es einfach zu halten und potentielle Fehler in OPNSense zu meiden (vllt kommt er mit den GUA, ULA, LLA Adressen im Alias bei der NAT Regel nicht klar), würde ich den Alias in "Hosts" ändern und dort nur die statische IPv4 der Fritzbox eintragen. Die Fritzbox selbst würde ich auch nur per IPv4 im LAN erreichbar machen und IPv6 für die Fritzbox komplett abschalten.

Nicht das die Fritzbox den keepalive random über IPv6 sendet und es dann zum Abbruch kommt, daher würde ich IPv6 als potentielle Fehlerquelle komplett ausschließen wollen.

Hast Du ein DualStack oder DS-Lite Setup? Weißt du das?

 

[CoMo]

Die NAT Regel sagt aber explizit nur IPv4.

Die Telekom-SIP Server sprechen ausschließlich IPv4. Es gibt keinerlei AAAA-Records. Also findet hier auch kein IPv6-Traffic in irgendeiner Weise statt.

Hast Du ein DualStack oder DS-Lite Setup? Weißt du das?

Telekom Business Anschluss mit statischer IPv4-Adresse und statischem /56 v6-Präfix. Bei der Telekom gibt es nur DualStack, unabhängig von der Anschlussart.

Ich verstehe deinen Ansatz, aber um es einfach zu halten und potentielle Fehler in OPNSense zu meiden (vllt kommt er mit den GUA, ULA, LLA Adressen im Alias bei der NAT Regel nicht klar),

Doch, das funktioniert und ist der zuverlässigste Weg, IP-Adressen in Aliase zu übernehmen. Darum kümmert sich der host discovery service. Dass die Regeln einwandfrei greifen, sehe ich im Firewall Log.

 

[ARNOFPS]

Als letzte Anregung: Da die Gesprächsabbrüche zu völlig unterschiedlichen Zeitpunkten auftreten, würde ich neben NAT und SIP auch die FRITZ!Box selbst bzw. DECT als Fehlerquelle in Betracht ziehen. Ein paralleler Paketmitschnitt auf LAN und WAN der OPNsense könnte zudem zeigen, welche Seite den Gesprächsabbruch tatsächlich auslöst.

Ohne solche Tests bleibt letztlich alles Spekulation. Da meine bisherigen Vorschläge offenbar nicht weiterverfolgt werden, bin ich an dieser Stelle raus. Viel Erfolg bei der weiteren Fehlersuche.

 

[CoMo]

Stimmt, auf DECT hatte @Luftgucker schon hingewiesen. Da muss ich mal schauen, wie ich das ohne Kabel-Telefon teste, eventuell mit einem Software-Telefon.

Paketmitschnitt auf der OPNSense habe ich tatsächlich schon mal laufen lassen. Bis zu einem Gesprächsabbruch nach etwa 50 Minuten. Da war aber nix zu sehen. Es fließen einfach plötzlich keine Pakete mehr. Nix, was auf einen aktiven Gesprächsabbruch hindeutet.

Da meine bisherigen Vorschläge offenbar nicht weiterverfolgt werden, bin ich an dieser Stelle raus.

Keine Ahnung, was du meinst. Den Alias? Der ist erst seit kurzem ein Alias auf die MAC-Adresse, denn den host discovery service auf der OPNSense gibt es noch nicht so lange. Vorher stand in den Regeln nur die IPv4-Adresse und da gabs das Problem auch schon. Das ist also bereits getestet.