23
Pfsense Port Forwarding NAT für VOIP
Nabend allerseits,
ich sitze jetzt schon ein paar Stunden an der Konfig der pfsense. Irgendwie funktioniert das Port forwarding / Outbound NAT nicht so wie es soll.
Ich habe mich an diese Anleitung gehalten, aber es will einfach nicht fliegen.
Hier meine Konfig:
Wo liegt der Fehler.....ich sehe den Wald gerade vor lauter Bäumen nicht. Ich denke aber, es liegt am NAT, denn raus kann ich telefonieren.
Gruß
ich sitze jetzt schon ein paar Stunden an der Konfig der pfsense. Irgendwie funktioniert das Port forwarding / Outbound NAT nicht so wie es soll.
Ich habe mich an diese Anleitung gehalten, aber es will einfach nicht fliegen.
Hier meine Konfig:
Wo liegt der Fehler.....ich sehe den Wald gerade vor lauter Bäumen nicht. Ich denke aber, es liegt am NAT, denn raus kann ich telefonieren.
Gruß
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: 281060
Url: https://administrator.de/contentid/281060
Ausgedruckt am: 05.11.2024 um 07:11 Uhr
23 Kommentare
Neuester Kommentar
Hallo,
Was sagt denn das Firewall Log der PfSense?
Gruß
Wo liegt der Fehler.....ich sehe den Wald gerade vor lauter Bäumen nicht. Ich denke aber, es liegt am NAT, denn raus kann ich telefonieren.
Aus dieser Frage entnehme ich, dass du keine Telefonate rein bekommst?Was sagt denn das Firewall Log der PfSense?
Gruß
Da ich raus telefonieren kann, zeigt er nichts auffälliges an.
Ich habe aber noch eine Anleitung in den Tutorrials von @aqui gefunden und das werde ich heute Nachmittag mal testen.
Ansonsten nochmal alles auf Anfang.....
Ich habe aber noch eine Anleitung in den Tutorrials von @aqui gefunden und das werde ich heute Nachmittag mal testen.
Ansonsten nochmal alles auf Anfang.....
Den Artikel in Deinem letzten Link habe ich mal ausgedruckt und werde das heute versuchen.
Ich hab die pfsense heute nochmal mit einem anderen Image aufgesetzt.
Damit hat dann auch das Port forwarding nach Anleitung geklappt.
Ich habe nur noch ein Problem. Ich kann aus dem Wlan nicht auf das LAN zugreifen. Aber das bekomme ich auch noch hin....Morgen.
Gruß
Looser
Damit hat dann auch das Port forwarding nach Anleitung geklappt.
Ich habe nur noch ein Problem. Ich kann aus dem Wlan nicht auf das LAN zugreifen. Aber das bekomme ich auch noch hin....Morgen.
Gruß
Looser
Ich kann aus dem Wlan nicht auf das LAN zugreifen.
Das ist auch vollkommen normal für eine Firewall wie jederman weiss !Die Default FW Regel lautet auf dem Interface DENY any any Sprich es wird alles verboten was nicht ausdrücklich erlaubt ist. Üblich eben für eine korrekte Firewall und ja auch gewollt.
Fazit: Passe die Firewall Regel deines WLAN Segments an und alles ist gut !
Entweder mit "Pass <wlan_segemment> any " als "Scheunentor Regel" die alles erlaubt oder etwas dedizierter das du Traffic ins LAN oder so eben blockst und nur ins Internet erlaubst.
Diese Regeln bestimmst ja DU selber !
Übrigens: Mit einem kurzen Blick unter Status --> System Logs --> Firewall hättest du das auch ganz schnell selbst erkannt ! Deshalb spricht die pfSense mit dir über ihre Logs. Man muss das Gesprächsangebot nur mal annehmen... !
Jups....
ABER: Eine Regel die sagt:
pass
Source - WLAN Net
Destination - LAN net
Port - any
sollte mir doch wohl Zugriff verschaffen, den ich dann weiter einschränken kann.
Laut Log kommt der Zugriff auch zustande, jedoch öffnet sich die Website des Devices nicht (VOIP-PBX).
Greife ich auf die Webseite des NAS mit dediziertem Port zu, funktioniert der Zugriff ohne Probleme.
Da muß ich dann nochmal ran.....
ABER: Eine Regel die sagt:
pass
Source - WLAN Net
Destination - LAN net
Port - any
sollte mir doch wohl Zugriff verschaffen, den ich dann weiter einschränken kann.
Laut Log kommt der Zugriff auch zustande, jedoch öffnet sich die Website des Devices nicht (VOIP-PBX).
Greife ich auf die Webseite des NAS mit dediziertem Port zu, funktioniert der Zugriff ohne Probleme.
Da muß ich dann nochmal ran.....
Zitat von @Looser27:
Jups....
ABER: Eine Regel die sagt:
pass
Source - WLAN Net
Destination - LAN net
Port - any
sollte mir doch wohl Zugriff verschaffen, den ich dann weiter einschränken kann.
Jups....
ABER: Eine Regel die sagt:
pass
Source - WLAN Net
Destination - LAN net
Port - any
sollte mir doch wohl Zugriff verschaffen, den ich dann weiter einschränken kann.
Nein, denn es greift immer die 1. Regel zuerst.
Wenn du erst alles erlaubst, sind alle nachfolgenden Regeln obsolete.
Gruß
Das muß ich dann heute Abend nochmal prüfen.
Nein, denn es greift immer die 1. Regel zuerst.
Richtig !!Im Regelwerk gelten 2 grundlegende Regeln:
- "First match wins" ! Sprich ist eine Regel positiv (Match) werden ALLE folgenden Regeln NICHT mehr ausgeführt. Die Reihenfolge der Regeln ist also essentiell wichtig für deren Funktion ! (Siehe Tutorial wo das MEHRFACH erwähnt ist.)
- Regeln gelten immer nur INBOUND. Also für Pakete die vom Draht oder WLAN IN die Firewall gehen.
Wenn du das beachtest klappt das auch.
Mein Vorgehen war schon soweit richtig. Es lag am Device. Hier gab es eine Möglichkeit die Fernwartung aus anderen Netzen zu deaktivieren. Kaum aktiviert funktionierte es.
Hauptsache es rennt nun wie es soll
Vielleicht postest du nochmal einen Screenshot der finalen Regeln mit denen es jetzt funktioniert. Das hilft sicher auch anderen die die pfSense nutzen mit VoIP Devices am lokalen LAN.
Vielleicht postest du nochmal einen Screenshot der finalen Regeln mit denen es jetzt funktioniert. Das hilft sicher auch anderen die die pfSense nutzen mit VoIP Devices am lokalen LAN.
So. Hier noch die Screenshots von den Firewall-Regeln für VOIP im LAN:
NAT:
WAN (werden automatisch aus der NAT-Regel generiert):
LAN:
Die IP 192.168.1.250 ist meine Telefonanlage.
Bei meiner Telefonanlage sind eingehend die SIP-Ports UDP 5004-5020 weiterzuleiten.
Zusätzlich noch UDP 5060 für SIP.
Ausgehend habe ich alle UDP Ports freigegeben, weil ich in den Logs eine sehr willkürliche Auswahl von UDP Ports gefunden habe, über die das Gespräch dann geführt wird.
Schränkt man hier ein, kommt das Gespräch nur sporadisch zu stande.
Die LAN-Regeln für SIP und STUN kann man sich eigentlich sparen, wenn man sowieso alle UDP Ports abgehend freigibt.
NAT:
WAN (werden automatisch aus der NAT-Regel generiert):
LAN:
Die IP 192.168.1.250 ist meine Telefonanlage.
Bei meiner Telefonanlage sind eingehend die SIP-Ports UDP 5004-5020 weiterzuleiten.
Zusätzlich noch UDP 5060 für SIP.
Ausgehend habe ich alle UDP Ports freigegeben, weil ich in den Logs eine sehr willkürliche Auswahl von UDP Ports gefunden habe, über die das Gespräch dann geführt wird.
Schränkt man hier ein, kommt das Gespräch nur sporadisch zu stande.
Die LAN-Regeln für SIP und STUN kann man sich eigentlich sparen, wenn man sowieso alle UDP Ports abgehend freigibt.
Danke fürs Feedback. Das hiesige pfSense Tutorial verweist auf diesen Link
Hallo, musste den Hoster wechseln, dabei auch gleich die Seite umgestellt. Der Link zur Anleitung ist zu meiner Lösung neu hier zu finden: https://www.godo.ch/index.php/2014/01/16/isdn-voip-mit-fritzbox-und-pfse ...
Dank für das Update. Ggf. kannst du deinen pfSense Screenshot zur Lösung noch direkt hier posten
(Bild hochladen)
(Bild hochladen)
Ich habe eine Frage zum 3. Bild - LAN (Beitrag: Looser27 am 28.08.2015)
Dort werden in der ersten Zeile UDP an Ports 1-65535 weitergeleitet und als VoIP RTP ext. kommentiert.
In Zeile 2 und 3 werden jeweils UDP für Ports 5060 (SIP) und 3478 (STUN) weitergeleitet. Aber diese Ports sind doch schon den Bereich der 1. Zeile von 1 bis 65535 abgedeckt. Oder soll in Zeile 2+3 TCP statt UDP stehen?
Dort werden in der ersten Zeile UDP an Ports 1-65535 weitergeleitet und als VoIP RTP ext. kommentiert.
In Zeile 2 und 3 werden jeweils UDP für Ports 5060 (SIP) und 3478 (STUN) weitergeleitet. Aber diese Ports sind doch schon den Bereich der 1. Zeile von 1 bis 65535 abgedeckt. Oder soll in Zeile 2+3 TCP statt UDP stehen?
An keinem einzigen der LAN Bilder wird irgendwo UDP an Ports 1-65535 weitergeleitet ! Wo bitte siehst du das ?
Außerdem wäre das auch gefährlicher Blödsinn, denn das betrifft ja die gesamte verfügbare TCP/IP Port Range. So einen gefährlichen Unsinn macht niemand der klar denken kann !
Am lokalen LAN Port hat man eh eine (Default) Regel Lokales_net --> Any die ALLES freigibt. Folglich muss man an den lokalen LAN Regeln auch niemals fummeln.
Außerdem wäre das auch gefährlicher Blödsinn, denn das betrifft ja die gesamte verfügbare TCP/IP Port Range. So einen gefährlichen Unsinn macht niemand der klar denken kann !
Am lokalen LAN Port hat man eh eine (Default) Regel Lokales_net --> Any die ALLES freigibt. Folglich muss man an den lokalen LAN Regeln auch niemals fummeln.
Ich lese das an dem 3. Bild mit der Überschrift LAN, da steht doch 1-65535.
Moin,
hier die Erklärung:
hier die Erklärung:
Ausgehend habe ich alle UDP Ports freigegeben, weil ich in den Logs eine sehr willkürliche Auswahl von UDP Ports gefunden habe, über die das Gespräch dann geführt wird.
Schränkt man hier ein, kommt das Gespräch nur sporadisch zu stande.
Schränkt man hier ein, kommt das Gespräch nur sporadisch zu stande.
Ich habe jetzt die FritzBox als "nur Telefonie-Box" seit mehreren Tagen problemlos am IP-Anschluß der Telekom im Betrieb, siehe Bilder im Anhang
Glückwunsch das es klappt ! Und...danke für das Feedback
Ich habe zu danken dafür, daß ich ermutigt wurde, weiterzumachen 
