Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

VoIP-Clients werden durch pfSense gehindert.

Frage Netzwerke TK-Netze & Geräte

Mitglied: istike2

istike2 (Level 2) - Jetzt verbinden

05.06.2013, aktualisiert 11:38 Uhr, 9086 Aufrufe, 15 Kommentare

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:

c3eff0b38a18d2c0da7d32227ee11a47 - Klicke auf das Bild, um es zu vergrößern
4901ba7081c1bb9df3b2192e88505c6f - Klicke auf das Bild, um es zu vergrößern
847a2bfc963c214cf280e517303e59b9 - Klicke auf das Bild, um es zu vergrößern

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: 0a3e741e8aaae67344ad725f65e830d5 - Klicke auf das Bild, um es zu vergrößern

Gr. I.
Mitglied: Anton28
05.06.2013 um 10:16 Uhr
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
Bitte warten ..
Mitglied: istike2
05.06.2013 um 10:34 Uhr
Danke Anton,

ich habe die Struktur als Grafik hinzugefügt.

I.
Bitte warten ..
Mitglied: matthew77
05.06.2013 um 10:46 Uhr
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
Bitte warten ..
Mitglied: aqui
05.06.2013, aktualisiert um 10:57 Uhr
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 !
Bitte warten ..
Mitglied: istike2
05.06.2013, aktualisiert um 11:39 Uhr
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: 31ee4890fa4cf301a7e98a594b6344e6 - Klicke auf das Bild, um es zu vergrößern

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: 2efb2b7881ecf9425251cdd9652ab888 - Klicke auf das Bild, um es zu vergrößern

Gr. I.
Bitte warten ..
Mitglied: matthew77
05.06.2013 um 12:42 Uhr
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
Bitte warten ..
Mitglied: aqui
05.06.2013, aktualisiert um 12:51 Uhr
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 !!
Bitte warten ..
Mitglied: istike2
05.06.2013, aktualisiert um 15:19 Uhr
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.
Bitte warten ..
Mitglied: matthew77
05.06.2013 um 16:45 Uhr
Das wäre ein Versuch Wert !

Übrigens, den Link habe ich dir schon bereits geschickt.

Gruß
m
Bitte warten ..
Mitglied: aqui
06.06.2013 um 20:59 Uhr
Muss man eigentlich nicht. Hier funktioniert es wunderbar ohne Zusatzsoftware und ohne "conservative"....jedenfalls mit SIPgate.
Bitte warten ..
Mitglied: istike2
06.06.2013, aktualisiert um 21:26 Uhr
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.
Bitte warten ..
Mitglied: istike2
06.06.2013 um 21:42 Uhr
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.
Bitte warten ..
Mitglied: aqui
07.06.2013 um 19:43 Uhr
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.
Bitte warten ..
Mitglied: istike2
07.06.2013 um 21:31 Uhr
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.
Bitte warten ..
Mitglied: aqui
07.06.2013, aktualisiert um 22:10 Uhr
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 ?!
Bitte warten ..
Neuester Wissensbeitrag
Humor (lol)

Linkliste für Adventskalender

(3)

Information von nikoatit zum Thema Humor (lol) ...

Ähnliche Inhalte
Voice over IP
gelöst PfSense: WAN1 Bandbreite für VoIP sinnvoll einschränken (3)

Frage von istike2 zum Thema Voice over IP ...

Firewall
TOR-Clients mittels pfSense blockieren (6)

Frage von mrserious73 zum Thema Firewall ...

Heiß diskutierte Inhalte
Windows Server
DHCP Server switchen (20)

Frage von M.Marz zum Thema Windows Server ...

Exchange Server
gelöst Exchange 2010 Berechtigungen wiederherstellen (20)

Frage von semperf1delis zum Thema Exchange Server ...

Hardware
gelöst Negative Erfahrungen LAN-Karten (19)

Frage von MegaGiga zum Thema Hardware ...

Exchange Server
DNS Einstellung - zwei feste IPs für Mailserver (15)

Frage von ivan0s zum Thema Exchange Server ...