Messages

Hey,
I'm having the same issue with OPNsense 18.1.10.

My public IP address is located on an DSL modem, because it don't allow PPPoE passthrough. Therefore the WAN interface of my OPNsense has an privat address within the LAN subnet of the DSL modem.

Every time the WAN address has changed, I need to press the "Test/Update" button to update the address in OpenDNS. A reboot of OPNsense don't update the address as well.

Is this a normal behaviour because the public address is not located to the WAN interface of the OPNsense? If yes, can I cron the update process of the OpenDNS plugin?

Thanks.
Jas Man

Anhand Deines Screenshots (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.

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.

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.

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?

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 :)

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?

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

Eine URL blocken geht m. E. nur mit dem Proxy.

Eine komplette Domain blocken kann man mit der Firewall realisieren. Man legt einen Alias für die entsprechende Domain an und verbindet diesen mit einer Block-Rule in der Firewall. Hinter dem Alias können auch mehrere Domains liegen. Das muss aber manuell gepflegt werden.

Alternativ kann man die Domain auch mit dem DNS Resolver blocken, indem man ein Redirect für z.B. youtube.com anlegt. Das lässt sich aber leicht umgehen wenn der Client auch externe DNS Resolver nutzen darf, oder er die IP anstatt der Domain in die Adresszeile eingibt.

Irgendwie seltsam, ja.
Was heisst denn "Standard FW-IPv4 LAN Regel"?

Wenn Du keine interne und externe Namen auflösen kannst, liegt das Problem vermutlich am DNS.
Ist die DNS Server IP, die per DHCP ausgegeben wird identisch mit der, die Du im Host manuell konfigurierst?
Nutzt Du die korrekte Subnetmask und Gateway wenn Du die IP manuell konfigurierst?
Eine entsprechende Regel für DNS (UDP/53) existiert in der Firewall für die Source "LAN Subnetz bzw. das "LAN Interface net"?
Was siehst Du denn in den Firewall Logs? Wird die DNS Anfrage geblockt oder was anderes?

[es]

Hey Taste,

muss mich erst mal korrigieren, anscheinend habe ich da was falsch getestet.

Also, das Firewall Objekt "LAN Interface net" beinhaltet auch die manuell, nicht vom DHCP vergebenen Adressen. Mit diesem Objekt wird also das komplette Subnet erlaubt wenn man es als Source in einer Firewall Regel einsetzt.

Nun zu Deiner Frage.

...
Also  die Firewall erlaubt den Traffic per se für das "Lan net", was ebenfalls per Default alle IP-Adressen im Lan entspricht. Dann kann ich im DHCP IP-Reservierungen einrichten, die außerhalb der DHCP-Range liegen müssen! Letzteres habe ich für die angesprochenen Clients gemacht. Daher müssten dann diese Clients, die eine IP aus dem "Lan net" haben, auch ins WAN kommen, also nicht von der Firewall geblockt werden, richtig?

Korrekt. Nur erlaubt die Firewall das nicht per se, sondern man muss die Regel dafür einrichten.
So habe ich es auch: Mein LAN hat das Subnetz 192.168.1.0/24. Mein DHCP Bereich liegt von 192.168.1.128 - 254. Für meinen PC habe ich die IP 192.168.1.15 per Static DHCP Lease reserviert, also ausserhalb des DHCP Bereichs.
In der Firewall auf dem LAN Interface habe ich eine Regel eingerichtet, die der Source "LAN Interface net" den Service 80/443 mit Destination Extern erlaubt. Zusätzlich die gleiche Regel für DNS. Das funktioniert einwandfrei.

...
Ich habe testweise mal auf "Lan Adresses" mit der any Einstellung umkonfiguriert. Nach ein paar Sekunden, kam ich dann gar nicht mehr ins WAN ... ?!
Ich bin irritiert, über die Logik

"LAN Interface Adresses" gibt es nicht. Meinst Du vielleicht "LAN Interface Adress"? Das ist das Objekt für die IP Adresse des LAN Interface der OPNsense. Bei mir wäre das z.B. die 192.168.1.1. Damit erlaubst Du nur diese eine IP. Alle anderen aus dem Subnetz fallen nicht da drunter und werden dann geblockt. Entspricht also Deiner Beobachtung.

Gruß
Jas

Hi,
sorry, hast Recht. Du schriebst ja dass die Firewall auf Grund des DHCP Eintrages "reagiert". Richtig, hat somit nichts mit dem DNS direkt zu tun.
...

Entschuldigungen sind unnötig. So ein Forum ist ja zum Fragen stellen und helfen da :)

