OPNsense Forum
International Forums => German - Deutsch => Topic started by: karl047 on August 10, 2018, 12:30:35 am
-
Das Titel beschreibt eigentlich das aktuelle Problem. Telefonieren (Fritzbox hinter OPNsense) hat vor dem Update auf 18.7 einwandfrei funktioniert, und nach dem Update funktioniert nicht mehr. Es klingelt aber keine Stimme (für die eingegangenen und gewählten Anrufe).
Wie ich die Fritzbox hinter OPNsense konfiguriert habe, könntet ihr das lesen:
https://forum.opnsense.org/index.php?topic=7663.0;topicseen
hat jemand eine Idee was los ist und woran das liegt? ich hoffe dass kein BUG mit dem System ist!
-
Was war die letzte funktionierende Version? Telefon auch schon neu gestartet? Siehst du geblockte Pakete?
-
@ mimugmail: Fritzbox habe ich neu gestartet, aber es hat nicht geholfen. ich habe die Update von 18.1.12 auf 18.7 durchgeführt und nachher ist mir aufgefallen dass das Telefon nicht mehr funktioniert (wie ich sagte, es klingelt aber keine Stimme dabei). Ich habe eine alte Version installiert (18.1.6) und das Telefon hat danach wieder funktioniert.
-
Siehst du geblockte Pakete?
-
@ mimugmail: nein... keine geblockte Pakete... laut diese Anleitung was ich damals gepostet habe, NAT (Outbound & Port Forwarding) ist weiter hin und her zur Fritzbox eingestellt, Ports sind: SIP (5060) & RTP (7078:7109)
Ich habe nachgeguckt und keine Pakete geblockt. Wie ich auch gepostet habe, die gleiche Einstellung hat mit 18.1.6 funktioniert, d.h. es liegt irgendwie an 18.7 , oder?!
-
Kannst du mal bis 18.1.13 hoch und testen?
-
Es tut mir Leid, aber ich muss bis morgen früh arbeiten. Ich werde erst Morgen das tun und schauen wir mal weiter
-
@mimugmail:
frisch installierte Image 18.1.6 neu konfiguriert : Telefonieren funktioniert !
Update von 18.1.6 auf 18.1.13: Telefonieren funktioniert immer noch !
Update von 18.1.13 auf 18.7 ODER frisch installierte 18.7 Image mit der gleichen Konfiguration : Telefonieren funktioniert NICHT MEHR.
Was sagst du dazu?
-
Muss mir noch mal den Changelog anschauen. Siproxd magst du aber nicht verwenden oder?
-
ich habe siproxd mit openWRT einmal probiert; ganz ehrlich, ich weiß nicht genau wie ich das Proxy konfigurieren kann. Aber ich bin momentan bei 18.1.13 und werde ich bleiben bis ein Update für 18.7 kommt, vlt wird das Problem irgendwie gelöst.
Ich verstehe wirklich nicht mehr wie es passieren könnte, solche Fehler aufzutrten von einem Update zu dem Anderen, das beste Image was ich einmal gehabt habe ist 18.1.9, es lief damals alles wunderbar, PPP0E war OK und das Gateway von IPv6 ist immer ständig online geblieben usw... Schade dass die Entwicklung von der Version so schief läuft.
-
Hast du schon mal in die Foren kommerzieller Hersteller geschaut? Da gruselts dich gleich. Ich denke nicht das der Fehler gefixt wird wenn du nicht aktiv mithilfst
-
18.1 -> 18.7 ist leider kein triviales Update. 18.7.1 kommt nächste Woche.
Allerdings kann in solchen Fällen das Live-Image mit Config Import empfehlen. Da kann alles ungefährlich getestet werden... Diagnosedaten sammeln, dann wieder Reboot und USB Stick raus und das alte System ist wieder da.
Ich vermute mal da ist ein NAT Port Alias im Spiel?
Grüsse
Franco
-
Hast du schon mal in die Foren kommerzieller Hersteller geschaut? Da gruselts dich gleich. Ich denke nicht das der Fehler gefixt wird wenn du nicht aktiv mithilfst
Du hast voll Recht "mimugmail". Es gibt überall Probleme mit dem Software usw... ich habe nicht kritisiert, was ich gemeint habe dass ich mich gewundert habe als ich 18.1.9 hatte und alles wunderbar funktionierte und ab 18.1.10 ist das gleiche Problem wieder aufgetreten
(( guck mal bitte nach:
https://forum.opnsense.org/index.php?topic=8910.msg40515#msg40515 ))
@Franco:
Ich vermute mal da ist ein NAT Port Alias im Spiel?
Ja, es ist ein NAT Port Alias: VOIP Ports: 5060,7078:7109
-
Mach mal eine (NAT)Rule für 5060 und eine für die Range, erst mal ohne Alias
-
ich habe es auch gemacht, weil ich auch so dachte, vlt liegt am Alias besonders Port-Range, aber es hat nicht geholfen.
-
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.
-
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 :-)
-
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
-
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
-
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)
-
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
-
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?
-
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
-
https://forum.opnsense.org/index.php?topic=9417.0;topicseen#msg42642
-
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 ;)
-
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
-
@Franco: danke dir für deine Hilfe dabei, den Output habe ich dir geschickt.
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 !
-
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
-
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.
-
Super :)
Grüsse
Franco