[Gelöst] Problem mit DMZ - Regeln

JeGr

Hallo Edgar,

Habe ich einen grundsätzlichen Denkfehler in den Regeln?

Ja. Ich denke du gehst zum einen von einem Ketten-artigen Verhalten der Regeln aus, das ist aber nicht der Fall. Zudem zäumst du das Pferd von hinten auf ;) denn per default gibt es bereits eine stehende Regel "BLOCK ANY ANY" die pfSense IMMER aktiv hat. Wenn du also alle Regeln auf einem IF löschst, dann geht kein Traffic mehr von dort aus drüber, da die Default Block Any Regel greift.

Ergo ist dein Screen 1 schonmal overkill, weil du erst einiges verbietest und dann erlaubst. Verkehrt herum. Alles löschen, dann hast du automatisch dein Block anything. Danach legst du nur gezielte Regeln an, die funktionieren sollen und gut ist.

Wichtig: Wenn eine Regel zutrifft wird sie SOFORT ausgeführt. Solltest du also danach noch eine haben, die auch zutreffen würde wird die ignoriert (Pass quick). Wenn du also bspw. das ganze LAN in die DMZ lassen willst aber 1 IP nicht, muss der Block der einen IP zuerst kommen, dann der PASS für das restliche Netz, danach gilt wieder Block any (quasi als immer letzte Regel).

Hoffe dir damit die Denkweise etwas erleichtert zu haben.

Grüße

eanneser

Hi Jens,

(schön, dass Du Dich wieder erbarmst …).

Dann sollte doch dieser Regelsatz (screen) auch Folgendes bewirken:

amadablam (mein Verwaltungsrechner) kann auf Alles in der DMZ
DMZ-Server (alias für alle Server in der DMZ) dürfen überall hin
LOGHOST (Syslog-Server im LAN) ist über UDP aus der DMZ erreichbar
alle Rechner aus der DMZ können ins WAN, also im Internet surfen, mailen usw.
ein Ping / eine Verbindung ins LAN ist (mit Ausnahme des Obigen) nicht möglich
ein Ping / eine Verbindung ins WLAN ist nicht möglich.

Das funktioniert aber so nicht. Ich kann von einem DMZ rechner aus nicht ins WAN (nur wenn ich "WAN net" durch "any" ersetze) - ergo: ich hab's immer noch nicht kapiert! [konkret: von einem DMZ-Rechner aus, ist heise.de über die IP-Adresse 193.99.144.80 nicht erreichbar, also mindestens kein DNS-Problem]

Edgar

screen.png_thumb

JeGr

Nein :) Du hast das verkehrt herum. Wie ich schon an anderer Stelle einmal ausgeführt habe sind die wichtigsten Regeln bei pfSense Filtern:

"Von WO nach WO möchtest du hin"
"Welches ist das ERSTE Interface, dass dabei erreicht wird"

Du möchtest VON "amadablam" IN die DMZ. Da du also in die DMZ willst, gehe ich messerscharf davon aus, dass amadablam eigentlich im LAN steht.

Ergo:

ich möchte VOM LAN in die DMZ
Das LAN ist das ERSTE Interface, dass dabei meine Pakete abbekommt.

Deshalb:

Regelinterface LAN, nicht DMZ
SOURCE = amadablam, NICHT Destination
Destination = DMZ network (alle Hosts der DMZ)

Done :)

Sobald dir das mal ein wenig in Fleisch und Blut übergeht ist es simpel. Die restlichen Regeln ergeben sich daraus:

DMZ Server:

Source = DMZ_Server
Dest = any
Interface DMZ

Loghost:

Source = any
Dest = LOGHOST (Port 514)
Interface = …. Ha, eine Ausnahme. Hier müsste die Regel tatsächlich auf jedes Interface, VON welchem Anfragen an den Loghost kommen. Also bspw. aufs DMZ Interface, damit DMZ Server auf den Loghost dürfen und bspw. auch das WLAN, wenn da bspw. der Access Point seine Logs auf den Loghost werfen soll. Wieder einfach überlegen: Wo steht die Quelle, wo das Ziel, welches ist das erste Interface auf dem Weg. Rückweg ist wegen Stateful eigentlich egal.

DMZ: (NACH der DMZ-Server Regel auf dem DMZ Interface, da die DMZ Server ja überall hin sollen, der Rest aber nur ins WAN)

