15
VoIP-Clients werden durch pfSense gehindert.
Hallo,
ich habe einige VoIP-Clients hinter einem neuen pfSense Firewall. Seit der Install können sie sich nicht anmelden.
Komischerweise ist nichts eingestellt, was ausgehende Anrufe blockieren könnten. Anbei findet ihr jeweils ein Screenshot über die LAN, WAN, NAT Settings:
Internet haben wir. Port 80 und 443 sind also auf jeden Fall in Ordnung.
Die 2. LAN Rule lässt allerdings alles raus unabhängig davon, dass 80 und 443 extra freigegeben sind.
Bei WAN ist nur OpenVPN frei. ich glaube aber kaum, dass hier eine Freigabe benötigt wird damit die Clients sich mit dem Server verbinden können.
Hat jemand eine Idee?
Danke.
Wenn ich in der Fritzbox nachschaue sehe ich:
Anmeldung der Internetrufnummer (<Rufnummer>) war nicht erfolgreich. Ursache: DNS-Fehler
Dieser Fehler tritt auf, wenn die Anmeldedaten für die Internettelefonie nicht korrekt eingegeben wurden. Gehen Sie folgendermaßen vor, um das Problem zu beheben:
Die DNS-Server sind auf jeden Fall zu erreichen. Internet haben wir ja.
LAN-Struktur:
Gr. I.
ich habe einige VoIP-Clients hinter einem neuen pfSense Firewall. Seit der Install können sie sich nicht anmelden.
Komischerweise ist nichts eingestellt, was ausgehende Anrufe blockieren könnten. Anbei findet ihr jeweils ein Screenshot über die LAN, WAN, NAT Settings:
Internet haben wir. Port 80 und 443 sind also auf jeden Fall in Ordnung.
Die 2. LAN Rule lässt allerdings alles raus unabhängig davon, dass 80 und 443 extra freigegeben sind.
Bei WAN ist nur OpenVPN frei. ich glaube aber kaum, dass hier eine Freigabe benötigt wird damit die Clients sich mit dem Server verbinden können.
Hat jemand eine Idee?
Danke.
Wenn ich in der Fritzbox nachschaue sehe ich:
Anmeldung der Internetrufnummer (<Rufnummer>) war nicht erfolgreich. Ursache: DNS-Fehler
Dieser Fehler tritt auf, wenn die Anmeldedaten für die Internettelefonie nicht korrekt eingegeben wurden. Gehen Sie folgendermaßen vor, um das Problem zu beheben:
Die DNS-Server sind auf jeden Fall zu erreichen. Internet haben wir ja.
LAN-Struktur:
Gr. I.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 207512
Url: https://administrator.de/contentid/207512
Ausgedruckt am: 22.11.2024 um 02:11 Uhr
15 Kommentare
Neuester Kommentar
Guten Morgen,
auch wenn es schon keiner mehr hören kann oder will.
Mach bitte eine Skizze, wer wo ist, wo dir pfsense, wo die VoIPs und so weiter und so weiter.
Mach bitte eine genaue Skizze.
Du magst ja Dein Netz kennen, aber wir hier nicht und ein Bild sagt mehr als tausende Worte.
Bitte, Danke.
Gruß
Anton
auch wenn es schon keiner mehr hören kann oder will.
Mach bitte eine Skizze, wer wo ist, wo dir pfsense, wo die VoIPs und so weiter und so weiter.
Mach bitte eine genaue Skizze.
Du magst ja Dein Netz kennen, aber wir hier nicht und ein Bild sagt mehr als tausende Worte.
Bitte, Danke.
Gruß
Anton
Danke Anton,
ich habe die Struktur als Grafik hinzugefügt.
I.
ich habe die Struktur als Grafik hinzugefügt.
I.
Hallo,
du musst wahrscheinlich das Überschreiben des Quellports durch Pfsense verhindern, standardmäßig schreibt pfSense dynamisch den Quellport auf allen ausgehenden Datenverkehr. Dies ist notwendig für die NAT.
Das kann unter Umständen bei mehreren VOIP-Clients hinter einer öffentlichen Adresse zu Problemen führen. Das heisst den Quellport statisch einstellen:
Firewall -> NAT -> Outbound
Unter Punk 2 steht wie du das einstellen sollst: (für Destination-Port 5060 / UDP musst man Quellport auf staticsetzen)
http://doc.pfsense.org/index.php/VoIP_Configuration
http://doc.pfsense.org/index.php/Static_Port
Gruß
m
du musst wahrscheinlich das Überschreiben des Quellports durch Pfsense verhindern, standardmäßig schreibt pfSense dynamisch den Quellport auf allen ausgehenden Datenverkehr. Dies ist notwendig für die NAT.
Das kann unter Umständen bei mehreren VOIP-Clients hinter einer öffentlichen Adresse zu Problemen führen. Das heisst den Quellport statisch einstellen:
Firewall -> NAT -> Outbound
Unter Punk 2 steht wie du das einstellen sollst: (für Destination-Port 5060 / UDP musst man Quellport auf staticsetzen)
http://doc.pfsense.org/index.php/VoIP_Configuration
http://doc.pfsense.org/index.php/Static_Port
Gruß
m
Wichtig ist auch das der Voice Provider STUN supportet und STUN auf auf der FB aktiviert ist !!
http://de.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT
Voice nutzt RTP für die Sprachdaten, das Gateway eröffnet aber einen dynmaischen Port um die Voice Verbindung herszustellen.
Mach dich also zusätzlich auch nochmal kundig über die verwendeten Voice Protokolle SIP, STUN und RTP !!
Kommt die jetzt an deiner Firewall an, dann existiert dafür kein Eintrag in der NAT Session Tabelle und die FW blockiert diese Verbindung richtigerweise was dann bewirkt das keine Sparchverbindung zustande kommt.
Achte also auf aktiviertes STUN.
Ansonsten kannst du am WAN Port mal die IP Adresse des Voice Gateways erlauben die an der FB eingetragen ist. das sollte das Problem auch lösen ist aber unsicher, da du die FW öffnen musst.
Besser also immer die STUN Lösung die klappt auch ohne Frickelei !
Den Rest hat ja schon Kollege mathew hinreichend erklärt !
http://de.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT
Voice nutzt RTP für die Sprachdaten, das Gateway eröffnet aber einen dynmaischen Port um die Voice Verbindung herszustellen.
Mach dich also zusätzlich auch nochmal kundig über die verwendeten Voice Protokolle SIP, STUN und RTP !!
Kommt die jetzt an deiner Firewall an, dann existiert dafür kein Eintrag in der NAT Session Tabelle und die FW blockiert diese Verbindung richtigerweise was dann bewirkt das keine Sparchverbindung zustande kommt.
Achte also auf aktiviertes STUN.
Ansonsten kannst du am WAN Port mal die IP Adresse des Voice Gateways erlauben die an der FB eingetragen ist. das sollte das Problem auch lösen ist aber unsicher, da du die FW öffnen musst.
Besser also immer die STUN Lösung die klappt auch ohne Frickelei !
Den Rest hat ja schon Kollege mathew hinreichend erklärt !
Danke für die Hilfe.
Ich versuche auf diesem Weg weiterzugehen...
Kurz um zu verstehen: Warum verursacht dasselbe Phänomen kein Problem bei http und https Verkehr, nur bei VoIP?
@aqui: Stun ist bei den VoIP-Logins eingetragen es muss an den fehlenden Static-Settings des 5060-Port liegen. Mich hat lediglich die tatsache verwirrt, dass die FW scheinbar alles durchgeleitet hat.
@matthew:
Ich habe die Outbound-Rule so erstellt:
EDIT: die Static-5060 Port hat lediglich bei den Snom M9 Clients geholfen. Die DECTs an der FB kommen noch nicht durch... Warum auch...
"Ansonsten kannst du am WAN Port mal die IP Adresse des Voice Gateways erlauben die an der FB eingetragen ist. das sollte das Problem auch lösen ist aber unsicher, da du die FW öffnen musst."
@aqui: Ich habe hier ja nichts blockiert. Was würde hier eine explizite Freigabe bringen?
Ich habe es trotzdem gemacht:
Gr. I.
Ich versuche auf diesem Weg weiterzugehen...
Kurz um zu verstehen: Warum verursacht dasselbe Phänomen kein Problem bei http und https Verkehr, nur bei VoIP?
@aqui: Stun ist bei den VoIP-Logins eingetragen es muss an den fehlenden Static-Settings des 5060-Port liegen. Mich hat lediglich die tatsache verwirrt, dass die FW scheinbar alles durchgeleitet hat.
@matthew:
Ich habe die Outbound-Rule so erstellt:
EDIT: die Static-5060 Port hat lediglich bei den Snom M9 Clients geholfen. Die DECTs an der FB kommen noch nicht durch... Warum auch...
"Ansonsten kannst du am WAN Port mal die IP Adresse des Voice Gateways erlauben die an der FB eingetragen ist. das sollte das Problem auch lösen ist aber unsicher, da du die FW öffnen musst."
@aqui: Ich habe hier ja nichts blockiert. Was würde hier eine explizite Freigabe bringen?
Ich habe es trotzdem gemacht:
Gr. I.
Kurz um zu verstehen: Warum verursacht dasselbe Phänomen kein Problem bei http und https Verkehr, nur bei VoIP?
Der Grund ist, dass Protokolle (SIP,SIT/STP und RTP) die IP/Port-Angaben auf der Anwendungsebe übermitteln und nicht auf Layer 3/4 und die Firewall kann keine IP/Port-Informationen aus der Anwendungseben auslesen.
Gruß
m
Der Grund ist, dass Protokolle (SIP,SIT/STP und RTP) die IP/Port-Angaben auf der Anwendungsebe übermitteln und nicht auf Layer 3/4 und die Firewall kann keine IP/Port-Informationen aus der Anwendungseben auslesen.
Gruß
m
Die Frage wäre überflüssig wenn man die Threadantworten hier wirklich einmal lesen würde !!! 
Stichwort: Dynamische Ports auf dem Reverse Patch bei Voice Protokollen. Lösung: STUN am Client (FB) aktivieren !! Oder FW per Scheunentor Regel öffnen !
Übrigens: Am WAN Port ist generell ALLES blockiert ! Das ist der Default auf ALLEN Firewall Interfaces, wie es für eine gute Firewall üblich und gewollt ist. Mit deiner 2ten Rule (WAN Port) oben, hast du aber die Firewall außer Kraft gesetzt, da nun alles erlaubt ist. Ob das gut ist und gewollt überlassen wir mal deiner Entscheidung !
Aktiviere auf allen deinen Voice Clients STUN und gib den STUN Server an dann kannst du dir diese ganze Frickelei ersparen !!
Stichwort: Dynamische Ports auf dem Reverse Patch bei Voice Protokollen. Lösung: STUN am Client (FB) aktivieren !! Oder FW per Scheunentor Regel öffnen !
Übrigens: Am WAN Port ist generell ALLES blockiert ! Das ist der Default auf ALLEN Firewall Interfaces, wie es für eine gute Firewall üblich und gewollt ist. Mit deiner 2ten Rule (WAN Port) oben, hast du aber die Firewall außer Kraft gesetzt, da nun alles erlaubt ist. Ob das gut ist und gewollt überlassen wir mal deiner Entscheidung !
Aktiviere auf allen deinen Voice Clients STUN und gib den STUN Server an dann kannst du dir diese ganze Frickelei ersparen !!
Hallo Aqui,
danke.
Ich verstehe es schon, dass STUN die beste Lösung ist.
Was in aller Welt soll ich aber machen, wenn dies bei allen Clients bereits eingetragen ist?
EDIT: Der VoIP-Server-Hoster meinte, dass eher die Punkte der Anleitung "http://doc.pfsense.org/index.php/VoIP_Configuration" eine Lösung bringen könnten.
Ich werde also die FW auf "Conservative" umstellen bzw. das Package "siproxd" installieren.
Gr. I.
danke.
Ich verstehe es schon, dass STUN die beste Lösung ist.
Was in aller Welt soll ich aber machen, wenn dies bei allen Clients bereits eingetragen ist?
EDIT: Der VoIP-Server-Hoster meinte, dass eher die Punkte der Anleitung "http://doc.pfsense.org/index.php/VoIP_Configuration" eine Lösung bringen könnten.
Ich werde also die FW auf "Conservative" umstellen bzw. das Package "siproxd" installieren.
Gr. I.
Das wäre ein Versuch Wert !
Übrigens, den Link habe ich dir schon bereits geschickt.
Gruß
m
Übrigens, den Link habe ich dir schon bereits geschickt.
Gruß
m
Muss man eigentlich nicht. Hier funktioniert es wunderbar ohne Zusatzsoftware und ohne "conservative"....jedenfalls mit SIPgate.
Komisch... Ich habe jetzt das Paket installiert bzw. auf Conservativ umgestellt. Nichts. Die SNOM Geräte funktzen weiterhin, die auf Fritzbox kommen nicht durch. Ich versuche mal den STUN-Server zu ändern. Aktuell sind die von 3CX eingestellt.
Die Tatsache, dass die SNOM M9 keine Probleme haben weist darauf hin, dass das Netzwerk inkl. PfSense richtig eingestellt ist.
Bessere Idee habe ich nicht.
EDIT: auch die Snoms können keinen eingehenden Anruf entgegennehmen. Raustelefonieren geht, angerufen werden nicht.
Gr. I.
Die Tatsache, dass die SNOM M9 keine Probleme haben weist darauf hin, dass das Netzwerk inkl. PfSense richtig eingestellt ist.
Bessere Idee habe ich nicht.
EDIT: auch die Snoms können keinen eingehenden Anruf entgegennehmen. Raustelefonieren geht, angerufen werden nicht.
Gr. I.
Hallo Aqui,
hast du Sipgate mit mehreren Clients probiert? Bei mir liegen die Probleme wohl daran, dass 9 Clients sich auf zwei IPs verteilt anmelden.
Gr. I.
hast du Sipgate mit mehreren Clients probiert? Bei mir liegen die Probleme wohl daran, dass 9 Clients sich auf zwei IPs verteilt anmelden.
Gr. I.
Mmmhhh wie meinst du das mit " 2 IP verteilen" ??
Hier hat jeder VoIP Client eine eigene IP die über das NAT Interface der pfSense (WAN) ins Internet zu Sipgate geht. Wie es eben Standard ist in simplen VoIP Umfeldern.
Hier hat jeder VoIP Client eine eigene IP die über das NAT Interface der pfSense (WAN) ins Internet zu Sipgate geht. Wie es eben Standard ist in simplen VoIP Umfeldern.
Hier hat natürlich jeder VoiP (DECT)-Client dieselbe Externe IP aus der Sicht des 3CX-Servers.
Snom M9 mit zwei Handsets
Fritzbox mit sieben CHandsets.
Auch das kann die Probleme verursachen durch pfsense und dann durch einen weiteren Modem (Router) mit einem völlig anderen Netz...
Ich habe den FW jetzt abgeschafft. Die Leute müssen ja arbeiten. Vielleicht nächste Woche experimentiere weiter oder ersetzte - mit freundlicher Unterstützung von SFR - den aktuellen Modem.
Gr. I.
Snom M9 mit zwei Handsets
Fritzbox mit sieben CHandsets.
Auch das kann die Probleme verursachen durch pfsense und dann durch einen weiteren Modem (Router) mit einem völlig anderen Netz...
Ich habe den FW jetzt abgeschafft. Die Leute müssen ja arbeiten.
Vielleicht nächste Woche experimentiere weiter oder ersetzte - mit freundlicher Unterstützung von SFR - den aktuellen Modem.Gr. I.
Ist das wirklich auch ein "Modem" oder auch ein Router ??
Sniffer einfach mal mit dem Wireshark einen sauberen SIP Verbindungsaufbau mit ohne FW und dann einmal mit FW.
Da siehst du dann sofort was fehlt.
Zudem steht das auch IMMER im Firewall Log der pfSense...wenn man da denn mal reinschaut.
Wie gesagt rennt hier mit einer simplen Standard Einstellung und STUN für 20 Clients und Sipgate OHNE das man was spezielles machen muss...
Gut möglich das du in dieses Problem rennst:
http://www.ip-phone-forum.de/showthread.php?t=211485&p=1588404& ...
Hast du auch mal einen "State Reset" in der pfSense gemacht und gecheckt obs danach rennt ?!
Sniffer einfach mal mit dem Wireshark einen sauberen SIP Verbindungsaufbau mit ohne FW und dann einmal mit FW.
Da siehst du dann sofort was fehlt.
Zudem steht das auch IMMER im Firewall Log der pfSense...wenn man da denn mal reinschaut.
Wie gesagt rennt hier mit einer simplen Standard Einstellung und STUN für 20 Clients und Sipgate OHNE das man was spezielles machen muss...
Gut möglich das du in dieses Problem rennst:
http://www.ip-phone-forum.de/showthread.php?t=211485&p=1588404& ...
Hast du auch mal einen "State Reset" in der pfSense gemacht und gecheckt obs danach rennt ?!
