DMZ oder besser DMZs?
-
Ok, konnte es jetzt mit meiner 100.65.xxx.xxx-IP, also meiner tatsächlichen WAN-IP, ebenfalls nachvollziehen, danke @JeGr !!
Edit: Und das in der Regel definierte Gateway verhindert den Zugriff ebenfalls nicht. Mein Eindruck zu Gateways ist, dass diese keine geprüften Voraussetzungen für eine Regel/Verbindung darstellen, sondern lediglich den Traffic anschließend ausleiten, sofern anwendbar.
-
@Bob-Dig said in DMZ oder besser DMZs?:
Edit: Und das in der Regel definierte Gateway verhindert den Zugriff ebenfalls nicht. Mein Eindruck zu Gateways ist, dass diese keine geprüften Voraussetzungen für eine Regel darstellen, sondern lediglich den Traffic anschließend ausleiten, sofern anwendbar.
Nun es schiebt den Traffic dann aus der Firewall ausgehend aus dem angegebenen Interface. In dem Fall wird es aber dort behalten weil die Firewall merkt, dass sie selbst gemeint ist. Daher klappt es wohl auch gut. Wie gesagt, wenn du jetzt RFC Block nicht drin hättest und wolltest ins LAN zugreifen würde es nicht klappen, weil der Traffic übers VPN gepresst wird und dort dann am GW abgewiesen wird. Darum muss auch bei MultiWAN bspw. und Policy Regeln da entsprechend drauf geachtet werden, dass man interne Ausnahmen o.ä. definiert, die als Gateway "default" (*) angegeben haben, damit das interne Routing sauber läuft.
Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!
If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.
-
@JeGr gerade mal getestet und Du hattest, wie immer, recht. Aber jetzt wird es wieder schwierig für mich, dem ganzen logisch zu folgen. Warum ist das Gateway mal optional und dann wieder nicht.
-
@Bob-Dig said in DMZ oder besser DMZs?:
Warum ist das Gateway mal optional und dann wieder nicht.
Warum sollte es optional sein? Dem kann ich jetzt nicht folgen.
-
@JeGr Na ja, warum konnte ich mit allein dieser Regel noch auf die Firewall zugreifen, wenn doch sämtlicher Traffic hätte ausgeleitet werden müssen. Du hattest schon was dazu geschrieben, ein logisches Problem aber bleibt (für mich).
-
Weil die IP auf der Firewall bekannt ist. Warum sollte ich ein Paket routen, wenn ich es selbst bin? Ganz einfach. Klar kann ich auf das Paket noch den Sticker draufkleben "schicke es über VPN wenns raus geht" aber wenns nicht raus gehen muss - ist das eben obsolet.
-
@JeGr Es ist und bleibt aber eine Regelverletzung.
-
@Bob-Dig said in DMZ oder besser DMZs?:
@JeGr Es ist und bleibt aber eine Regelverletzung.
Wie kommst du darauf? Nein ist es nicht?
Regel sagt "erlaube alles was NICHT RFC1918 ist und überall hin will". Zusätzlich sagst du damit "route wenn nötig als GW nicht per Default sondern per VPN". Da Routing unnötig -> Paket bereits am Ziel wenn Firewall erreicht - ist das alles komplett legitim.
-
@JeGr said in DMZ oder besser DMZs?:
Wie gesagt, wenn du jetzt RFC Block nicht drin hättest und wolltest ins LAN zugreifen würde es nicht klappen, weil der Traffic übers VPN gepresst wird und dort dann am GW abgewiesen wird. Darum muss auch bei MultiWAN bspw. und Policy Regeln da entsprechend drauf geachtet werden, dass man interne Ausnahmen o.ä. definiert, die als Gateway "default" (*) angegeben haben, damit das interne Routing sauber läuft.
Ich sehe das im Widerspruch zu dem hier, wo etwas durchs Gateway gepresst wird, obwohl ja ebenfalls unnötig. Aber wie gesagt, mir fehlt da wohl der Blick fürs große Ganze und solange es Sinn für dich macht, alles supi.
-
@Bob-Dig said in DMZ oder besser DMZs?:
wo etwas durchs Gateway gepresst wird, obwohl ja ebenfalls unnötig.
Das passiert aber nur, weil es nicht die Firewall selbst ist, also keine lokale IP. Ergo wird es geroutet. Und statt der Routing Tabelle wird eben durch die Regel (PBR) dann das Gateway "erzwungen" und das Paket da rausgepresst. Wenns aber nirgends hin muss - bleibts zu Hause :)
-
@JeGr said in DMZ oder besser DMZs?:
- rejected alles was DMZ_net auf DMZ_net ist (wäre standard)
Moin Jens,
ich habe nochmal eine Frage dazu.
Was wäre hierfür das Anwendungsgebiet. Wenn ich einen Switch angeschlossen hätte, so könnte pfSense auf dem selben Interface eh nichts filtern, weil der Verkehr allein über besagten Switch liefe, korrekt? Was beträfe das also, vielleicht wenn ich Ports in pfSense gebridged hätte?
-
Da ich Bridging auf der Sense vermeide wie Teufel und Weihwasser und ich das einfach Unfug finde, ja vielleicht. Es blockiert gegenüber "_address" eben jegliche Adresse aus dem "_net" auch wenn ich der Firewall mehrere IPs gebe. Ggf. will ich ja wirklich nur innerhalb des Netzes filtern. Anderer Punkt: NAT Reflection unterbinden. Bei Reflects wäre der Zugriff tatsächlich von _net auf _net weil die IP aus der DMZ auf die externe IP geht, auf der FWL umgeschrieben wird auf die DMZ IP und dann wieder in die DMZ geht. Ich möchte aber ggf. gar nicht dass sich Kiste 1 selbst via extern aufruft oder Kiste 2 über extern aufruft, sondern die sollen direkt intern miteinander reden um direkter zu kommunizieren und Latenz zu sparen. Rejecte ich das, merkt man das sofort ob/was für ein Zugriff da zum Tragen kommt.
-
@JeGr Danke Dir.
Denke, damit ist das Thema DMZ hinreichend beschrieben. Schönes WE. -
Oder bis später? ;)
-
@Bob-Dig said in DMZ oder besser DMZs?:
Der xmpp-Client verbindet sich übrigens mit IPv6, was die Sache wohl erklärt. Das doofe daran, ich wollte ja damit bewusst ein Stück weit und einfach die Erreichbarkeit von außen testen, was so wahrscheinlich gar nicht funktioniert. Gut, ich hab ja immer noch StatusCake.
Hatte gerade mal wieder einen Ausfall. Nun läuft's wieder, aber IPv6 geht noch nicht und ich sehe, dass die Verbindung über IPv4 erfolgt, wie gesagt, ohne NAT Reflection. Faszinierend.
-
Ich habe jetzt die DMZs fertig angelegt.
Was mich noch stört ist die Reihenfolge der Interface in pfSense, insbesondere unter Firewall / Rules. Gibt es hier eine Möglichkeit Ordnung bzw. eine gewünschte Reihenfolge einzurichten? Ggf. welche Risiken wären damit verbunden?
Und spricht etwas dagegen, den ganzen /48er und den /64er von HE in einen Alias zu packen und ihn dann quasi als RFC1918-Alias zu nutzen?
Würde die Regelerstellung vereinfachen.
Und wenn ich unter dieser ASN-Nummer von meinem ISP gucke, dann sehe ich dessen gesamtes IPv6-Netz? Das könnte ich ja auch noch dem Alias hinzufügen, um sicherzustellen, dass auch mein dynamischer IPv6-Prefix nie angegrabbelt werden kann?
-
@Bob-Dig said in DMZ oder besser DMZs?:
Was mich noch stört ist die Reihenfolge der Interface in pfSense, insbesondere unter Firewall / Rules. Gibt es hier eine Möglichkeit Ordnung bzw. eine gewünschte Reihenfolge einzurichten? Ggf. welche Risiken wären damit verbunden?
Deshalb hatte ich da schonmal gesagt, ich sortiere die alphabetisch und benenne die Interfaces mit Prefixen. Dann ist das meine Sortierung :)
System / General -> Sortierung mit Haken auf alphabetisch. Dann einfach den Namen ändern. Fertig.
-
@JeGr Danke, werde ich dann auch so machen. Und auch ne Meinung zum Rest des gesagten?
-
@Bob-Dig said in DMZ oder besser DMZs?:
Und spricht etwas dagegen, den ganzen /48er und den /64er von HE in einen Alias zu packen und ihn dann quasi als RFC1918-Alias zu nutzen?
Würde die Regelerstellung vereinfachen.Ja, weil es nichts mit RFC1918 zu tun hat ;)
Nenne es wie du möchtest - aber bitte nicht RFC9181 :)Und wenn ich unter dieser ASN-Nummer von meinem ISP gucke, dann sehe ich dessen gesamtes IPv6-Netz? Das könnte ich ja auch noch dem Alias hinzufügen, um sicherzustellen, dass auch mein dynamischer IPv6-Prefix nie angegrabbelt werden kann?
Nicht zwangsläufig, außerdem haben Provider oftmals mehrere ASNs.
-
@JeGr said in DMZ oder besser DMZs?:
Nenne es wie du möchtest - aber bitte nicht RFC9181 :)
Gegenvorschläge? :)
