Fritzbox hinter pfsense VOIP Probleme
Aloha an alle,
ich habe seit 2 Tagen das ganze Internet nach einem Lösungsweg abgesucht, aber nichts hat bisher gefruchtet.
Meine Situation:
Bisher hatte ich einfach (privat) eine Fritzbox 7270 am 1und1 Anschluss hängen.
Jetzt möchte ich eine PFSense FireWall dazwischen hängen.
Internet etc. funktioniert wunderbar. Ich kann auch vom Telefongerät nach außen wählen.
Was nicht möglich ist:
Den Gesprächspartner hören und von außen angerufen werden.
Also für mich ist das an sich ein klares Problem mit NAT und FireWall.
Aber selbst wenn ich (testweise) alle UDP Ports an die Fritzbox weiterleite ändern sich die Symptome nicht.
Bisher habe ich auch die klassischen schon ausprobiert (5060,7077-7097, 30000-30019, etc…)
Kennt jemand diese Situation oder weiß Abhilfe?
lg
Theo
ich habe seit 2 Tagen das ganze Internet nach einem Lösungsweg abgesucht, aber nichts hat bisher gefruchtet.
Meine Situation:
Bisher hatte ich einfach (privat) eine Fritzbox 7270 am 1und1 Anschluss hängen.
Jetzt möchte ich eine PFSense FireWall dazwischen hängen.
Internet etc. funktioniert wunderbar. Ich kann auch vom Telefongerät nach außen wählen.
Was nicht möglich ist:
Den Gesprächspartner hören und von außen angerufen werden.
Also für mich ist das an sich ein klares Problem mit NAT und FireWall.
Aber selbst wenn ich (testweise) alle UDP Ports an die Fritzbox weiterleite ändern sich die Symptome nicht.
Bisher habe ich auch die klassischen schon ausprobiert (5060,7077-7097, 30000-30019, etc…)
Kennt jemand diese Situation oder weiß Abhilfe?
lg
Theo
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 231636
Url: https://administrator.de/forum/fritzbox-hinter-pfsense-voip-probleme-231636.html
Ausgedruckt am: 22.12.2024 um 13:12 Uhr
27 Kommentare
Neuester Kommentar
Moin moin!
Vorneweg: Ich meide VOIP wo es nur geht und ignoriere das, solange es noch ISDN mit halbwegs sinnvollen Bandbreiten gibt, von daher ist meine Expertise begrenzt, aber PfSense ist immer ein spannendes Thema...
Das Dokument https://doc.pfsense.org/index.php/VoIP_Configuration hast Du gelesen?
Evtl. kannst Du auch das https://forum.pfsense.org/index.php?topic=68182.0 auf 1&1 anpassen?
Nur ins Blaue, ich befürchte, dass mir das Thema bald selbst begegnet...
Der Buc
Vorneweg: Ich meide VOIP wo es nur geht und ignoriere das, solange es noch ISDN mit halbwegs sinnvollen Bandbreiten gibt, von daher ist meine Expertise begrenzt, aber PfSense ist immer ein spannendes Thema...
Das Dokument https://doc.pfsense.org/index.php/VoIP_Configuration hast Du gelesen?
Evtl. kannst Du auch das https://forum.pfsense.org/index.php?topic=68182.0 auf 1&1 anpassen?
Nur ins Blaue, ich befürchte, dass mir das Thema bald selbst begegnet...
Der Buc
Es ist vermutlich eine fehlende Port Forwarding Regel !
WIE ist die FB und die FW zusammengeschaltet ??
Erst FB dann pfSense dann lokales LAN oder andersrum ? Wenn andersrum was benutzt du als Modem am WAN Port der pfSense ? Ist das ggf. auch ein Router wo das Port Forwarding für VoIP fehlt oder ist das ein reines NUR Modem ?
WIE ist die FB und die FW zusammengeschaltet ??
Erst FB dann pfSense dann lokales LAN oder andersrum ? Wenn andersrum was benutzt du als Modem am WAN Port der pfSense ? Ist das ggf. auch ein Router wo das Port Forwarding für VoIP fehlt oder ist das ein reines NUR Modem ?
Nein, falsch !
An der Fritzbox musst du gar nichts forwarden !! Mach das also schnell wieder rückgängig !!
Da die FB bei dir nur als reines Modem arbeitet "versteht" diese doch gar kein IP (und damit auch logischerweise kein VoIP) sondern ist nur noch ein reiner dummer Pegelwandler !
Im Kapitel "Die Internet Anbindung und Betrieb" hier im Tutorial:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
ist ein Sreenshot einer zum Modem konfigurierten FritzBox abgebildet !!
Das kannst du auch daran sehen wenn du in der pfSense auf die Interface übersicht gehst das dort die öffentliche IP deines providers steht.
Zudem hast du ja auch den WAN Port auf PPPoE gestellt und deine Providerdaten am WAN Port der pfSense konfiguriert !
DAS ist also dein Dreh und Angelpunkt !
Hier musst du das VoIP Port Forwarding machen wenn dein VoIP Endgerät im lokalen Netzwerk befindet. Was das ist hast du uns ja noch nicht mitgeteilt
An der Fritzbox musst du gar nichts forwarden !! Mach das also schnell wieder rückgängig !!
Da die FB bei dir nur als reines Modem arbeitet "versteht" diese doch gar kein IP (und damit auch logischerweise kein VoIP) sondern ist nur noch ein reiner dummer Pegelwandler !
Im Kapitel "Die Internet Anbindung und Betrieb" hier im Tutorial:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
ist ein Sreenshot einer zum Modem konfigurierten FritzBox abgebildet !!
Das kannst du auch daran sehen wenn du in der pfSense auf die Interface übersicht gehst das dort die öffentliche IP deines providers steht.
Zudem hast du ja auch den WAN Port auf PPPoE gestellt und deine Providerdaten am WAN Port der pfSense konfiguriert !
DAS ist also dein Dreh und Angelpunkt !
Hier musst du das VoIP Port Forwarding machen wenn dein VoIP Endgerät im lokalen Netzwerk befindet. Was das ist hast du uns ja noch nicht mitgeteilt
In einem extra DMZ Port an "LAN1" der Fritzbox die Fritzbox.
Der Satz ist etwas kryptisch. Eine Fritzbox zu Fritzbox Verbindung macht hier doch keinen Sinn, wie aqui schon schreibt.
Also hast Du: Modem --> (WAN) PfSense (LAN1) --> Fritzbox 7270 --> VOIP ?
Dann müsstest Du unter NAT für das WAN Interface der PfSense alle VOIP Ports an die IP der Fritzbox forwarden. Und die assoziierte Firewallregel am Ende nicht vergessen.
Wenns dann nicht geht, mal in die geposteten Dokumente schauen. Da stand etwas von Problemen mit einseitiger Verbindung bei der PfSense.
Gruß
Buck
OK nur nochmal zur Sicherheit nachgefragt:
Wenn du den angerufenen nicht hörst, denn funktioniert SIP einwandfrei denn das macht die Wahl aber Voice selber wird mit RTP oder RTSP übertragen.
Deine Firewall in der pfSense blockt das also noch.
Das müsstest du aber auch im Firewall Log sehen können ! Also das mal löschen, dann einen Anruf tätigen und mal ins Log sehen, da sollte das dann drinstehen wa sgeblockt ist.
Bedenke das die pfSense bzw. deren IP ja die IP ist die der VoIP Server des Providers "sieht" und Pakete an diese sendet.
Du musst auch imemr 2 Schritte ausführen deshalb:
1.) Einmal generell diese Ports erlauben in den Regeln auf die WAN IP Adresse
2.) dann in den NAT Regeln diese Ports auf die lokale LAN 1 IP der FB forwarden !
Eine Sipgate Doku beschreibt die Grundlagen:
http://www.sipgate.de/static/sipgate.de/media/Hilfe-Routerkonfiguration ...
Wenn du nach NAT oder Firewall und VoIP Ports bei Dr. Google suchst findest du zig Dokus dazu:
http://www.voipmechanic.com/port-forwarding-voip.htm
http://www.voip-info.org/wiki/view/NAT+and+VOIP
usw.
Ansonsten den "Schrotschuss" Ansatz vom Kollegen orcape oben. Erstmal alles aufmachen, checekn obs klappt und dann langsam wieder "zusperren".
das ist eine 2te Fritzbox die mit dem LAN 1 Port im lokalen LAN hängt, richtig `?
Hier soll VoIP terminiert werden ?Wenn du den angerufenen nicht hörst, denn funktioniert SIP einwandfrei denn das macht die Wahl aber Voice selber wird mit RTP oder RTSP übertragen.
Deine Firewall in der pfSense blockt das also noch.
Das müsstest du aber auch im Firewall Log sehen können ! Also das mal löschen, dann einen Anruf tätigen und mal ins Log sehen, da sollte das dann drinstehen wa sgeblockt ist.
Bedenke das die pfSense bzw. deren IP ja die IP ist die der VoIP Server des Providers "sieht" und Pakete an diese sendet.
Du musst auch imemr 2 Schritte ausführen deshalb:
1.) Einmal generell diese Ports erlauben in den Regeln auf die WAN IP Adresse
2.) dann in den NAT Regeln diese Ports auf die lokale LAN 1 IP der FB forwarden !
Eine Sipgate Doku beschreibt die Grundlagen:
http://www.sipgate.de/static/sipgate.de/media/Hilfe-Routerkonfiguration ...
Wenn du nach NAT oder Firewall und VoIP Ports bei Dr. Google suchst findest du zig Dokus dazu:
http://www.voipmechanic.com/port-forwarding-voip.htm
http://www.voip-info.org/wiki/view/NAT+and+VOIP
usw.
Ansonsten den "Schrotschuss" Ansatz vom Kollegen orcape oben. Erstmal alles aufmachen, checekn obs klappt und dann langsam wieder "zusperren".
Mal eine dumme Frage in den Raum geworfen:
Ist am VoIP-Client ein STUN-Server eingetragen?
Ich kenne die Infrastruktur von 1&1 nicht, aber da dein VoIP-Client im lokalen Netz hängt, kann er ohne STUN-Server seine externe IP nicht kennen.
Dies ist jedoch zwingend notwendig, da er diese in den SDP der SIP-INVITES hineinschreiben muss.
Prüfe daher also, ob im VoIP-Client der richtige STUN-Server hinterlegt ist
Danach sollte ein Portforwarding auf 5060/UDP reichen (wobei vermutlich nichtmal das)...
Ist am VoIP-Client ein STUN-Server eingetragen?
Ich kenne die Infrastruktur von 1&1 nicht, aber da dein VoIP-Client im lokalen Netz hängt, kann er ohne STUN-Server seine externe IP nicht kennen.
Dies ist jedoch zwingend notwendig, da er diese in den SDP der SIP-INVITES hineinschreiben muss.
Prüfe daher also, ob im VoIP-Client der richtige STUN-Server hinterlegt ist
Danach sollte ein Portforwarding auf 5060/UDP reichen (wobei vermutlich nichtmal das)...
Das sind die RTP-Ports, die werden jedes Mal mehr oder weniger zufällig ausgehandelt. Bei der FritzBox hast du vermutlich wenig Einfluss darauf, welcher Portrange benutzt werden soll.
Allerdings sollte der RTP-Datenstrom auch ohne Portforwarding seinen Weg durch das NAT finden - denn immerhin sendet die FritzBox ja auch selbst UDP-Pakete an die 1&1-Server, so dass das eine ganz normale Bidirektionale Datenverbindung wird (sonst würde DNS ja auch nicht funktionieren).
Unterstützt deine PFSense "SIP ALG"? Das ist das, was du aktivieren möchtest. Dann arbeitet die PFSense als transparenter SIP- und Mediaproxy...
Allerdings sollte der RTP-Datenstrom auch ohne Portforwarding seinen Weg durch das NAT finden - denn immerhin sendet die FritzBox ja auch selbst UDP-Pakete an die 1&1-Server, so dass das eine ganz normale Bidirektionale Datenverbindung wird (sonst würde DNS ja auch nicht funktionieren).
Unterstützt deine PFSense "SIP ALG"? Das ist das, was du aktivieren möchtest. Dann arbeitet die PFSense als transparenter SIP- und Mediaproxy...
Hi theoberlin,
installiere auf der pfSense mal das Packet "Siproxd" und probiere das ganze noch mal in der bisherigen Konfiguration.
https://doc.pfsense.org/index.php/Siproxd_package
Gruß orcape
installiere auf der pfSense mal das Packet "Siproxd" und probiere das ganze noch mal in der bisherigen Konfiguration.
https://doc.pfsense.org/index.php/Siproxd_package
Gruß orcape
Ein lokaler Labortest brachte folgendes Ergebnis:
Zur Verfügung stand ein VoIP Softclient "Phoner lite" auf einem Windows 7 Laptop und eine VoIP Telefonanlage von Auerswald Compact 3000 VoIP.
Beide wurden an einem Sipgate Basic VoIP Anschluss getestet mit Standard Einstellungen.
Als pfSense Plattform kamen einmal eine Watchguard X-Core 500 Plattform und ein klassisches ALIX 2D13 zum Einsatz jeweils mit der aktuellsten 2.1er Firmware nur um sicherzustellen das es keine HW spezifischen Unterschiede gibt.
Der Testaufbau sah so aus:
(Internet)==DSL==(Cisco NAT Router)----LAN---(WAN-pfSense-LAN)---Labornetz---(Laptop, oder Anlage)
Die besondere Herausforderung bei diesem Aufbau war also das doppelte NAT durch den Cisco und auch die pfSense. Vorab wurde aber wasserdicht die beiden VoIP Endgeräte auch im LAN getestet um sicherzustellen das der Cisco Router SIP und RTP sauber durchreicht, was der Fall war.
Gestartet wurde mit einer Standardkonfig also pfSense Ver. 2.1 einfach hochgefahren mit den Factory Defaults. Den WAN Port ins LAN gesteckt (Cisco vergibt IPs mit DHCP) und am LAN Port den Laptop bzw. die Anlage aufgesteckt.
Keinerlei NAT Forwarding oder spezielle Firewall Rules konfiguriert, nur Default Konfig.
Ergebnis: Sowohl die Anlage als auch der Softclient konnten sofort eine SIP und RTP Verbindung zum Registrar aufbauen und sich registrieren bei SIPgate.
Ein Testanruf auf deren Testnummer 10005 spielte auch die testweise aufgenommene Sprache vom Endgerät problemlos zurück was schon mal vielversprechend war.
Ein folgender Testanruf aus dem externen ISDN Netz und auch einer vom GSM Mobilfunk Netz auf jeweils die Anlage und auch den Softclient wurden sauber durchgereicht und beide Endgeräte klingelten.
Bei Annahme des Anrufs war problemloser beidseitiger Telefonieverkehr möglich.
Der Austausch der pfSense Plattform war dann nur noch reine Formsache. Mit beiden Hardwaren funktionierte es fehlerfrei ! Ein mitgeschnittener Wireshark Trace vom Registrieren (SIP) und auch dem darauf folgenden Anruf (RTP) belegt das eindeutig !
Fazit: Es ist keinerlei zusätzliche oder spezielle VoIP Konfiguration oder Anpassung der Firewall Regeln erforderlich bei der pfSense für die VoIP Telefonie im lokalen LAN !
VoIP Telefonie Zugriffe aus dem lokalen LAN über die pfSense funktionieren also problemlos "out of the Box" ohne spezielle Konfiguration !
War eigentlich auch vorauszusehen, denn das können heutige Consumer Billigstrouter auch und von einer professionellen Firewall sollte man das allemal erwarten können.
Zur Verfügung stand ein VoIP Softclient "Phoner lite" auf einem Windows 7 Laptop und eine VoIP Telefonanlage von Auerswald Compact 3000 VoIP.
Beide wurden an einem Sipgate Basic VoIP Anschluss getestet mit Standard Einstellungen.
Als pfSense Plattform kamen einmal eine Watchguard X-Core 500 Plattform und ein klassisches ALIX 2D13 zum Einsatz jeweils mit der aktuellsten 2.1er Firmware nur um sicherzustellen das es keine HW spezifischen Unterschiede gibt.
Der Testaufbau sah so aus:
(Internet)==DSL==(Cisco NAT Router)----LAN---(WAN-pfSense-LAN)---Labornetz---(Laptop, oder Anlage)
Die besondere Herausforderung bei diesem Aufbau war also das doppelte NAT durch den Cisco und auch die pfSense. Vorab wurde aber wasserdicht die beiden VoIP Endgeräte auch im LAN getestet um sicherzustellen das der Cisco Router SIP und RTP sauber durchreicht, was der Fall war.
Gestartet wurde mit einer Standardkonfig also pfSense Ver. 2.1 einfach hochgefahren mit den Factory Defaults. Den WAN Port ins LAN gesteckt (Cisco vergibt IPs mit DHCP) und am LAN Port den Laptop bzw. die Anlage aufgesteckt.
Keinerlei NAT Forwarding oder spezielle Firewall Rules konfiguriert, nur Default Konfig.
Ergebnis: Sowohl die Anlage als auch der Softclient konnten sofort eine SIP und RTP Verbindung zum Registrar aufbauen und sich registrieren bei SIPgate.
Ein Testanruf auf deren Testnummer 10005 spielte auch die testweise aufgenommene Sprache vom Endgerät problemlos zurück was schon mal vielversprechend war.
Ein folgender Testanruf aus dem externen ISDN Netz und auch einer vom GSM Mobilfunk Netz auf jeweils die Anlage und auch den Softclient wurden sauber durchgereicht und beide Endgeräte klingelten.
Bei Annahme des Anrufs war problemloser beidseitiger Telefonieverkehr möglich.
Der Austausch der pfSense Plattform war dann nur noch reine Formsache. Mit beiden Hardwaren funktionierte es fehlerfrei ! Ein mitgeschnittener Wireshark Trace vom Registrieren (SIP) und auch dem darauf folgenden Anruf (RTP) belegt das eindeutig !
Fazit: Es ist keinerlei zusätzliche oder spezielle VoIP Konfiguration oder Anpassung der Firewall Regeln erforderlich bei der pfSense für die VoIP Telefonie im lokalen LAN !
VoIP Telefonie Zugriffe aus dem lokalen LAN über die pfSense funktionieren also problemlos "out of the Box" ohne spezielle Konfiguration !
War eigentlich auch vorauszusehen, denn das können heutige Consumer Billigstrouter auch und von einer professionellen Firewall sollte man das allemal erwarten können.
Das müsste man dann mal wirklich genau mit einem Wireshark Trace untersuchen.
Der hiesige zeigt auch ein paar Interessante Dinge beim Phoner Lite Softclient die der nicht negotiaten konnte aber dennoch problemlos funktionierte.
Gut die benutzte Version ist 3 Jahre alt
Appropos...
Ziemlich erschreckend war, das die RTP Voice Daten weder vom Softclient noch von der Anlage verschlüsselt übertragen wurden mit SRTP zu Sipgate.
Klickt man beim Wireshark Trace auf das erste RTP Packet des Telefonats hat der einen Player onboard der dann fröhlich die gesamte Telefon Kommunikation über den Laptop Lautsprecher abspielt.
Da bekommt man schon gehörig Bauchschmerzen und überlegt sich wahrlich ob man auf einen VoIP Vollanschluss wechseln sollte ?!!
Der hiesige zeigt auch ein paar Interessante Dinge beim Phoner Lite Softclient die der nicht negotiaten konnte aber dennoch problemlos funktionierte.
Gut die benutzte Version ist 3 Jahre alt
Appropos...
Ziemlich erschreckend war, das die RTP Voice Daten weder vom Softclient noch von der Anlage verschlüsselt übertragen wurden mit SRTP zu Sipgate.
Klickt man beim Wireshark Trace auf das erste RTP Packet des Telefonats hat der einen Player onboard der dann fröhlich die gesamte Telefon Kommunikation über den Laptop Lautsprecher abspielt.
Da bekommt man schon gehörig Bauchschmerzen und überlegt sich wahrlich ob man auf einen VoIP Vollanschluss wechseln sollte ?!!
Eine Lösung wie es geht findet man auch hier:
http://www.godo.ch/index.php/projekte/3-linux/16-isdn-voip-mit-fritzbox ...
http://www.godo.ch/index.php/projekte/3-linux/16-isdn-voip-mit-fritzbox ...
Bei Godo wohl nun unter Open Source Projekte gelandet...
https://www.godo.ch/index.php/2014/01/16/isdn-voip-mit-fritzbox-und-pfse ...
https://www.godo.ch/index.php/2014/01/16/isdn-voip-mit-fritzbox-und-pfse ...