...
Ich kenne die optimale Konfiguration noch so, dass man z.B. die Clients per DHCP Range konfiguriert z.B. .100-.200 und den Servern direkt die IP im System vergibt. Dadurch kann bei einem Fehler / Ausfall des DHCP der Server seine IP nicht verlieren, was wesentlich wichtiger ist als ein Client. Klar kann man auch verschiedene Ranges im DHCP vergeben, oder alle in einem Netz per DHCP versorgen und wichtige per Reservierung fest vergeben, aber das ist irgenwie noch so im Kopf. Mag sein dass es so nicht mehr aktuell ist bzw. korrekt, aber daher sprechen wir ja mal drüber .)

So kenne ich das auch und so machen wir das auch in der Firma, in der ich arbeite.

Wenn Du das so umsetzen möchtest, kannst Du einen Alias im OPNsense mit den manuell vergebenen IPs anlegen. Falls Du einen IP Bereich für die manuell vergeben IPs reserviert hast, kannst Du anstatt jede einzelne IP auch den Bereich im Alias eintragen. Das erspart Dir Pflegeaufwand falls ein weiterer Server hinzu kommt. Die Firewall-Regel für den entsprechenden Dienst kannst Du von der Regel für die DHCP Clients kopieren, und änderst nur die Source von "LAN Interface net" auf den Alias ab.
Oder, wie schon oben beschrieben, Du erlaubst direkt das komplette Subnetz anstatt des Objekt "LAN Interface net" in der bereits bestehenden Regel. Dann lässt die Firewall alle Clients aus dem Subnetz raus. Spart ebenfalls Pflegeaufwand und hält die Anzahl der Regeln klein. Aber aus Security Sicht nicht so gut, da die Firewall somit jede IP aus dem Subnetz durchlässt.

Der Eintrag im DNS hat doch nix mit der Firewall zu tun. Das ermöglicht nur, dass die reservierten IPs immer per DNS aufgelöst werden können, auch wenn der Client offline ist. Bei einem normalem, dynamischen Lease wird der DNS Eintrag verschwinden sobald der Client offline und der Lease abgelaufen ist.

Ich finde Deine Konfiguration mit der manuell eingetragenen IP und der zusätlichen DHCP Reservierung auch etwas ungewöhnlich. Was willst Du damit bezwecken? Das die Clients auch bei ausgeschalteter OPNsense kommunizieren können? Dann kannst Du unter Windows die "Alternative Konfiguration" verwenden. Die zieht nur wenn der Client keine DHCP IP bekommt.

Das die OPNsense sich so verhält wusste ich auch noch nicht. Bin erst durch Deinen Post auf dieses Verhalten gestoßen :)

Hi Taste,

ich verstehe das jetzt so:

"...mit statischer IP im System konfiguriert..."

Du hast eine IP manuell auf Betriebssystemebene auf dem Client eingetragen. Sprich der Client oder Server arbeitet nicht als DHCP Client.

"eine Reservierung im DHCP eingerichtet"

Und Du hast zusätzlich eine Reservierung im ubound eingerichtet.

Wenn der DHCP Lease nicht aktiv ist, d.h. nicht aktiv von ubound ausgegeben wurde, wird die Firewall diese IP auch blocken, solange Du das "LAN interface net" als Source in den Firewall Regeln verwendest.

Wenn ich Deinen Aufbau richtig verstanden habe, musst Du eigentlich nur die Clients/Server auf DHCP umstellen und dann sollte alles gehen.
Gruß
Jas

Hi Taste,

wenn Du deine Clients mit statischen IPs versorgt hast, also diese manuell auf Betriebssystemebene einträgst, ordnet die Firewall diese Clients nicht dem vordefiniertem Firewall Objekt "LAN Interface net" (oder wie auch immer dein LAN Interface heißt) zu.
D.h. in den Firewall Regeln darfst Du als Source nicht das Objekt "LAN interface net" nehmen, sondern mußt manuell das Subnetz über "Single host or network" angeben (z.B. 192.168.1.0/24). Dann dürfen allerdings direkt alle IPs des Subnetz ins WAN.

Alternativ kannst Du im DHCP Reservierungen für die Clients mit statischer IP anlegen. So mache ich das und das ist auch Best-Practise, behaupte ich mal.
Vorteil: Ändert sich z.B. der DNS Server bei Dir im Netz, braucht Du das nur im DHCP der Firewall anzupassen und alle Clients bekommen das über DHCP mitgeteilt.
Bei statischen Einträgen auf dem System müsstest Du die DNS Adresse auf jedem System manuell anpassen.
Gruß
Jas

EDIT: Stimmt so nicht -> Siehe weiter unten!