Source = DMZ network
Destination = (hier würde ich ein Network Alias anlegen, in welchem das LAN Netz und WLAN Netz enthalten ist und dieses mit aktiviertem NOT Schalter einfügen. Damit darf DMZ überall hin aber NICHT ins LAN/WLAN, was also nur noch das WAN über lässt)
Interface = .... du errätst es schon ... DMZ :)

Ping/Verbindung nicht möglich -> sollte durch die block any default Einstellung bereits gegeben sein, denn alles was nicht explizit erlaubt ist, wird verboten.

Damit dürfte bspw. momentan (da dus nicht erwähnt hast) bspw. das LAN und WLAN gar nichts (von amadablam und dem Loghost abgesehen) wenn also LAN noch ins Internet (aber nicht ins WLAN) soll, gäbe es hier wieder Sinn für ein Alias, welches das DMZ Netz und WLAN Netz ausschließt und den Rest ins WAN erlaubt (beispielsweise). Dito natürlich für WLAN.

Ich hoffe der Exkurs war einigermaßen verständlich :)

Grüße

eanneser

Hi,

Danke für Deine Erläuterungen. Jetzt habe ich's kapiert (- glaube ich) - Du hast das sehr anschaulich an den Beispielen erläutert. Genau nach einer solchen Anleitung - am Beispiel - habe ich gesucht!

Ich werde Deine Vorschläge (mit den Aliasen) so umsetzen. (Z.T., soweit das von ausserhalb des Büros geht, habe ich das schon gemacht und es klappt).

Jetzt habe ich noch ein weiteres Problem, von dem ich nicht weiss, ob es hierher gehört, aber vielleicht kann mir jemand helfen:

Ich habe in meiner DMZ ein paar Rechner, die von aussen erreichbar sein sollen. Klappt auch soweit, dank Portforwardings.
Unter anderem steht da eine QNAP-NAS in der DMZ (erreichbar über Portforwarding). Soweit - sogut!

Nach einiger Zeit (einige Stunden) ist das Login nicht mehr erreichbar. Weder vom Internet, noch vom LAN aus (Timeout im Browser). Ab diesem Zeitpunkt funktioniert dann auch kein Ping vom LAN aus mehr auf die NAS - und - auch nicht mehr auf einige der anderen IP-Adressen in der DMZ. (Seltsamerweise gibt es einen Rechner, der weiterhin pingbar ist.)
Diese Situation bleibt wieder über eine unbestimmte Zeit (einige Stunden) bestehen - dann funktioniert wieder alles ganz normal.
Wenn ich einen Dauerping aus dem LAN auf irgendeinen der Rechner in der DMZ laufen lasse, geht der normal durch. Irgendwann kann ich mich dann auf der NAS wieder nicht mehr einloggen (der Dauerping bricht weg - Zeitüberschreitung) und solang der Dauerping weiterläuft, kommt bleibt auch alles nicht erreichbar. Mache ich den Dauerping aus und warte (1/2 Stunde) ist alles wieder (vorerst) erreichbar.

Bezug zur pfSense-Firewall: der Ping aus dem Diagnosemenü der pfSense geht die ganze Zeit über völlig problemlos auf alle Rechner in der DMZ (Ausser ich stelle die "Source Address" auf LAN). Die Rechner antworten also, was darauf schliessen lässt, dass es doch mit der Einstellung der Firewall zu tun haben könnte …

Wo soll ich anfangen zu suchen?

ich bin nicht sicher, ob die NAS der wirkliche Auslöser der Probleme ist ...
den Switch zwischen pfSense und DMZ habe ich schon getauscht (kein Effekt)
die pfSense (incl. Backup) schon gebootet
die NAS (und die anderen betroffenen Rechner in der DMZ) auch alle schon gebootet
im FW-Log findet sich nichts, die Zugriffe auf den Umgleiteten Port werden als "passed" angezeigt
könnte das irgendwas mit doppelten IP-Adressen zu tun haben (... ist so ein Gefühl)?

Vielleicht kann mir jemand einen Tipp geben.
Sollte das Alles hier (trotz Bezug zur pfSense - s.o.) OffTopic sein, bitte den Beitrag hier einfach löschen und den Thread auf [gelöst] setzen. (Ich will ja hier nicht nerven und brauche vielleicht wieder mal Hilfe direkt zur pfSense)

Danke auf jeden Fall für die Hilfe (und vielleicht für den Tipp)

