<SOLVED> Telefonieren (Fritzbox hinter OPNsense) funktioniert nicht mehr in 18.7

Started by karl047, August 10, 2018, 12:30:35 AM

Previous topic - Next topic
Print
Go Down Pages 1 2
User actions
August 12, 2018, 12:12:19 PM #15
Also wenn Stimme in eine Richtung nicht geht muss es was mit RTP sein. Schau doch mal im tcpdump ob am WAN die RTP Pakete korrekt rein und raus gehen und wenn ja, dann am LAN schauen. Vergleichen ob die Range auch so passt wie in der Regel.
August 12, 2018, 08:02:30 PM #16
die Stimme geht aber nicht in den beiden Richtungen, und nicht nur in einer. Ich bin sicher dass mit den Regeln alles in Ordnung ist. Mit oder ohne Alias hat es auch nicht funktioniert. Ich habe heute wieder alle Möglichkeiten probiert und bin gerade bei 18.1.13 gelandet, und bin damit sehr zufrieden: es läuft :-)
August 12, 2018, 08:25:37 PM #17
Hab mir deinen Thread mal angesehen. Bild 8 würde ich den Port Alias auf Destination setzen, das macht mehr Sinn. Und dann würde ich wenn das nicht geht STUN auf der FB eintragen. Eigentlich brauchst du das
August 12, 2018, 08:56:02 PM #18
Das einfachste wäre die /tmp/rules.debug vom funktionierenden System auf 18.1.13 und vom 18.7 wo es nicht mehr geht. Es liegt ja offensichtlich an den Firewall Regeln. :)


Grüsse
Franco
August 12, 2018, 09:26:29 PM #19 Last Edit: August 12, 2018, 09:28:18 PM by karl047
Quote from: mimugmail on August 12, 2018, 08:25:37 PM
Hab mir deinen Thread mal angesehen. Bild 8 würde ich den Port Alias auf Destination setzen, das macht mehr Sinn. Und dann würde ich wenn das nicht geht STUN auf der FB eintragen. Eigentlich brauchst du das

Wenn ein Anruf ankommt: Fritzbox wird reagieren durch die registrierte Nummer, die Ports die für telefonieren zuständig sind (standard in Fritzbox) sind 5060 als SIP und 7078:7109 als RTP, dann wenn ich anrufe: durch die registrierte Nummer und die zuständige Ports vom Fritzbox soll alles im Prinzip funktionieren (und das was tatsächlich passiert unter 18.1.13), deswegen muss alles auf source und nicht destination konfiguriert werden.

Edit: ich habe 2 Punkte vergessen: alles läuft über UDP , und ich habe nie STUN gebraucht.

@Franco: ich werde das tun, obwohl ich kein Lust mehr habe mit installieren und wieder zurück, aber wir sollen auch wissen woran das Problem liegt  8)
August 12, 2018, 11:19:42 PM #20
Nein, wenn ein Anruf ankommt gilt nur die NAT Regel, und da ist es Destination. Die Firewall Regel selbst wäre für ausgehend.

Keine Ahnung wieso es funktioniert hatte, SIP ist halt ein schwieriges Protokoll, eigentlich sollte es nur mit STUN funktionieren
August 13, 2018, 11:54:48 AM #21
es wird jetzt ein bisschen komlizierter für mich... in Bild 8 NAT ist so eingestellt für die ausgehenden Anrufe (deswegen stehen die VOIP-Ports im Source-Bereich), und für die ankommenden Anrufe ist Port Forwarding zuständig (stehen die VOIP-Ports im Destination-Bereich).

ich weiß nicht ob du auch Fritzbox hast, aber ich habe eine kleine Frage nach STUN:
bei mir läuft das Telefon über 1&1 , in Fritzbox habe ich einfach Anbieter 1&1 und weitere Daten von den Telefonnummern und Passwörter, und es lief danach ohne Probleme.
Du meinst ich soll STUN server eintragen, aber wie???
Wenn ich im Telefone Bereich auf anderen Anbieter gehe, es zeigt mir kei STUN server sondern Registrar und proxy server, und die beiden sind 1und1.sip.de laut der Internetseite von 1&1.
Sag mir bitte wo und wie ich STUN eintragen soll?
August 13, 2018, 02:57:00 PM #22
Hm, also mit outbound Proxy braucht er eigentlich kein Stun ... Es ist remote leider schwer zu debuggen. Als nächstes würde ich das von Franco mal testen. Nächste Woche bin ich wieder in der Arbeit, da könnte ich tagsüber auch mal mit Teviewer schauen wenn gewünscht
August 13, 2018, 05:03:33 PM #23
August 13, 2018, 09:55:30 PM #24
ich werde es morgen wieder probieren... firewall rules debug von den beiden versionen vergleichen, Aliases mit Ports usw ersetzen, und schauen wir mal wie es wird...

@mimugmail: ich danke dir für deine Mühe ;)
August 14, 2018, 01:58:24 PM #25
Entschuldige die späte Meldung.

Die beiden Files müssen nur jeweils verglichen werden mit:

# diff -u rules.debug.18.1 rules.debug.18.7

Der Output reicht und ist meist anonym genug. Wenn nicht können die IPs dann noch entfernt werden.

Kann auch an franco@opnsense.org gesendet werden. Public Key gibt es auf Anfrage auch. :)


Grüsse
Franco
August 14, 2018, 10:25:45 PM #26 Last Edit: August 15, 2018, 11:49:45 AM by karl047
@Franco: danke dir für deine Hilfe dabei, den Output habe ich dir geschickt.

Quote from: mimugmail on August 13, 2018, 02:57:00 PM
Nächste Woche bin ich wieder in der Arbeit, da könnte ich tagsüber auch mal mit Teviewer schauen wenn gewünscht

du kannst das gerne tun, und habe keine Problem mit. Mal schauen zuerst was Franco mit dem Vergleich rausfinden wird, weil ich fast alle Möglichkeiten mit oder ohne Alias probiert habe und hat es nicht funktioniert, und wenn es auf 18.1.13 zurück ist, funktioniert es wieder einwandfrei !
August 15, 2018, 07:12:59 PM #27
Hallo Karl,

Danke für die Mail. Es sieht so aus als wäre es das Problem welches in 18.7.1 behoben wurde:

Der Port-Alias wurde nicht korrekt validiert und die VoIP NAT Regeln daher temporär deaktiviert.


Grüsse
Franco
August 15, 2018, 10:23:07 PM #28
Quote from: franco on August 15, 2018, 07:12:59 PM
Der Port-Alias wurde nicht korrekt validiert und die VoIP NAT Regeln daher temporär deaktiviert.

Herzlichen Dank für deine Hilfe dabei. Ich bin bei 18.7.1_3 gelandet nach dem Update, und das Problem mit dem Port-Alias wurde tatsächlich behoben, es läuft wieder einwandfrei.
August 16, 2018, 08:07:13 AM #29
Super :)


Grüsse
Franco
Print
Go Up Pages 1 2
User actions