[Solved] DMZ mit zwei externen Subnetzen

[StephanBiegel]

Ich richte gerade ein DMZ für einen Webserver auf eine aktuellen OpnSense ein.
Die Grundkonfiguration funktioninert

Ich habe:
- ein LAN Interface > rein zum Zugang auf die Firewall
- ein WAN Interface > mit einem 8er IP Block und dem entsprechenden Gateway konfiguriert x.x.x.x/29. Erste IP direkt der Rest als virtuelle IPs angelegt.
- ein internes DMZ, hinter dem ein Testserver steht > hierfür ausgehende Regeln für Internetzugriff konfiguriert. Welcher auch geht
- Portforwarding für ICMP eingerichtet

Ping von extern auf den Server geht.

Nun habe ich noch einen weiteren 16er IP Bereich x.x.x.x/28, welchen ich nicht zum Laufen bekomme.

Ich habe die IPs als virtuelle auf dem WAN Interface definiert und die Portweiterleitung eingerichtet. Erstmal nur ICMP zum Testen. Mit dieser externen IP kann ich den Server nicht Pingen.

Ich habe auch bereits mal versucht ein Gateway, erst normal, dann die fernes Gateway Option aktiviert zu nutzen. Dazu habe ich die WAN Firewall Regeln manuell erzeugt und das Gateway ausgewählt. Hat mich leider nicht weiter gebracht.





Habt Ihr noch einen Tipp für mich?

[Hunduster]

Hallo Stephan,

bezüglich deines zweiten Public Subnetz: ist dieses vom selbigen Provider am selbige Anschluss?

Beide Subnetze benötigen in jedem Fall ein "Upstream" Gateway auf der OPNsense, da die Pakete sonst nicht geroutet werden können.

[StephanBiegel]

Ja, sind vom gleichen Provider.
Ich habe auch das Gateway für das zweite Netzsegment angelegt. Aber ich wüsste nun nicht, wo ich das Einstellen kann. I WAN Interface kann ich ja nur eine Hauptadresse definieren und ein Upstream Gateway hinterlegen.
Die anderen IPs sind im Moment ja nur virtuelle. Dort hatte ich entdeckt das man unter erweiterte Einstellungen ein Gateway hinterlegen kann. Hab da mal testweise die IP eingetragen des Gateways. Das hat aber nicht geholfen.

Kannst Du mir sagen, wie ich hier richtig vorgehen muss?
Danke schonmal für die Hilfe :)

[Hunduster]

Also ich habe ein sehr ähnliches Szenario an einem Colt Glasfaser-Anchluss. Hier habe ich zwei /29er Netze.

Auf dem WAN-Interface habe ich die erste IP aus Subnetz A angelegt.

Alle weiteren IPs aus Subnetz A und Subnetz B sind bei mir als CARP-Adressen hinterlegt, was am Cluster liegt und analog zu deinen Virtual IPs ist. Soweit also alles richtig. Bei den CARP/VIPs habe ich dann jeweils das passende Gateway für die Subnetze hinterlegt.

Für beide Subnetze ist jeweils das passende Gateway angelegt, wobei bei das Gateway aus Subnetz A das Upstream Gateway ist und das Gateway aus Subnetz B Upstream UND "Far Gateway" ist. Letzteres bedeutet, dass die OPNsense nicht meckert, dass eben dieses Gateway nicht aus dem Netz von Subnetz A stammt, welches ja fest an das Interface gebunden ist.

Somit sollte Gateway B online gehen und die IPs aus Subnetz B sollten erreichbar sein.

[StephanBiegel]

Danke! Es funktioniert jetzt.

Habe ich dann jeweils das passende Gateway für die Subnetze hinterlegt.

War der wichtige Satz. Da die ersten IPs ja bereits gingen, habe ich hier die Gateways weggelassen.
Dachte das er für die ja den Upstream Gateway nimmt.
Es ist aber wohl so, dass wenn man eins konfiguriert, man alle einstellen muss.

Danke für die Hilfe!

[StephanBiegel]

