[SOLVED]DMZ mit vlans
-
Hallo zusammen,
ich bin der "NEUE" und auch wenn die Amtsprache EN ist, wollte ich meinen ersten Post hier absetzen. :)
Soweit läuft die pfs recht gut, bin gerade dabei mich hier etwas einzuarbeiten, da ich von einer anderen FW kam, aber ein Teil der Migration ist erfolgreich gewesen. Danke der geilen PFS :-*Nur habe ich ein kleines Verständnisproblem mit der DMZ die ich geschaffen habe, auf Basis eines VLANs und den Zugriff ins Internet und zurück.
mein anderes VLAN für WLAN läuft soweit gut, aber irgendwie habe ich es bei dem DMZ Netz geschafft, dass nix rein oder raus geht.Kann mir jemand kurz erklären wie der Ablauf ist, für einen Zugriff auf HTTP(s) von extern nach intern in das DMZ auf eine ZielIP (Nextcloud) inkl. Interfacesetting und Firewall + Rules.
Muss nicht so genau sein, nur damit ich mal prüfen kann was ich nicht getan habe.Ich muss dazu sagen, meine pfs steht als exposed host hinter der Fritzbox, daher sollte hier nichts geroutet werden müssen.
Über ein paar brauchbare Doc, HowTos oder sonst etwas wäre ich sehr dankbar.Kann auch noch Screens oder Configsettings bei Bedarf hier rein laden, solltet ihr noch etwas spezielles wissen wollen.
Vielen Dank! 5p9
-
Hallo!
Beim Interface gibt es nichts besonderes einzustellen, lediglich ist zu beachten, dass "Block privat networks" nicht angehakt sein darf. Nachdem du auch ein anderes VLAN hinbekommen hast, sollte es ja auch daran nicht scheitern, jedenfalls nicht auf Seite der pfSense.
Für Internet-Zugriff aus der DMZ benötigst du nur eine FW-Regel am DMZ Interface, die das erlaubt und ein funktionierendes Outbound NAT. Bezüglich letzterem, das macht pfS automatisch, jedoch könnte es ein Problem geben, wenn du die Interface-IP geändert hast.
Zu überprüfen in Firewall > NAT > Outbound. Da muss eine Regel für das DMZ-Netz am WAN zu finden sein. Falls nicht hilft es vielleicht, den Modus zu ändern auf manuell und wieder zurück, beides mit speichern, damit die Regel richtiggestellt wird.Fall du den ausgehenden Traffic einschränkst, bedenke, dass zumindest auch DNS erlaubt sein muss.
Erst wenn ausgehende Verbindungen funktionieren, kümmer dich um eingehende.
Im Grunde ist dafür nur eine NAT Portforwarding Regel nötig:
Interface: WAN
Protocol:TCP
Source: any
Source port: any
Destination: die Server IP
Dest. Port: 80
Associated firewall rule: pass oder associated ruleDaselbe nochmals mit Dest. Port 433, oder du packst die beiden Port in einen Alias (Firewall > Aliases > Ports) und verwendest diesen in einer einzigen Regel.
Grüße
-
Moin,
herzlichen Danke für die Infos.
Habs schon einmal geschafft die DmZ nach aussen hin frei zu geben, sprich ping in die weite Welt ist nun möglich. Aber das mit dem Outbound NAT muss ich mir noch ansehen.
Aber daran könnte es liegen ;)Werde es mal testen.
VG, 5p9
EDIT: Ich verstehe es noch nicht…
Also was habe ich bisher:
- Bild 1 ist das Interface selbst
- Bild 2 ist Port Forward
- Bild 3 ist DMZ FW Rules (die letzte Regel ist im Moment aktiv - der Rest nicht und waren nur spielchen)
- Bild 4 ist Outbound und jeweils mit dem Pfeil markiert und somit hinterlegt
Von der DMZ komme ich raus. Vom LAN via https://10.YYY.ZZZ.102 komm ich an die WUI.
Jedoch komme ich nicht via DynDNS Name (der auch hinterlegt ist) nicht von extern oder intern ran! Ist mir irgendwie schleierhaft. :o
- Bild 5 DynDns, muss ich den refresh für den Dyn manuell immer anstoßen oder kann ich dies auch noch definieren? Quasi den Force Update.
-
Hi,
wofür maskierst du deine internen IPs? Die sind doch kein Geheimnis, daran kommt ohnehin keiner ran.
Du hättest meinen Rat befolgen sollen und die nötige Regel für den Webserver per "associated rule" erstellen lassen sollen. Deine ist am falschen Interface. Firewall Regeln gehören immer an dem Interface erstellt, an dem die Verbindung in die pfSense reinkommt. In diesem Fall also am WAN.
Du kannst das einfach richtigstellen, indem du die Regeln editierst und das Interface auf WAN umstellst. Die Regel wird dann auch anstatt auf dem DMZ am WAN Tab angezeigt.Um Nextcloud auch von intern zu erreichen, ist ein DNS Override das beste Mittel. Vorausgesetzt natürlich, du verwendest ein internes DNS.
Andernfalls kannst du es auch mit "NAT Reflection" erreichen. Das ist in der Portforwarding Regel ganz unten zu setzen. Falls der Hostname auch aus der DMZ selbst erreicht werden soll, benötigst du "NAT + proxy". Das ist bspw. nötig, wenn du auch Collabora Online auf der Nextcloud installierst. Ansonsten reicht "Pure NAT".
Ich hatte die Erfahrung gemacht, dass die Proxy-Variante mit den Root-Rechten der Firewall arbeitet. D.h. es gibt immer Zugriff, ungeachtet der FW-Regeln. Deshalb ist "Pure NAT" die bevorzugte Methode nach DNS Override.Was meinst du mit dem DynDNS Refresh manuell anstoßen zu müssen? War das je nötig?
Wenn sich die WAN IP ändert, macht pfSense das automatisch, wenn nicht, macht sie nach 25 Tagen ein DynDNS Update, um den Account aktiv zu halten. -
Für Gedankenhilfe und Logikverständnis ist meist das hier der Ausschlag gebende Punkt:
Filter & NAT Regeln werden IMMER an dem Interface erstellt, an dem ein Paket der Verbindung zum ersten Mal die Firewall "betritt".
5p9 hat z.B. nach einer HTTPS Verbindung vom Internet auf seine Nextcloud in der DMZ gefragt. Also einfach betrachtet:
Client -> WAN/Internet -> OPs Fritzbox, dank exposed Host -> pfSense WAN Interface rein, dann raus aus dem DMZ Interface -> DMZ Host (Nextcloud)
Also spielt sich alle Musik für Freigaben in einer DMZ auf dem WAN ab. Nirgends sonst. Zugriff vom LAN aus auf die DMZ ist dann nochmals gesondert zu betrachten, das hat Virago aber schon wie immer richtig beschrieben: Kann man via NAT Reflection machen, ist aber häßlich. DNS Override bzw. SplitDNS ist da schöner.
Grüße
-
Moin,
wofür maskierst du deine internen IPs? Die sind doch kein Geheimnis, daran kommt ohnehin keiner ran.
die macht der Gewohnheit.
Danke euch beiden für die Unterstützung. Hab da wohl noch Knoten im Kopf ;)
Du hättest meinen Rat befolgen sollen und die nötige Regel für den Webserver per "associated rule" erstellen lassen sollen. Deine ist am falschen Interface.
Ah okay. Das muss ich wohl noch anpassen.
DNS Override bzw. SplitDNS ist da schöner.
Super, an das habe ich noch garnicht gedacht. Muss ich mir auch noch ansehen.
Die denys rules werde ich dann umsetzten wenn ich es so habe wie ich es mir vorstelle.
Was meinst du mit dem DynDNS Refresh manuell anstoßen zu müssen? War das je nötig?
Wenn sich die WAN IP ändert, macht pfSense das automatisch, wenn nicht, macht sie nach 25 Tagen ein DynDNS Update, um den Account aktiv zu halten.Leider bekommt er den täglichen switch nicht mit und alle 25 Tage wäre etwas unpraktisch :D Kann man das nicht noch irgendwie anpassen, bzw. feststellen warum er es nicht mitbekommt?
VG, 5p9
-
@5p9:
Was meinst du mit dem DynDNS Refresh manuell anstoßen zu müssen? War das je nötig?
Wenn sich die WAN IP ändert, macht pfSense das automatisch, wenn nicht, macht sie nach 25 Tagen ein DynDNS Update, um den Account aktiv zu halten.Leider bekommt er den täglichen switch nicht mit und alle 25 Tage wäre etwas unpraktisch :D Kann man das nicht noch irgendwie anpassen, bzw. feststellen warum er es nicht mitbekommt?
Wie? Deine WAN IP ändert sich und die pfSense aktualisiert nicht automatisch das DynDNS?
Dass sie es nicht mitbekommt, kann doch gar nicht sein. Schließlich ist die Erneuerung der IP eine Aktivität der pfSense selbst.Also bei mir sieht das so aus:
WAN = PPPoE
Mein Provider trennt die Verbindung nach längstens 24 Stunden, beim Wiederaufbau bekommt die pfSense eine neue WAN IP. Weil sich damit die Trennung zeitlich immer etwas nach hinten verschiebt, habe ich in der WAN Interface Konfiguration einen "Custom reset" gesetzt, damit das immer zur gleichen Zeit in den frühen Morgenstunden passiert.
Das DynDNS (auch SPDNS) wird sofort nach der Wiederherstellung der PPPoE-Verbindung aktualisiert. Das funktioniert aber auch ohne "Custom reset" tadellos.Wenn das bei dir nicht klappt, stimmt wohl etwas nicht. Schau mal ins System-Log. Die IP-Erneuerung und alles, was damit zusammenhängt, wird da immer ausführlich geloggt, ebenso die DynDNS-Aktualisierung.
Falls du das dennoch irgendwie beeinflussen möchtest oder es anders nicht klappt, auf der pfSense läuft ein cron-Job, standardmäßig einmal täglich um 1:01 Uhr, der die Übereinstimmung der DNS-Einträge mit der WAN-IP überprüft und das DynDNS ggf. aktualisiert (/usr/bin/nice -n20 /etc/rc.dyndns.update). Wenn du diesen ändern möchtest, installiere dir das cron-Paket, anschließend kannst du in Services > Cron die Jobs editieren.
Grüße
-
Morgen,
Wie? Deine WAN IP ändert sich und die pfSense aktualisiert nicht automatisch das DynDNS?
Dass sie es nicht mitbekommt, kann doch gar nicht sein. Schließlich ist die Erneuerung der IP eine Aktivität der pfSense selbst.genau so ist es. Da es sich bei der WAN Adresse um eine private IP handelt, kann es schon sein, dass er dies nicht mitbekommt. WAN Adresse ist auf der Fritzbox als ExposedHost hinterlegt.
/usr/bin/nice -n20 /etc/rc.dyndns.update
Vielen Dank für diesen Tipp! Habe an der Fritzbox meine Wunschzeit hinterlegt und im Cron den Check dahingehend angepasst. Sau geil und läuft nun.
Ich muss hier noch viel lernen wie die pfs arbeitet. Aber, danke an Alle die hier daran arbeiten. Wahninn…
Das mit der DMZ muss ich auch noch testen. Zum Teil funktioniert der Zugriff, aber die Weiterleitung habe ich noch nicht hinbekommen. Sprich wenn ich am WAN Interface mein https Port öffne und meine DynDns für die Cloud von extern aufrufe, komme ich zumindestens schon einmal an die pfs (longin) ran. Was ich nicht will, aber es ist schon mal der richtig Schritt in die richtige Richtung. :)
Ich werde es dann mal weiter versuchen die Tage. Bis dahin, vielen Dank für die Inputs!
VG, 5p9
-
Hallo,
ja, das DynDNS-Update sollte das Geräte machen, das die WAN-IP hat und die Änderung mitbekommt. Alles andere ist suboptimal.
@5p9:
Das mit der DMZ muss ich auch noch testen. Zum Teil funktioniert der Zugriff, aber die Weiterleitung habe ich noch nicht hinbekommen. Sprich wenn ich am WAN Interface mein https Port öffne und meine DynDns für die Cloud von extern aufrufe, komme ich zumindestens schon einmal an die pfs (longin) ran. Was ich nicht will, aber es ist schon mal der richtig Schritt in die richtige Richtung. :)
Ich verwende generell nicht die Ports 80 oder 443 für die WebGUI der pfSense.
Das lässt sich in System > Advanced > Admin Access ändern. Hier setze ich einen anderen TCP Port und mache einen Haken bei "Disable webConfigurator redirect rule", dann gibt es keine Probleme mit einer Portweiterleitung zu einem Webserver.Grüße
-
So, habs nun wie folgt mit meiner Cloud hingebogen.
Jetzt muss ich nur noch die Netze sauber trennen und nur die gewünschten Ports entsprechend für LAN, WLAN und DMZ hinterlegen. Sieht soweit schon recht gut aus.
Danke für eure Unterstützung!
VG, 5p9
-
genau so ist es. Da es sich bei der WAN Adresse um eine private IP handelt, kann es schon sein, dass er dies nicht mitbekommt. WAN Adresse ist auf der Fritzbox als ExposedHost hinterlegt.
Nope, das bekommt die pfSense trotzdem mit. Ist die WAN IP eine private IP wird der Check mittels Prüfung auf checkip.dyndns.org erledigt. Steht bei dem DynDNS Eintrag sogar extra dabei:
Interface to Monitor: WAN
-> If the interface IP address is private the public IP address will be fetched and used instead.Somit sollte das immer funktionieren und nicht manuell angestoßen werden müssen. Gerade checkip kann sonst auch mal zickig werden wenn zu oft angefragt wird. Ich nutze das hinter einer Kabel-Fritte schon seit Jahr und Tag zuverlässig