Edgar

-flo- 0

könnte das irgendwas mit doppelten IP-Adressen zu tun haben (… ist so ein Gefühl)?

Wo hast Du doppelte IP-Adressen und ggf. warum?

Ich würde erwarten, daß jedes Segment ein eigenes Subnetz hat, so daß alle Adressen "auf Deiner Seite vom WAN" eindeutig sind. Ist das nicht so?

eanneser

@-flo-:

Wo hast Du doppelte IP-Adressen und ggf. warum?

ich habe keine doppelten IP-Adressen vergeben. (Ich hatte aber 'mal in einem anderen Netz ein auch sehr eigenartiges "waberndes" Erreichbarkeitsverhalten und da hatte sich dann - nach sehr langem Suchen - herausgestellt, dass ein Client auf seiner NIC eine zweite IP-Adresse (eben dann eine anderswo verwendete) eingetragen hatte. Deswegen das "Gefühl". In der DMZ gibt's nur ein paar Rechner, alle mit statisch konfigurierten IP-Adressen (ich werde die morgen alle einzeln kontrollieren …).

Ich würde erwarten, daß jedes Segment ein eigenes Subnetz hat, so daß alle Adressen "auf Deiner Seite vom WAN" eindeutig sind. Ist das nicht so?

Ja, so ist es - natürlich. ;)

Gruss
Edgar

JeGr

OK nachdem was du schreibst würde ich auf der LAN Seite mal nachsehen ob IRGENDein Gerät sich nach ner bestimmten Zeit die gleiche IP zieht wie die pfSense auf dem LAN hat. Du schreibst pfSense inkl. Backup -> CARP Cluster?
Wenn Cluster dann zum beschriebenen Zeitpunkt unbedingt mal auf beiden Geräten den CARP Status checken, dass da nicht ggf. beide plötzlich Master sind.

Außerdem nachschauen: Hast du irgendwo -> WAN, DMZ, LAN ggf. noch weitere Geräte, die etwas ähnliches wie CARP sprechen? Cisco VRRP, HSRP oder ein vergleichbares Redundanzprotokoll? Wenn JA:

ACHTUNG: Wenn mehrere Geräte im gleichen Segment (LAN/DMZ/…) Redundanz wie CARP nutzen und die GLEICHE CARP ID haben (VRRP ID, HSRP ID, ...) kannst du genau solche schränken Verbindungsaussetzer haben, denn dann bekommt ggf. der pfSense Cluster Infos von einem anderen Cluster der sich da reindrängelt und plötzlich die Pakate zu sich zieht. Dass ein zwei Rechner nach wie vor funktionieren könnte hier mit ARP zusammenhängen, dass dieser Rechner eben den neuen ARP nicht bekommen hat und noch brav die Pakete an den richtigen Cluster schickt. ID lässt sich sehr einfach prüfen: Einfach mal auf jedem Interface die CARP ID editieren und jedem eine andere neue ID verpassen (irgendwas Mitte 100 oder so, was SEHR unwahrscheinlich wäre).

Also unbedingt auf IP DOPPELUNG, CARP STATUS oder CARP ID checken!

Wir hatte das Problem bei Einführung unseres neuen DC Clusters, dass der Upstream Provider trotz anderer Zusage VRRP ID 1 auf seinen Ciscos verwendet hat und wir die 1 im CARP Cluster (weil ja frei sein sollte). Effekt war abgehender Traffic mit 30-80% loss Rate.

MTR ist hier ein gutes Testtool, da man es über längere Zeit in verschiedene Richtungen laufen lassen kann und somit ein Bild bekommt, auf welchem Weg es genau schiefgeht.

Grüße

eanneser

@JeGr:

OK nachdem was du schreibst würde ich auf der LAN Seite mal nachsehen ob IRGENDein Gerät sich nach ner bestimmten Zeit die gleiche IP zieht wie die pfSense auf dem LAN hat. Du schreibst pfSense inkl. Backup -> CARP Cluster?
Wenn Cluster dann zum beschriebenen Zeitpunkt unbedingt mal auf beiden Geräten den CARP Status checken, dass da nicht ggf. beide plötzlich Master sind.

Ja, Cluster. CARP-Status ist ok.

