Hallo liebe Leute,
ich möchte meinen Freifunk-Router über eine eigene NIC an einer pfSense-Firewall betreiben. Welche Ports müsste ich freischalten, damit der Freifunk-Router durchkommt, Port 10000, Port 10010?
Vielen Dank
1 „Gefällt mir“
Normalerweise brauchst du nur den Zugrif auf dein Gateway-Port im pfSense via NAT.
Portforwarding für einzelne Ports brauchst du gar nicht.
Ob es Sinn macht den Zugriff aufs inet durch einen ausgehenden weiteren Firewall zu begrenzen wage ich zu bezweifeln.
Wenn der Freifunk-Router ein eigenes LAN hat, besteht ja im Normalfall kein Zugriff auf dein privates LAN.
Fazit: du musst nur auf an deiner inet-Schnittstelle ausgehenden Traffic vom FF-Router erlauben.
Harry
Hallo Max_Bandbreite,
ganz einfach:
- Port 10000 UCP fastd VPN
- Port 53 UDP/TCP DNS
Gruß Jörg
1 „Gefällt mir“
Wenn der FF-Router hinter einem NAT hängt (was die Regel sein dürfte) ist das überflüssig.
Harry
Nicht jedeR hat unendliches Vertrauen, z.B. weil er oder sie ihre Gluon-Images nicht selbst baut.
(oder keine Lust/Zeit/Durchblick hat, den Source auditieren.)
Von daher ist „Betrieb am Gastlan“ oder „hinter Firewall“ nicht verkehrt. (Und ja, PFsense ist performant und hat trotzdem einen schmalen Fußabdruck.)
1 „Gefällt mir“
Das hab ich nicht angezweifelt.
Ich verwende selber seit Jahren pfSense, und auch bei mir hängen die FF-Router in einem separaten LAN.
Allerdings braucht es dazu keinerlei Port-Forwarding.
Harry
Ich denke, dass es dem Threadstarter nicht um Portforwarding, sondern nur um Filtering auf der FW (hier: LAN>WAN) geht.
Wenn die FF-Router in einem eigenen LAN hängen braucht man nichts ausser der NAT-Regel!
In der Grundkonfiguration (automatic NAT-rules) wird die sogar autom. angelegt.
1 „Gefällt mir“
Ich glaube, hier prallen zwei unterschiedliche Sichtweisen/Strategien gegeneinander.
Die einen fangen eben mit „deny_all“ an und schalten frei, von dem was sie wissen was benötigt wird.
Die anderen beginnen mit „allow_all“ und sperren dann das, von dem sie glauben, dass es problematisch ist.
Beides valide Ansätze. Aber wenn der Threadstarter nach den Regeln für die „deny_all“-Strategie fragt, dann ist das hier vermutlich nicht der richtige Ort, ihn zu überzeugen, dass „allow all“ doch viel besser sei.
„deny-all“ ist Standard (auch bei pfSense)
So lange alle FF-Knoten in einem separaten LAN liegen und es nur um den Uplink ins inet geht, reicht die NAT-Rule.
1 „Gefällt mir“
…wobei wir bald aus „Solidaritätsgründen“ alle mal IPfire testen müssten, immerhin wird dort gerade an einer nativen Implementierung des Freifunk für uns gearbeitet… 
Ich fürchte ja fast, dass das dann OSLR sein wird
Ich werde ausführlich über das Projekt und die Details berichten.
Gruß,
Philip
1 „Gefällt mir“
Hallo, hier ist der Thread-Starter wieder.
Vielen Dank für die angeregte Diskussion. Auch, wenn ich immer noch nicht sicher bin, was ich jetzt genau machen soll, habe ich wieder Einiges mitnehmen können. Ich will mal weiter ausholen:
Ich bin kein IT-Profi, sondern betreibe für mich, meine Mitbewohnerin und einen Nachbarn ein gemeinsames LAN. Tief schockiert über die anhaltende, staatlich gedeckte und tiefgreifende Überwachungssch… hatte ich (kurz)zeitig sogar überlegt den Stecker ganz zu ziehen, aus Prinzip!
Der für uns neue Ansatz ist nun grundsätzlich ALLES was ein Kabel hat als feindlich anzusehen. Eine wichtige Investition war nun eine pfSense-Firewall (läuft seit einer Woche). Die pfSense-Kiste hat ausreichend NICs und arbeitet gleichzeitig als DHCP. Unser kabelgebundenes LAN hat einen eigenen Adressbereich, unser WLAN ebenfalls und zum vergleichsweise anonymen Surfen und anderen guten Gründen soll nun ein Freifunk-Router an eine eigene NIC kommen. Jetzt soll ausschließlich der VPN-Verkehr des Freifunk-Routers über die ihm eigene und ausschließliche NIC durch die pfSense-Kiste ins Internet kommen, sonst soll dieser Kanal so dicht wie möglich sein (deny-all!!).
Für DAUs: Was muss ich in pfSense wie freischalten, bitte?
Vielen lieben Dank und herzliche Grüße
P.S.: Wo logge ich mich hier im Forum eigentlich wieder aus?
Du must NAT-Regeln für alle gewünschten Ports einrichten.
Findest du im Menu unter Firewall->NAT->Outbound
Ohne jede Regel ist das LAN dicht.
Mit den NAT-regeln erlaubst du den Zugriff auf deine DSL-Verb.
Denk dran den Outbound NAT-Mode auf „Manual Outbound NAT rule generation“ zu stellen, sonst generiert der dir automatisch Regeln die den Zugriff nach Aussen erlauben.
Wenn du das umgestellt hast, kannst du automatisch generierte Regeln löschen und/oder ändern.
Und zum Thema ipFire:
Alles schön und gut; ich hab selber bis vor ca. 3J ipFire genutzt.
Heute kann ich das nicht mehr verwenden, da das auf die 4 Zonen WAN,LAN,DMZ und Wireless begrenzt ist, und ohne Gefrickel keine VLANs beherscht.
Ich hab im pfSense inzw. einige Zonen mehr
…soweit mir das bislang bekannt ist sind Deine Informationen ab der IPfire Version 3 veraltet…
Werd ich mir gerne nochmal anschauen, aber am So. beim FF-Treffen in Witten war auch jemand vom ipFire-Team, und da hörte sich das anders an.
Klare Aussage: „keine VLAN-Config in der GUI“.
Wenn ich das richtig verstanden hab, auch weiterhin nur 4 Zonen.
Abgesehen davon wäre der Aufwand auf einen anderen FW umzustellen absolut unzumutbar.
Dann stell ich lieber ne Kiste mit nem Atom-Board nur für FF daneben.
Zu VLan Config in de Gui weiß ich nichts.
Explizit wurde mir gesagt, dass die 3er Version beliebig viele Zonen unterstützen würde.
Darüber hinaus dann die Freifunk Integration, bei der sich die Firewall wohl selber direkt per fastd ins bspw. Freifunk Ruhrgebiet Netz einwählt und auf eine Zone bridged, inkl. batman und zipp und zapp, um keinen Plasterouter mehr für den Freifunk benutzen zu müssen, ohne einen eigenen Linux Server für den Zugang manuell aufzubauen.
Das halte ich soweit erstmal durchaus für eine nennenswerte Innovation, auch wenn die Scripte und Web-Gui Integration nun erst noch gebaut werden müssen
In der Tat.
Kann der sich nicht die site.conf von Gluon einlesen?
Das wäre der Idealfall.
Der Philip müsste da mal was zu sagen, mein Stand ist weder aktuell noch detailliert genug, um dazu was sagen zu können, wie es nun tatsächlich funktionieren soll.