Kleiner Nachtrag.
Nach dem Post habe ich dann die Portweiterleitung auf einen anderen Host umgestellt.
Dann ging es wieder nicht.
Habe nun die virtuelle IP in einen CARP Anschluss gewandelt. Jetzt scheint es zu gehen.
Mehrfach umgestellt, entfernt und wieder hinzugefügt.
Geht jetzt immer. Keine Ahnung, ob das ein Bug in den virtuellen IPs ist.

[Hunduster]

Da die ersten IPs ja bereits gingen, habe ich hier die Gateways weggelassen.

Eigentlich sollte die OPNsense anhand des Subnetzes das passende Gateway automatisch auswählen, sodass die Einstellung hier nicht von Nöten ist. Aber es ist OK, ich hab es auch so gemacht.

Denk ggf. noch dran, eine WAN Gruppe einzurichten, sodass deine internen Systeme auf die Gruppe maskiert werden (NAT) und raus können, sollte eines der GWs mal ausfallen. Die FW-Regeln musst du dann entsprechend auch auf die WAN Gruppe setzen.

[StephanBiegel]

Da hier auch Mailserver auf den Kisten in der DMZ laufen, müssen die immer über das Richtige GW und mit der richtigen Sende IP hinaussenden. Sonst lehnen viele SMTP Server ab, da die IPS nicht als MX im DNS stehen.

Musste dafür auch noch die automatischen ausgehenden Regeln deaktivieren und manuelle erstellen mit der jeweiligen externen IP als Maskierung. Klappt jetzt gut. Noch Geoblocking davor gehauen und schön ist :)

Danke. Hast mir echt weiter geholfen!

[Hunduster]

Da hier auch Mailserver auf den Kisten in der DMZ laufen, müssen die immer über das Richtige GW und mit der richtigen Sende IP hinaussenden. Sonst lehnen viele SMTP Server ab, da die IPS nicht als MX im DNS stehen.

Musste dafür auch noch die automatischen ausgehenden Regeln deaktivieren und manuelle erstellen mit der jeweiligen externen IP als Maskierung. Klappt jetzt gut. Noch Geoblocking davor gehauen und schön ist :)

Das ist ja unabhängig voneinander. Das Regel- und NAT-Werk arbeitet ja von oben nach unten. Du machst also für deine Mailserver SNAT auf die entsprechend richtige IP. Hier reicht ja Port 25 ausgehend, musst ja nicht den ganzen Server über eine feste IP "natten". Die dafür notwendige FW-Regel geht dann auch nur auf das jeweilige Gateway.

Alle anderen Regeln auf die WAN Gruppe, damit die beim Ausfall eines Gateways noch raus können - somit wäre ggf. nur der Mailserver offline bzw. nicht fähig zu senden.

Wie gesagt ist nur noch ein Tipp  ;)

[Reiner030]

Kleiner Nachtrag.
Nach dem Post habe ich dann die Portweiterleitung auf einen anderen Host umgestellt.
Dann ging es wieder nicht.
Habe nun die virtuelle IP in einen CARP Anschluss gewandelt. Jetzt scheint es zu gehen.
Mehrfach umgestellt, entfernt und wieder hinzugefügt.
Geht jetzt immer. Keine Ahnung, ob das ein Bug in den virtuellen IPs ist.

Das ist leider - schon bei pfSense - nicht gut dokumentiert gewesen.
Es ist wohl kein "Bug" von virtuellen IPs, IP Aliasen usw., sondern die sind einfach nicht für bestimmte Services geeignet, weil zumindest bestimmte Services z.B. auf ein IP Alias kein bind() machen können, wo man nur mit CARP IPs erfolgreich weiterkommt.

[StephanBiegel]

@Hunduster: Stimmt, so ginge das. :)

@Reiner030: Danke für die Aufklärung. Ja, sollte im NAT Port forwarding Guide erwähnt werden, dass es da mit virtuellen IPs zu Problemen kommen kann :) Ich denke ein DMZ mit zwei Subnetzen ist jetzt nichts so Ungewöhnliches für eine Firewall.

Auch den Hinweis, dass manche Regeländerungen erst ziehen, wenn man die Statustabelle löscht, hätte mir einiges an Selbstzweifel erspart. ;)

Das würde ich als ersten Satz in die Firewall-Regeln Sektion schreiben.