ACHTUNG: Wenn mehrere Geräte im gleichen Segment (LAN/DMZ/…) Redundanz wie CARP nutzen und die GLEICHE CARP ID haben (VRRP ID, HSRP ID, ...) kannst du genau solche schränken Verbindungsaussetzer haben, denn dann bekommt ggf. der pfSense Cluster Infos von einem anderen Cluster der sich da reindrängelt und plötzlich die Pakate zu sich zieht. Dass ein zwei Rechner nach wie vor funktionieren könnte hier mit ARP zusammenhängen, dass dieser Rechner eben den neuen ARP nicht bekommen hat und noch brav die Pakete an den richtigen Cluster schickt. ID lässt sich sehr einfach prüfen: Einfach mal auf jedem Interface die CARP ID editieren und jedem eine andere neue ID verpassen (irgendwas Mitte 100 oder so, was SEHR unwahrscheinlich wäre).

Also unbedingt auf IP DOPPELUNG, CARP STATUS oder CARP ID checken!

Ich habe den CARPs jeweils eine andere ID verpasst.
(Könnte wirklich sein, dass es damit zu tun hat. Im anderen Netzwerk, das ein Beinchen in meiner DMZ hat, sind ein paar abgefahrene Cisco-Teile verbaut …
Ob es die Ursache war, kann ich nicht mit Bestimmtheit sagen. Ich habe ein paar der Rechner in der DMZ abgesteckt und momentan läuft alles perfekt. Mal sehen, was passiert, wenn einer um den anderen wieder online geht ...)

MTR ist hier ein gutes Testtool, da man es über längere Zeit in verschiedene Richtungen laufen lassen kann und somit ein Bild bekommt, auf welchem Weg es genau schiefgeht.

Danke für den Tipp.

Damit setze den Thread dann auf "gelöst".
Eine Anmerkung noch "for the Records", zum Urspünglichen Thema Firewallregeln:
Man muss sich bewusst machen, dass "WAN net" nicht gleichbedeutend mit "Internet" ist! Das mag trivial sein, mir war es jedenfalls nicht sofort bewusst!

Danke für die Hilfe an Alle

Edgar

JeGr

Hallo Edgar,

Man muss sich bewusst machen, dass "WAN net" nicht gleichbedeutend mit "Internet" ist! Das mag trivial sein, mir war es jedenfalls nicht sofort bewusst!
Stimmt, das ist vielleicht nicht sofort klar, wenn man die Regeln baut da man für sich selbst WAN = Internet assoziiert, aber spätestens wenn man bspw. ein Transfernetz seines Upstream Providers nutzt oder eines braucht, da davor noch ein anderer (Zwangs)Router steht, ist es glaube ich eingängiger, dass damit das dort anliegende Subnetz gemeint ist :)

Wäre schön wenn du uns auf dem Laufenden hältst, ob es die CARP ID oder ggf. eine duplicate IP war.

Grüße
Jens

eanneser

@JeGr:

Wäre schön wenn du uns auf dem Laufenden hältst, ob es die CARP ID oder ggf. eine duplicate IP war.

… mach' ich doch gerne:

Also: ich habe nacheinander alle vorher in der DMZ befindlichen Rechner wieder angeschlossen (natürlich nach gründlicher Überprüfung auf evtl. doppelte IP-Adressen).
Bisher hatte ich keinerlei Ausfälle oder Probleme.

Nachdem ich ausschliesslich die CARP-IDs geändert habe, kann man wohl davon ausgehen, dass wirklich die IDs das Problem waren.
(der Admin, der für die Beinchen des "fremden" Netzwerkes in unserer DMZ verantwortlich ist, kann dazu nur sagen, dass sein Dienstleister, der die FW für ihn wartet "irgendwas mit failover" auf einer Cisco-Maschine macht ...)

Grüsse (- und bis zum nächsten Mal)

Edgar

JeGr

(der Admin, der für die Beinchen des "fremden" Netzwerkes in unserer DMZ verantwortlich ist, kann dazu nur sagen, dass sein Dienstleister, der die FW für ihn wartet "irgendwas mit failover" auf einer Cisco-Maschine macht …)

Auweia, sowas von einem "Admin-Kollegen" lesen zu müssen, ist schon gemein - als Admin sollte man wissen, was in seinem Netz los ist ;) Aber schön, dass das Problem tatsächlich so leicht zu finden war. Und IMF (irgendwas mit Failover) bei Cisco heißt im Normalfall mind. HSRP oder sogar VRRP. Dann ist es kein Wunder.

Grüße