Freigaben aus LAN in DMZ routen

Moin.

Ist das ein Tipfehler?

Mit Portforwarding hat das nichts zu tun.

Die Routen sollten schon passen, beide Netze sind ja local für die pfSense

Gemounted wird nach wie vor von 192.168.1.6 - die NAS IP ändert sich ja nicht.

Du must lediglich die CIFS-Ports (135,137 und 445 wenn micht nicht alles täuscht) für neue Verbindungen von (DMZ)Ubuntu an (LAN)NAS freigeben.

lg,
Slainte

Nein, das sind Firewall Regeln... "Erlaube Port 445 von Ubuntu an NAS" - dabei wird immer die IP der NAS verwendet, niemals die IP der pfSense.

@em-pie
Wenn die komm. LAN->DMZ funktioniert, würde ich mir über die IPFire erstmal keine Gedanken machen

Jo, hast du recht... Wenn man mal genauer drüber nachdenkt
Naja, aber somit hat er jetzt zumindest auf dem Schirm, dass die Pakete in jedem Fall über die IPFire "rutschen", da diese ja offensichtlich das Gateway für die DMZ ist, da die Kommunikation LAN-DMZ zunächst zu funktionieren scheint....

Naja vielleicht gibt's ja auch einen entsprechenden routing Eintrag auf dem Ubuntu... aber da würde ich jetzt mit Hinsicht auf den Kenntnisstand des TOs nicht drauf eingehen

WAS ist denn die DMZ ? Das 192.168.10.0er Segment ?
Wäre ja Blödsinn, denn das ist keine richtige DMZ. Oder ist das das Segment wo das NAS drin ist ??

Kommst du denn aktuell irgendwie an die Ubuntu-Kiste dran (SSH)?
Wenn ja, mach mal ein traceroute auf das NAS vom Uuntu-Server aus.
Dann wissen wir schon mal, welchen Weg die Kiste geht

@aqui
in meinen Augen hat er doch genau eine DMZ abgegildet: https://www.elektronik-kompendium.de/sites/net/0907241.htm
Der Ubuntu-Server steht in der DMZ, das einzige, was er nur vor hat, ist von der DMZ aus einen Zugriff zur NAS zu ermöglichen.

Hallo,

also normaler weise baue ich hinter einen Router oder eine Firewall nur eine zweite wenn da niemand hinter
kommen soll und das zweite Netzwerk auch vom ersten mittels unterschiedlicher Firmware komplett
abgeschottet sein soll. Denn das erste Netzwerk kann dann entweder Ports geöffnet haben und es
können auch Protokolle weitergeleitet werden.

Wenn man so eine Dual Homed oder Bastion Host Sache aufsetzt dann auch alles in die DMZ rein was von
außen erreichbar sein soll. Also auch das NAS. Ansonsten einen Switch dahinter und einen in die DMZ Zone
rein und man spart sich gleich die zweite Firewall komplett auf zum spielen, üben oder als Ersatz oder gar
für einen HA Einsatz mit nur einer Firewall Software.

Gruß
Dobby

Hallo nochmal,

Ob billig oder teuer ist doch im Endeffekt egal oder? Es geht hier doch darum das man mittels einer (pfSense)
Firewall auch eine DMZ aufmachen kann, und die kann man auch noch mittels Snort oder Suricata gut absichern!

Und wenn man eine Dual Homed DMZ oder Router Kaskade anlegt, dann wird in der Regel und aus Sicherheitsgründen
dort kein Port geöffnet und auch kein Protokoll weitergeleitet, ansonsten ist das ganze Konstrukt völlig wertlos und
man wäre mit einem ordentlichen Switch und einer Firewall die ein LAN und eine DMZ bereit stellt wesentlich besser
oder übersichtlicher gefahren! Ist wie bei den Gefängnissen wo erst eine Tür bzw. ein Tor geöffnet wird und wenn das
dann wieder geschlossen wird, dann erst wir die zweite Tür oder das Tor geöffnet. Und wenn nun beide Türen oder
Tore zugleich geöffnet werden dann ist das Sicherheitspotential dieser "Schleuse" völlig wertlos! Eventuell erklärt
das meine Ablehnung an Dein Anliegen etwas besser.

Dann stelle ich das in die DMZ rein und kann aus dem LAN auch drauf zugreifen, fertig.

Verstehe ich jetzt nicht so ganz, man kann auch mittels Linux und Jails arbeiten und dann ist das etwas besser
abgesichert, gar keine frage, ansonsten ist es immer besser alles was Kontakt zum Internet haben soll in die
DMZ zu stellen und alles was keinen Kontakt zum Internet haben soll in das LAN.

Stell Dir doch mal bitte vor dass Du die Tür abschließt und dann das Fenster und die Balkontür offen lässt!

Das ist doch wieder eine ganz andere Sache.

