Dual WAN dual Voip mit O2 und Osnatel Problem
-
Hallo zusammen,
ich habe ein Problem mit der Telefonie. Mein Aufbau:Fritzbox1 Osnatel (192.168.0.10)
Fritzbox2 O2 (192.168.0.7)
Beide müssen für die Telefonie genutzt werden und befinden sich im Heimnetz der PFsense
PFsense:
Fritzboxen -> Heimnetz
Gateway1 PPPOE-> Modem1 -> Osnatel
Gateway2 PPPOE-> Modem2 -> O2Grundsätzliche Einstellung in den Fritzboxen: Client Modus und Verbindung halten damit die Firewall nicht zu macht
Grundsätzliche Einstellung PFsense: Port Scrubbing deaktiviert, Alle Zustände zurücksetzen wenn sich die WAN IP ändert.
Nat:
Firewall Heimnetz:
Mit diesen Einstellungen zeigen beide Fritzboxen an das die Telefonnummern registriert sind. Bei der O2 Telefonie funktioniert nur das klingeln aber keine Sprache. Bei Osnatel funktioniert nicht mal das klingeln.
Woran kann das liegen? -
Das habe ich gerade auch noch getestet. Hat aber nichts bewirkt.
Die selbe Konstellation funktioniert einwandfrei an einem Dual Wan Router von TP-Link. Dort habe ich auch nur jeder Fritte den passenden Gateway zugewiesen und über die Portweiterleitung die SIP und RTP Ports freigegeben. Leider ist der TP-Link Router zu schwach unter der Haube für schnelle VPN Verbindungen. Daher meine Bemühungen auf PFsense umzusteigen.
-
Von Osnatel habe ich noch eine genaue Beschreibung der SIP Trunk Spezifikation gefunden.
Osnatel SIP Trunk Spezifikation
Damit werde ich mal weiter testen. -
@pfsense1975
Hi,Du hast auf zwei Schnittstellen (die beiden WAN) das gleiche Netz (192.168.0.0/24). Das wird nicht funktionieren.
-
@jma791187
Hallo,
das verstehe ich nicht so ganz. Das ist das Netzwerk vom Heimnetz. Von da aus möchte ich mit den Geräten auf WAN1 oder WAN2 zugreifen können. Den entsprechenden Gateway lege ich doch in den Firewall Regeln vom Heimnetz fest. Also Gerät x nutze WAN1 oder Gerät y nutze WAN2. Ein Fehler sehe ich da gerade nicht. Bitte etwas näher erklären. -
-
@pfsense1975 said in Dual WAN dual Voip mit O2 und Osnatel Problem:
Fritzbox1 Osnatel (192.168.0.10)
Fritzbox2 O2 (192.168.0.7)da schreibst Du, welche IP-Adressen die beiden Fritten haben. Dachte ich zumindest...
Daher die Annahme von mir. Beschreibe doch mal bitte Dein ganzes Netz, was es darin gibt und welche Adressen auf welchem Interface liegen.
JeGr hat sehr schön beschrieben (https://forum.netgate.com/topic/19017/netzwerk-diagramme-zum-einf%C3%BCgen-in-eigene-posts), wie das hier im Forum geht.Dann sehen wir weiter.
Gruß, Jörg
-
-
@pfsense1975
Ich sehe gerade das die Service IPs der Modems evtl. stören könnten. Die liegen im Subnetz des Heimnetzes und auf der WAN Seite. Ist das möglich? -
Ich habe gerade einmal ein paar Diagnose Daten gesammelt. Es sieht für mich so aus das der SIP Traffic durchgeht aber keine RTP Verbindung zu stande kommt. Die Mitschnitte sind jeweils erfolgt beim Versuch raus zu telefonieren. Es kommt dann immer die Meldung Vermittlungsfehler. Die Daten beziehen sich nur auf die Osnatel Verbindung.
IPs vom Anbieter
Mittschnitte und Diagnosedaten
Paketmitschnitt Heimnetz
Paketmitschnitt WAN Osnatel
Die Portweiterleitung war so eingestellt. Ausgehend NAT unverändert.
-
@pfsense1975 Moin,
da du die IPs vom Provider hast: wenn du einen Testanruf machst, siehst du nur Traffic ausgehend? Oder kommt zu dem Zeitpunkt von draußen auch was rein von den IPs die du kennst? Eventuell stimmen auch die Ranges nicht ganz, der Provider hat IPs dazubekommen und hat seine Doku nicht aktualisiert o.ä. und jetzt versuchen Requests von draußen reinzukommen die nicht durchgehen?
Ausgehend sieht es ja so aus, als wäre alles static port gemappt, das wäre sicher schonmal die erste Hürde. Und zumindest 5060 scheint ja schon sauber rauszugehen. Sehe jetzt nur in den States und Co nicht wirklich was, was RTP Traffic zu sein scheint wenn das alle States sind. Vielleicht brauchen sie auch aus-/eingehend zusätzlich 5060/tcp?
Cheers
-
@jegr
Ich habe den Fehler gefunden ! Meine Fresse was ein Staatsakt. Beim Paketmitschnitt sind mir Pakete aufgefallen die zu groß waren für UDP.
Das SIP Protokoll ist extrem empfindlich gegenüber Änderungen. Da die Datenpakete zu groß waren wurden diese in zwei Pakete aufgeteilt. Dadurch wurde die SIP Nachricht ungültig und auf der Gegenseite verworfen. Ich habe zuerst mit den MTU Werten der Schnittstellen gespielt. Das hatte aber nichts gebracht. Die stehen nun alle auf 1492. Erfolgreich war die Einstellung der MSS Werte der Schnittstellen auf 1299.
Der Wert soll für verschiedene Scenarien ein guter Mittelwert sein. Hauptsache es läuft erstmal. Feintuning kommt später.