Dual WAN dual Voip mit O2 und Osnatel Problem
-
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.