Ich denke heute ist das so, dass viele Leute sich selber mit der EDV/IT auseinander setzten müssen und dann
eben auch gerne einmal machen wollen was möglich ist, nur ob das eben immer Sinn macht ist eben eine andere
Frage. Ich kaufe zusätzlich keinen Sicherungsriegel für die Tür und lasse dann das Fenster auf!

Standard hin oder her da kann man ja immer drüber diskutieren, und jeder macht es anders oder braucht es
anders, aber bei einigen Sachen gibt es früher oder später eben immer Probleme damit und dann ist das eben
sagen wir mal aus Erfahrung vorher besser jemandem davon abzuraten als später andere Probleme mit Ihm
zu lösen.

Ich würde heute gar keinen Port mehr am WAN öffnen wollen oder Protokolle weiterleiten, denn das ist einfach zu
gefährlich und man kann auch alles gut per VPN erreichen. und wenn dort etwas stehen muss oder soll, dann lieber
ein altes gebrauchtes NAS kaufen und dort alles drauf packen und wenn dem dann was passieren sollte ist das auch
kein Problem. Macht aber auch jeder anders, also nimm mir das nicht so "krumm", andere Leute haben auch andere
Meinungen dazu und dafür ist so ein Forum ja auch nicht schlecht!

Gruß
Dobby

@em-pie
Eigentlich ist das nach Definition keine wirkliche DMZ.
Der gesamte Traffic des Client Segments an der pfSense plus der gesamte NAS Traffic gehen ja über dieses "DMZ" Segment. Eine wahre DMZ ist immer ein isoliertes Segment ohne Durchgangstraffic.
Sowas Gruseliges kann man dann nicht wirklich als DMZ bezeichnen, denn das ist Bastelkram aber sicher keine DMZ in dem Sinne..
Wenn überhaupt, dann müsste das Koppelsegment was die pfSense mit der ipFire verbindet eine isolierte Punkt zu Punkt Verbindung sein und die DMZ dann ein entsprechend gesichertes Segment was an der pfSense hängt wie Clients oder NAS.
Dann könnte man von einer DMZ sprechen.

Aber abgesehen davon klappt das natürlich auch so in diesem etwas gewöhnungsbedürftigen Design.
Mit den richtigen Regeln auf der pfSense ist da natürlich keine Tat das sofort zum Fliegen zu bringen.

Am Ubuntu:
Route ins Netz 192.168.1.0/24 mit Gateway 192.168.10.2 eintragen

An der pfSense
Ziel-Ports 137/udp, 138/udp 139/tcp und 445/tcp freigeben von WAN/192.168.10.11 -> LAN/192.168.1.6

Das sollte eigentlich ausreichend sein, ausgehend davon, das auf der pfSense alles LAN -> WAN freigegeben ist.

Statische Routen auf den Servern sollte man besserr vermeiden. Dort immer nur ein Default Gateway eintragen und die Route am Gateway selber eintragen. Router sollen routen
Also etwas abgewandelt und ausführlicher:

Am Ubuntu:
Default Route auf die IP Fire

Auf der IP Fire:
Statische Route ins Netz 192.168.1.0 /24 mit Gateway 192.168.10.2 (pfSense) eintragen

An der pfSense
Am WAN Port den Zugriff von RFC 1918 Netzen erlauben (Haken entfernen in Interfaces -> WAN -> Block Private and loopback networks )
Ziel-Ports 137/udp, 138/udp 139/tcp und 445/tcp freigeben von WAN/192.168.10.11 -> LAN/192.168.1.6 mit einer Regel am WAN Port
Achtung: Das klappt außschliesslich nur wenn das NAS die Session auf den Ubuntu Server initiiert. Also wenn das NAS ein entsprechedes Mapping aufbaut.
Soll es auch umgekehrt gehen das der Ubuntu Server eine Verbindung auf das NAS aufbauen kann musst du zwingend noch eine NAT 1:1 Regel erstellen, denn ansonsten bleibt der Unbuntu Verbindungsversuch an der NAT Firewall der pfSense hängen. Diese macht ja NAT am WAN Port.
Wenn diese Richtung Ubuntu -> NAS auch gewollt ist sollte man sinnvollerweise das NAT komplett deaktivieren auf dem WAN Port im pfSense Setup.

Das wars...damit klappt das auf Anhieb.

Glückwunsch !
Einsicht ist der erste Weg zur Besserung !
Du meinst den WAN Port, oder ? Aber das nix geroutet wird ist natürlich Unsinn. Die FW muss ja routen wenn irgendwelcher Traffic fliessen muss wie auch immer. Ohne Routing hättest du Stillstand.
War wohl eher ein Freudscher Versprecher
Letztlich sind aller alle deine Lösungsansätze absolut richtig und OK. Die Begründung umso mehr.
Fazit: Entspanntes Wochenende...