OPNsense Forum
International Forums => German - Deutsch => Topic started by: FirstSoul on June 03, 2018, 01:37:33 pm
-
Moin.
Ich habe da ein Problem.
Meine OPNsense ist eine VM auf einem ESX mit 4 Netzwerkkarten (WAN, LAN, DMZ, Kids LAN), Diese sind per VLAN auf einem Netgear Switch getrennt. Das funktioniert auch.
Nun habe ich die Interfaces entsprechend eingerichtet mit eigenem Netz und eigenem DHCP Server.
Das funktioniert auch soweit...
Nun will ich aber, dass die Netze sich untereinander nicht sehen/finden, aber auch ins Internet. Und nun hört mein Verständis auf. (Ich komme aus der Sophos UTM welt und da war es... sagen wir... einfacher).
Bespiel:
Ich kann ein Gerät von der DMZ im LAN anpingen und umgekehrt. Aber das will ich verhindern. Ist ja logisch ;-)
Ich habe ein Alias erstellt indem alle Netze drin sind:
https://cloud.froechtenicht.de/index.php/s/EgdJjgYMMjekWJF
Nun habe ich auf jedem Interface folgende FW Regeln:
LAN:
https://cloud.froechtenicht.de/index.php/s/Daq4PxLqrqdWSzs
DMZ:
https://cloud.froechtenicht.de/index.php/s/yj4mB5et5SRQJ6W
Kids (nicht wundern, hier noch kein Internet, da noch der WebProxy kommt):
https://cloud.froechtenicht.de/index.php/s/X34Hr9czdiYWfW9
Hier noch ein Bild vom Ping Test:
https://cloud.froechtenicht.de/index.php/s/Y54BfHr6Z874qBY
Habt ihr eine Idee? Ich verzweifel langsam...
-
Hi,
der Fehler liegt in den FW Regeln.
Du hast als erstes eine Allow Regel mit Destination alles ausser die lokalen Subnetze (!Local subnets). Das erlaubt den Clients den Zugriff auf das Internet.
Danach folgt eine Allow Regel mit Destination Any. Das erlaubt dann den Traffic zwischen den Subnetzen.
Entweder richtest Du explizit eine Deny-Regel für die Kommunikation von einem Subnetz zu den anderen ein, oder Du löscht einfach die letzte Regel. Dann zieht die Default-Deny Regel.
Alternativ kannst Du auch die erste Regel löschen und bei der zweiten Regel das WAN Gateway angeben. Dann wird nur der Traffic über das Gateway erlaubt.
Generell würde ich die Regeln etwas detaillierter konfigurieren, und so wenig wie möglich "Any" verwenden.
Ich habe z.B. einen Alias mit allen privaten IP Adressen (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) eingerichtet, und setze den in Regel für die Kommunikation in Richtung Internet als invertierte Destination (sprich alles außer den Netzen). Zusätzlich habe ich für jeden benötigten Dienst eine eigene Regel bzw. in einem Alias zusammen gefasst, und gebe noch die WAN Gateway Adresse mit:
Gruß
Jas
-
Hi,
danke für die Tipps.
Entweder richtest Du explizit eine Deny-Regel für die Kommunikation von einem Subnetz zu den anderen ein
Habe ich gemacht. Geht nicht.
oder Du löscht einfach die letzte Regel. Dann zieht die Default-Deny Regel.
geht nicht.
Generell würde ich die Regeln etwas detaillierter konfigurieren, und so wenig wie möglich "Any" verwenden
Da es für einen Privathaushalt ist und keine Bank... Brauch ich das nicht. Ist mir zu aufwendig.
Irgendwie verstehe ich gerade nichts mehr...
Hat noch jemand eine Idee?
Das Diagnostic Tool von der OPNsense (also Ping) scheint alles durch zu jagen. In der Log wird alles geblockt, aber der Ping geht durch in dem Tool...
-
Kannst Du mal einen Screenshot vom kompletten Regelwerk inkl. der Deny-Regel machen?
Der Ping geht durch und wird zeitgleich in den Firewall-Logs als "Blocked" gekennzeichnet?
Hast Du evtl. eine Flow-Regel angelegt, die noch auf allen Interfaces liegt und auf Allow steht?
-
Du meinst einen Screenshot, wenn ich die Regel öffne?
Bleiben wir beim Beispiel LAN und DMZ.
https://cloud.froechtenicht.de/index.php/s/wLEbLTEzNQ4irmA
https://cloud.froechtenicht.de/index.php/s/2do6a22xEbjpWdb
https://cloud.froechtenicht.de/index.php/s/gSDTmstAwf28LGG
https://cloud.froechtenicht.de/index.php/s/wdADza6TgB6KFj4
Ist die Rule Order so korrekt?
Es wird nichts geloggt... Egal welche Richtung.
Floating ist leer und NetFlow ist aus.
-
Du hast auf dem LAN Interface eine Regel, die der Source "LAN_net" alle Services zu allen Destinations erlaubt.
Die Regel matcht sobald Du von einem LAN Client z.B. einen Host in der DMZ anpingst. Danach wird die Regelverarbeitung abgebrochen, d.h. die Deny-Regel auf dem Interface "DMZ" kommt gar nicht mehr zum Einsatz.
Generell blockt man den Traffic da wo er entsteht. Wenn Du mit der Deny-Regel arbeiten willst, müsste die also auf dem LAN-Interface liegen. Und dann auch vor der Allow-Regel.
Aber eigentlich ist das gar nicht notwendig, denn die Default-Deny-Regel blockt den Verkehr zwischen den verschiedenen Subnetzen wenn dieser nicht durch eine vorherige Regel erlaubt wird.
Um den LAN Clients den Zugriff auf das Internet zu erlauben, und den Zugriff auf die DMZ zu verbieten müsste die Regel auf dem LAN Interface m. E. wie folgt aussehen:
Interface: LAN
Action: Allow
Source: LAN_net
Destination: !Local_Subnets
Weitere Regeln sind auf dem LAN Interface nicht notwendig. Deny-Regeln für Kommunikation vom LAN_net zur DMZ auf dem DMZ Interface kannst Du löschen.
EDIT: Ich hatte vorher auch die Sophos UTM, und das man bei der OPNsense Regel pro Interface anlegen kann war für mich auch gewöhnungsbedürftig. Ist aber eine coole Sache wenn man es einmal verstanden hat :)
-
Danke für deine Mühe!. So Grundsätzlich habe ich das alles schon verstanden...
Aber es klappt nicht. So langsam habe ich das gefühl, dass etwas "kaputt" ist...
Egal wie und was ich einstelle. Keine Änderung.
So sieht es jetzt aus:
https://cloud.froechtenicht.de/index.php/s/j7WjFsMgtDzjfDP
https://cloud.froechtenicht.de/index.php/s/HDRzy4oGGigdBRB
https://cloud.froechtenicht.de/index.php/s/cyMnyoHEkXax3ra
https://cloud.froechtenicht.de/index.php/s/JsoF2Nd3nJRszrc
Ich starte die Kiste mal neu... Glaube aber nicht, dass es daran liegt.
Aktuell kann ich nur mit dem internen Pingtool von der OPNsense testen... Ich habe aktuell keinen Client in der DMZ. Ich mach hier gerade alles per VPN aus dem Hotel :-D
-
Sieht eigentlich alles gut aus. Ich überlege gerade ob es eine Option gibt, die die Firewall Interfaces generell erlaubt, egal welche Regeln sonst existieren.
Was ist denn, wenn Du alle Regeln deaktivierst? Kommst Du dann noch raus ins Internet?
-
Also wir können nun defintiv sagen, dass das Pingtool von der Sense nichts taugt.
Meine Freundin ist von der Nachtschicht gekommen und es geht nichts. Kein Internet keine Hue Steuerung nichts.
Also funktionieren die Regeln wie oben in meinen Screenshots... aber es geht nichts raus.
Habe jetzt auf dem LAN Interface nur die eine Regel "Default allow LAN to any rule" wieder aktiv, damit es läuft...
-
Im Regelwerk ist standardmässig eine "let out anything from firewall host itself" Regel drin.
Du kannst die effektive Regeltabelle unter "Firewall -> Diagnostics -> pfTop -> View Type: Label" ansehen.
Ein weiteres Goodie wenn du von Sophos UTM kommst:
Wenn du etwas an den Regeln änderst gilt dies immer nur für NEUE Verbindungen (auf der UTM ist es dasselbe).
Du hast aber im Gegensatz zur UTM die Möglichkeit die bestehende Verbindung manuell zu trennen! Gehe dazu auf "Firewall -> Diagnostics -> States Dump". Dort findest du dann die offene Verbindung und kannst sie killen. Sehr praktisch wenn man am Regelwerk bauen und testen ist.
-
Im Regelwerk ist standardmässig eine "let out anything from firewall host itself" Regel drin.
Du kannst die effektive Regeltabelle unter "Firewall -> Diagnostics -> pfTop -> View Type: Label" ansehen.
...
Yep, das meinte ich. Danke.
Also wir können nun defintiv sagen, dass das Pingtool von der Sense nichts taugt.
...
Mit der o.g. Option sollte der Ping auch nicht mehr funktionieren.
...
Meine Freundin ist von der Nachtschicht gekommen und es geht nichts. Kein Internet keine Hue Steuerung nichts.
Also funktionieren die Regeln wie oben in meinen Screenshots... aber es geht nichts raus.
Habe jetzt auf dem LAN Interface nur die eine Regel "Default allow LAN to any rule" wieder aktiv, damit es läuft...
Das zeigt das die Regeln ziehen und im Standard alles geblockt wird. M.E. ist alles gut. Das Problem liegt im Regelwerk.
-
> Also wir können nun defintiv sagen, dass das Pingtool von der Sense nichts taugt.
Vielleicht verstehst du auch nicht, was es tut? Es pingt eben VON der Sense nach irgendwo hin und legt dabei als Quelle das Interface an, was dem Ziel am nächsten ist. Pingst du von der Sense ins Internet, geht der Ping VOM WAN aus weg, außer du stellst explizit das LAN als Quelle ein. Man muss auch genau verstehen, was man misst/testet. Nicht das Tool ist kaputt, sondern der Test. :)
Am Einfachsten ist die Regelverarbeitung, wenn man auf Kniffe wie "!<alias>" verzichtet, denn das kann an anderen Stellen wieder seltsame Nebeneffekte haben. Im Prinzip ist es recht einfach, wenn man nur möchte, dass jedes lokale Netz, dass an der Sense anliegt ins Internet kommt:
1) Alias erstellen mit allen lokalen Netzen: exemplarisch 10.0.1.x, 10.0.2.x, 10.0.3.x (LAN1-3)
2) Auf jedem LAN1-3 Interface:
2a) erlaube ggf. hier dediziert noch Traffic von LANx nach LANy von gewissen Hosts/IPs oder generell
2b) erlaube vom LANx_net auf LANx_adresse Dienste wie DNS & NTP
2c) blocke Zugriff von LANx_net auf Destination "lokaleNetze"
3) erlaube alles (da vorher die anderen lokalen Netze geblockt wurden, ist "alles" jetzt quasi nur noch das Internet)
Das macht es einfacher und man kann auch mal testweise Regeln disablen um zu sehen was nicht läuft. Ggf. aber States clearen nicht vergessen, sonst wundert man sich warum etwas noch geht, was eigentlich verboten sein sollte.
-
"Am Einfachsten ist die Regelverarbeitung, wenn man auf Kniffe wie "!<alias>" verzichtet, denn das kann an anderen Stellen wieder seltsame Nebeneffekte haben. "
Also zumindest bei der pfsense stirbt mir regelmäßig auf einer Installation die Auflösung der Aliases, mal nach 24 h, mal nach 2-3 Wochen und dann werden Regeln mit Aliases zu einem großen Problem. Nur als Hinweis... Warum die Aliases nicht mehr aufgelöst werden? Keine Ahnung! Irgendwann hatte ich mir mal einen Fehlerbericht dazu gegoogelt, war schon etwas älter und hatte sich nichts getan.
Die Aliases werden auch nicht mit TLS DNS aufgelöst (habe ich im Resolver konfiguriert), solange man unter "General" DNS Server gesetzt hat (Habe ich letzthin mit Wireshark auf dem WAN Interface gefunden).
-
@chemlud: keine Ahnung was das jetzt genau mit dem anderen Thema zu tun hat, dass du zum einen Probleme mit pfSense und zum anderen mit Aliasen hast. Vielleicht mal meinen ganzen Satz lesen, der bezog sich auf das ! (also NOT) und Nutzung von !<IP> oder !<ALIAS>. Das hat jetzt schon mehrfach zu konfusen Regeln und seltsamen Seiteneffekten geführt, weil Regeln anders gegolten haben bzw. andere Inhalte hatte, als derjenige, der es konfigurierte erwartet hat.
Deshalb war mein Ratschlag, kein NOT(!) zu nutzen, sondern es plain & simple top down mit erlaube/blocke/erlaube zu regeln, dann ist die Reihenfolge klar und man wundert sich nicht, warum manches plötzlich trotzdem geht, was man nicht erwartet hat.
Edit: letzten Absatz gelöscht
-
> Also wir können nun defintiv sagen, dass das Pingtool von der Sense nichts taugt.
Vielleicht verstehst du auch nicht, was es tut? Es pingt eben VON der Sense nach irgendwo hin und legt dabei als Quelle das Interface an, was dem Ziel am nächsten ist. Pingst du von der Sense ins Internet, geht der Ping VOM WAN aus weg, außer du stellst explizit das LAN als Quelle ein. Man muss auch genau verstehen, was man misst/testet. Nicht das Tool ist kaputt, sondern der Test. :)
Das will ich nicht ausschließen. Aber wenn ich bei "Source" DMZ angebe, dann gehe ich davon aus, dass der Ping in das LAN nicht funktioniert.
Ich nehme nun eine VM in der DMZ und ein Gerät im LAN zum testen... Dann kann ich sicher sein, dass es geht oder eben nicht.
Am Einfachsten ist die Regelverarbeitung, wenn man auf Kniffe wie "!<alias>" verzichtet, denn das kann an anderen Stellen wieder seltsame Nebeneffekte haben.
Und die Alternative? Alles einzeln Freigeben? Nein, danke. Ich bin keine Bank...
Im Prinzip ist es recht einfach, wenn man nur möchte, dass jedes lokale Netz, dass an der Sense anliegt ins Internet kommt:
1) Alias erstellen mit allen lokalen Netzen: exemplarisch 10.0.1.x, 10.0.2.x, 10.0.3.x (LAN1-3)
2) Auf jedem LAN1-3 Interface:
2a) erlaube ggf. hier dediziert noch Traffic von LANx nach LANy von gewissen Hosts/IPs oder generell
2b) erlaube vom LANx_net auf LANx_adresse Dienste wie DNS & NTP
2c) blocke Zugriff von LANx_net auf Destination "lokaleNetze"
3) erlaube alles (da vorher die anderen lokalen Netze geblockt wurden, ist "alles" jetzt quasi nur noch das Internet)
Das macht es einfacher und man kann auch mal testweise Regeln disablen um zu sehen was nicht läuft. Ggf. aber States clearen nicht vergessen, sonst wundert man sich warum etwas noch geht, was eigentlich verboten sein sollte.
Nun. Danke! Das habe ich nun getestet und...
es geht.
Regeln erstellt und dann einen Reset State ausgeführt. Nun kann ich keine Geräte in andere Netze mehr anpingen und komme trotzdem ins internet. Ich bekomme in der Live Log zwar Blocks von glaube ich meinem Amazon Echo angezeigt, der per 443 nach außen will. Das wird von der Default Deny Rule geblockt. Warum? Keine Ahnung.
Danke an alle für die Hilfe. Jetzt klappt es wie gewünscht.
Die Regel sieht nun auf jedem Interface so aus:
https://cloud.froechtenicht.de/index.php/s/JTmmkYXpXa98Gk2
In dem Alias "StandardServices" ist nun DNS, NTP, DHCP drin.
(bis auf OpenVPN, dass ist nur bei LAN).
Soweit okay? Was vergessen, besonders bei den StandardServices?
Danke!
-
Schön das es jetzt geht. Verstehe aber immer noch nicht warum die von mir vorgeschlagenen Regeln nicht funzten.
...
Am Einfachsten ist die Regelverarbeitung, wenn man auf Kniffe wie "!<alias>" verzichtet, denn das kann an anderen Stellen wieder seltsame Nebeneffekte haben.
...
Ich nutze für alle meine Regeln, die Zugriff auf Dienste im Internet erlauben sollen, als Destination !LAN_Netze. Damit möchte ich einfach sicherstellen, dass eine Regel nicht doch den Zugriff in ein anderes LAN Subnetz ermöglicht, weil sie an einer falschen Stelle der Reihenfolge steht. Ab einer gewissen Anzahl von Regeln wird es (zumindestens für mich) leicht unübersichtlich.
Aber beides funktioniert, man spart sich nur die ein oder andere Regel.
-
Vielleicht war es der State Reset. Wobai ich ja die Firewall auch mal komplett neugestartet habe.
Kann mir jemand das nochmal in einfachen Worten erklären, wie die Firewall arbeitet?
oder denke ich richtig:
Am Beispiel LAN (mein Screenshot):
1. Alles wird gesperrt
2. Mein Management Port wird freigegeben
3. OpenVPN wird freigegen
4. Standard Ports werden freigeben (damit allgemein Netzwerkfunktionen laufen)
5. Alles von LAN Netz in ALLE Subnetze (weil im Alias ja auch das LAN Netz drin ist) wird geblockt
6. Alles wird freigeben
Für mich ergibt das einfach kein sinn. Laut z.B. Sophos würde die Regel 6 alle vorherigen aufheben.
Kann mir jemand das in einfachen worten erklären. Ich finde im Netz dazu irgendwie nicht.
-
Anhand Deines Screenshots (https://cloud.froechtenicht.de/index.php/s/JTmmkYXpXa98Gk2 (https://cloud.froechtenicht.de/index.php/s/JTmmkYXpXa98Gk2)):
Regel 1: Erlaubt den Zugriff aus allen Netzen auf die Management Oberfläche der OPNsense über die IP des LAN Adapters.
Regel 2: Erlaubt den Zugriff aus dem OpenVPN Netz in alle Subnetze des LANs / hinter dem LAN Adapter
Regel 3: Erlaubt Zugriff aus dem LAN Netz auf Standard Services (DNS, NTP, DHCP) über die IP des LAN Adapters.
Regel 4: Verbietet den Zugriff aus dem LAN Netz in alle anderen lokalen Subnetze
Regel 5: Erlaub den Zugriff aus dem LAN Netz in alle anderen Netze (auch Extern)
Bei einem eingehenden Paket arbeitet die Firewall die Regel nacheinander ab, bis eine Regel passt/matcht. Sobald eine passt werden die nachfolgenden Regeln nicht mehr verarbeitet. Passt keine Regel, wird das Paket durch die Default-Deny-Rule abgelehnt.
Nehmen wir als Beispiel mal eine DNS Anfrage aus Deinem LAN zur OPNsense. Die Regel 1 und 2 passen hier nicht. Das Paket rutscht bis zur Regel 3 durch und hier passt es. Es wird gemäß der Regel die Aktion "Allow" ausgeführt. Fertig. Die nachfolgenden Regeln werden nicht mehr beachtet.
Wenn Du z.B. als Regel 4 eine identische Regel wie Regel 3 nur mit der Aktion "Deny" hättest, würde DNS weiterhin erlaubt da die "Allow" Regel vor der "Deny" Regel steht.
-
> Und die Alternative? Alles einzeln Freigeben? Nein, danke. Ich bin keine Bank...
Sorry das ist quatsch. Ob du jetzt 3 Regeln oder 4 oder 5 machst, macht wohl den Kohl nicht fett. Das hat nichts mit Bank, sondern Übersichtlichkeit zu tun und die Oberfläche macht durch Regel kopieren etc. das jetzt wirklich einfach. Ist ja nicht so, als müsste man die Dinger per Hand tippen wie früher...
> Am Beispiel LAN (mein Screenshot):
Das was @JasMan schreibt. Die erste Regel ist die AntiLockout Regel. Die zweite macht für mich keinen Sinn, denn es wird kaum auf dem LAN Interface Traffic ANkommen, der aus dem OpenVPN Netz kommt. Der kommt auf dem OpenVPN Netz an und geht AUS dem LAN Netz raus. Gefiltert wird aber immer EINgehend, nicht AUSgehend (Ausnahme Floating Regeln, aber das wäre einen Komplexitätsschritt höher und es sollte ja möglichst einfach und übersichtlich bleiben). Der Rest ist wiederum so wie ich es auch schon beschrieben hatte. Erlaube die Dienste die auf dem LAN ankommen müssen, blocke die anderen LAN/lokalen Netze, erlaube den Rest damit das Internet geht :)
Ich denke was dein Problem ist, ist nicht so sehr die Abarbeitung der Regeln, sondern vielmehr die Denkweise, dass du ein- sowie ausgehende Pakete alle händisch filtern musst. Das ist NICHT der Fall:
Gefiltert wird im Normalfall NUR EINgehender Traffic. Sprich: alles was auf Interface X ankommt, nicht was nach Verarbeitung irgendwo wieder rausgeht. Das wird automatisch gemacht. Genauso der entsprechende Antworttraffic. Der wiederum ist durch stateful firewalling eh schon erlaubt.
Einfaches Beispiel: Du hast im LAN ein NAS stehen. Das hat eine Weboberfläche. Die soll erreichbar sein via VPN (OpenVPN) sowie im LAN. LAN->LAN hat nichts mit der Firewall zu tun, da kannst du natürlich immer drauf zugreifen. Wenn du aus den anderen lokalen Netzen (bspw. LAN2 oder DMZ) drauf zugreifen willst, dann muss auf dem Interface, auf dem das Paket AN das NAS zuerst ankommt, die Regel für die Allow Regel ran. Du sitzt in LAN2? Also muss auf LAN2 eine Regel drauf mit "erlaube Paket von Rechner/LAN2 Netz/etc. nach NAS_im_LAN auf Port 80/443". Dass das Paket daraufhin aus dem LAN Interface wieder rauskommt musst du nicht extra erlauben. Das wird implizit angelegt. Ebenso ist durch stateful firewalling aller Antwort-Traffic vom NAS an deinen Rechner in LAN2 ebenso erlaubt.
Aber der Zugriff aufs NAS soll auch per VPN gehen. Also Laptop an, VPN gestartet, eingeloggt. Wo schlägt das Paket dann auf? Auf dem "virtuellen" OVPN Interface. Ergo muss deine Regel aufs OVPN Interface und ähnlich der LAN2 Regel aus obigem Beispiel aufgebaut sein, à la "erlaube TCP Traffic von OVPN_Netz nach NAS_IM_LAN Port 80/443".
Das natürlich nur ein Beispiel, aber vielleicht wird dadurch das wie und warum der Regeln ein wenig klarer. Zudem gilt: Alles was NICHT durch Regeln auf den Interfaces definiert ist, wird am Ende nochmal durch eine block any Regel geblockt. Trifft auf dein Paket also keine der Regeln bspw. auf dem OpenVPN Interface zu - wird das Paket geblockt.
Ansonsten hatte JasMan ja schon beschrieben, dass PF (der Filter) die Regeln top down abarbeitet. Die erste, die zutrifft wird sofort angewendet und die weitere Verarbeitung abgebrochen. Daher kommt es auf Reihenfolge und Scope (also Geltungsbereich) an.
Ich hoffe das macht es etwas klarer :)
-
> Und die Alternative? Alles einzeln Freigeben? Nein, danke. Ich bin keine Bank...
Sorry das ist quatsch. Ob du jetzt 3 Regeln oder 4 oder 5 machst, macht wohl den Kohl nicht fett. Das hat nichts mit Bank, sondern Übersichtlichkeit zu tun und die Oberfläche macht durch Regel kopieren etc. das jetzt wirklich einfach. Ist ja nicht so, als müsste man die Dinger per Hand tippen wie früher...
Okay, hast recht. Meine Denkweise war etwas anders. Aber ich lasse es jetzt so, weil ich schon kommen sehe:
Meine Freundin kauft Gerät X, konfiguriert das und... es geht nicht. Somit kommt es aufjedenfall raus und kann arbeiten. DAs ist mein gedanke dahinter ;-) Aber das ist ja in jedem sein ermessen ;-)
Danke an euch beide für die Erklärung. Nun habe ich es verstanden. Etwas komplizierter, aber geht.
Mit meinen Worten:
Paket kommt an, erste Regel passt nicht, weiter, nächste Regel passt und wird angewendet, nächstes Paket.
Damit kann ich doch arbeiten :-)