[SOLVED] - Mysteriöses Routing
-
Hallo,
dein erstes Problem lässt sich durch die pass any to any Regel am LAN erklären. Ein Gerät im LAN darf damit überall hin.
@blubb1992:
2. Ich komme per RDP von der 10.10.5.2 auf die 10.10.2.2 und .3 aber nicht umgekehrt
Das lässt sich auch mit der Standardregel am LAN erklären.
@blubb1992:
2. Ich komme per RDP von der 10.10.5.2 auf die 10.10.2.2 und .3 aber nicht umgekehrt
Das lässt sich auch mit der Standardregel am LAN und den fehlenden Regeln an den anderen Interfaces erklären.
@blubb1992:
2.und von der 10.10.5.2 auch nicht in das 10.10.4.0-Netz
Die Firewall am Zielhost erlaubt das?
Routen sind nicht nötig, um zwischen den an den Interfaces konfigurierten Netzen zu routen.
-
Hi,
danke für Deine schnelle Antwort. Jedes der internen Interfaces hat die Regel, die wie auf dem Screen (das ist das .4-er-Netz) aussieht. Die Quelle ist natürlich angepasst auf die Bezeichnung des jeweiligen Interfaces.
Du hast recht, dass das Problem, dass ich die Interface erreiche, dann behoben ist.
Wie sieht denn dann eine normale Regel aus, die erlaubt, dass Traffic über ein Interface zum WAN darf? Wenn ich WAN net dort als Ziel eingebe, klappt das nicht.
Danke für Deine Hilfe
VG
Blubb1992
-
WAN net ist nur das Subnetz, das am WAN Interface konfiguriert ist. Damit kommst du also nicht weit, im Gegenteil, damit erlaubst du u.U. Zugriff, den du vielleicht gar nicht haben möchtest.
Meine Praxis, um Zugriff auf interne Netze zu beschränken, ist, mir einen Alias für alle RFC 1918 Nezte anzulegen (Firewall > Aliases > IP). Das ist dann auch noch fest, wenn du zusätzliche interne Netze einrichtest oder welche änderst.
Wie du am Besten die Regeln erstellst, hängt davon ab, wie viele Regeln du planst. Sollen es viele sein, erstellst du am Besten ein Block-Regel mit dem RFC1918 Alias als Ziel und setzt diese ganz oben auf die Regelliste.
Sind deine Regeln überschaubar, kannst du deine vorhandenen Regel editieren und bei Destination "invert" anhaken und den RFC1918 Alias einsetzen. Das bedeutet dann, du erlaubst alles überall hin ausgenommen der RFC1918 Nezte. -
Hi,
HAMMER!
Sind deine Regeln überschaubar, kannst du deine vorhandenen Regel editieren und bei Destination "invert" anhaken und den RFC1918 Alias einsetzen. Das bedeutet dann, du erlaubst alles überall hin ausgenommen der RFC1918 Nezte.
Darauf zu kommen… ::) Einfach die privaten Bereiche negieren... Sehr toller Tipp! Danke dafür :)
Was mir dabei nur nicht in den Kopf will ist, warum er kein DNS mehr macht ??? ??? Ich hab war gesagt, das der Weiterleitungsmodus im DNS Resolver eingestellt ist, aber eigentlich sollte er die DNS-Server erreichen können, da die ja auch nicht unter RFC1918 fallen ??? ::) -> Hast Du hier auch einen Tipp?
Hab es an einem Interface eingerichtet und es hat alle Symptome behoben. Jetzt kann ich da normale Regeln bauen, damit das kontrolliert funktioniert :)
Danke :)
-
Du verwendest demnach das DNS auf der pfSense. Das ist mit dieser Regel dann nicht mehr erlaubt. Dafür musst du eine eigene Regel erstellen.
Ich verwende für diesen Zweck eine Floating Rule (können für mehrere Interfaces aktiviert werden). Bsp. für DNS
Action: pass
Quick: checked
Interface: alle nötigen auswählen
Direction: in
Protocol: TCP/UDP
Source: any
Destination: This firewall
Destination Port Range: 53 -
Hi,
danke das funktioniert. Aber mit ist nicht klar, warum ich die Regel benötige. Am Client ist das Interface als Gateway und DNS eingetragen und dann sollte die pfsense das doch von selbst machen. Warum muss ich den Zugriff darauf freigeben?
Danke und VG
Blubb1992 -
Macht sie aber nicht von selbst. Warum auch immer, man sollte meinen, wenn man in der DNS-Konfig das Interface für eingehende DNS-Anfragen angibt, ist damit auch der Zugriff erlaubt. Ist aber nicht so. Möglicherweise um die DNS Pakete über die FW-Regeln besser und sicherer kontrollieren zu können.
Das einzige, was in neueren Versinen automatisch erlaubt wird, ist der Zugriff auf den DHCP-Dienst. Früher musste auch das explizit per Regel erlaubt werden.
Grüße
-
Hi,
okay, dann ist das so. Wenns nicht funzt, wissen das man das einfach setzen muss. ;D
Ich Danke Dir für Deine Hilfe.
Vg
Blubb1992 -
DHCP geht aber doch nur deshalb (automatisch), weil zu dem Zeitpunkt noch gar keine Adresse vergeben ist - wir spielen hier also irgendwo zwischen Layer 2 und 3, denn der Client macht beim DHCP ja einen Broadcast mit seiner MAC. Somit ist das kein wirkliches Layer 3 Verhalten was im Filter geblockt werden müsste (zumindest IMHO).
Dass alles andere - wie DNS etc. - dann mit einer selbstgebauten "Blocke Alle RFC1918" nicht geht ist ja einleuchtend. Wäre es anders gäbe es zu 99% wieder Stimmen, die das intransparent, unpraktisch oder sonstwie unschön fänden. Insofern finde ich den Ansatz nach wie vor simpel und einleuchtend: Was am Interface NICHT definiert ist (als erlaubt) wird geblockt. Einzige Ausnahme (die aber angezeigt werden) sind die Anti-Lockout Regeln auf dem Default LAN bzw. die Bogon/Private Blocks auf den Interfaces wo sie definiert sind. Finde ich persönlich auch angenehmer so. Ja, muss man beachten wenn man seine Regelsätze auf den Schnittstellen baut, aber so ist es wenigstens transparent :)
Und an der Stelle noch der Hinweis: Nutzt die farblichen Trenner (Seperator) als Beschreibungshilfe und zur Übersicht - ihr freut euch spätestens wenn ihr wieder reinschaut und es besser versteht was ihr da eigentlich gemacht habt. Und nutzt die Descriptions (auch bei Aliases) sinnvoll als "inline Doku". :)
-
Hi,
@blubb1992:Hi,
okay, dann ist das so. Wenns nicht funzt, wissen das man das einfach setzen muss. ;D
Ich Danke Dir für Deine Hilfe.
Vg
Blubb1992Wenn etwas mal nicht geht, solltest du einfach mal in das Firewall Log schauen. Meistens steht dort sehr genau wo das Paket geblockt wird und von welcher Regel. Man muss sich nur was einfuchsen und die Filter Funktion erkunden.
Auch kann es hilfreich sein sich per SSH auf der pfSense einzuloggen und dort in der Shell mit dem Kommando tcpdump zu arbeiten um zu sehen welche Pakete auf welchem Interface auftauchen oder auch nicht.
Gruß blex
