15
PfSense VoIP-Ports manuell einrichten
Hallo,
ich habe hier verschiedenen VoIP-Endgeräte angeschlossen an einer Fritzbox, die Verbindung funktioniert zu dem 3CX-Server, Telefonieren nach außen ist möglich (STUN ist aktiviert). Auf dem Admin-Dashboard des Servers sind alle Clients als registriert angezeigt.
pfSense ist so eingerichtet (Siehe Screenshots):
Das eigentliche Problem ist, dass die Anrufe zwar herausgehen, hören tut man aber nichts.
Was ich nicht weiß:
- reicht es auf dem Modem - der sich vor Firewall und vor Fritzbox in der Kette befindet - UDP 5060 auf die Fritzbox statisch weiterzuleiten oder sollen auch alle RTP-Ports.
- dieselbe Frage betrifft auch die WAN / LAN interfaces der PF. Sollen auch dort alle Ports geöffnet werden oder nur Outbound?
Danke sehr für eure Hilfe.
Hier ist die Skizze des Netzwerkes:
Gr. I.
ich habe hier verschiedenen VoIP-Endgeräte angeschlossen an einer Fritzbox, die Verbindung funktioniert zu dem 3CX-Server, Telefonieren nach außen ist möglich (STUN ist aktiviert). Auf dem Admin-Dashboard des Servers sind alle Clients als registriert angezeigt.
pfSense ist so eingerichtet (Siehe Screenshots):
Das eigentliche Problem ist, dass die Anrufe zwar herausgehen, hören tut man aber nichts.
Was ich nicht weiß:
- reicht es auf dem Modem - der sich vor Firewall und vor Fritzbox in der Kette befindet - UDP 5060 auf die Fritzbox statisch weiterzuleiten oder sollen auch alle RTP-Ports.
- dieselbe Frage betrifft auch die WAN / LAN interfaces der PF. Sollen auch dort alle Ports geöffnet werden oder nur Outbound?
Danke sehr für eure Hilfe.
Hier ist die Skizze des Netzwerkes:
Gr. I.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 231346
Url: https://administrator.de/contentid/231346
Printed on: April 19, 2024 at 23:04 o'clock
15 Comments
Latest comment
Hallo,
man kann das lles auf verschiedenen Wegen realisieren;
- Einen kleine Askozia oder Asterisk Appliance in eine DMZ stellen
- Das Plugin FreeSwitch auf der pfSense installieren.
- Mit dem STUN arbeiten
Gruß
Dobby
man kann das lles auf verschiedenen Wegen realisieren;
- Einen kleine Askozia oder Asterisk Appliance in eine DMZ stellen
- Das Plugin FreeSwitch auf der pfSense installieren.
- Mit dem STUN arbeiten
Gruß
Dobby
Ich würde gerne mit STUN arbeiten. Asterisk oder Freeswitch brauchen wir ja nicht. Wir haben einen 3CX Server, der seit Ewigkeiten gut funktioniert. Hier muss lediglich pfSense so eingerichtet werden, dass die Geräte telefonieren können.
Auf den beiden Screenshots sieht man welche Ports ich eingerichtet habe.
Ich habe auch von dem Modem einen Route auf den Fritzbox eingerichtet.
Was ich nicht weiß:
sollen die betroffenen Ports SIP 5060 und die RTP Ports sowohl inbound als auch outbound (LAN und WAN) interfaces der pfSense geöffnet werden?
Laut pfSense-Doku liegt es an folgendes: https://doc.pfsense.org/index.php/VoIP_Configuration
Gr. I.
Auf den beiden Screenshots sieht man welche Ports ich eingerichtet habe.
Ich habe auch von dem Modem einen Route auf den Fritzbox eingerichtet.
Was ich nicht weiß:
sollen die betroffenen Ports SIP 5060 und die RTP Ports sowohl inbound als auch outbound (LAN und WAN) interfaces der pfSense geöffnet werden?
Laut pfSense-Doku liegt es an folgendes: https://doc.pfsense.org/index.php/VoIP_Configuration
Gr. I.
kannst Du bitte mal eine Zeichnung anfertigen wie Dein
Netzwerk wirklich aussieht!? Denn irgend wie sehen viele
Leute das was sie zu hause installiert haben und teilen
uns hier im Forum immer nur die Hälfte mit und dann
müssen wir uns den Rest denken, was nicht immer von
Erfolg gekrönt ist!
Gruß
Dobby
Wenn schon eine AVM Fritz!Box vorhanden ist
wozu dann noch ein Modem und wo steht der
3CX Server denn nun wirklich?
Netzwerk wirklich aussieht!? Denn irgend wie sehen viele
Leute das was sie zu hause installiert haben und teilen
uns hier im Forum immer nur die Hälfte mit und dann
müssen wir uns den Rest denken, was nicht immer von
Erfolg gekrönt ist!
Gruß
Dobby
Wenn schon eine AVM Fritz!Box vorhanden ist
wozu dann noch ein Modem und wo steht der
3CX Server denn nun wirklich?
Skizze siehe in dem ersten Posting.
Fritzbox brauchen wir aus zwei Gründen:
- als Host für die VoIP-Zugänge für die DECT-Handsets
- SFR gibt uns nicht die DSL-Zugangsdaten. Ihre Box muss eingesetzt werden.
Gr. I.
Fritzbox brauchen wir aus zwei Gründen:
- als Host für die VoIP-Zugänge für die DECT-Handsets
- SFR gibt uns nicht die DSL-Zugangsdaten. Ihre Box muss eingesetzt werden.
Gr. I.
Fritzbox brauchen wir aus zwei Gründen:
ok nun wird es ein wenig klarer.Hast Du die Fritz!Box na LAN Port1 oder am WAN Port
installiert? Und wo steht der CX3 Server denn?
Gruß
Dobby
Fritzbox hängt mit LAN1 am Switch.
CX3 Server steht draussen in einem Rechenzentrum wir mieten ihn.
Ich habe jetzt noch aus dem pfSense Log einige Ports manuell freigeben, zumindest die ausgehenden Telefonate scheinen jetzt zu klappen.
Mit diesen Einstellungen
Warum auch, sie waren ja auch früher freigegeben ...? Einziger Unterschied, dass hier die IP-Adresse des Servers natürlich explizit festgelegt wurde. (Siehe blaue Markierungen)
Das einzige was noch nicht klappt sind die eingehenden Gespräche auf Clients hinter NAT.
Ich muss diese Ports dann wohl auch an dem WAN-Interface des Firewalls öffnen.
Da ich in dem pfSense-Log keinen Spur von blockiertem Traffic sehe vermute ich mal, dass ich aus dem 10.1.3.0 Netz noch weitere Ports / Routes ins 10.1.2.0 ermöglichen muss. Aktuell erreichen die Pakete den Firewall wohl erst gar nicht.
Eventuell so: http://www.tecchannel.de/kommunikation/handy_pda/433069/voip_hinter_ein ...
Das Problem ist, dass wir neben der FB noch weitere Clients haben die SIP benutzen und IP per DHCP bekommen. Auch dann wenn ich denen statische IPs zuweisen würde wäre es schwierig auf alle Portblöcke freizuschalten.
Gr. I.
CX3 Server steht draussen in einem Rechenzentrum wir mieten ihn.
Ich habe jetzt noch aus dem pfSense Log einige Ports manuell freigeben, zumindest die ausgehenden Telefonate scheinen jetzt zu klappen.
Mit diesen Einstellungen
Warum auch, sie waren ja auch früher freigegeben ...? Einziger Unterschied, dass hier die IP-Adresse des Servers natürlich explizit festgelegt wurde. (Siehe blaue Markierungen)
Das einzige was noch nicht klappt sind die eingehenden Gespräche auf Clients hinter NAT.
Ich muss diese Ports dann wohl auch an dem WAN-Interface des Firewalls öffnen.
Da ich in dem pfSense-Log keinen Spur von blockiertem Traffic sehe vermute ich mal, dass ich aus dem 10.1.3.0 Netz noch weitere Ports / Routes ins 10.1.2.0 ermöglichen muss. Aktuell erreichen die Pakete den Firewall wohl erst gar nicht.
Eventuell so: http://www.tecchannel.de/kommunikation/handy_pda/433069/voip_hinter_ein ...
Das Problem ist, dass wir neben der FB noch weitere Clients haben die SIP benutzen und IP per DHCP bekommen. Auch dann wenn ich denen statische IPs zuweisen würde wäre es schwierig auf alle Portblöcke freizuschalten.
Gr. I.
Du hast einen grundlegenden Fehler gemacht:
1.) Das "Modem" vor der pfSense ist KEIN Modem sondern ein Router (vermutlich). Ein Modem hat keine IP und ist am IP Forwarding unbeteiligt !
Du nutzt vermutlich einen weiteren NAT Router in der Kaskade davor, richtig ?
Das kannst du daran sehen das die Provider Zugangsdaten "dort" definiert sind !
Wäre es ein Modem würde der WAN Port der pfSense im "PPPoE Modus" stehen und die Zugangsdaten wären auf der pfSesne konfiguriert !
2.) Kardinalsfehler: Niemals solltest du das WAN Interface der pfSense im DHCP Modus laufen lassen. Grund: Die IP Adressvergabe geschieht dynamisch. Ändert sich diese mal aufgrund der Dynamik von DHCP, dann laufen ggf. konfigurierte Port Forwarding Anweisungen auf dem Router im Nirwana.
Hier gilt: Immmer statische IP Adressierungen in solchen Konstrukten verwenden !
Ausnahme: Dein vorgeschalteter Router supportet ein DHCP Nailing wo du auf Basis einer Mac Adresse immer fest eine IP Adresse zuweisen kannst. Dann wäre die pfSense WAN IP ja auch quasi statisch !
Du solltest ertsmal folgendes testen:
Es wäre mal generell hilfreich zu erfahren was eigentlich diese unsinnige Konstrukt mit 3 NAT (Adress Translation) Kaskaden für einen tieferen Sinn hat ? Vom Design sieht das ziemlich unglücklich nach "Von hinten durch die Brust ins Auge..." aus. Generell ist jeder NAT Hop immer problematisch für VoIP da die beteiligten Protokolle nicht unbedingt sehr NAT freundlich sind.
Man müsste nur mal den Sinn verstehen.
Nebenbei: Die Regel 10.2.11 auf einen Broadcast Adresse .255 ist übrigens völliger Unsinn und überflüssig weil eine Firewall/Router keine Broadcasts forwardet. Broadcasts sind so oder so nur fürs lokale Netz gedacht, verlassen das also niemals. Die kannst du auch entfernen...
Ebenso gilt das für die 224.0.0.1 als Zieladresse. Das ist einen Multicast Adresse: http://de.wikipedia.org/wiki/Multicast die ebenfalls das Segment nicht verlässt. ICMP nutzt diese Adressen so oder so niemals. Die ist also auch sinnfrei und kann weg.
Das problem mit den eingehenden Gesprächen sind in der Tat die fehlenden Port Forwardings. Der VoIP Server im Internet "sieht" ja nur die WAN IP Adresse des ersten Routers (vor der pfSense) als Ziel zu den Endgeräten. Wenn nun also ein Call per SIP reinkommt, dann MUSS dort 5060 auf den WAN Port der pfSense forgewardet werden. Wenn du mehrere SIP Endgeräte hast dann 5061, 5062 usw.
Nimm einen Sniffer, dann siehst du das ! Ebenso die STUN Ports müssen durch die Router Kaskade 2mal geforwardet werden und natürlich auch in der pfSense erlaubt sein als Zugriff auf die dortige WAN IP ! Derzeit blockst du hier alles und da ist es klar das das nicht klappt.
Sinnvollerweise solltest du hier auch das RFC 1918 Netz Blocking vom WAN Port deaktivieren !! (Default Setting)
Hier lauert die oben angesprochene Gefahr mit DHCP am pfSesne WAN Port ! Beachte das !
Im Zweifel benutz die Sniffing Funktion der pfSense !
1.) Das "Modem" vor der pfSense ist KEIN Modem sondern ein Router (vermutlich). Ein Modem hat keine IP und ist am IP Forwarding unbeteiligt !
Du nutzt vermutlich einen weiteren NAT Router in der Kaskade davor, richtig ?
Das kannst du daran sehen das die Provider Zugangsdaten "dort" definiert sind !
Wäre es ein Modem würde der WAN Port der pfSense im "PPPoE Modus" stehen und die Zugangsdaten wären auf der pfSesne konfiguriert !
2.) Kardinalsfehler: Niemals solltest du das WAN Interface der pfSense im DHCP Modus laufen lassen. Grund: Die IP Adressvergabe geschieht dynamisch. Ändert sich diese mal aufgrund der Dynamik von DHCP, dann laufen ggf. konfigurierte Port Forwarding Anweisungen auf dem Router im Nirwana.
Hier gilt: Immmer statische IP Adressierungen in solchen Konstrukten verwenden !
Ausnahme: Dein vorgeschalteter Router supportet ein DHCP Nailing wo du auf Basis einer Mac Adresse immer fest eine IP Adresse zuweisen kannst. Dann wäre die pfSense WAN IP ja auch quasi statisch !
Du solltest ertsmal folgendes testen:
- VoIP Telefon am WAN Netzwerk anschliessen und testen ob Telefonie sauber funktioniert
- Dann am LAN Port der pfSense erstmal "any zu any" erlauben wie bei der Default Regel um zu verhindern das irgendwas hängenbleibt.
- Dann Telefon umklemmen auf den LAN Port der pfSense und nochmal testen. Funktioniert die Telefonie ? Wenn ja jetzt besser langsam Regel für Regel hinzufügen und sehen wo es dann nicht mehr geht. Mit dieser Vorgehensweise weisst du immer welche Regel dir die Telefonie blockt !
Es wäre mal generell hilfreich zu erfahren was eigentlich diese unsinnige Konstrukt mit 3 NAT (Adress Translation) Kaskaden für einen tieferen Sinn hat ? Vom Design sieht das ziemlich unglücklich nach "Von hinten durch die Brust ins Auge..." aus. Generell ist jeder NAT Hop immer problematisch für VoIP da die beteiligten Protokolle nicht unbedingt sehr NAT freundlich sind.
Man müsste nur mal den Sinn verstehen.
Nebenbei: Die Regel 10.2.11 auf einen Broadcast Adresse .255 ist übrigens völliger Unsinn und überflüssig weil eine Firewall/Router keine Broadcasts forwardet. Broadcasts sind so oder so nur fürs lokale Netz gedacht, verlassen das also niemals. Die kannst du auch entfernen...
Ebenso gilt das für die 224.0.0.1 als Zieladresse. Das ist einen Multicast Adresse: http://de.wikipedia.org/wiki/Multicast die ebenfalls das Segment nicht verlässt. ICMP nutzt diese Adressen so oder so niemals. Die ist also auch sinnfrei und kann weg.
Das problem mit den eingehenden Gesprächen sind in der Tat die fehlenden Port Forwardings. Der VoIP Server im Internet "sieht" ja nur die WAN IP Adresse des ersten Routers (vor der pfSense) als Ziel zu den Endgeräten. Wenn nun also ein Call per SIP reinkommt, dann MUSS dort 5060 auf den WAN Port der pfSense forgewardet werden. Wenn du mehrere SIP Endgeräte hast dann 5061, 5062 usw.
Nimm einen Sniffer, dann siehst du das ! Ebenso die STUN Ports müssen durch die Router Kaskade 2mal geforwardet werden und natürlich auch in der pfSense erlaubt sein als Zugriff auf die dortige WAN IP ! Derzeit blockst du hier alles und da ist es klar das das nicht klappt.
Sinnvollerweise solltest du hier auch das RFC 1918 Netz Blocking vom WAN Port deaktivieren !! (Default Setting)
Hier lauert die oben angesprochene Gefahr mit DHCP am pfSesne WAN Port ! Beachte das !
Im Zweifel benutz die Sniffing Funktion der pfSense !
Hallo Aqui,
Danke!
ja, die Neufbox von SFR ist ähnlich wie Fritzbox Modem mit Routerfunktionen. Die Zugangsdaten sind dort eingegeben. Wir brauchen ihn also.
pfSense brauche ich wegen OpenVPN-Server und die Fritzbox wegen der DECT-Telefone bzw. wegen der VoIP-Zugänge. Alle drei haben also einen Sinn.
2. WAN als DHCP. Den Denkfehler habe ich inzwischen auch entdeckt und geändert.
Ich werde mal deine Testvorgehensweise abarbeiten. Sowohl WAN also auch LAN auf "any zu any" ändern und schauen ob etwas hängen bleibt.
gr. I.
Danke!
ja, die Neufbox von SFR ist ähnlich wie Fritzbox Modem mit Routerfunktionen. Die Zugangsdaten sind dort eingegeben. Wir brauchen ihn also.
pfSense brauche ich wegen OpenVPN-Server und die Fritzbox wegen der DECT-Telefone bzw. wegen der VoIP-Zugänge. Alle drei haben also einen Sinn.
2. WAN als DHCP. Den Denkfehler habe ich inzwischen auch entdeckt und geändert.
Ich werde mal deine Testvorgehensweise abarbeiten. Sowohl WAN also auch LAN auf "any zu any" ändern und schauen ob etwas hängen bleibt.
gr. I.
Wir brauchen ihn also.
Nein, nicht zwingend, denn ein simples Modem und das Setzen der Zugangsdaten in der pfSense wäre technisch erheblich besser !Wenn du die FB wegen der Telefonie brauchst warum setzt du diese dann nicht VOR die pfSense und fackelst damit alles ab !
Das erspart dir den dritten Router und die Performance wird es dir auch danken...
1
Klar. Wenn wir das PW wüssten. SFR rückt es nicht aus. Sie haben die Box vorkonfiguriert zugeschickt... Plug & Play halt... 
Zitat von @aqui:
Wenn du die FB wegen der Telefonie brauchst warum setzt du diese dann nicht VOR die pfSense und fackelst damit alles ab !
Wenn du die FB wegen der Telefonie brauchst warum setzt du diese dann nicht VOR die pfSense und fackelst damit alles ab !
Weil pfSense neben OpenVPN natürlich auch sicherheitsrelevante Funktion hat
, WLAN wird aber leider über FB verwendet. So würden die User den FW natürlich umgehen.
Ich sehe jetzt, dass Internet erst dann stabil funktioniert, wenn ich den WAN interface auf DHCP setze. Will ich einen statischen IP4 Adresse einstellen, in diesem Fall 10.1.3.1 gibt es nur Izugang mit Aufrufezeichen. 10.1.3.1 ist die IP-Adresse des Modems als Gateway eingestellt.
Ich wüsste nicht, was ich noch als Gateway benutzen könnte.
Sonst funktioniert eigentlich alles bis auf die eingehenden Gespräche. Die Clients können telefonieren, können aber vom VoIP-Server nicht erreicht werden. Im WAN-Interface der PfSense ist nichts blockiert. Es soll also wohl an den fehlenden Routing zwischen Modem und Firewall.
Mein Problem ist mit all diesen Umleitungen, dass ich mehrere IPs habe worauf ich Ports umleiten müsste. Gibt es eventuell eine sinnvolle Methode,.
Im Grunde stellt sich die Frage, wie ich die Ports so einrichten könnte, dass STUN funktioniert. Dies wäre ja im Grunde dafür zuständig, dass ein Client hinter NAT gefunden wird.
Wie stelle ich es sicher?
Gr. I.
Ich wüsste nicht, was ich noch als Gateway benutzen könnte.
Sonst funktioniert eigentlich alles bis auf die eingehenden Gespräche. Die Clients können telefonieren, können aber vom VoIP-Server nicht erreicht werden. Im WAN-Interface der PfSense ist nichts blockiert. Es soll also wohl an den fehlenden Routing zwischen Modem und Firewall.
Mein Problem ist mit all diesen Umleitungen, dass ich mehrere IPs habe worauf ich Ports umleiten müsste. Gibt es eventuell eine sinnvolle Methode,.
Im Grunde stellt sich die Frage, wie ich die Ports so einrichten könnte, dass STUN funktioniert. Dies wäre ja im Grunde dafür zuständig, dass ein Client hinter NAT gefunden wird.
Wie stelle ich es sicher?
Gr. I.
Hallo nochmal,
mach Dir das Leben doch nicht so schwer.
- Frag den der die FB konfiguriert hat und dann lass Dir das PW geben!
- Ich würde auch immer den einfachsten und vor allen anderen Dingen
den Weg gehen wollen der am wenigsten Ärger macht!!!
Mensch überlege mal wenn Du bei dem Konstrukt noch ein oder zweimal
was änderst dann geht gar nicht mehr!! Und hier noch Sicherheit zu reden
und direkt ins LAN Ports zu öffnen ist doch auch nur Makulatur, oder?
- pfSense mit FreeSwitch
- So wie @aqui es schon angesprochen hat die AVM FB vor die pfSense
- Eine Askozia oder Asterisk PBX in eine DMZ an der pfSense
- Den LAN Port 4 der AVM FB zu einem DMZ Port machen und dann
via "Exposed host" an das WAN Interface der pfSense und an die anderen
LAN Ports der FB einen Switch nur mit den IP Telefonen.
Also Möglichkeiten gibt es da genug für Dich (Euch) da muss man sich
nur mal vernünftig einen Plan machen und dann kann man das auch ohne
Komplikationen abhandeln.
Gruß
Dobby
mach Dir das Leben doch nicht so schwer.
- Frag den der die FB konfiguriert hat und dann lass Dir das PW geben!
- Ich würde auch immer den einfachsten und vor allen anderen Dingen
den Weg gehen wollen der am wenigsten Ärger macht!!!
Mensch überlege mal wenn Du bei dem Konstrukt noch ein oder zweimal
was änderst dann geht gar nicht mehr!! Und hier noch Sicherheit zu reden
und direkt ins LAN Ports zu öffnen ist doch auch nur Makulatur, oder?
- pfSense mit FreeSwitch
- So wie @aqui es schon angesprochen hat die AVM FB vor die pfSense
- Eine Askozia oder Asterisk PBX in eine DMZ an der pfSense
- Den LAN Port 4 der AVM FB zu einem DMZ Port machen und dann
via "Exposed host" an das WAN Interface der pfSense und an die anderen
LAN Ports der FB einen Switch nur mit den IP Telefonen.
Also Möglichkeiten gibt es da genug für Dich (Euch) da muss man sich
nur mal vernünftig einen Plan machen und dann kann man das auch ohne
Komplikationen abhandeln.
Gruß
Dobby
Ok. danke, ich verstehe. Mir kommt nur die Lösung FB vor dem pfSense in Frage. Ich muss also ein Access Point besorgen, damit DECT und WLAN Funktionalität getrennt werden.
WLAN geht hinter Firewall und DECT vor den Firewall.
Gr. I.
WLAN geht hinter Firewall und DECT vor den Firewall.
Gr. I.
WLAN geht hinter Firewall und DECT vor den Firewall.
So würde ich das auch machen wollen!Gruß
Dobby
